33rd Degree Conference - Day 2

Okay, a long time since I wrote the first part of my 33rd degree journal and even a longer time since the conference itself. Still, I will try to write down what I learned, just to refresh my own memory.

Agile, Lean and Startups Practice & Principles to create ultimate value creation machine

by Barry O'Reilly

Starting early (not really, but I had some late night discussions with my colleagues) in the morning with a non-technical talk. I'm (unfortunately?) from the corporate world rather than from startup environment so I picked this talk to get a better understanding of how startups work (maybe one day I'll need this knowledge, who knows?). Barry started by introducing (?) waterfall, agile, lean and startup and highlighting some of the differences. He presented how the Deming cycle applies to startups and gave a handful of useful tips:

Ask: What's the smallest thing I can build that will give me a lot of feedback?

"Validate that what you're trying to build is the right thing to build.

In startup you don't have infinite time to do useless things as you might have in corporate world (oh yeah, I know something about it...).

 You need good understanding of the potential users to design a system suiting their needs  

Street surveys: help the team interact with end users to understand their motivations  

Developers don't just write code now, they have to understand their users

Get out of the building. Go to a coffee shop and talk to someone: Hey, I'm building something... 

Barry suggested doing street surveys - the very thought of it scares the s**t out of me but I guess that would be a scary & insightful exercise, as it would take me as far from my comfort zone as possible. That's how we learn after all. There's a few things to remember when doing it:

"Always ask Who? Why? How? What? and that kind of questions" 

"Ask demographic questions first to check if you're talking to the right person"

He also presented a few useful tools that can help people to understand their business (Business Model Canvas, personas, User value stream maps) and make it work better. And he stressed how important for startups is learning how are you doing (various metrics) & learning from mistakes:

Understanding what your customer wants is pure gold

Measure - data is the new oil

Don't waste your failures - don't celebrate failures but what you learned from them

I'll finish here as you can find the slideshow located here. I think that the talk, while concentrating on startups, has a lot of value for people coming from corporate world. I think that many of the patterns/tips applied to such environment would only make it better.

Micro Services - Java, the Unix Way

by James Lewis

Just noticed today - the slides are finally available! Yay!

The title of the talk intrigued me when I first saw it some time before the conference and I knew I'll participate. I think that was the best talk I've been to in the conference - maybe not the best show but I think most valuable from my point of view.
James shared with us the story of a project he participated in - they've build a huge application out of tiny, independent services (divided along the business capabilities of the system - one or more service per capability), implementing using various technologies (individual teams was free to choose whatever technology worked for them), all communicating in the same way - via HTTP.

"Micro service - small enough to fit in your head. Small enough so you can throw it away"

The services were small enough so that they could be discarded & rimplemented at any time. In fact, rewritting them would be even faster & cheaper than applying bigger modifications to them, should the need arise ("Rewrite over Maintain").

"Organize your teams around your business capabilities"

Such divide & conquer approach allowed them to share the workload among many teams, not conflicting with one another (and remember the Conway's law!). Otherwise, they wouldn't be able to meet tight deadlines they had. Additional benefit of this architecture:

• can adjust the architecture of individual services according to the specific requirements (like huge data sets or low latency)
• adhering to SRP (each application doing only one thing)

"If the class on the screen is bigger than by head it's too big"

• individual services fits in one's head (simplicity!)

"Be of the web, not behind the web"

The services were talking to each other via REST APIs, using regular request-response calls and publishing ATOM-based event logs.
The services were distributes as standalone JAR files (with Unix rc.d scripts), along with their configuration. To prevent developers from seeing the similarities in the code & extracting tons of common code, they were put in different VCS roots (with some library/infrastructure code being shared as separate artifacts, maintained in a open-source-like way).
Later, James explained how such system scales (see the presentation), what tools have they used. He also stressed that the uniform interface of the services is critical and how to deal with eventual consistency in this case. He didn't manage to talk about versioning but he was asked about it after the talk and explained that they were using automated tests as contracts between the systems - as long as the tests were passing the applications could communicate with their collaborators. I find this a wonderfully simple (conceptually) way to ensure that systems can change & still work together.

The presentation was a great example how huge things can built from small parts, using well-known, open technologies, without a need to spend years to develop an internal framework that nobody will be familiar with. Additionally, I found it interesting to see the same concepts Greg Young was talking about during his DDD/CQRS training were coming out in this talk (eventual consistency, bounded contexts, simplicity!). I guess great minds think alike and those techniques are not something new, that people could be afraid to use or have troubles with understanding.

After the talk, I bought the 'REST in Practice' book that James recommended. I'm reading it right now and I see it will make me smarter, even if we're not doing REST in our projects at work.

Concurrency Without Pain in Pure Java

by Venkat Subramaniam

I arrived really late for this talk (stayed a bit longer near the TouK room to listen & talk to James Lewis after his presentation). As for every talk Venkat gave, the room was suffering from a heavy participants overflow so I wasn't really able to see/hear everything. I only saw Venkat showing how to use STM (using Refs) in Java (and Clojure, IIRC). While entertaining (as always!) this talk didn't bring much value to me. Maybe if I had participated from the beginning.

What's new in Groovy 2.0?

by Guillaume Laforge

This was one of those presentation I wasn't paying 100% of my attention to. I don't know Groovy too well so learning what's new wasn't of much use to me but what I've seen looks like a really nice language. I'm a bit surprised that Groovy developers are going in the direction of allowing Groovy code to be statically compiled - I know performance might be an issue (and it certainly is for Groovy 1.x) but that's the tradeoff you make when using a dynamic language - sacrificing performance & compiler checks for reduced development friction & more expressiveness. But anyway, I like the dot- and parentheses-less code you can write with Groovy.

And of course - attending this presentation enabled to get me a seat for the next talk:

Scala for the Intrigued

by Venkat Subramaniam

This one I was really looking for. First - you know the show will be great if Venkat is the presenter (no free seats 15 minutes before the presentation start). Second - from what I have seen so far, Scala looked like a nice language. Maybe not entirely familar, but kind of luring me to give it a try. Therefore I wanted to see what cool features of the language Venkat will show us.
First class support for XML, no primitives, implicits are only some of the goodies you get if you run away from Java language to embrace Scala. As Venkat said - Scala is Java with its flaws fixed. An expressive, low-ceremony language that doesn't need an IDE that will produce hundreds of lines of code for getters, setters etc for you:

"Java: I just declare fields and my IDE magically vomit the rest of the getters, setters and constructors"

Additionally, Scala has traits (~ mixins) - something I was often missing when hacking Java code.
Of course, the show was as good as expected and this presentation was a good ending for the second day of the presenatation (at least for me). Scala seems to be really promising and we even get support from our manager to learn Scala and use it (as a proof of concept initially) at work! Good news indeed.