techblog 

These are my notes from the JAOO conference in Århus in Denmark. Since this is a long post, I will start with a list of the sessions I went to and the best quote from each. If you think this is worth reading, you can click through to read the whole thing.

• Bob Martin - Clean Code - “Avoid Turgid Viscous Architectures”
• Charles Nutter and Tom Enebo - JRuby - “Struts is the redheaded stepchild that everyone picks on”
• Joe Armstrong - Erlang - “When x=x+1 is not deterministic, programming is really difficult”
• Justin Gehtland - Ruby in the Enterprise - “This stuff is not rocket surgery”
• Diana Larsen - Agile Retrospectives - “Software developers are smart people who are good at thinking individually, but not necessarily together“

Bob Martin - Clean Code II - Craftsmanship and Ethics

He started out by asking if we have a true profession. In his opinion, around the year 2000 something changed and our craft began to be defined. He thought this was to do with discipline and that this corresponded with the move towards Agile processes.

Some of the things that go into this were:

• The use of short iterations to keep projects on track
• The idea that you need to always keep moving forward. So you don’t wait for definitions, you work with others to get what you need to start working. You also strive to decouple yourself from other people and teams by the use of stubs, mocks and so on.
• Avoid Turgid Viscous Architectures. Does your architecture actually make it easier to get things done, or harder? He suggested that often it is easy at the beginning, but over time things get harder and harder.
• Incrementally improve the code - Clean up slowly over time and don’t do grand redesigns as these bring as many problems as they solve
• Progressively widen and deepen the code. So start out writing end-to-end spikes and widen them. To explain deepening he told a story about writing a login screen with another developer. The developer got to the point where the front end screen had to talk to the middleware and then he stopped because the middleware didn’t exist. Bob got him (with persuasion) to make it talk direct to the database just to get it working. Then it was easy to tease the code apart and put code in the middleware and so on.
• Don’t write bad code. You can’t argue with that
• Do proper line-by-line test driven development. Then you are only ever a couple of minutes from having everything working
• No manual test scripts - they are soul destroying and immoral. Automate everything that’s scriptable and have testers do exploratory testing looking for devious ways to break things

There were lots of other things too, the majority of which are well known agile techniques. But I thought it was interesting that he tied this in with the idea of discipline, in that you should do these things for the professional pride rather than because someone told you to.

Charles Nutter and Tom Enebo - JRuby

There wasn’t a huge amount in this talk that I didn’t know already, but it was interesting to hear about JRuby direct from the two main developers. They started out with an overview of what JRuby is and why you might want to use it.

One point of interest to me was that they said that once the compiler is complete, they will be able to compile Ruby down to Java bytecode. At this point they will ship precompiled Ruby libraries, which will be a big help for performance. They then went through different areas and how JRuby fits into that sphere:

• Swing - They showed a series of ways to generate Swing GUIs from interacting directly with the API to declarative DSLs.
• Webapps - They noted that Rails has influenced almost every other web framework since. They talked about how Java frameworks are too complicated and had a good quote “Struts is the redheaded stepchild that everyone picks on”. Then there was a discussion of Ruvlets, which are a Ruby way to do Servlets, which is apparently something they get asked about all the time.
• Persistence - Active Record was mentioned of course, but they also talked about Active Hibernate which allows a Ruby application to talk to Hibernate. This looks like it is still at the alpha stage.
• Build Automation - There was a comment from the audience that the original Ant developer no longer has it installed on his machine and uses Rake to build Java projects. Aside from Rake, they mentioned Ant Builder which is a Ruby wrapper around Ant and Buildr which is a rubyized Maven.

Finally they gave a demo. They used Netbeans, which looked pretty good as a Ruby IDE. They showed a refactoring that didn’t quite work (Ooops!), but made up for this with smart completion on regexes and ruby’s % operators. They also showed a version of Sun’s glassfish app server which is optimized for Rails.

Joe Armstrong - Erlang

This talk was by one of the originators of Erlang, who interestingly is a Brit. He said that something important happened in 2002 but went mostly unnoticed. At that point we got to the stage where you can’t reach all of the chip in one clock cycle. So a single core doesn’t cut it any more - there’s no point in increasing clock speed more and more. So chipmakers have moved to multiple cores instead.

