Tuesday, 19 November 2024

Peak of Complexity

So, I was at Devoxx 2024. During the opening keynotes, Brian Goetz spoke regarding Peak of Complexity.

You can find it below at [1].

It's important to me on a personal level, as I do tend to make things more complex than they should be.

Often times, it means I overengineer my solutions and program for exceptional situations that are unlikely to occur.

One of those overengineered ways of thinking happened today.

A colleague asked if he was doing it right. He was reading in an XML file of about 5000 entries in a Batch process.

  1. First I thought we should use a stream, build the stream ourselves, so we can have an XMLReader that provides us each piece of information we need without loading the entire thing in memory.
  2. Then I found out that it's bloody hard to make your own streams. A default builder in the JDK uses a SpinedBuffer which is basically an ArrayList containing ArrayLists. Which means the entire thing is still read into memory.
  3. So I thought I could use a simple Consumer. The Consumer gets a new one from the XMLReader when he has one available.
  4. Then I found out that that doesn't really mesh well with the Batch Reader process. So I started thinking about using an iterator, instead of an Consumer.
  5. But in the end, after everything's said and done, the XML file contains only 5000 entries, and the entries are not very complex and the whole thing could be put into a List of simple POJOs. So now it's just a simple List.

Once again, in the end, I've managed to whittle it down to the simplest solution, but it would be nice if I started from the simplest solution, and only increase complexity when needed.

I guess I still need to work at it.

References

[1] Postcards from the Peak of Complexity by Brian Goetz
https://www.youtube.com/watch?v=Yiye8lqh0Ig

Tuesday, 22 October 2024

Git: Adding your own commands

So I do have a habit of adding my own commands, simply as an alias, simply in the startup scripts of my *nix account and it works fine.

But apparently it also can be done inside git.

So in the example in [1], the new command is "git eradicate".

It was added to the ~/.git-config file as:

eradicate = "!git reset --hard; git clean -fdx"

"-fdx" will also remove files that are mentioned in the .gitignore file.

As there are settings in there, this is perhaps not what you want.

According to the manual in [2] regarding git clean, the option "-x" has the following interesting effect:

"Don’t use the standard ignore rules (see gitignore[5]), but still use the ignore rules given with -e options from the command line. This allows removing all untracked files, including build products. This can be used (possibly in conjunction with git restore or git reset) to create a pristine working directory to test a clean build."

In that case, perhaps the one below is safer:

eradicate = "!git reset --hard; git clean -fd"

References

[1] Medium.com - SE Radio, Git Eradicate, Progress On JMS
https://medium.com/nipafx-news/jpms-support-for-module-versions-a-research-log-2c96f5d0c1ee
[2] Git - --distributed-is-the-new-centralized - Git Clean
https://git-scm.com/docs/git-clean
explainshell.com
https://explainshell.com/explain