As my career has turned into full-time authorship, I often worry about distancing myself from the realities of day-to-day software development. I've seen other well-known figures lose contact with reality, and I fear the same fate. My greatest source of resistance to this is Thoughtworks, which acts as a regular dose of reality to keep my feet on the ground.
Thoughtworks also acts as a source of ideas from the field, and I enjoy writing about useful things that my colleagues have discovered and developed. Usually these are helpful ideas, that I hope that some of my readers will be able to use. My topic today isn't such a pleasant topic. It's a problem and one that we don't have an answer for.
I don't not write much production code these days, but I still spend quite a few hours writing code. This code is a particular form of code, meant for explaining ideas in books. Book code isn't quite like real code, there are some different forces to consider when writing it.
Currently there's quite a debate raging over the relative merits of Groovy and JRuby as scripting languages running on the Java virtual machine. Curious minds want to know - which of these languages will win this upcoming language war? People want to know which language to pick for a project, or which language to commit to learn.
Last weekend I attended the Alt.NET conference. It was the first named gathering of a group of people I've been watching on the blogosphere for quite a long time. A group of long-time users of Microsoft technologies who feel that their development philosophy has been getting out of sync with the perceived orthodoxy from Redmond. While some have considered moving away this group is keen to stay and try to influence the Microsoft world.
The OOPSLA 2007 conference occurred on the 20th anniversary of Fred Brooks's famous paper "No Silver Bullet". So to mark this, we had a retrospective panel, including the Mr Brooks. I was lucky enough to be invited on the panel, although I doubt they expected quite the contribution I ended up making.
A key property of agile development is figuring out how to make a system go live with a small subset of features. We build software for the business value it offers, the quicker we go live, the faster we get at least some of that business value.
I was in Boston, about to fly out to our office in Calgary. I look at my calendar to see if I have a meeting. First one is at 10.30am - cool no need to rush out of bed in the morning.
I was in the Calgary office last week and had a good chat with John Kordyback, one of our most trusted technical leads. He's worked on, and dug into, a number of travel loyalty software systems (frequent flyer/sleeper etc) and we talked about the nature of these kinds of things and how to think about them in a more fruitful manner.
Is changing the interface of part of the code a refactoring?
Should we strive to only have one language in our development efforts?
Is it worth the effort to design software well?
Last week I got the newest book in my signature series: xUnit Test Patterns by Gerard Meszaros. I've been working with Gerard with it on and off for a couple of years, so I'm fairly familiar with its contents, but somehow seeing the physical copy gave me quite a shock. Somehow it hadn't dawned on me how big the book was - 883 pages, easily the biggest book in my series.
At RailsConf2007 there was a lot of excitement over JRuby. This small team had taken a moribund project and turned it into what looks like a first class implementation of the Ruby platform on the JVM. They got a lot of cheers and deserved them all.
So with JRuby pretty much here, the spotlight moves onto the other common managed code runtime - .NET. Microsoft's intentions for Ruby are currently much less clear. They have announced Ruby as a language for scripting Silverlight - but that still leaves a lot of open questions. Is this a full implementation of the ruby language, or is some form of Ruby++ - an enhanced subset of Ruby?
I don't go to as many conferences as I used to, but the advantage of that is that I have time to go to ones that take my fancy. I've long had a particular fondness for the Ruby community, so I turned up as an attendee at this year's RailsConf.
As I explore parser generator tools for external DomainSpecificLanguages, I've said HelloAntlr and HelloSablecc. If you spend much time looking at parser generators you can't really avoid looking at the old stalwarts lex and yacc (or their gnu counterparts flex and bison). I want to explore the way lex and yacc operate, but my C has got too rusty. As Erich Gamma quipped, I've got too lazy to take out my own garbage. Fortunately there is an implementation of a yaccish system for Java, which is just what I need.
It's one thing to idle away your productive hours reading this blog, but some people like to translate it too. So I'd like to welcome a Thai translation which is being done by a team of people led by Wee Witthawaskul. About fifteen years ago I visited Thailand as a typical backpacker western tourist. I have fond memories of the river buses in Bangkok, hiking near Pai, snorkelling at Ko Pi Pi, and some great food. I first met Wee while he was working with Ralph Johnson, he's now joined me at Thoughtworks.
In the past few days I've been reviewing an in-progress article by a Julian Simpson, a colleague of mine, on refactoring ant files. Julian is one our "deployment dudes" who've been responsible for applying our agile-oriented work habits to the deployment of systems. In doing this Julian has run into more than his fair share of gnarly ant build scripts. His article is a nice description of some his favorite ways to clean up the mess.
When doing builds using make, you determine whether you need to
do work by comparing the modificiaton dates of the output file and
the input files. For things like compiling (
a.out depends of
this works well, but sometimes the output is harder to see.
I'm a big fan of Continuous Integration, it's an relatively simple practice that can make a huge difference to most development teams. However like most practices it has its flaws^H^H^H^H^H opportunities for improvement. Paul Duvall, author of the soon-to-be-standard book on the subject, pointed out one of these recently. If the commit build breaks, the whole team is affected and potentially slowed until it's fixed.
I've been exploring various alternative languages and grammars for external DSLs. One of my main tools for this is Antlr. With this kind of exploration I have a project with multiple similar grammar files where I want to run essentially the same thing with different grammars. Although I only have a few grammar files at the moment, I could well end up with a couple of dozen.
The recent fracas over death threats to Kathy Sierra has been bouncing around the blogs I read. The fact that I'm writing this shows it's triggered some thoughts of my own.
In recent weeks I've been playing with, and looking at, compiler-compiler tools. A common feature of these tools is that they have a grammar file whose core is a description of the production rules of a grammar for a language. As well as describing the grammar, the file also provides information to the parser about how to process the language as it recognizes the language elements. In most compiler-compiler tools these instructions are represented as actions in the grammar - often these actions are encoded as as fragments of code in a high level language.
A couple of years ago I was talking to a couple of friends of mine who were doing some work at eBay. It's always interesting to hear about the techniques people use on high volume sites, but perhaps one of the most interesting tidbits was that eBay mostly hardly ever uses database transactions.
A keynote for The Server Side Java Symposium that I gave with Neal Ford. We look at the growing movement towards Domain Specific Languages, what kinds of languages exist and why they are interesting. If you're looking for one talk on the subject then my preference is for the JAOO video, but this one expands on some of the themes and is more entertaining due to Neal's presence. It would also work fine audio only, if you can find a way to extract the audio stream.
The organizers of QCon London 2007, asked me to do a conference session on modifiability of architecture. I thought that rather than listening to me, the audience might prefer listen to some of the Thoughtworks architects whose ideas I usually repackage: Dave Farley, Ian Cartwright, Fred George, Erik Doernenberg, and Daniel Terhorst-North. InfoQ has now put up a video of session.
A keynote for QCon 2007 that I did with my colleague Dan North. We both see the gap between developers and their customers/users as the biggest problem in software development. (We'd call it a chasm, but that word is so overused.) Here we talk about this gap, why it's important, and what we need to do to cross it. In particular we argue that the traditional role of an intermediary Business Analyst acts as a ferry, while what we really need is a bridge that enables directly contact between developers and their customers (and analysts can build and maintain that bridge). This is one of my favorite joint keynotes, both because I think the topic is so important, and because Dan is such stimulating co-speaker.
I've done a small amount of playing around with SableCC recently. It took a bit of effort to get a "Hello World" style parser going, so I thought I'd put some notes here as to what I did to get it working. I'm not saying this is the best way to do it, but it may be useful if you're looking to play with it.
I had a need yesterday to play around with velocity in order to explore some stuff on templating and macros. I like velocity's simple template language, but this was one of those times where I wasn't using it in the context of some Java or .NET work. At that point working with velocity becomes a bit of a pain as you have to setup the context and run the processor in Java.
"'War and Peace' is a wonderful book.
"Let me see... pity this book has such a tattered cover"
Two sentences, each uses the word 'book'. We glance over combinations like this every day without remarking that the word 'book' means something completely different in each of those sentences.
When you learn about objects, you usually learn that they can capture two kinds of data: instance and class. Instance variables are the most common case, the data varies with each instance of the object. Class variables, often referred to as static variables, are shared across all instances of a class. Every instance points to same value and any changes are seen by all. Class variables are much less common than instance variables, especially mutable class variables.
(Updated as Sam Ruby persuaded me to use second-precision on my dates.)
The term 'Mock Objects' has become a popular one to describe special case objects that mimic real objects for testing. Most language environments now have frameworks that make it easy to create mock objects. What's often not realized, however, is that mock objects are but one form of special case test object, one that enables a different style of testing. In this article I'll explain how mock objects work, how they encourage testing based on behavior verification, and how the community around them uses them to develop a different style of testing.