When you have two cores it doesn’t really matter if you only use one. You are only missing out on a little of the power of the machine. But when you have a thousand or a million cores (projected by 2019), it makes a huge difference.

This has been a paradigm shift in hardware. And this is a real shift, not just marketing speak. We need to do the same in software. Can we make it so that running our code on N cores means it goes N times faster?

The problem is that the usual model of concurrent programming is very hard and error prone. He had a good quote: “If x=x+1 is not deterministic, programming becomes very hard”. Concurrent programming in languages such as Java uses the shared memory model of programming. The Byzantine Generals Problem shows that 2 phase commit doesn’t always work so this method will always be error prone.

The alternative is to use message passing and no shared state. He said that message passing is like email, you can’t be sure that the recipient got it unless they send you a message back. He also said that people work in a concurrent way naturally and understand this stuff deeply, but obviously we don’t have shared memory.

So Erlang is built around the idea of message passing. It enforces no shared state by being a functional language where everything is immutable. It is actually rather an old language (1986), which has been open source since 1998.
The overall philosophy is to use lots of processes, avoid sequential bottlenecks and use large computation and small data transfer to get the job done.

Justin Gehtland - Ruby Enterprise Case Study

Again, this talk was not earth shattering, but there were enough little nuggets of interesting stuff to make it worth attending. He looked at the uses of Ruby in Enterprise environments and how it is seen as only being useful for green-field development and small scale applications. In his opinion, the ‘Enterprise’ is not a single thing that needs one solution - you should be using multiple tools and technologies and Ruby has its place. He suggested that if you use JMS or HTTP to link systems together then it doesn’t matter what language they are written in.

The case study in question was about a big insurance company’s bond application. He talked about what they did and the lessons learnt. They developed an application with a small team in Ruby in just a few months while the previous team had taken years and not delivered anything. Part of this might have been down to having committed developers, but it was impressive nonetheless.

They used JRuby, but only so that they could use JDBC to connect to a DB2 database on a mainframe, the C Ruby implementation being very flaky. They also used VMWare for testing to mock out a legacy system. He suggested a couple of rules for bringing Ruby into the mix:

1. Have a plan to manage your Ruby processes - use something like Monit or God.
2. Test everything and then test for performance.

He also said that many of the things that they expected to be problems turned out not to be. For example, things like SOAP support can be handed off to other processes outside Ruby where needed. He scoffed at the idea that you need Wizard developers to handle things like Metaprogramming. Remember, none of this is rocket surgery!

Diana Larsen - Agile Retrospectives

In this session, Diana Larsen talked about techniques for getting teams of people to reflect on what they are doing and adapt their practices to suit the situation. She said that software teams are good at thinking individually, but not necessarily together and pointed out that this is not a skill we are generally taught in the education system.

Something that interested me was the idea that these retrospectives could be triggered by different things other than just the end of a development cycle (iteration, release, project). She suggested that a big surprise in the project was a good time to have one. She gave the example of a company getting taken over, or a big change in the market.

The steps she outlined for running a good retrospective were:

1. Set the stage - This means firstly choosing a goal for the retrospective which is not the same each time. Otherwise the process becomes repetitive. So you might focus on improvement of customer communication or improvement in code quality. Another thing to do at this stage is set out the ground rules for the retrospective. She mentioned Norm Kerth’s Prime Directive as a possible rule.
2. Gather data - at this point you produce charts, timelines etc and most importantly get some agreement about the matter in hand.
3. Generate insights - now you are ready to start looking for patterns and drawing some conclusions from the data. She said that technical people tend to jump straight to this point.
4. Decide what to do - once you’ve worked out what is going on, you can decide how to influence the situation. She said that you need to concentrate at this point on finding a Best Fit solution rather than a First Fit, i.e. the first thing you thought of. Apparently business people tend to jump straight to this stage in the process.
5. Close the perspective - finally you work out how you will make these ideas actually happen.

There were one or two other techniques around the retrospective that I found interesting. She suggested giving people a chance to give feedback on the retrospective itself in terms of “Return on Time Invested” so that we can possibly improve the retrospectives themselves over time. She also mentioned that any changes that come out of a retrospective need to be supported by giving opportunities for people to learn and practice new techniques, or simply to remind them of what was decided.