The last two days I hit some great sessions and some blah sessions. As I mentioned in my last post, my favorite part about this conference has been the people I’ve met and not the sessions as much. The third day I really saw that it can be tricky because although you can respectfully bail within the first five minutes of the presentation, I haven’t been able to decide if it is a miss until I’m in too far to make a switch.
Fortunately the day started off awesome with Matt Stine applying Uncle Bob Martin and Michael Feather‘s SOLID OOP principles to functional programming. As Matt pointed out, principles are universally true, and hence there should be no reason we cannot apply SOLID to functional programming. He did a fantastic job of demonstrating these principles with some Clojure code that I was able to mostly understand. The coolest part of this presentation was towards the end when he brought up the notorious Simple Made Easy keynote by the venerable Rich Hickey, and defined each of the SOLID principles in terms of complecting stuff that should be separate.
After such an outstanding talk, I thought I’d hang around and enjoy Matt’s next talk, Programming with Immutability. I should have read the overview/slides before this one started because it was all Java. Granted I still enjoyed the topic, I probably could have found something more relevant for me. Once he got into some details of different libraries to aid Java developers in adopting more immutability, I caught a severe case of disinterest and worked on yesterday’s blog post.
The next talk I attended was another dose of Nate Schutta titled You’re an architect… Now what?. I thought this would be a good one given my previous experience with Nate and my still-recent entry into the world of architecting. I came out of this talk quite reassured about how I’ve been approaching my opportunity.
After lunch I caught Rob Spieldenner showing off some of Netflix’s cloud goods. As much as I really enjoyed hanging out with Rob and Dan Woods from Netflix, this was not the talk for me. In a nutshell, it was a workshop on AWS using stuff that Netflix built because they don’t use Elastic Beanstalk. Although Rob did a fine job with the workshop, it just brought me back to how much I don’t enjoy the AWS aspects of my job.
I had no qualms skipping the second half of the AWS action for some scaling agile action with Esther Derby. This talk was probably better than I realized, but the exhaustion of the conference was building quite strongly by this point. I wasn’t able to focus very well, although I did live tweet a handful of good nuggets. Other than my general interest in agility, my primary motivation for attending this talk is to be prepared for when my team grows or our project gets other teams working on the code base. The problems we have at our tiny size will be very different from the ones we’ll have when (not if) those things happen. The biggest point that resonates with me is her suggestion to not divide teams up by component/function. Each team should be full-stack and able to deliver working pieces of functionality without depending on another team for the rest of the vertical slice. Beyond that I mostly came away with more reinforcements for what I’m already learning at work and through other resources such as This Agile Life.
I started the next day watching Rob talk more about Netflix, but this time it was about continuous delivery. Although I like where my team is on this front, I know we could get better. One of the most interesting things I discovered is that they don’t just deploy application code like we do. Their teams build out (or “bake” as they like to call it) the application code along with a machine image which eventually gets dropped and deployed on the cloud. I also learned that there are a lot of monkeys running around their cloud. The have scripts they’ve given monkey names that randomly kill off machine instances in production, in addition to scheduled drops of availability zones and regions.
Haskell is every bit of bad ass I expected. I was pretty comfortable with many of the concepts because of my work in Scala. As much as I love type inference in Scala, I didn’t realize how much I was missing. Haskell will look at the body of the function and infer output AND input types. I’ve been doing Java and Scala so long, that it hadn’t even occurred to me that such a thing could happen. I really love the ideas behind having an IO monad and all that good stuff, and it was cool seeing it in action. One thing I didn’t expect to see is how the inputs to a function can be pattern matched right there at declaration time, reminding me of what I’ve seen in Erlang. I also had forgotten how every function in Haskell takes at most one argument. More arguments just means that you’re really returning another function with the next argument. Unfortunately, I’m in the same place with Haskell as Clojure… I don’t know what I should aim for next. I need to dream up something I can build with each one.
So that was the rest of the sessions I attended. As I’ve said many times, the best part is the stuff I’m not bothering to write up: Hanging out with other developers. Although I enjoyed a lot of talks at this conference, I would gladly return only to hang out. I’ve made some great connections that I’m excited about and I look forward to what some of us might be cooking up in the near future. Stay tuned.
Leave a reply below, or send me a tweet.