shinzui

What a waste of tokens.

It’s amazing how many of those types of problems are easily avoided or solved with event sourcing and CQRS.

The premise of the article is flawed. I read a lot of code, and that's how I learn and discover new things.

Because TypeIDs are compatible with UUIDv7 and are supported by libraries in many languages.

The author seems to be unaware of TypeID. You can use TypeID and ignore this article.

https://github.com/jetify-com/typeid

Hurl is better than any of those GUIs. You can version your Hurl files and use them for CI/CD.

The best thing about Category Theory is that the computer scientists that understand it create the abstraction, so you don’t have to suffer from five layers of abstract junk written by your coworker.

The title should have been breaking up with Angular. I posit that they would have had a much different experience using react with relay and graphql.

Lens is one of my favorite libraries, but I can understand why optics, in general, is a divisive topic. Like many things in Haskell, you won't appreciate optics without suffering through a steep learning curve.

Optics don't just save you a few keystrokes. Instead, they make tedious code that you would never write trivial. And more importantly, they're composable. So it's impossible to appreciate their effectiveness without using them on a real-world app. For example, I've worked in an app with three layers, each with its record types, and without the lens library, the pain of converting between records would have been insufferable. Instead, most developers would couple the three layers together to avoid the problem, which makes the codebase brittle.

DDD offers a lot of benefits regardless of the programming paradigm. We heavily use DDD in Haskell.

DHH’s preferred architecture is a rails monolith with a single database behind it that you keep scaling vertically. I believe both Hey and Basecamp are still using that architecture.

It's worth noting that Basecamp's architecture relies on vertical scaling, which can get very expensive in the cloud.

DevOps (the term), like Agile, made sense when it was introduced but lost its meaning as the industry evolved.

nix-darwin currently does not support that directly, but there is an open PR to fix that. For my dotfiles, I added the module from the PR with some slight modifications. You can find the code below.

https://github.com/shinzui/dotfiles.nix/blob/master/modules/...

I use nix-darwin to automate that.

Thanks. That's exactly what I meant.

GraphJSON looks nice. Do you mind sharing the clickhouse infrastructure that's powering it?

I got the impression that you're already using FRP for inflex.

A traditional rails structure does not age well. It must be a nightmare for any new hire to understand the domain and boundaries.

Unfortunately, it's extremely rare to find software that exhibits "miryokuteki hinshitsu." The author's examples are not quite right. For example, linear is missing too many core features to be useful for many use cases.

The article premise is completely wrong. Zestimates were never meant to be accurate. In fact, they were deliberately inflated to drive traffic to Zillow.

Yes. Take a look at Pijul. Here is an article explaining the algorithm. https://jneem.github.io/merging/

It depends on your context. Having moved from ECS on AWS to K8s on GCP I found kubernetes simpler despite its vast number of concepts. It has the correct abstractions for a microservice architecture, and it made us write less boilerplate code to manage and deploy services.

The best part of reading technical content is the discussion in the comments – Medium makes that impossible.

The author must not have been to Tokyo because I've never had bad connectivity underground there.

Could you elaborate on the problem with the default AMI?

Four years after launch, it's now clear that the web does not need another useless news publication.

It's hard to beat react right now. I came to react from ember and I regret not adopting react earlier.

A hybrid approach is a better strategy once you have product/market fit. You should build your core domain as a monolith but have auxiliary infrastructure services built as microservices. The hybrid approach has the advantage of safely investing in microservices architecture that would later allow you to refactor your monolith once you truly understand your bounded contexts.

The "Revolutionary App Architecture" looks like a big red flag. Also, that's the first time I've seen a scrum master credited for an open source project.