Buildstuff Conference Report - day 3
The energy level for me as well as several other attendees was noticeably lower on the third day. I do think that three days of tech talks is just too much, though I must admit I’ve been stuffing myself with all kinds of side-dishes too - reading several of O’Reilly’s free programming books (on reactive programming and microservices). Highly recommended by the way.
The biggest trick consultants ever pulled was convincing the world continuous delivery was easy
Paul Stack @stack72
Paul’s talk was the first one I attended today. It didn’t tell me anything new about continuous delivery (but maybe I’m not playing a fair game since I had already read Continuous delivery by Jez Humble and David Farley). There were several notable ideas though.
First, not nearly enough people run a smoke test once they have deployed their software to the production server. Second, there are several interesting books about making delivery more successful. One is an older book that is not about IT, called “The Goal”. Another one, which is about IT, is called “The Phoenix Project”. Both seemed like interesting reading material. Paul also showed sort of a tube map for continuous delivery, which seemed like a useful high-level overview of what you can do, both as a developer and operations person, to make delivery easier and less error-prone.
Javaslang - Functional Java done right
Grzegorz Piwowarek @pivovarit
I had seen some of Java 8’s “functional programming” (FP) features before. Since I have been learning more about FP recently, I already knew that it missed some big points. I had also heard people say: “Why learn Scala? You can do it all with Java!” Well, there is a lot to discuss there, but my conclusion is that currently Scala has a lot more to offer. I think that FP with Java requires way too much code to get even the most simple things done. Also, if you’ve never done FP, I assume it will be hard for you to get going with FP in Java, while all the imperative alternatives are still around, screaming at you, trying to convince you not to fall for all that hipster FP stuff.
Yet, you could say the same for Scala. It still allows for an imperative programming style. It has great support for immutability, but doesn’t make it your default option. It doesn’t enforce the “pure functions can never call impure functions” rule either.
So if you want to learn hardcore FP, you might be better off diving into Haskell for example. But if you’re living in a Java world and you want to apply FP principles when the team as a whole doesn’t want to switch to a functional language, you could instead add the Javaslang library as a dependency to your project. This gives you lots of functional goodies, like tuples, currying, Option, Try, Lazy and Future monads, as well as functional data structures amongst other things.
Michael Feathers @mfeathers
It was great to finally see Michael Feathers on stage, delivering a very practical talk, basically about improving code by pushing away the noise that prevents you from recognising what the core concerns of the code are. Examples of noisy parts of code are the parts that deal with exceptions, logging, decisions (if/else), goto statements, etc. Michael calls these the “edges” of the code; where decisions are made or things can go wrong.
Michael encourages us to ignore the problems first. Then we can see how things are supposed to work and we can look for alternatives to keep our coded solution clear. There are many different strategies, e.g.:
- Extend the domain of a function. Take for example a string manipulation function that accepts an index: we could throw an exception if that index is negative (since a string has no negative index), or we could extend the domain and take the negative index to designate an index starting from the right end of the string.
- Saturate a given input. This basically means cutting of values: if a value is out of the domain of a function, you just take another value that will do the job (for example a value at the edge of that domain).
- Introduce a Null-object. Not passing actual null values helps reducing the number of decision points.
- Use an empty list. This allows clients to use the result value in the same ways as they would when there was in fact an element in the list. This is also why a flatMap in functional programming is such a valuable idea.
There are many more options to reduce the number of edges in your code.
Michaels talk resonated quite a lot with Mark Seemann’s talk yesterday. It looks like many of the problems automatically disappear when we start doing functional programming.
Kevlin Henney @KevlinHenney
At this point I didn’t think that staying at the conference any longer would be very beneficial to me. I’m happy I stayed for this one though. Kevlin is an excellent speaker. I had seen him before (since Ibuildings has invited him as keynote speaker at the Dutch PHP Conference several times already).
What he tries to achieve with this talk is something he calls defamiliarization: presenting a familiar topic in an unfamiliar way. In this case, the topic is functional programming and he applies it to C++, something that indeed not many other people do. The idea is that C++ code would be better off with some functional principles applied to it. Kevlin shows many options for doing this.
Part of the talk is dedicated to explaining the difficult problems we get from working with threads and shared mutable state. We should at all times avoid mutable state from being shared (we can have shared immutable state, unshared immutable state or unshared mutable state without any problem).
Kevlin had a lot to show us, but I find it hard to summarise it in a way that might be interesting to you. Instead, I can recommend you watch the video (once it’s available), in case you’re interested in a mix of C++, FP and great ideas from the history of programming.
This concludes my conference report. You can read reports of the other days here and here. I’ve had a great time. Everything was very well arranged. Thanks BuildStuff (and thanks Ibuildings for sponsoring the trip). See you some other time!