stepbeek

Yes! The UK has viewed private sector efficiency as axiomatic throughout my life. The New Statesmen has a good article on the systemic impact of such decisions in the current issue: https://magazine.newstatesman.com/2022/09/28/dieter-helm-cap...

> Same for which the roofs. You don't have a white/silver roof on your house? Fuck you.

Why?

Very frustrated by this while messing around with some CSS this morning. I was using the .cover class from every-layout which adds margin to this element making it very obvious that it's there.

My experience has been that word of mouth is by far the best way to win new clients. It's a warm introduction, everyone involved has some social incentives to behave appropriately, and the lead normally has a rough idea of pricing from the person that referred them.

That being said, this isn't advice. It's an admission that being lucky enough to have a few seed clients land in your lap (and taking that opportunity) is the optimal way to start consulting (imo).

Some movies remain popular long after they were released though.

I want the software in cars to be locked down. I don't want to be on the road with a car that's running some hacked together software. That's what makes this so infuriating - the risks involved in switching to an open source version of the software are too severe.

This article doesn't really lay out what - from a customer perspective - would class heroku as a sinking ship? The DevEx is still great, the alternatives are either borderline ridiculous (K8S is a laughably complex beast in comparison), or not fully cooked yet (fly.io, render etc.) I know that it's expensive, but it's nowhere near the price of having an engineer manage cloud infrastructure full-time.

I would love Heroku to have more reasonably priced compute. I'm desperately hoping that genuine competition in this space will pressure Heroku into sorting this. But the frequent refrain recently that Heroku just doesn't match with my experience in recent years. When the alternative PaaS solutions offer a comparable postgres service, then we'll have a genuine competitor. Until then, I'm not sure I really grok the level of disdain for it that's been on HN recently.

I don't think I understand why DDD and PaaS are mutually exclusive. Can you elaborate please?

The grocery store near me has a food bank donation that you can put items in before you exit.

This is the sticking point I've found. The definition of "unit" is different depending on who I talk to.

What kind of libertarianism? Afaik left-libertarianism is in favour of unions. If it's right-libertarianism you're referencing then can you share some of the "economics science" that promotes it?

I’m not sure I understand why kotlin will need to catch up with loom? Blocking kotlin code should benefit immediately.

This has gotten better in the UK. I give blood regularly and the questionnaire now makes a distinction for monogamous homosexual relationships. It doesn’t impact me so I’m not sure if there’s some other hurdle to cross but I thought it was a good sign.

I use miro and figma as examples of products that would be extremely hard to build as a traditional SSR app.

This is a false-dichotomy/straw man. The conversation is about a javascript-heavy approach being overkill. I haven’t seen many arguing for noscript here.

Implementing a form that autosubmits and updates an element takes very little js.

Why? Going to a music festival to see a single act is pretty common and seems analogous to me.

Sure, but we don’t need to be sat next to them. A large e-commerce company can A/B test new models to improve. The success metric is revenue.

For smaller customer bases this is a tricky problem, but I’d argue that automated recommendations don’t work at a small scale anyway so manual curation is king.

What’s C# and .Net really like on Linux now? I know Microsoft says it’s great but I’m once bitten twice shy after trusting that Azure would be good.

I am happy to try different languages but I will never again support a Windows Server over a Linux VM.

Any stateless service can be scaled horizontally. But the fixed cost of running the JVM is higher than the runtimes in other ecosystems (say a rust application as an extreme example). The JVM has had an outrageous amount of effort put into having it scale well for large heaps with high CPU counts.

As the OP points out, GC in java-land isn't worth writing home about on 1vCPU. When you throw a 16GiB heap at it though, with 16vCPUs then you'll unlock some of the really interesting optimizations and garbage collectors that the showcase the JVM in an advantageous light.

So it's not that the JVM can't scale horizontally - that's a matter of system architecture - it's that scaling it as 100 tiny nodes is far less impactful than having 5 large nodes.

I feel like I bump into this a lot in the tech world (especially the highly funded) and I’m not sure what the fallacy is called.

There are existing industries with smart people with a wealth of experience. A tech company comes along and claims superiority by virtue of deductive reasoning. But they pay almost zero heed to the inductive reasoning of the incumbents and have to repeat their mistakes - this time with an app.

I never understood why Uber would win. All it was going to take was an uber-like app that existing companies could pay for and their primary (non-funding) advantage was gone. Otherwise they’re a normal cab company with all that entails.

I would love to know how many members of that team read the book cover-to-cover. I’m consistent surprised by how many developers invoke a particular methodology without having sone the work to understand it.

In particular, I’ve gone through very similar experiences where functional-programming was the silver bullet that secretly no one understood.

I don’t believe that Evans was arguing for pulling every concern in the wider system into a single model (the last third of the book gives techniques for overall system architecture). Different service lines, or products, would surely belong in distinct bounded contexts in DDD.

> keeping the business logic as far in user configuration land as possible

This sounds dreadfully difficult to build and test. The kind of business rules engine that you’re describing is more likely to be overpriced and buggy than a simpler well-modeled set of core domain classes imo.

Not every piece of software should be excel.

I’ve been impressed with the Disney app. They had a rocky start but now it’s excellent. Definitely better than Amazon’s in my experience.

I very much enjoyed this comment - it sounds like it was a great experience. It’s a nerdier kind of beatnik prose.

Perhaps as a result of incorrectly classifying K8S or K8SaaS as a PaaS when it’s very far from it. Heroku offers the same - or better - devex without the operational burden.

> It's a disservice to persuade businesses to use smaller projects that don't have a comparable level of support, or flexibility.

This is why we use Spring. We have confidence that it'll be supported long-term and will continue to have backing from a whole host of companies.

It's slightly different in a large enterprise environment where a service might be fairly straighforward - take in input, spit out output to some data store. But for the kind of work we do - end-to-end webapps - we'd be doing ourt clients a great disservice to sell them on a microframework with our homespun implementations of security, transactions etc. bolted on top.

I found the real challenge to be that it's very difficult - if not impossible - to determine how spring functions simply by reading code and using it. In simpler libraries or frameworks, I normally just read the source to understand how I should be using it. With Spring, I've had to spend a lot of time reading and re-reaading docs to understand what's going on.

I think that this is sometimes a hard shift for developers who otherwise have spent their lives with an ability to puzzle out the constructs that they come across.

> If I change it unsuccessfully, it will break a core part of the system that people are paying for.

This is such an underutilized heuristic. I find phrasing the question as “Should we risk having a detrimental impact on customers for an aesthetic desire?” helps me to either get my head straight or to realize that the refactor has genuine value beyond aesthetics.

That’s very fair - I’ve seen the same thing with confluence. Maybe having slack as a suboptimal knowledge store in these situations beats the alternative?

I've found slack to be a pretty poor tool for knowledge sharing like this in comparison to a more document-driven form of communication. We previously used a wiki-tool for this (I don't think it really matters which one), but in recent years we've used Basecamp for this.

I'm completely sold on decisions being driven by a doc of a few paragraphs with the conversation around it co-located in the comments. It's easy to scroll through a list of such conversations in the message board and read through the context with discussion. In comparison, finding a previous conversation is slack is much more difficult.

Even if I can find the conversation, I think that the chat-focused nature of slack encourages short, loosely worded messages. This is great in the moment but the lack of context a few months on is pretty tough to deal with.