I think I've asked this before on HN but is there a language-independent test format? There are multiple libraries (think date/time manipulation for a good example) where the tests should be the same across all languages, but every library has developed its own test suite.
Having a standard test input/output format would let test definitions be shared between libraries.
> Part of our interview process is a take-home where we ask candidates to build the fastest version of a pipeline they possibly can. People usually use C++ or Julia. All of the fastest answers are in Julia.
It would be fun if you could share a similar pipeline problem to your take-home (I know you can't share what's in your interview). I started off in scientific Python in 2003 and like noodling around with new programming languages, and it's great to have challenges like this to work through. I enjoyed the 1BRC problem in 2024.
The closest publicly available problem I can think of is the 1 billion rows challenge. It's got a bigger dataset, but with somewhat simpler statistics – though the core engineering challenges are very similar.
> Okay, you may want to do "responsive" design, but you have the semantic layout fixed, therefore you try and contort a styling engine into pretending to be a layout engine when in reality it is three stylesheets in a trenchoat.
I need to write this up properly, but one of my bugbears with responsive design is that it became normalised to push the sidebar down below the content on small screens. And if you didn't have a sidebar, to interweave everything in the content no matter what screensize you were viewing on.
What I want is a way to interleave content and asides on small screens, and pull them out into 1+ other regions on larger screens. Reordering the content on larger screens would be the icing on the cake but for now I'll take just doing it.
Using named grid-template-areas stacks the items you move to the sidebar on top of each other, so you only see one of them.
'Good' old floats get most of the way, but put the item in the sidebar exactly where it falls. Plus they're a pain to work with overall: https://codepen.io/pbowyer/pen/jEqdJgP
I know, Everything is one of the few pieces of software I've missed when switching to macOS.
Cardinal seems to be almost as responsive, except that the current search doesn't update when you delete a file that's in it - you have to search again for it to be gone. IIRC Everything auto-refreshes the view.
> Otherwise, there will be far easier solutions at lower scale.
Which solutions do you have in mind?
- VPS with software installed on the host
- VPS(s) with Docker (or similar) running containers built on-host
- Server(s) with Docker Swarm running containers in a registry
- Something Kubernetes like k3s?
In a way there's two problems to solve for small organisations (often 1 server per app, but up to say 3): the server, monitoring it and keeping it up to date, and the app(s) running on each server and deploying and updating them. The app side has more solutions, so I'd rather focus on the server side here.
Like the sibling commenter I strongly dislike the configuration management landscape (with particular dislike of Ansible and maintaining it - my takeaway is never use 3rd party playbooks, always write your own). As often for me these servers are set up, run for a bit and then a new one is set up and the app redeployed to that (easier than an OS upgrade in production) I've gone back to a bash provisioning script, slightly templated config files and copying them into place. It sucks, but not as much as debugging Ansible has.
This is well timed as my wife has lost her educator status, and we've canceled Adobe Creative Cloud this month as we can't stomach the jump from £400 to £800/yr.
Intellij's tab-complete is coming along; it's hit and miss if it will work but for similar edits I'm finding it picks up the pattern quickly and I can tab - tab - tab to make them happen.
I find Cursor's tab completion to be distracting enough with multi-line changes that I just disabled it, while I use IntelliJ's tab completion regularly.
Cursor's tab completion is better, but it doesn't seem to have a concept of not trying to tab complete. IntelliJ is correct half the time for completing the rest of the line and only suggests when it is somewhat confident in its answer.
I agree about the multi-line blocks Cursor proposes. Like it gets the first two lines right and then after that it's nonsense. I'd rather it stuck with a single line change at a time, and let me press enter before it predicts again.
> One of the big advantages people enjoy is the elimination of the network latency between the application server and the DB. With SQLite your DB is right there often directly attached over NVME.
You can install MySQL/PostgreSQL on the application server, connect over a unix socket and get the same benefits as if you'd used SQLite on the application server (no network latency, fast queries). Plus the other benefits that come from using these database servers (Postgres extensions, remote connections, standard tooling etc). I'm guessing more RAM is required on the application server than if you used SQLite but I haven't benchmarked it.
Unix sockets don't actually give you the same benefit. You're still doing IPC which can incur substantial memory subsystem utilization. SQLite is on the same thread/core as whatever is using it.
> And yet some of the most popular OLTP databases in the world today are still highly dependent on a single node architecture.
Which databases? SQLite is the one I can think of, but it's designed for that use-case. Others start as single node but will replicate to other nodes, either as master-slave or master-master.
With the bounds capped by a single writer. Unless you can shard the data and create a distributed database with manual sharding.
But yes. Postgres remains an amazing choice, especially with modern hardware, until you also have the money available to tackle said write throughput issue.
I think the point is that sharding won't really help that much since transactions will happen across all or most shards, and then you have certain accounts that will be more active than others.
Yes, sharding would kill performance under contention, which characterizes many OLTP workloads (e.g. top ten bestseller list on Black Friday, super stocks like NVIDIA, the big 4 banks on a switch, PhonePe/Google Pay on UPI etc)
Having a standard test input/output format would let test definitions be shared between libraries.
reply