cryptos

Moving to Linux is not an option for everyone. I like Linux for development, but from time to time I use other software (e.g. graphics software) that is only available for Windows and macOS. Hopefully more commercial software will be available for Linux in the future.

This historic story has even inspired a movie with Michael Douglas: https://en.wikipedia.org/wiki/The_Ghost_and_the_Darkness

Too bad .io became the hipster domain of the day. It was a bad idea to misuse a ccTLD for coolness in the first place ...

I like the idea to pay for quality content - or search results. If you don't pay for it, someone else will and the "sponsor" will probably have different objectives than you. So, you won't get the best information and it would be likely to waste money because of that (e.g. buying an advertised low-quality product).

You speak from my soul! An often underestimated fact is the future growth in features and complexity. Following the CRUD way this might easily end up in a mess, where you can hardly see domain concepts in all the technical code.

I see one obstacle by this transparency approach: How to create a fair measure for "impact"? I would say that it is very hard to measure the actual impact of a senior developer. He gives advice here and there, he influences decisions in a good way, he asks the right questions, he recognizes risks early and so on. All that can hardly be measured.

In what a cave of nerds am I in here?! :-D

The statement that everything boils down to CRUD is not wrong, but also not very useful. Whether you should think of some operation in CRUD terms or not depends on the level of abstraction you are thinking in. Create, Read, Update, and Delete are mostly technical terms that might not have a well defined or understood meaning in a certain domain.

Therefore, I would suggest to use "CRUD" terminology mostly the more technical parts of the application (e.g. some adapter to communicate with a database) and to use business terms (from the "ubiquituos language", as it is called in domain-driven design) otherwise.

I once had a coworker argueing against DDD ideas with the killer argument that it would be only "CRUD". But it was in no way useful to think about the problem in these terms. Later it turned out that we had quite some business logic and that "CRUD" wouldn't have been very helpful to express that.

The interesting question is: What will Sonos change to make sure that such a desaster will not happen again? Besides some software engineering challanges I see a big failure in the approach to user experience design. It looks like hardly any real user was involved, but that is key to UX design.

More businesses should work that way! I especially dislike these catchy 0 €* (or 0 USD) offers from other providers where all the truth is in the *.

I really whish that Hetzner continues to evolve the cloud business, so that more kinds of managed services could be booked.

I don't think that prefixing IDs with some semantic "type" is not such a great idea, because it makes IDs unnecessary long (and inefficient) and because it is basically a mixture of the actual data and a type, but we have typing systems for that. In general it is also not really an advantage. In case of URLs like http://example.com/items/0190b12d-5ed1-72f5-964c-2252afd2da7... "items" is already the "type". To avoid confusion on the server side the value extracted from the path could be put into some object like an ItemId (basically a typed wrapper around a UUID).

What I notice reading some of features is that Markdown is insufficient for that. For example Markdown dosen't support captions or side notes. AsciiDoc would be a much better fit for such cases.

Now we need another round of the language battle, because now this approach needs to be implemented in Rust, Go, Zig, Nim ... you name it!

Luckily there is Kotlin that gives programmers a nicer interface to the JVM.

To make this secure, some secret salt value needs to be added before hashing.

You're right that including the Gradle wrapper is a common good practice for years. But if you have to or want to move to a newer Gradle version than you can enjoy the full randomness of the domain specific language from Gradle itself and from a thousand plug-ins.

What you say about Gradle's instability over a long time is so true. Even code snippets from 3 to 5 five years ago seldom work without some (more or less random) adjustments.

My impression is that inheritance is in many common programming languages the easiest way to share code. Sharing code in another way would require some more thoughts and sometimes code, so the lazy programmer takes inheritance.

Traits as a general concept would be very useful in many programming languages, but only some (like Scala) have proper support for it. In principle a Java interface with default methods (implemented methods) is also something like a trait, but very limited compared to traits in Scala. I have no statistics, but my impression is that inheritance is much less used in Scala, because the language has an easy to use alternative.

Another example is Go, where structs with their associated methods can be embedded, what is exactly composition supported by the language. Since Go doesn't support inheritance, programmers obviously needs to use this approach, so you would never see inheritance in Go programs.

So, my conclusion is that the usage of inheritance depends on what the language supports and how easy it is to use.

Yeah, but that is what makes engineering interesting. You always have to find the right balance with your trade-offs.

First the planes crash, then the company crashes.

Isn't accounting "finance engineering"? :-)

Although I like Kotlin better, I'm really impressed how Oracle continues to improve Java. Some developers think Java is an old, cumbersome language, but it is indeed such a productive language and ecosystem with outstanding quality! Java has quite good support for functional programming, concise and immutable structs (called "records"), pattern matching, string templating, virtual threads, structured concurrency (preview for now), a vast ecosystem with outstanding quality, world class documentation, a fast and robust runtime and so on.

Even after nearly 30 years, Java is still a good choice to start something new (e.g. a startup).

This is indeed nice. However, static extension methods would have made this feature simpler (and more generic).

This is nice for beginners, but the confusion is only postponed, because then you'd have to learn why you need to write a class as a container for static methods and that these methods must be static. So, the Java developers created another special case in the language.

Compare that with Kotlin where you have top-level functions, so that `main` is just like any other function.

Rego is a DSL and the main purpose of DSLs is to simplify things (compared to general purpose programming languages), so in my opinion Rego is not a good DSL.

I tried to implement some simpler cases with the policy language, Rego (https://www.openpolicyagent.org/docs/latest/policy-language/), of OPA and found it overly cumbersome. A simple check like "if user is in group A and in group C, but must not be in group C" is hard to express in this language. It would be a trivial task in any somewhat decent programming language (e.g. JavaScript).

I understand why restricting the possibilities with an external DSL might be a good idea, but I consider Rego to be to restricted. I mean, in the the a policy is just a function saying basically "yes" or "no" (I know, it's not that simple with OPA, but it boils down to access yes/no, anyway).

I doubt that the price will stay that low. Bitwarden has taken a lot of venture capital and someday the investors want to earn some money ...

https://bitwarden.com/blog/accelerating-value-for-bitwarden-...

Skia is also used by "Compose Multiplatform" by JetBrains. https://www.jetbrains.com/lp/compose-multiplatform/

But the project configuration has nothing to do with the web framework. You can use Javalin with Maven (and therefore XML), too. And you can use Spring without any XML by configuring the project with Gradle's Kotlin DSL. Modern Java development is not what it was 20 years ago.

In my experience the web layer is (or should be) pretty thin, so a framework in this layer shouldn't change too much in the overall application architecture.