Today was simply fantastic. Every session I went to was really good or brilliant and the keynotes were really good too. I really want to say thank you to my employer Active Solution and my manager Magnus for sending me to Øredev. It is very much appreciated!
Reginald Braithwaite – The Rebellion Imperative
Compared to the keynote with Jim McCarthy on Wednesday, Reginald Braithwaite was much more lowkey (in a very charming way). His first sentence was to apologize for not being a professional speaker as he is just a programmer. But he displayed a lot of natural talent and inserted loads of subtle jokes.
“I’m lisping slightly. Just imagine that there are () around everything I’m saying, it’ll work out”
– Reginald Braithwaite
Reg introduced himself as the child of two socialists and that he loves Cuba. And this led onto his vision of the dark future we live in where corporations don’t care about progress. Wealth breeds inefficiency amongst people and corporations as they have no incentive to change. In fact it’s just the opposite and they build moats to protect their interests e.g. patents.
“All those moments will lost in time, like tears in rain”
– Roy Batty, Bladerunner
is the quote Reg used to illustrate the fate of many of the great innovaters. He showed us a picture of the inventor of Visicalc, Dan Bricklin, and asked how many of us recognized him. No hands went up. Same for Jef Raskin the creator of the Mac computer.
“Your ideas will go further if you don’t demand that you go along with them”
– Reginald Braithwaite
Using ideas from the book Marketing Warfare, Reg presented the four sustainable positions for a company:
– The leader
– the rival
– the innovator/disrupter
– the 99%
The rebels are the 99%. All these startups are trying to be the disrupter but that’s really hard to do and only a handful will succeed. So if you want to be a rebel and build a successful business then go and watch Reg’s keynote!
He finishes the keynote with a dance to jitterbug music, so all in all this keynote is well worth your time.
Fred George – Micro-Service Architecture
This was the first session at Øredev this year where I felt really challenged by a new idea. I’d heard a little bit about micro services last year via Dan North but I haven’t read or heard much about it since. Fred George is a very experienced programmer (IBM and ThoughtWorks) and he used the timeline of his career to show how he evolved from using a layered architecture to micro services. The story starts with a 1 million line J2EE system with a layered architecture now in a pitiful state. Only 70% of the acceptance tests passed and not the same 70% after every run. They measured the amount of unit tests written every week and noticed that only a few programmers were writing all the tests. As an aside, weekly unit test count is really a interesting way to measure progress. The maintenance of the project had been outsourced and it was wallowing in technical debt. So how did it end up this way? Fred’s theory has four reasons for the existence of Technical Debt:
- No power to refuse
Fred then continued along the timeline of his career through a series of shorter projects or prototypes where he started to move towards the pub/sub model of architecture. This led to Fred and his colleague, Jeff Bay coming up with the Baysian Service Principles (after Jeff Bays).
- It’s okay to run more than one version of a service at the same time
- You can only deploy one service at a time
These rules started to change how the team worked. They started deploying 3 times a day.
The next evolution and step in the timeline was a project where they tried out a technique that they called the Pinball Method. The project was to build a system to do batch processing of replacement parts for cars. Processing started with an empty order i.e. the pinball. The order then bounced around the system calling lots of tiny services to fill up the order object with all the information it needed. These services were around 100 lines of code each and did one thing. They did have some problems with this, it was hard to figure out where the order is and hard to understand, especially for inexperienced programmers.
They iterated this architecture more successfully after that, especially at the Forward Internet Group. This resulted in services that were small and disposable. If a change needed to be made to a service then they rewrote them instead of modifying them. The services became self-monitoring and this replaced unit testing. Real-time business monitoring replaced acceptance testing. They used JSON as the message standard for communication between service which meant that the services became language agnostic (Ruby, C++, Clojure, Node). He also mentioned that they used LinkedIn’s pub/sub system Kafka.
All this resulted in them killing off a lot of their agile practises and their technical debt pretty much disappearing. As the system consists of hundreds of small services instead of the usual layers, it is not monolithic but is still complex due having to manage the flow of all of these services. Fred mentioned that he was surprised about how large the impact of this technical change was. It changed the dynamic of the team and the company.
This session really got me thinking. It feels like there are both definite advantages and disadvantages to the micro service approach. Some businesses cannot afford to test in production in this way. The learning curve must be quite steep and would require very competent programmers. Companies like Github do something similar to this on their frontend (but not on their backend however). I’m also wondering how they solve all the potential performance problems. But I’m intrigued and I highly recommend this session. Should be up on Vimeo soon.
Denise R. Jacobs – Scalable and Modular CSS FTW!
Ivar and Daniel at work have both been talking about SMACSS as a better way to structure CSS files. I work on projects that use Twitter Bootstrap or similar grid frameworks and on legacy system with loads of horrible CSS but don’t feel that I really have control over the CSS in the same way as I do over the rest of the code. And Denise did a great introduction into not just SMACSS but also OOCSS, DRY CSS and CSS for Grown Ups. These are all style guides or rules that you can apply to your CSS architecture. Denise did a great job of making her presentation in to a fairytale with herself as a pirate that was helping to restructure the CSS foundation of a castle so that its foundations would be as beautiful as the outside. It might sound a bit strange but she pulled it off. Denise goes through the different style guides and describes both the differences and the similarities between them. This session is full of good tips to improve your CSS, things like writing better selectors, how to group them, naming conventions, layout helpers, leveraging the CSS cascade and how to modularize your CSS. These are tips that you can start applying tomorrow. And best of all, I won the SMACSS book by Jonathon Snook for being brave (or stupid) enough to answer a question from Denise at the end. I think my CSS skills are about to get dramatically better!
I am going to have split this up in two parts, I just couldn’t stop myself writing about these sessions as they were so good. And the afternoon sessions were brilliant too. So lots more to come in part 2 – the afternoon.