stepbeek

Killer feature for me was transactional schema changes. We use flyway for db migrations which works fine but a failed migration is left in a half completed state in MySQL - Postgres can execute the migration in a transaction that rolls back on failure.

Great write up, but I’m surprised by SvelteKit being described as full stack. It doesn’t seem to offer anything around normal back-end functionality. I’ve normally understood full-stack to refer to a framework like Ruby on Rails.

This made me laugh out loud. Thank you.

> You seem to think masks matter

Do they not?

I’m sorry this has happened to you. I’ve had a chronic sickness for three years now and whenever I’m impacted by it I’m met with polite confusion. “Oh, isn’t that over?”

I can’t imagine what a lifetime would be like.

I switched from Scala because I found the interior to be so good. Calling Java from kotlin is easy, and - unlike Scalia - the inverse is also true.

I’ve converted several projects from Java to kotlin incrementally and it’s been very smooth.

Have you ever tried kotlin? I've found it to be an encoding of best practices from Java with nullability pinned down. Really made me enjoy working in a most OO/procedural language again after fleeing to scala for a few years.

I don't think bitcoin would escape conventional legal definitions of ownership. I wouldn't want to be the one to test it at least.

It’s an amazingly good read. The follow up - The Unicorn Project - wasn’t as good, but definitely worth reading.

> There's a reason why AWS oncalls are infamous whereas Google's are not.

Could market share be a significant factor here?

Given the second principle of devops is amplifying feedback loops, I think a more charitable view could be "the common misunderstanding of DevOps has lead to a terrible dev environment".

Fwiw, I'm fully onboard with you, but really love the core message of books like the phoenix project and don't really want it to be lost because of overzealous use of docker.

I’ve found DDD’s insistence that cross-aggregate aggregation be done through IDs to be helpful here. It makes transitioning to other persistence implementations easier.

I explicitly claim to use a "citadel" archicture [0] when talking about breaking off services for very similar reasons. Having a single microservice split out from a monolith is a totally valid application of microservices, but I've had better results in conversation when I market it properly.

I've found this to go so far as to have "monolith" understood to mean "single instance of a system with state held in memory".

[0] https://m.signalvnoise.com/the-majestic-monolith-can-become-...

Thanks for sharing! This line made me laugh out loud:

"JRuby is known to consume more memory than MRI. You may want to run standard-2x dynos for optimal performance."

I follow the following blogs for front-end.

* https://adactio.com * https://piccalil.li/blog/ * https://stephaniewalter.design/ * https://www.baldurbjarnason.com/

This post has some good pointers: https://www.baldurbjarnason.com/2021/what-do-i-need-to-read-...

I'm not sure what other advice to give. A lot of this was collected over time in response to frustrations I felt around the direction front-end has been moving in (css-in-js, atomic css etc.) and looking for people writing criticisms of it.

I'm in a similar boat to you - I've built non-trivial side projects in other tech stacks, but I'm a JVM developer at heart. I've been conflicted about whether to dig into ruby/rails more to jump ship recently because of the philosophy in the community.

I love kotlin as a language and enjoy working with spring boot but the hype in the JVM community around JSON API + React SPA does make me wonder whether I'm moving away from it philosophically.

I'm particularly excited by Spring Native right now. Having a Spring Boot app startup quickly and use less memory will fit heroku-like PaaS environments perfectly.

This sounds dreadful. I don’t think microservices are with talking about with these basics figured out.

It’s pretty customizable. I’d argue that changing from default colors, fonts and spacing results in a very different aesthetic. With pico, this is easy to do with a handful of css variables - so you don’t even need a pre/post-processor.

I’ve been structuring my styles with CUBE.css (https://cube.fyi) for a few months now and a classless approach fits the composition piece very well.

Example: In a particular context (say the <h3> tag in the <header> of each <section>) I almost always want a default style. On changing that style, I don’t want to modify markup. In future, when adding more pages, I don’t want to remember the particular combination of css classes that I’ve used elsewhere. When a particular face out is different (this <article> is a modal) then I can add meaningful class names to convey intentions.

From a practical perspective, I’ve found it to give me 90% of the UI I want at 10% of the cost.

CSS frameworks are a great tool for getting started, or building something where you have some flexibility in the design, but my experience has been that it's often harder to fight a framework to fit a particular design than it is to just write CSS.

100% agree. I used it for position management software in equities and it fit like a glove. Effectively, we had a stream of transactions coming from upstream that we aggregated into a cache. Being able to replay events, or step through to figure out why something had gone wrong was terrific.

I then tried to apply this to a conventional request-response web service. It did not fit well. Everything was immediately significantly harder with only a marginal gain.

My rule fo thumb now is to use event sourcing when doing otherwise would be difficult. A justification based off of an improvement, rather than one solving an obvious problem, isn't worth the extra effort.

That internal state is a burden on small teams though - you're efectively implementing the persistence layer twice. I'm totally onboard for SPAs as an option when breaking down an organization, or for solving a particular kind of problem.

But they're just not worth the effort for a form-oriented website with a small-medium team behind it. Almost everything about a web-app is harder with an SPA.

The issue is that Linux isn’t running well enough on the apple silicon to be a viable option (yet).

The UK has a progressive income tax system (iirc up to 10k is tax-free, then 20% from 10-50k, then 40% from 50-150k and 45% for everything beyond that). This means that spreading tax liability between capital gains and income tax leads to a lower total tax bill.

You also get to write off business expenses and reclaim VAT (sales tax) as a business, which a normal consumer cannot do.

Your point about remuneration is spot on. But remote work for US clients is possible and I’ve found that they’re happy to pay close to US rates for UK remote.

Not the parent, but I’ve found Sandi Metz conference talks to be an amazing resource for learning more about this message focused approach.

We've been building on top of Spring Boot with nodejs as a part of the build process for front-end assets.

It's not as nice as rails, but we love kotlin so it's hard to give up.

This sounds like it's specific to a particular market (and that market is the USA). My experience has been that being an employee (in the UK) resulted in significantly more taxes than being self-employed. Europeans almost never have comparable healthcare costs to the USA, so that part isn't universally true either.

Perhaps check out https://hotwired.dev/

I’ve found server rendered apps to be the most productive on small teams or solo projects. Hotwired adds some sprinklings of JS that make this approach slicker.

Hence “silly trolling.”

I'm not going to die on that hill, but I will gleefully call an API "RPC-over-HTTP" as a kind of silly trolling when this style of JSON-over-HTTP RESTful is equated with cool.