oftenwrong

Would a wider road not embolden drivers to increase their speed?

There is something to be said for having some basic data access libraries already in place, even if they are not ideal, so that developers can bang out functionality more quickly. That is the typical selling point of ORMs, isn't it? While there are well-known downsides, you can skip the ORM when it's not a good fit, or later when you realise that it is causing a problem.

Generally, I prefer to create functions for specific queries, rather than for specific "entity" types, and the return type of each query matching the result of the query. This fits with the reality that queries often involve multiple entity types.

My favourite application-later database tool so far is https://www.jooq.org/ because it allows for code generation from the database schema, allowing for type-safe construction of queries. I find this makes it easier to create and maintain queries. It is a relatively unopinionated power tool, with minimal attempts at "automagic" behaviour. I find myself missing jOOQ now that I am not working much with Java.

It's less complicated than you might think. A Java Development Kit (JDK) is a filesystem directory, and includes everything necessary to run a Java program. Most of the mysterious installers and version managers are managing a collection of these JDK directories in some fixed location on disk. You can download a JDK directory (tarball), and use the `java` binary within it directly.

There is also a convention of using the `JAVA_HOME` environment variable to allow tools to locate the correct JDK directory. For example, in a unix shell, add `$JAVA_HOME/bin` to your `PATH`.

A live demo is better for selling. A live demo says "this is real and it works".

I have been struggling with some team members who don't have taste, and amplify that via this sort of uncritical application of AI. The issue for one if them seems to be that they think the AI is perfect. They think: "If it comes up with it, it must be good/correct. If people are not using it for everything, they are wasting time doing something that the AI could do." It's frustrating to work with people like this because they rapidly produce bad results. I find it disrespectful to generate a large design document in one go, probably without even reading it, and then put it up for review, wasting the reviewers' time picking it apart. Someone "with taste" could produce something decent to begin with.

Don't discount the technical innovation required to integrate existing technologies in a novel and useful way. Docker was an "off the shelf" experience unlike any other solution at the time. You could `docker run ...` and have the entire container environment delivered incrementally on demand with almost no setup required. It did have a social factor in that it was easy for people to publish their own images and share them. Docker Hub was provided as a completely free distribution service. The way they made distribution effortless was no doubt a major factor in why it took off.

https://www.youtube.com/watch?v=wW9CAH9nSLs

In many systems it is reasonable not to include a zone. Usually that goes hand-in-hand with the desire to use a more compact representation, such as storing a numerical timestamp with a customary interpretation (usually UTC or TAI). If you must store a string, you may as well include a zone. Using ambiguously-zoned timestamps is an invitation for bugs. I feel your pain.

I think there was an even earlier example of merge trains at Etsy mentioned here: https://pushtrain.club/

This blog post about choosing which commit to test is also relevant and may be of interest: https://sluongng.hashnode.dev/bazel-in-ci-part-1-commit-unde...

EVs still produce air pollution from tyre, brake, and road surface abrasion. There is also new research that indicates resuspension of particles is a major source of roadway-related pollution.

This review is a good jumping-off point for research on the subject if you are interested: https://www.sciencedirect.com/science/article/pii/S096669232...

Storing an IR also means we can create languages beyond the limits of syntactical practicality. Imagine, for example, an entire comment/documentation dimension of the code. Instead of commenting on a line near some code, you could attach comments semantically to an expression, or to a variable, or to any unit of code.

Unison's immutable definitions also enable a bunch of compelling capabilities. No merge conflicts. Incremental everything: build, test, lint, distribution, rendering as formatted text, et cetera. Trivial to apply "hot" updates to running systems.

Protobuf is typically serialised using a TLV-style encoding.

https://protobuf.dev/programming-guides/encoding/

A major value of protobuf is in its ecosystem of tools (codegen, lint, etc); it's not only an encoding. And you don't generally have to build or maintain any of it yourself, since it already exists and has significant industry investment.

Can you explain what you mean in #4, or provide a link for further reading? Throughout the period of my career so far, API design has always been a major part of the job of a developer. Therefore, I assume you mean something else than what I am thinking of. What is emerging now that is different?

Many drivers do let their mind wander. This is especially true of motorway driving; it is easy to enter a state where the mind is only passively engaged in driving.

