2017-10-27

My notes on "Greg Young - The Long Sad History of Microservices"

Greg Young - The Long Sad History of Microservices
From the "Build Stuff" event of April 2017.

Talk begins at 9:45.


27:00 Placing a network between modules simply to enforce programmer discipline 

29:05 There is other levels of isolation I can go to. I can run a docker container per service. That's the coolest stuff right? What that means is I can make it work on my machine so I send my machine to production. 

29:52 Now, one thing that's very useful is I don't necessarily want to make this decision up front. And I don't necessarily want to make the same decision in dev as in production. I may want in dev to have a different way that we run things, why? because bringing up 19 docker containers on your laptop is not very much fun. I may prefer to host everything inside a single process to make debugging and such a lot easier when I am running on dev in my laptop. Whereas in production we may go off to multiple nodes. 

34:16 If you have maintenance windows, why are you working towards getting rid of your maintenance windows? Is this a business drive or is this you just being like C.V. driven development? 

Unfortunately his shrieky voice makes him sound like he is bitching about things, which in a sense he is, but it would help his cause to deliver his criticism in a more palatable tone. Also, in order to make his point about microservices being nothing new he seems to disregard the one characteristic of microservices which I think defines them, which is their statelessness.

Resources referenced in the talk:

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

https://en.wikipedia.org/wiki/π-calculus

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

Leslie Lamport - Time, Clocks, and the Ordering of Events in a Distributed System
(available on the interwebz)

C.A.R. Hoare - Communicating Sequential Processes
(available on the interwebz)

2017-10-01

Migrating a project from java 8 to java 9


Now that Java 9 is out, I decided to migrate to it my pet project, which is around 120K lines of java.

The first step is to just start compiling and running against jdk9, without using any of its features yet.

This is an account of the surprisingly few issues that I encountered during this first step and how I resolved them.




Issue #1: Object.finalize() has been deprecated.


2017-09-26

A Hacker's Tale (With a Human Side)

This is a hacking story from my University years. It ends with a nice bit about human qualities.

The University had several computer labs, most of them equipped with Unix workstations, a few with PCs. I would often be found in the PC lab, since I was already quite familiar with that kind of machine and operating system. It was the early nineties, and PCs back then were running MS-DOS. Networking was done by connecting them to Novell™ servers via coaxial Ethernet cable, which delivered a (decent, for that time) 10 megabits per second.

Each PC in the lab was running a network driver, which was making parts of the server's filesystem visible locally as DOS drives. These drives were available only at a filesystem level: if you bypassed the OS and invoked the BIOS to enumerate the physical hard disks on the system, they did not show up, because they did not physically exist.

Filesystem access to these drives was subject to security checks performed by the Novell™ server, which was running some proprietary Novell™ operating system, so the whole setup was fairly secure, and for even higher security, the server was kept locked in a cabinet, so nobody but the administrator had physical access to it. The administrator of the lab was Dr. "A", and he had appointed as co-administrator a fellow student and friend of mine, Bashir.

Back in those days, if you were a power user, (let alone a computer lab administrator,) you absolutely had to be using the Norton Utilities.

Screen capture of the main menu of the Norton Utilities; found on the interwebz.
Of course, most of these utilities required physical access to the disk, so it was impossible to use them on the server, but they could be used on workstations.  And they were indispensable, so Bashir had stored them on the server, in order to be able to access them from any workstation.


2017-07-18

Grumpy Posts

Besides the delicate grumpiness which is gratuitously scattered throughout this blog like the golden rays of light in a gentle sunset, there exist a few blog posts which have been written with the express purpose of venting out some major grumpiness.




Here is a list of them:

On Full Stack Developers

On UUIDs and GUIDs

On scripting languages

Why Oracle sucks

The GWX (Get Windows 10) KB3035583 trojan horse

"By using this site, you agree to the use of cookies."


(The list will be extended as more posts are added.)

2017-07-17

On Full Stack Development

Q: How does a full stack developer sleep?
 A: They don't sleep, they REST.



Almost every single company delivering some kind of product on the web since the early 2010s seems to be looking to hire full-stack developers.  Full stack development is all the rage.  If you are an employer, you can't possibly be doing it right unless you are hiring full-stack developers to do the job.  If you are a programmer, you are not particularly employable unless you can work with the full stack.

It is almost as if software architectures requiring individual programmers to work on every single layer of the entire stack are a good thing. It is almost as if the the job market is full of programmers who are actually capable of working on every layer of the stack.  And it is almost as if they could possibly be any good at that. Or any part of it.

How did it all go so wrong?

2017-07-12

Rich Hickey - Simple Made Easy

"Simple Made Easy" presentation by Rich Hickey from the InfoQ Software Development Conference, recorded at Strangeloop 2011



It is best to watch this presentation here: https://www.infoq.com/presentations/Simple-Made-Easy Where the slideshow plays alongside with the video. (It is a lot better like that.)

My notes on the presentation:

"Simplicity is prerequisite for reliability" - Edsger W. Dijkstra

Simple vs. Complex, Easy vs. Hard

2017-06-18

On UUIDs and GUIDs

Universally Unique Identifiers (UUIDs) otherwise called Globally Unique Identifiers (GUIDs) are 128-bit numbers that are often used to identify information. In its canonical representation, a UUID looks like this: 2205cf3e-139c-4abc-be2d-e29b692934b0  

The Wikipedia entry for Universally Unique Identifier (https://en.wikipedia.org/wiki/Universally_unique_identifier) says that they are "for practical purposes unique" and that "while the probability that a UUID will be duplicated is not zero, it is so close to zero as to be negligible."  Wikipedia then does the math and shows that if 103 trillion UUIDs are generated, the chance of duplication among them is one in a billion.

Great.  Now, let me tell you why I hate UUIDs.

The 32 hexadecimal digits that make up a UUID have a higher concentration of entropy than anything else that I deal with during a regular working day.  (It helps that IntelliJ IDEA spares me from having to see git commit hashes.)  This is to say that the overwhelming majority of all the entropy that I am exposed to nowadays is due to seeing UUIDs. This was not happening in the days before the UUID; entire weeks could pass without seeing something as hopelessly nonsensical as a UUID, requiring me to coerce my brain to ignore it because "there is no sense to be made here". The higher the entropy of the visual stimulus we are exposed to, the higher the cognitive effort required to process it, even if just to dismiss it as un-processable. This makes UUIDs very tiresome to work with. When looking at a table of columns, the UUID column is always the angry column.