antonhag

Congrats! Being able to run a nice company bootstrapped seems amazing.

Turning 10, you might want to stop ditching WordPress for being 15 on your homepage though ;)

   Your customers demand blazing-fast digital products, web standards are evolving at the speed of light, yet you rely on 15-years-old solutions like WordPress that force you to deliver heavy, low-quality user experiences. 

After all, you'll be there in only 5 years!

From the readme:

  VSCode Extension
    1. Open VSCode
    2. Go to Extensions (Ctrl+Shift+X)
    3. Search for "mbake Makefile Formatter"
    4. Click Install

I often reach for jq to understand what unicode is in a string, e.g.:

  [wl-paste|xclip-o|pbpaste] | jq -R --ascii-output

It doesn't provide any per-character explanation, but it is local and I already have jq installed.

AWS has good base building blocks (ALB, EC2, Fargate, RDS, IAM etc). But it takes knowledge to put the pieces together. Thus AWS tries to create services/tools that orchestrate the base blocks (Amplify, Beanstalk) for you, which in my experience always becomes a mess where you don't actually understand what you are running in your cloud setup.

I'd recommend either learning the basic building blocks (these skills also transfers well to other clouds and self hosting) or using a higher level service provider than AWS (Vercel etc) - they do it better than AWS.

For AWS the solution for container deployments (without dealing with VMs) is Fargate, which imo works reasonably well.

+1, but I'm not sure if the "simple is robust" saying is straightforward enough? It opens up to discussion about what "simple" means and how it applies to the system (which apparently is a complex enough question to warrant the attention of the brilliant Rich Hickey).

Maybe "dumb is robust" or "straightforward is robust" capture the sentiment better?

I like the house analogy, but I like to think of it as if the people building the house did not know how it was supposed to look (or function). This is mostly true, since very few developers know exactly how the end result (product/service) should look and function when the start coding.

e.g. "We did not know where to put the piping at the start, so we put it on the outside and now installing a new restroom is sort of tricky."

> I'm currently building a skyscraper on the foundations of a bikeshed.

Not sure if you are joking or not, but I often hear similar things and I believe that it misses the point. What constitutes a good foundation in software is very subjective - and just saying "foundation bad" does not help a non-technical person understand _why_ it is bad.

It's better to point at that one small rock (some ancient perl-script that no-one longer understands) which holds up the entire thing. Which might be fine until someone needs to move that rock. Or something surrounding it.

My bad - I got confused as the original DIS+BIS took ~60s on my machine. I reproducing the Custom 1 implementation locally (before seeing your repo) and it took ~48s on the same machine. JFR (which you honestly can trust most of the time) says that the HashMap lookup now is ~50% of the time and the String constructor call being ~35%.

Aren't the versions that take 10% of the time only reading each city name once, and then doing an array lookup rather than a hashmap lookup?

From the code samples it's hard to tell whether or not this has to do with de-serialization though. It would have been fun to see profiling results for tests such as these.

Hi! Crate author here, happy to see my old project getting mentioned. Let me know if you have any questions!