Monday, September 30, 2013

GOTO Day 1

Day 1 of this years GOTO Aarhus is drawing to an end. It's time to recap. As always at a large conference there are a lot of things going on at once. So I may just have missed the action. But, well, to be honest I didn't get enough bang for the bug today. I had a hunch this was going to be the case today because too much of today's program seemed to be either too much talk and too little code for my taste or to be really introductory.
On the other hand there were highlights:
  • Phil Calcados Javascript talk. Phil has been involved in recruiting at Soundcloud for a few years. As part of the interview process Soundcloud has candidates submit code in whatever language the candidate wants to. Interestingly Phil observed that a very high percentage of the submission done in Javascript were rejected, and the candidates did not make it to the next round of interviews. Submission in other languages did better. It is also noteworthy that there were actually a large percentage of the submission that were in Javascript - so the high rejection rate does not seem to be an artifact of sampling size. Phil talked about some of the problems in the Javascript submissions, what could be done about them and ventured guessed at why Javascript stood out in this way. Interesting stuff. 
  • Mogens Heller Grabe's Rebus talk was by far the best talk of the day for me. It was concrete, had lots of code and it put some conplicated architectural ideas into fairly simple terms. Mogens talked about distributed system, anchoring the discussion firmly in reality by doing live demos of the patterns and by exmplifying based on his personal experience working with real clients. Great!

The part keynote will in a few minutes. So I'm off :)

Sunday, September 29, 2013

The "Instant Nancy Web Development" Book

After a quick six month writing and editing process my Nancy book is published. It's available as e-pub, mobi, pfd and dead trees via the publishers site as well as Amazon, Amazon UK, and Safari.

What's it about?
Well, it about the Nancy web framework. Nancy is an awesome .NET based web framework that focuses on being both easy and fun to work with. Nancy lends itself to writing highly testable web application with simple, concise and readable code. Who doesn't want that?
The book starts from the very basics of getting Nancy up and running, but quickly moves into more interesting areas including dependency injection, hosting, content negotiation, authentication, async processing and more. Check out the full table of contents at the publishers site.

Who's it for?
The reader I've had in mind is a .NET oriented backend developer who values clean testable code and who is curious about what all the fuss around Nancy is about. It's a short book, so it is also a quick read and a quick way to get into a whole bunch of Nancy topics.

Why did I write it?
There are a number of reasons I wrote this book. I'll only talk about a few of them here. Starting from the egotistical side @thecodejunkie nailed it on jabbr: "It's about bragging rights" :-) I have to admit there is truth in that.

Another reason is that I really think Nancy deserves having a light shone on it, and I believe a book is one way to do that.
I believe a book can reach another segment of developers and architects than Github wiki, blogs and demo applications. The book hopefully wont be the end stage for those developers and architects, but rather the gateway to the Github wiki and even the Nancy source code, which is so readable that it actually is a fine source to learn Nancy from.
I also think a book can lend a sense of legitimacy to an OSS, which may help a little bit with getting through the gate into enterprises. @cranialstrain expressed this well on twitter the other day.

Saturday, September 21, 2013

Impressions from Software Architecture Open Space 2013

We ran the 2013 edition of the Software Architecture Open Space conference (SAOS) this past Thursday, and once again I am amazed how well the open space format works. Everybody there were both highly knowledgeable and keen to share. The combination is a goldmine of learning opportunity.

The topics covered this year were quite diverse. Ranging from the particulars of to the most effective place in an organization for an enterprise architect to work.

Since there were up to 7 seven sessions running in parallel I did not participate in all discussions. Even so just looking at the topics I had the chance to discuss paints a broad picture: "Event Sourcing in practice", "Modeling in NoSQL DBs", "How to Build an Architecture that Enables Flow in Development", "Reactive Manifesto", "NoProcess Development", "Architects and Organizations" og "The Value of Contributing in Open Source".

Take Aways
What one takes away from an event like SAOS obviously vary a lot lot from person to person. Personally the main points I came away with were:
  • I am not the only one that thinks that lean thinking can be applied to software architectures, not just organizations and processes. Hallelujah I am not alone :-P
  • Confirmation that Continuous Delivery is slowly but steadily becoming mainstream
  • A better understanding of the role of Enterprise Architecture in large organizations (and confirmation that EA is not for me)
  • Lots of new good contacts
  • Insights into concrete experience with introducing event sourcing to a team and which type of common hiccups to expect

Saturday, September 14, 2013

Eyes Forward?

Over next couple of weeks I'm attending two conferences. Two very, very different conferences. The first one is the Software Architecture Open Space 2013 (SAOS) and the second is GOTO Aarhus.
  • GOTO is a traditional conference where there is a divide between those who contribute content - the speakers - and those who consume - the attendees. SAOS is not traditional and completely erases that divide by demanding all attendees to contribute.
  • The GOTO format is well known: The speaker prepares a talk based on his/her experience and expertise. The attendees flock into a room, sit down and listen for an hour - all facing toward the speaker. The SAOS format is less well known: Nobody prepares content beforehand, but everybody contributes to it during the conference. Session topics are found through brainstorming and agreed upon progressively throughout the day. For sessions attendees flock into a room, sit down and discuss for an hour facing each other.
  • GOTO is big - lots of people, lot of tracks. SAOS is small - about 50 people, as many tracks as emerge.
  • GOTO is well publicized. SAOS is invite only.
  • GOTO focuses on teaching attendees about ideas or technologies that the speakers already know about. SAOS focuses on finding and developing ideas and techniques.
  • At GOTO the networking happens in the proverbial hallways and at the social events. At SAOS networking happens just as much during the sessions.
It will be interesting to get to go these events almost back-to-back. I expect the two to be very different, but I also expect to learn a lot at both.

It is also interesting that GOTO has a fish bowl session on Tuesday. A fish bowl is in the same vain as the open space format used at SAOS. Whether it really works in such a large setting will be interesting to see.

And, by the way, in case you are wondering, SAOS is the successor to the Agile Architecture Open Space Conferences I've run the last two years. This time around I've had the good fortune of getting invaluable help from some awesome partners in crime (Nikola Schou-Pedersen, Jeppe Cramon and Jakob Bendsen), and I think the conference will even better this year.

Sunday, September 8, 2013

Playtime: Riak, Azure, F#

Sifting through the programme for this years GOTO conference one of the talks I thought I'd go see was the one on Riak in the big data track. This is not a new topic at GOTO. In fact I've seen several really good Riaks talks there (like the Riak on mobiles one, that has also been at GOTO). Each time I've gone out of the talk thinking "I've gotta play around with Riak! It's cool." This time around I thought I'd start the playing around beforehand, with the added benefit that I have a bit more context coming into this years Riak talk.

What follows is a short account of my Hello World level experiences of getting Riak up and running on Azure and talking to it from a bit of F# sharp code.

Riak on Azure
As someone who works mostly on Windows the first thing I ran into with Riak is that there is no Windows option on the downloads page - it's different Unix flavors all the way through. Not worry though, in the cloud age spinning up a new Unix box is easy. As it turns out getting Riak on there is pretty easy too (just a few curl commands and that's it): I just followed the step-by-step guide to running Riak on Azure. The guide is little bit out of date with regards to the screenshots from Azure, but nothing that will trip you. The stumbling block was the very last curl command in the guide which is

curl -s | sh

but just gives you a redirect to a page on github. It's not a hard stumbling block though; you just follow the redirect and put in this command instead:

curl -s | sh

At this point I had a VM in Azure running Riak. I was able to put data into it and read it again through Riaks HTTP API simply using more curl commands.

Talking to Riak with F#
The basics of Riaks HTTP API are pretty easy - HTTP PUT to create a new key-value pair in a bucket, HTTP PUT to modify existing values, and HTTP GET to read them - but even doing that with curl gets a bit cumbersome pretty quickly. So here is how to talk to Riak with F# code using xUnit as an execution container.

First, checking the Riak cluster is even reachable can be done by pinging it like this:

Moving on to adding a key-value pair and implicitly creating a bucket too looks like this:

Finally reading data out again looks like this:

And that's it for getting data in and out of Riak from F# code.

Sunday, September 1, 2013

From Fact to Theory

I often find that the tests I write can be slowly generalized as the feature I happen to be working on is fleshed out. In terms I find that a fair number of the tests tend to move through these four stages:
  1. Start out as a single [Fact], working on hardcoded input data
  2. Pull out the hardcoded data, turning the tests into a [Theory, AutoData]
  3. Add edge cases, evolving the test into [Theory, AutoData, InlineData, InlineData]
  4. Add cases representative of equivalence classes, thus adding more InlineData attributes to the test
Each of the stages generalizes the test a bit more making it more potent in several ways. As the test moves through each stage it gains greater coverage in terms of the possible inputs, making it a better regression guard. But there is more at play. Along with the generalization (and multiplication) of the inputs the test can often be refactored towards being more about the behavior of the SUT and less about its implementation. So alongside the four stages above I find tests tend to move through these stages as well:
  1. While being a [Fact] the test is named something very specific - a specific example of how the SUT should behave
  2. During stage 2 or 3 the test name becomes something that expresses a general trait of the SUT
  3. The assertions in the test becomes less dependent on implemntation details
I am not always able to make my tests follow either of these progressions, but when I am I find it very rewarding.