Hacker News new | past | comments | ask | show | jobs | submit | momania's comments login

CAT Financial Products | Zürich, Switzerland | Full-time | On-site | C#, dotnet, Typescript, Angular, Scala, Looking for needles, Any stack.

Who you are: Full stack, hay stack, whatever stack. You code, so you fear no stack. You see coding as a creative art and a passion. You know it requires discipline, thought, moments of joy and pain, but in the end it will result in something beautiful. Whether it is a simple integration, or a distributed farm of AI-bots, all code is equally important to you and working on all sorts of code is equally enjoyable to you. Experience wise, you are still fresh like young cheese, ready to mature, but no mozzarella. Still mature enough, but no vintage Gouda.

Why we are looking for you: We will keep it short: we have quite some work ahead of us. I mean: quite a lot (not Alot). So the answer is easy: we cannot handle it on our own and can use some help. Your main set of skills revolves around the .NET world, but you are a person of many traits and although you are fluent in C# you do speak a couple of words across the other side of an API. Sprechen Sie TypeScript? Parlez vous python?

What we have to offer: We offer you to be part of an expert team of IT people (yes, you do have to interact with non-developers and even non-IT). We offer you moments to learn, moments to teach, moments to cry and moments to laugh. We offer you our ears, but also expect you to use your voice (remember we mentioned passion?). We are not perfect, but who is? Foremost we offer you an enjoyable, but honest and real, environment to work in.

When should you apply: If you are ready for a new challenge of course, but also ready to commit. Really, do not come job-hopping, we also do not want to employee-hop. Your work comes first, then the reward, as you see profit as a result of your success, not as a measurement of your success.

Who we are: https://catfp.ch Direct contact: recruitment@catfp.ch


As a programmer you need (or actually want) to make use of some of the most acrobatic shortcuts that cross a large portion of the keyboard. Having a smaller keyboard just makes that a lot more comfortable, because you don't need to have hands the size of King Kong to be able to utilise those shortcuts. :-)


Do you have examples of such shortcuts? Apart from CTRL+C/X and CTRL+V I can't think of any useful?


Lots of IDEs have complicated keyboard chords. For IntelliJ, there's Alt+[1..9], Shift+F6, Ctrl+Alt+L, and others on a daily basis. Some of them cross basically the entire keyboard, and it's not convenient to use one hand to do so.


Anything a computer can do can be assigned to a shortcut.


Use vim and the command line. Why would I need anything other than a full-size mechanical clicky keyboard with full travel? My hands rarely stray off the home row.


I assume Apple will just remove it from the US App Store. You are aware that Apple can control the listed apps in the App Store per country?


That's missing the point, though.

The Commerce Department choosing not to go that broad doesn't make it less concerning that they can go that broad.


Added to this, the additional light, especially so close to the front window, reduces your visibility, certainly on pitch dark roads. You'd be amazed how well you can see on a pitch dark road, if all the interior light is switched off (or dimmed to a minimum), with just the running lights. No need for high beams in most cases. Big interior screens make a huge impact on this too.


You don't even need them to be big, even a low budget car's infotainment touchscreen is enough. Mine has adaptive brightness, so it means that at night in a dark road it'll be at lowest brightness, with black/gray, which makes it even less visible. It's still enough to screw with my night-vision when compared to old cars I had without interior lighting save for some very dim reds on important buttons.


And what if I fire 500 concurrent keep-alive's? (Or maybe a bit of overhead). Then the 500 lambda instances will stay alive for a couple of minutes again, but I'm still only charged the 500 calls. Not the Gb/sec the rest of the time the labmda's are alive, right?


How do you ensure that the 500 concurrent keep-alives land on different Lambda functions? I.e. requests 220 and onwards might hit lambda functions which were warmed up by requests 0-219. I just made the above numbers up of course.


That's why I mentioned 'with maybe some overhead'. You can also have the keep-alive handling take a second or 2 extra to complete, to have the lambda blocked for this time, so the burst calls get more spread. It's not going to be a precise solution, but still, paying 2-3 seconds every minute instead of paying the whole minute is still a lot cheaper.


Ok, I quickly did the math for 500 lambdas (1Gb):

Provisioned: 500 * 86400 (sec/day) * 0.000004167 ~= $180

Keep-alive: 500 * 1440 (min/day) * 2 (sec. runtime) * 0.000016667 (100ms price) * 10 ~= $240

Invocation costs on the provisioned ones would be a lot cheaper too cheaper too. Roughly $45 provisioned vs $80 for 50M calls.

So depending on the demands, provisioning can be more performant, and cheaper at the same time.


My bank doesn't even allow password resets like that. If you forget, you can request a new one, but that goes just like the initial setup: you get 2 separate documents per post, one with a new password, and one with a new activation code.


> Some vintage techie posing with an Apple II computer.

Yeah, just some techie. LOL


At least they named the Apple, just in case you didn't know what it was.


Not really a techie; more like a marketing/business strategy guy.


Kinda got the impression that was fairly tongue-in-cheek, lol


"One-time Atari employee" would also fit.


Adding to that: written code has no value, only running code has. The quality of what running code is, or needs to be, depends on the stage of your product and who will be responsible for keeping the code running (either the developer himself or an ops team for instance).


... still cheaper than a Slack subscription.


> consider going old school and rendering your HTML on the server; you might be delighted

One idea I'd wish more sites would consider.


Consider applying for YC's Summer 2025 batch! Applications are open till May 13

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: