@SuppressWarnings

I accidentally stumbled upon a blogpost showing all available SuppressWarnings values¹. Convenient.

References

[1] all that jazz - List of SuppressWarnings arguments

https://jazzy.id.au/2008/10/30/list_of_suppresswarnings_arguments.html

On Broken Window Theory and Cake

Occasionally, among my varied interests, I enjoy cooking. I find that it is one of mankind's most interesting practical applications of Alchemy, but that is a Blogpost for another day. I recently baked two cakes for my colleagues at work. I had no special reason for doing it besides the joy of cooking.

In this case it provided a perfect example of the Broken Window Theory¹.

I put the two cakes on the counter of the cafeteria, as soon as I came in that morning. Two hours later, I noticed that both cakes were still in one piece.

My colleague and I surmised, that this was because the cake was still undamaged. To test this, we both took a piece of cake. With two hours all but a small bit of one cake remained and at the end of the day, the second cake suffered a similar fate.

Note: interestingly enough even a perfect cake will suffer, if it sits next to a cake that is already in the process of being eaten.

On code

Of course, a similar conclusion can be drawn from your code. If your code is a work of beauty, naturally people who need to make changes, will do so with respect for the beauty of the code.

With code that is already showing wear and tear, or code that has originally not been well designed, this process of entropy is increased dramatically.

It is in many ways similar to the design principles of the Boyscout Rule² of Uncle Bob.

References

[1] Wikipedia - Broken Window Theory

https://en.wikipedia.org/wiki/Broken_windows_theory

[2] O'Reilly Commons - The Boy Scout Rule

http://programmer.97things.oreilly.com/wiki/index.php/The_Boy_Scout_Rule

J-Fall 2017 - Writeup

2 november 2017 has come and gone, and with it J-Fall 2017 has drawn to a close. Time for the write up.

Getting to know the Blockchain in plain Java

Johan Kragt & Cédric van Beijsterveldt

Welcome J-Fall 2017

Bert Jan Schrijver

Democratization of AI: from researchers to any user

Xavier Dupré

From Monolithic to SoC: Architecture & Teams

Guy Rombaut

CQRS Processing events

Martijn Blankestijn

Fostering an evolving architecture in the agile world

Roy van Rijn

From Code Commit to Production within a Day In One of the Most Critical Industries in the World

Gebrian uit de Bulten, Vincent van Kooten

Live Coding Time & State with Sonic Pi

Sam Aaron

Designing for Modularity with Java 9

Sander Mak

Safely Shoot Yourself in the Foot with Java 9

Heinz Kabutz

Afer all that, I felt the need to take a break and therefore did not attend the last presentation.

Getting to know the Blockchain in plain Java

This talk provided a very good basic level of how the blockchain works. It explained it by means of building a very simple blockchain in Java. The implementation mirrored the design choices made by Bitcoin. The presentation contained lots of demos, where you could see the blockchain being built. Based on the demos it became clear what the weaknesses of blockchains are, and what happens for example when an implementation forks.

It was most interesting and easy to follow.

Github repo was available at https://github.com/jcoreNL/Chain.

Democratization of AI: from researchers to any user

The Microsoft keynote was about machine learning, deep learning and Artificial Intelligence and how cloud services can facilitate this with custom made services and setup.

From Monolithic to SoC: Architecture & Teams

The talk focused on the evolution of both the backend and the frontend of applications. Where in the past these two were intertwined, nowadays we see increasingly that the two are separated.

You can find Guy Rombauts website here.

CQRS Processing events

It was a complicated talk, for anyone not familiar with some of the tools, software stack and principles behind CQRS. I hope to jot down some comments that struck me as important during the talk.

Event Sourcing (ES) basically means that all changes to the application state are stored as events. The current state is computed base on (re)playing the events.

Changing the state or the history is basically destruction of information, and is therefore frowned upon.

A good part of the talk was regarding what to do when the need for information changes. This requires some thinking on how to re-create the event stream or add information to the event stream. Some ways to do this:

• multiple versions - has readside impact
• upcasting - you can create a version 2 from version 1, this means the reads only need to know the latest version.
• in place transformation - changes the event store
• copy and transformation - creates a new event store to hold the new format, facilitates splitting and merging

See with regards to conversion also The Dark Side of Event Sourcing: Managing Data Conversion.

Then there's the difference between push and pull, where pull means periodically updating your read store, and push is registering yourself for new events. Push is therefore quite feasible in case events do not happen often.

“No one wants eventual consistency. It's a necessary evil. It's not cool. It's useful.”

- Jonas Bonér

Also check out what Martin Fowler has to say.

Fostering an evolving architecture in the agile world

It was a very interesting talk of Roy van Rijn, regarding the software application used by the Port of Rotterdam and how it evolved from a monolithic monster to more and more microservices.

“Don't do agile, be agile.”

- Roy van Rijn

“The purpose of bureaucracy is to compensate for incompetence and lack of discipline.”

- James C. Collins

“Schedule irreversible decisions for the last responsible moment, that is, the last chance to make the decision before it is too late.”

- Mary Poppendieck, Implementing Lean Software Development: From Concept to Cash

He also seems to have doubts about a DOD - Definition of Done document. He poses that your responsibility for your code will be replaced by a list. Which means, if the list is followed, it's no longer your problem.

positive/negative	visible	invisible
positive	Feature	Architecture
negative	Bug	Technical Debt

He also showed us the greatest example of Survivorship Bias I have ever heard!

A general in the army put some grunts to work registering the places on returning airplanes were these were hit by enemy fire. He took this diagram to the airplane designers, and told them they needed more armour on marks on the airplane where the damage was. The airplane designers told him, they would put the armour at the places where no damage was.

Their reasoning was: the diagram had no damage points in those areas, because if your plane gets damaged there, it is no longer in a position to land safely at an airport. It crashes. Which means we need more armour there.

From Code Commit to Production within a Day In One of the Most Critical Industries in the World

A massively interesting talk about the company that is processing billions of financial transactions per day on the internet, Ingenico. About all the different payment systems that are in use around the world, and how to interact with them and what kind of challenges that brings.

Live Coding Time & State with Sonic Pi

Sam Aaron showed us the Sonic Pi, which is basically a Raspberry Pi with software to generate programmatically music live. It was an amazing piece of work, where he showed different styles of music, performed by a simple 10 lines of code. He uses it to show kids in school how programming can be fun.

He also told of the challenges to create the software, make it perform music in parallel in a multi-threaded way. How to keep the music in sync on different architectures with different threading principles and the challenges that this brings.

Check it out at Sonic Pi - The Live Coding Music Synth for Everyone.. Incidentally, he's looking for money to continue the work.

Designing for Modularity with Java 9

An interesting talk, where we are introduced shortly into modules in Java 9, before diving deep into it and seeing how dependencies work, etc.

Safely Shoot Yourself in the Foot with Java 9

The talk was about how to do weird and unsafe things in Java 9, which were already possible in Java 8, but now require some changes.

Java Modules:

• The Size of the JVM has decreased significantly.
• Security has been a big plus.
• Faster performance

Some things to look up:

• get/setPlain
• get/setOpaque
• getAquire/setRelease
• @Contented
• Stream.takeWhile(pred)
• Stream.dropWhile(pred);

He showed how to overwrite the underlying bytearray in a static string, how to write UNIX Shell scripts using the new java jshell. He mentioned that the visualvm memory poker is gone from the JDK, but can still be gotten from github. He mentioned both Java Flight Recorder and Java Mission Control as good replacements. And lots of other things.

References

NLJUG - JFall 2017

http://jfall.nl/

J-Fall 2017 Starts Now!

It is 2 november 2017 and it is time again for J-Fall 2017. I am already on route to the Cinemec in Ede and looking forward to an entire day of finding out what's new in the Java Community.

I plan to focus on a bit of Blockchain, a bit of Java 9 and a bit of Microservices.

References

NLJUG - JFall 2017

http://jfall.nl/