rvdginste

I don't believe in this: if you follow through on that, you will end up with a low-code or no-code platform. Or basically, you are creating a programmable platform where your "configuration" is actually gonna be code.

When you create software to support a business, you automatically support business processes. The better you try to support those processes, the better the user experience and the more "tied" the software becomes to those processes.

Often, when you create the software and analyse the needs, it is also a learning experience for the business because they are forced to think about the business processes they have and about the business processes they want to move to.

If, in that business context, certain needs or flows change, it is natural that it requires changes on the code, but those changes should rarely be so dramatic that you have to rewrite big parts of the application. When that happens, there must have been a serious flaw with the analysis and design, or the code was simply bad.

And yes, for certain things, there is a bit of a balance in whether it should be configuration or code. But from the analysis, for most things it will be very black-and-white on whether it should be configuration or code.

> Or how bad Amazon S3 would be if it had a "startup" or "video provider" domain.

I don't understand this comment. Amazon S3 on its own would be very bad to support the business processes of a video provider. And software to support a video provider business would be very bad as a general blob storage solution.

Obviously there is a difference between a general "product" that you want to make usable for a target audience as big as possible and a customised solution to support a business in the best way possible. But both are also different domains. So, yeah, if you create something for a certain domain, it will be an issue if you want to use it for a completely different domain.

I used an iBook G3/G4 12" for several years with linux. I remember the G3 was supported completely out of the box. I loved it: it was small, battery lasted pretty long (I did spend some time fine tuning laptop-mode-tools), suspend-to-ram was working flawlessly and from what I remember all hardware was supported, including 3d graphics (ati radeon). For the G4, I remember there were some issues to get the wireless card working when it came out (Broadcom hardware I think), but the rest of the hardware also worked out of the box.

It looks interesting, so I'll keep an eye on it, but currently there is not that much information available.

What kind of output formats to you target? I assume PDF, but aside from that? HTML? epub?

Will you maintain a history of a document? I assume this will be a hosted platform, and as a user, I cannot just add a document into source control?

I don't know if any company is exploring what you are mentioning, but battery swapping for electrical scooters (Gogoro) is in common use in Taiwan. Instead of you charge your scooter, you drive to a battery swap station and exchange your empty battery for a full one. see [1].

But some companies are also investigating battery swap stations for cars. So, you might not be able to swap a short-range battery with a long-range battery yourself, but I imagine that would be possible with those battery swap stations. See [2]. Battery swap stations means that you have full range again for the same time it takes to fill a car with gas. But obviously, you need to have enough of those stations to make it usable. And if every car brand is gonna create its own mechanism for battery swapping, then that would probably only be interesting in city areas where it's worthwhile for the manufacturer to run those stations.

[1] https://www.electrive.com/2022/01/18/battery-swapping-statio... [2] https://www.bbc.com/news/business-61310513

Edit: typo.

I have wondered about that too. But when I think about a file system transaction, I immediately think about a file system transaction enlisting in an ambient transaction, together with a database transaction. This would make code much more simple/clean for cases where you must create a file and store metadata on the file inside the database. And on the other hand, some database systems do provide features for storing large file-like blob objects, which give you these transactional features.

So I think it depends on the context and what you wanna use it for. I don't see the transactional features of a file system as useful for actual users that are directly interact with files on their file system. It seems more useful in the context of applications that maintain files and where you likely do not want the user to directly interact with those files.

With these kinds of really cheap devices, it always makes me wonder whether you are not better off buying older used hardware instead... especially if you are looking for a cheap linux laptop.

For example, some time ago I got a Thinkpad X200 tablet in good condition off ebay for that price. I was mainly interested in the tablet functionality, but it's a nice little laptop that is still usable today.

Even if you are specifically interested in Chrome OS, Chrome OS Flex might be an option on used hardware.

I think people who think that commit messages don't matter, should be forced to maintain a code base written by colleagues of the same opinion for the next 5 years.

As a team lead I insist on a link to a ticket for stuff that is related to a ticket. When moving to another ticket system, I insist either on keeping older projects on the old system, or alternatively on migrating old tickets to the new system and keeping the original references; the same way I insist on keeping history when moving from one source control system to another one.

