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?

That's nice - I'd encourage you to play around with attaching e.g. JMC [1] to the process to better understand why things are as they are.

I tried recreating your DataInputStream + BufferedInputStream (wrote the 1brc data to separate output files, read using your code - I had to guess at ResultObserver implementation though). On my machine it roughly in the same time frame as yours - ~1min.

According to Flight Recorder:

  - ~49% of the time is spent in reading the strings (city names). Almost all of it in the DataInputStream.readUTF/readFully methods.
  - ~5% of the time is spent reading temperature (readShort)
  - ~41% of the time is spent doing hashmap look-ups for computeIfAbsent()
  - About 50GB of memory is allocated - %99.9 of it for Strings (and the wrapped byte[] array in them). This likely causes quite a bit of GC pressure.

Hash-map lookups are not de-serialization, yet the lookup likely affected the benchmarks quite a bit. The rest of the time is mostly spent in reading and allocating strings. I would guess that that is true for some of the other implementations in the original post as well.

[1] https://github.com/openjdk/jmc

edit: better link to JMC

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.

I don't actively use it, unfortunately. The main inspiration was to faster sort inputs into the https://github.com/BurntSushi/fst crate, which I in turn used to try to build a search library.

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

fwiw, works on my machine (linux+ff). No failed requests in inspector.

This got me thinking - the salinity of the water in the bothnian bay is very low (seems to be about 1/10th of ocean water). Wouldn't that effect electrolysis?

This assumes a clear interface. Which assumes that you get the interfaces right - but what's the chance of that if the code needs rewriting?

Most substantial rewrites crosses module boundaries. In micro services changing the module boundary is harder than in a monolith, since it can be done in a single commit/deploy.

Most times you won't need a well-formed (REST) API to start with, and many times you will never need it. Most small projects should start without one and create one when need arises.

Counter-example: https://javalin.io/ uses Servlets, and seems to be doing quite fine without annotations.

Elasticsearch is decent at using non-text criteria provided that they are:

1. In the same document (a document in ES is a JSON object) 2. You have indices for them. ES (and Lucene) supports indices on raw text values and numbers as well.

ES does not do well with relations (joins). You can de-normalize data to deal with that.. but that makes data consistency harder.

An alternative if you want a bit more help with charting, without client side JS, is to use d3-shape (https://github.com/d3/d3-shape) to server-side render SVGs.

It depends - even when you run into an "everything is slow" problem, it might be that it's like 1 endpoint out of 2000 that causes performance issues. In this case, you might need to focus very much on performance for that endpoint, but maybe not for other endpoints. Profilers can help you figure out what code to focus on.

If the majority of code is performance critical, the tradeoffs are of course different.

It is quite common that you only need to optimize very small parts of a program to this level. The rest of the program can be written in more conventional styles.

You could of course FFI into e.g. C for those parts, but that is usually harder to maintain than a few well optimized java classes.

I find this interesting because: 1. It seems like the svelte plugin for intellij has been lagging behind the language server quite a bit 2. As far as I know, Jetbrains have not been very keen on integrating LSP before.

I have kept building on https://blunders.io - a profiling tool for the JVM. Will soon no longer be a side project though, looking forward to spending more time on it!

For what it's worth, this is most likely not a JVM configuration issue and more likely an ES/OpenSearch issue.

I built https://blunders.io, a profiling tool for JVM applications. I think that I have a decent product but I'm not a great salesman :)

One thing I love about Svelte/Sapper is that it can be used for both the server-side rendering and the interactive map. And it doesn't feel like an afterthought - idiomatic usage leads to server-side rendered html with progressive enhancement of JS.