I do somewhat miss and romanticise my public transport commute in the pre-smartphone era. I had a lot of time to look out the window, read books, listen to music, and think. No internet connection.

There is a PostgreSQL extension that adds support for incremental updates to materialised views: https://github.com/sraoss/pg_ivm

That is also something that I have always wanted... and it seems like we are in good company.

There are some very basic tools that can help with portability, such as https://github.com/milesj/rust-cicd-env , but I agree that there is a lot of proprietary, vendor-specific, valuable functionality available in the average "CI" system that you cannot make effective use of with this approach. Still, it's the approach I generally favor for a number of reasons.

I would say that is a reasonable constraint. As you know, version ranges, and other "dynamic" versions in Maven are inherently incompatible with reproducible builds because they are resolved non-deterministically during the build. The most common approach when reproducibility is required is to resolve dynamic dependency versions in source, which is a strategy shared by tools that use lockfiles.

I agree that Maven would be better with lockfile support. However, as with any proposed evolution of Maven, I can imagine it would be quite hairy to implement in a way that is compatible with other mechanisms.

On the other listead caveats, I would add:

- Output line endings are controllable via line.separator, which Maven honors. Input line endings are an important consideration for reproducibility, but also not truly a problem of Maven's reproducibility.

- JDK version can be enforced with Maven Enforcer and/or toolchains.

Good system design is designing a system that works good.

A boolean is smaller, which is a relevant consideration for some workloads. For example, you may be pre-aggregating a large amount of data to serve a set of analytical queries which do not care about the associated timestamp. The smaller data type is more efficient both in storage and in query execution.

Additionally, there are situations where it is logical to store a boolean. For example, if the boolean denotes an outcome:

    process_executed_at timestamp not null
    process_succeeded boolean not null

>Maven doesn't support reproducibility

I don't think that is true:

https://maven.apache.org/guides/mini/guide-reproducible-buil...

Maven is not Java, though.

To add: if you would like to avoid depending on Maven's dependency mediation behaviour, then a useful tool is Maven Enforcer's dependencyConvergence rule.

https://maven.apache.org/enforcer/enforcer-rules/index.html

I don't think clothing quality has fallen. Quite the opposite. We are able to buy high quality clothing at a very low price. More advanced materials, more consistent construction, better construction, greater selection, etc.

Much of what you can buy today did not even exist 30 years ago. For example, trail running shoes more or less did not exist. Perhaps you could have had a pair custom made, at a high price, with the worse materials available at the time, but today you can them "off the shelf".

Even the many shirts I've received for free are very high quality and have endured years of abuse.

A related aspect that I experienced was that public pools were typically cold enough that my kids did not enjoy them much. Private swimming schools keep their pools quite warm.

The 5A had a serious motherboard defect that caused phones to become unusable. Google had a device replacement program that allowed owners to exchange dead 5As for newer models.

One more similar feature from a different system: PostgreSQL COMMENT

https://www.postgresql.org/docs/17/sql-comment.html

This allows you to attach text to various database objects in PostgreSQL.

I wish PostgreSQL had a feature that was more like structured key-value database object metadata that could be edited.

Another little-known feature is git trailers:

https://alchemists.io/articles/git_trailers

These are key-value structures data that can be included on a commit when it is created. These are used by some systems for attaching metadata. For example, Gerrit uses this for attaching its Change-Id.

Given that this post is meant to explain your perspective at the time, I think it would make sense to explain it at least a little. At the very least, I am curious. What does Al-Ghazali have to say about making decisions that influenced you? I have not read Al-Ghazali yet.

The operators of Maven Central deserve a lot of credit for their good stewardship. Unlike the NPM registry, Maven Central does not permit anyone to unpublish packages. Unlike the NPM registry, Maven Central requires verification of domain or forge account ownership to claim a namespace. These are good practices, and anyone seeking to create a central package registry would do well to at least consider this. Maven Central is currently operated by SonaType, but it has changed hands a few times. This article covers its history: https://www.sonatype.com/blog/the-history-of-maven-central-a...

Additionally, it is standard practice in the Java world, which is more "corporate" or "enterprise-y", for better and for worse, to have organisations operate their own internal package registries / mirrors. Even if you unpublished a major package from Maven Central, many organisations would be completely unaffected because they retain archived copies of all of their dependencies.