Also... why would a company go through 3 different ticket systems in 5 years? That must cost a lot and definitely is not gonna help convincing people to use it...

> I'll consider ceasing to write "good" commit messages when I'm confident the code I check in doesn't contain any bugs.

Please don't. As much as it is useful to fix buggy code at a later point, it is the same useful to prevent introducing buggy code at a later point!

Never saw some code that looked funny at first sight, and that you considered 'fixing', then checked the commit messages and understood why the code was written the way it is? Fixing it, would have meant introducing a bug.

That's convincing :) Good to know, thanks!

Do you think the Tex Shinobi is worth its price? I'm familiar with the Thinkpad X200 keyboard and interested in the Tex Shinobi, but find it a bit hard to justify spending that much on a keyboard. (I am a software engineer and do spend a lot of time on keyboards and I do value a good keyboard.)

Thank you for the references to those languages.. interesting!

Exactly!

A couple of years ago, we invested in using the libraries from Microsoft Code Contracts for a couple of projects. It was a really promising and interesting project. With the libraries you could follow the design-by-contract paradigm in your C# code. So you could specify pre-conditions, post-conditions and invariants. When the code was compiled you could configure the compiler to generate or not generate code for these. And next to the support for the compiler, the pre- and post-conditions and invariants were also explicitly listed in the code documentation, and there was also a static analyzer that gave some hints/warnings or reported inconsistencies at compile-time. This was a project from a research team at Microsoft and we were aware of that (and that the libraries were not officially supported), but still sad to see it go. The code was made open-source, but was never really actively maintained. [0]

Next to that, there is also the static analysis from JetBrains (ReSharper, Rider): you can use code annotations that are recognized by the IDE. It can be used for (simple) null/not-null analysis, but also more advanced stuff like indicating that a helper method returns null when its input is null (see the contract annotation). The IDE uses static analysis and then gives hints on where you can simplify code because you added null checks that are not needed, or where you should add a null-check and forgot it. I've noticed several times that this really helps and makes my code better and more stable. And I also noticed in code reviews bugs due to people ignoring warnings from this kind of analysis.

And finally, in the Roslyn compiler, when you use nullable reference types, you get the null/not-null compile-time analysis.

I wish the tools would go a lot further than this...

[0] https://www.microsoft.com/en-us/research/project/code-contra... [1] https://www.jetbrains.com/help/resharper/Reference__Code_Ann...

I used the Terminus bitmap font until a year ago because I found it really clear and sharp even on small sizes. Since bitmap fonts are not that well supported anymore, I switched to JetBrains Mono for both terminal and IDE. I started using JetBrains Mono in my IDEs as soon as it came out.

> Yes, hardware has limits and you just cannot have a single machine with unlimited number of cores and disks.

Ok, but it still makes me wonder how far you can go today with a good old-fashioned RDBMS, running native on modern server hardware. I believe you can go a lot further than most developers seem to think, without having to go to more complex distributed setups.

