Keep it simple

To sum up the first part of day 1 of GOTO Conference, I must say there’s a pattern in otherwise unrelated talks: simplicity.

“Programming is hard”, says Donald Knuth. It seems that the speakers all agree, we should stop making it even harder. We tend to, says Russell Miles. “We do it out of boredom”. He argues, that if the task at hand is boring, doesn’t inspire us or is simply just to simple, we tend to try and make it interesting, by making it more complicated. “Uh, I always wanted to look into python. Maybe and can solve the task using that”. And – oh – look and behold. Trouble down the road. But Russel also have a suggestion on how to avoid the complexty we tend to introduce our selfes. He call it O.R.E. – or Organize, Reduce and Encapsulate.

He argues that organizing is nothing more than identifying if a part of a module has to know about the outside world or not. If it does, it is integration, if it doesn’t it is core. Database access? Integration. Rest services? Integration. Business rule? Well, if all data is supplied by the integration parts, I guess it’s core.
He also argues, that integrations should be kept at a minimum af knowledge about the other parts to avoid entanglement. Just pass simple data documents and parse whatever you can understand. “Be liberal in what you accept”. By deciding that data should be immutable, he argues that this also helps in reducing complexity. He says, that to his experience, it will end up looking like functional programming and have a reduce complexity and entanglement. I’m already doing functional programming in clojure, so if it is true, that it ends up looking like functional programming, I would say that he is more or less correct in the rest of his arguments.

Simplicity also seems to be the keyword in the next talk with Mathias Meyer about Travis CI, a hosted,continous integration platform. In the talk, he tels the story about how they redesigned the system from a monolithic architecture to a scalable architecture, build from small, distributed parts. But more about that in a later post. Still have some digesting to do.

On Ticket goto GOTO;

Whoop, whoop. I’m in luck. It seems I have found a sponsor for a ticket for GOTO;!

Now that I dare hoping to attend, I have started to study the details of the program. One of the tracks has a day called “Distributed Systems Renaissance”, and that caught my interest, because distributed systems is a part of my day job.

One talk in particular caught my interest: “The Smallest Distributed System”. In distributed systems, one of the challenges is being robust to systems falling out and comming back online. This could be due to errors like network problems or due to planned downtime. No matter what, the rest of the system should continue to run and when the missing part is back online, it should be able to catch up whith what have happend while being down. Think of cash machines, that can run whithout connection to the bank. It happily hands out money and when it reconnects to the bank, all of the transations are transmitted. This also implies, that the account balance might not reflect how much money you actually have left the account, as some transactions might still be only in the cash machine. But eventually all transactions will be transmitted, so eventually the balance will be correct. This is more or less what eventual consistency is about, and this talk promis to address these issues.

Where I work, we have a produktion system holding about 1.2 million customers. Most of it is build from the ground up, and for the newest and most central parts, we have used things like Clojure and Datomic – and it’s distributed. Though I have been interested in and been building distributed systems for years now, there a still loads of stuff I should and could learn. I’m really hoping this talk can give me some more insight.

But man – when a glance through the program. It’s like a candy store and I’m starving.