ravloony

Just to consider the opposite viewpoint, I sometimes wonder if it's not better that they do churn in that case. Assuming the sales team is doing their job properly, there are other prospects who may not need that feature, and not ramming the feature in under time constraints will lead to a much better product. Eventually, their feature will be built, and it will have taken the time that it needed, so they'll probably churn back anyway, because the product from the vendor they did get to ram their feature in is probably not very good.

Same here! We should have an e-coffee or something. I'm currently building my second indie project. I would love to compare notes

In my experience, full body sports (krav maga in my case) are the exception here. It's super easy to stay lean if you eat normally and do this kind of thing. My explanation for this is that the body adapts very well to using a single set of muscles because it expects to have to do it for a long time, like when hunting or gathering, but full body means you are fighting for your life. I think this is also why lifting heavy works so well too. (I have no credentials or training in this area, just my own xp, so treat this as wild speculation of course.)

Absolutely. I was leading a team a while ago and I instituted this practice to good effect.

Conversely, I was called by a company that I had built an app for previously. They had not upgraded the framework it was built with (Laravel), and ended up offering me consulting days to jump several versions. The irony is that the job ended up being quick and easy to do.

I also came here to say this. Structured concurrency gets rid of these types of problems.

This is exactly why this thread is full of slightly insecure comments making vague predictions. I'd suggest to most of them to get off HN and back to work, now is the time to make yourself useful!

Ah, but that is not what he wrote. He never claimed the toilet was broken because he was broke, but due to bad organisational skills.

He then used the story to illustrate the fact that such things can become fond memories, and related _that_ fact to poverty.

At least, that is how I understand the text.

anecdote incoming!

In my previous gig, we had a premium website hosting platform, and our incoming clients would usually want their old inbound links to keep working. Over time, this meant a few hundred thousand autogenerated rewrite rules in Nginx. This was causing Nginx to use about 10G of memory, so restarting it, which we had to do every time we added a redirect, was an issue.

I replaced this with a small reverse proxy written in rust that loaded all of the redirects from postgresql into a cuckoo filter. Adding a redirect was an INSERT, followed by a NOTIFY to let the proxy know to add the redirect to the filter.

Putting it all together took about 2 weeks of swearing at the compiler, but it never had an issue in production, and used about 1M of memory, while adding less than 1ms of latency, or about 4ms in case of a filter hit. Cuckoo filters can have false positives, so if a redirect was found, we still had to check in the db table before returning 301.

As far as I know it's still working fine, and I use rust whenever I can.

It seems to me like nix fits all of those criteria.

This is one of the reasons why I chose Purescript for my team's projects. Also it's got a more complete type system, a simpler FFI, and compiles to less javascript.

This is not to say that Elm is bad. O think it's great as a path into FP, and in fact _was_ my path in. But it does limit you in what you can do and learn.

Also, Purescript has this interesting property of being hard to learn (because it is powerful), but dead simple to use (because it compiles to JS). So you only really get stuck on figuring out how to do things in PS, as opposed to how to get PS working, and therefore every time you get unstuck, you have leveled up. So it's hard, but rewarding.

I'm probably off topic by now, but I do think that Purescript in the frontend is a better option for solid application development.

This is actually a very good idea. Time is the one asset we all have. Community service is also a good idea, but it lacks the immediacy of both fines and your suggestion.

I don't subscribe to this at all. I think that the better explanation is that the people who are negotiating with the EU are, almost to a man, convinced EU-philes (for want of a better word). And so they favour the EU position in the negociations, instead of just implementing the will of the people.

I also use Pass. It integrates great with git, so you can store your password database anywhere, and sync on demand with `pass git pull`.

Also by using GPG as an encryption mechanism it allows you to use your gpg-agent so you only have to authenticate when you log in to your computer.

Basically it relies on existing tools to solve existing problems (sync, encryption) and concentrates on the added value: listing, storage and retrieval of passwords.

A greatly useful application of the unix philosophy.

One assumes. I am not sure that that would be the case. I remember when my non-tech friends only had email and maybe MSN and their passwords were not secure in any way, even for the time. There is more awareness now, though, so maybe.