In the environments I work in, it seems people often first check on scaling horizontally instead of checking how far they could scale vertically... my preference is to first scale vertically before trying to scale horizontally. (I am aware both have different advantages, but I'm mainly thinking from a performance point of view.)

> ...and you never really grasp before moving on to the next thing.

Then why do you move on to the next thing?

Not a frontend dev, but I notice that a lot of frontend devs seem to be really eager to jump to the next hot thing when it becomes available, even though the thing they are using is still well maintained.

I think it's a bit naive to think that a given developer will produce better code when using an editor instead of an IDE. I believe that a certain developer will produce the same quality code whether he uses an editor or an IDE.

If you use default templates and don't really care about the structure of your code when using an IDE, you won't suddenly start to care when using an editor. If you don't care about all kinds of shortcuts and specific functionality in your editor, you won't care about learning the shortcuts (and even functionality) in your IDE.

Some people seem to think they will become better developers by learning to do their development with an editor, but I do not believe that is true. Maybe except for one thing: if you do use an editor and don't use something like LSP in your editor, you will be forced to memorise the standard libraries of your programming language; you need to memorise those to stay productive with an editor. And in general, I do believe that the pure text editing part is often more advanced in a good editor than in an IDE.

But, a good IDE is an amazing tool when you have the hardware to run it. Especially with typed languages, an IDE makes it a lot easier to refactor code and change the design of your code. This really lowers the threshold to change the design of your code when requirements change. Since the changes are simple and fast, developers are more confident to do those changes and will consider those changes in more cases. And aside from that, IDEs also often include an analysis part and warn you about fishy things in your code.

I have been an Emacs user for a very long time. I used it for C long time ago, and recently used (limited) it with an LSP server for C# (using the Doom Emacs distribution). And that is working nicely: magit is great, integration with LSP servers is great... you can get a lot of the stuff that is typical for IDEs. But when you do activate all those integrations, you will notice that it is also heavier to run and less responsive. So, in the end, when the hardware can run it, my preference is still the full-blown Rider IDE for C#. The IDE is much more complete out-of-the-box.

I use the convention that an 'null' value is a value that was not explicitly set by the user.

So in C#, I would always use a nullable boolean in this case (choices yes and no). If the field is a required value, I would annotate the field as such.

When using the field in an ORM, the required annotation would lead to a not-null field in the database.

When using the field in a dto, the required annotation could be used for validation of incoming input.

If the user should have the choice "yes", "no", "unknown", I would use a nullable enum to express this. An 'null' value means that the value was not explicitly set. The enum value "unknown" indicates that the user explicitly chose the "unknown" value.

So, in both cases the 'null' is not a separate state, it simply indicates that no explicit value was given to the field.

Yes, I understand, but I've searched for this before and it is hard to find a list of the utilities that people typically use with i3wm or any other barebones window manager.

This is exactly the kind of thing I wanted to know. Thanks!

Do you use i3 all by itself, or do you add base services from a desktop environment?

In the context of a laptop, I am thinking about things like: mounting external drives, power management configuration, network configuration (access to wireless networks), switching keyboard layout (e.g., US, US international), ...

(edit) Context: I did use i3 all by itself before, but always seemed to be missing something. Afterwards I switched to KDE which I do like, but i3 is snappier and a tiling wm is handy on laptops with small screens and/or older hardware.

One of the things I always found fun in programming, is anything related to graphics. The main reason is that you get immediate feedback while you are working on it.

If you are into computer graphics, you might be interested in the following:

The Ray Tracer Challenge, see https://pragprog.com/titles/jbtracer/the-ray-tracer-challeng...

three.js journey, see https://threejs-journey.com/

> The fundamental problem is the difference between Curated and Uncurated packaging systems

Exactly this! It is expected from linux distros that they have curated packaging. I think that is good and I really expect it to stay that way.

Whether you want curated or uncurated packages depends on the use case.

As the user of a program, I definitely want curated packages.

As the developer of a program, I want to specify myself which version of a dependency I want to develop against and I don't want to be hindered by the linux distro in doing that. I do think that developers in that context are not always supported that well in linux distros. And on the other hand, I do think that tools supported by the programming language can assist in that scenario. (for example installing multiple versions of the compiler and runtime in the users home directory and being able to easily switch between those versions on a project basis...)

Regarding PGP's 'Web of Trust', I thought the purpose of this was to validate the link between the key and the owner of that key. This is not what you get from retrieving a public key from github... that only gives you the link between that key and a github account. But what does that give you?

From what I understand, it gives you nothing for anything that is signed and that does not have a direct link to a github account. Obviously, if someone releases software on that github account and I find a signed release of that software, I can validate that it really was signed by the official source of that software on github. For anything that does not have that direct link, it really does not give you anything.

I've never used PGP, but I thought the web of trust was used to validate metadata on the key and that this can be used to validate that a key really belongs to the person that you think it belongs to. I saw it more like how you have SSL certificates with different degrees of validation and where you must deliver more proof of your identity if you want to receive a certification with a higher degree of validation.

I'm all for using SSH keys for signing, but I still would like to have something like PGP's web of trust for those keys.

The way you setup branches and how you work with them, is your own choice and is not directly tied to a specific version control system. I used to work with feature branches on subversion before I moved to git. Git does support more types of branch configurations and more ways of bringing code from one branch into another branch.

I believe that the issue that you ran into would have been best solved with a reset and a force push, as long as you see it rightaway and thus before other commits were done and as long as you can warn the whole team that an error happened and that it will be fixed with a reset+force push. At least that's the way I would do it. We use bitbucket and disable reset+force push on the main branch, but allow it on feature branches. When it is really needed, we temporarily enable it on the main branch to do a fix and immediately disable it again.

Also, IMHO, if you have a main and development branch, I think that the feature branches should be based on the development branch and not on the main branch. Normally you want the feature branch to take into account the most recently merged code. To me it seems that if you want to make a new release of 'main' before the release of 'development', you are talking about a hotfix and that should be exceptional. For a hotfix, you'd base the fix off the version with the bug, and then check whether the fix is also needed on development. Moving commits around like that with git can be done fairly easily using 'cherry-pick'. But mainly my point is: all the different branches that you define and how you work with them is really your own choice, you can make it as hard or as simple as you want. It seems a lot of people are making that setup very complex, but remember that not everyone is working on a project used by 10 customers with 3 active major versions, each of which requiring features and bugfixes. In a lot of cases, you can get away with one long-living main branch and short-living feature branches. As long as each release is properly tagged, you can make a bugfix or hotfix release for anything that you released before. And, again in my opinion, the default should be that when a feature is merged, it means that it was ready for release and will be in the next 'regular' release.

> Surely we can do better than this? A tool being powerful should be no excuse for it having footguns!

I don't really understand what you mean here. Git is very powerful and allows you to manipulate commits in a lot of different ways, some of which are destructive... but that is part of its power. What are in your opinion the footguns and how would you remove them?

What I did notice, is that a lot of people just seem to refuse to take the time to actually learn how git works and how they can work with it. A lot of people seem to be convinced that it is a much better use of their time to search for a git UI that hides all the complexities and shows them a more simplified presentation that likely is a bit closer to how they are used to work with other source control systems, than that they use the same time to learn to use git. Personally, I use the git tools that come with git: the git cli, gitk to visualize history and git gui to commit work. (I do like the UI built into JetBrains IDEs because it is pretty good and doesn't try to hide anything or invent a new name for certain git terms.)

Completely agree with parent and grand-parent. For me, a nice clean commit history is an investment in future maintenance.

Following the rules described above means that you get a lot of context on why code was changed:

* the invidivual commit which should contain a description of the change if the change is not self explanatory or not 'intuitive', the individual commit should consist of only 1 functional change

* the commits surrounding it, the feature branch (clearly visible because of the merge commits)

* the issue number on the commit itself and possibly in the merge commit

I've found all this context very informative for projects that are in maintenance mode and still need changes from time to time. Obviously, the higher the quality of the commit history, the higher the quality of the information you get out of it.

Meaning: if you put a rename with an impact over the whole code base (because the original name just happened to bother you that day) together with a bugfix in the same commit and the commit message has the very informative text 'fix', and the referenced issue mentions 'add support for blah' (but the commit obviously does not implement anything related to 'blah'), then... well, yeah, then how you organise your commit history does not really matter.

If you use left-inclusive, right-exclusive intervals [), then then the overlap condition is:

meeting_a.starts_at <= meeting_b.ends_at && meeting_b.starts_at <= meeting_a.ends_at

So, indeed, the scenario as described in the article is more complex than needed.

For backends, I typically use ID generation in the application layer (the backend). And with ID generation I mean the HiLo generator from Hibernate (or NHibernate). By default the HiLo generator will still use a monotonic increasing number, possibly with gaps. (Either way, as long as you expose some form of monotonic increasing number in your api, enumeration attacks could work. The correct way is to simply not expose the original id if that is an issue: you could expose some kind of opaque token in the api instead of a literal id.) The advantage of the HiLo generator is that the ORM knows the generated id up-front and does not need a round-trip to the database to determine it. So it can generate more performant queries. Also, contrary to UUIDs it does not have the disadvantages regarding indices. The only reason I have ever used UUIDs was because of a requirement that external clients needed to generate the ids.

Uh... well, it would be even more embarassing to admit how long I've been telling myself that I'd start learning emacs-lisp in earnest... so I won't. :)

Ok, thanks, good to know.