Paul's techie blog

2008-09-26T23:16:00.002+01:00

Scotland on Rails 2009 - Call for Proposals

Last week, we opened up the CFP for Scotland on Rails 2009. After the success of this year, and the buzz around SoR in Berlin, next year's going to be pretty special. We've already confirmed keynotes Marcel Molina, and Giles Bowkett. Chad Fowler's coming too, and is teaching a charity tutorial along with Marcel.

The venue is University of Edinburgh's Pollock Halls again, 26 to 28 March 2009.

The call for sessions is here, by the way: http://scotlandonrails.com/proposals.html.

2008-09-24T22:36:00.003+01:00

Rails Conference 2008

It’s been a few weeks since the European Rails Conference in Berlin and about time I shared my experiences.

Vibe

At the Bratwurst on Rails someone asked what I was excited about seeing at the conference, and I couldn’t answer. Last year DHH’s keynote was that the revolution was over, which seems to be holding true. Changes are steady and incremental, and there doesn’t seem much to get really excited over. This year’s DHH keynote was on refactoring (without mentioning the word): he made good points but nothing particularly new to anyone who’s been exposed to Extreme Programming .

I don’t know how much this was just my perception, but the conference felt a bit flat.

Ruby with an Accent

Alan and I talked on organising a regional conference; considering who we were up against and the niche non-technical nature of our talk, it was reasonably well attended and was followed by a lively question and answer session which spilled into the corridor track. The slides are here. The session has also been accepted at RubyConf in Orlando but I’m not going to make it Graeme will be talking my place.

RSpec

Last year there was a lot of excitement and sessions around RSpec this year not so-much. The corridor-track did confirm, though, that it has become the de facto method of testing Rails apps. This is despite a large amount of indifference, even perhaps hostility, from the Rails core-team. I haven’t tried or been exposed to RSpec much, though I admit to feeling a certain amount of antipathy towards it and ‘BDD’ – largely I don’t see the point. However people new to programmer testing do seem to get it.

One concern is that discussions around the advantages of RSpec seem to place it in the acceptance/customer testing niche. I wonder if it is being used appropriately at the unit level. I really should try it out properly; I may even become a convert.

Ruby versions

Ruby’s David A Black led a well-attended plenary symposimi which touched on the new Ruby versions. There didn’t seem to be a lot of excitement around 1.9, and zero interest in 1.8.7. Pretty much the entire conference was present and from a show of hands, probably 25% had looked at 1.9 and a handful 1.8.7. There was one person using 1.8.7, and that was because it was the only way she could get a patched version for whatever Linux flavour she was using.

Alternative VMs

Rubinius

The Rubinius presentation clashed with ours, but from what I’ve heard (and gathered from other sources) the big news is that there’s not much news. They seem to have embarked on a rewrite phase and a 1.0 release is sometime away.

Maglev

“Monty Williams:http://smalltalkers.ning.com/profile/Monty ran a Maglev BOF, which was really more of an unofficial presentation running after hours. Again, there’s not much to report here – it runs benchmarks significantly faster than MRI. (The really interesting aspect – the transparent persistence wasn’t even demonstrated.) A public beta, never mind a 1.0 release, is not going to happen anytime soon.

He did suggest that the eventual licensing model would include a reasonably generous free option. I didn’t make a note, but I think he was musing on single CPU and 1 or 2GB memory for free.

JRuby

I didn’t go to any “JRuby:http://jruby.codehaus.org/ presentations as there didn’t seem to be much that new and exciting to see. From speaker-room conversation, I gather they are pushing the multi-threading advantages with Rails, and deployment on Glassfish. They are, also making steady progress with regular 1.1x releases and remain the only production alternative to MRI.

Working with multiple applications

A recurring theme for me (well one tutorial and one presentation) was dividing your application into many little apps, both for re-packaging in different contexts and maintaining modularity / separation of concerns. This is an approach I’ve never tried but quite like, although I’d always felt a bit vague about how it would actually work. My only known example, 37s’ Basecamp integration with Campfire and Writeboard seems quite a kludge. Two approaches were presented: creating applications as ‘resourceful’ plugins; deploying multiple applications with a single sign-on.

Resourceful plugins

The ‘resourceful’ plugin is an approach to reuse mini-applications across many different sites. A conference site, for instance, is really a mixture of different applications: you might want a CMS for displaying the more static content, a blog application for news, a session submission and approval application, and a delegate registration application; a product site might want a CMS and blog, but need a shopping cart. Both sites probably want to customise the applications in some way.

In a half-day tutorial Ben Scofield presented an approach for extracting those separate applications into plugins for reuse, and non-invasive customisation, in different applications. This is a similar approach to Engines, but without the need for a framework and deep hooks into the Rails code that need to be fixed for each release.

There presentation is here. You might also want to check out the source for bloget and sandstone, a blog and CMS application written as resourceful plugins.

Multiple co-operating apps

Justin Gehtland’s presented a different aspect: deploying your site as multiple small rails app. The is more robust: if one app goes down the other’s keep going. It also makes it possible to scale and tune different parts of the application according to their own usage. The illusion of being a single app to the user is maintained through a single-signon server (eg RubyCAS-Server), sharing code through plugins, a shared common database, and asynchronous messaging (eg via active-messaging).

Justin’s written this up with example code here.

As well including some great material in his talk, Justin is also a hugely entertaining speaker – this was my favourite session of the conference.

Fizzled out

Like last year, there was no closing keynote: the last session ended and everyone just wandered off; the conference just fizzled out, like this blog post.

2008-08-28T22:44:00.000+01:00

Off to Berlin

I’m looking forward to going to to Berlin next week for RailsConf Europe. Last year’s conference was interesting and great fun.

This year I’ll be speaking with Alan Francis on organising a regional conference.

2008-08-19T23:30:00.001+01:00

Clarke Ching’s Bastard CEO

Being such a nice chap, Clarke’s having writing the Bastard CEO in his soon-to-be-published business novel. Ironically it is incredibly easy for someone in a position of power to become an arse-hole: all they have to do is ignore their elevated rank.

In Gore Vidal’s historical novel Julian, the newly created emperor is taking a bath while discussing politics with his uncle, a distinguished senator, when his friend Oribasius arrives:

I submerged for a moment, eyes tight shut, soaking my head. When I came to the surface, Oribasius was sitting on the bench beside my uncle. “That is no way to approach the sacred presence.” And I splashed Oribasius very satisfactorily. He laughed. My uncle Julian laughed too, for I had soaked him as well. Then I was alarmed. In just this way are monsters born. First the tyrant plays harmless games: splashes senators in the bath, serves wooden food to dinner guests, plays practical jokes; and no matter what he says or does, everyone flatters him, finds witty his most inane remarks. Then the small jokes begin to pall….

Before he became emperor, Julian would have received some censure for splashing a senator: he has now lost that feedback; as emperor he now must either have the discipline and self-awareness to be an accurate judge of his own behaviour or becomes another Nero or Caligula.

Fortunately our managers and CEO’s don’t quite have the power and privileges of Roman emperors, but they often run mad in their own smaller ways. This is especially true if they believe their own myths about their “open door policy”, or “speaking their own mind and expecting everyone else to do the same”. One of the lessons I took from the Deep Dynamics of Agile Teams course I helped organise a few years ago was that figures in authority cause resentment when they do not recognise their own rank. Behaviour which is acceptable between peers, can be inappropriate when coming from a high ranking individual: for instance gallows humour about the likelihood of redundancies is okay amongst work colleagues, but in extreme bad taste coming from a CEO.

I imagine Harry, Clarke’s fictional CEO, to be someone lacking Julian’s astuteness; he has come to believe what is implied by the behaviour of his subordinates that he is a particularly witty, interesting, and wise individual who’s views everyone is eager to hear. I would expect a Bastard CEO like Harry to

talk the most and for longest during meetings avoiding soliciting, listening to, or giving much time to other’s views or questions
make inappropriate jokes about other’s abilities, timeliness, or diligence (a joke about installing closed-circuit cameras to stop people slaking off for instance, would be great for demotivating a stressed-out development team)
organise meetings (or more likely get his PA to do it) and turn up very late, or not at all. After all, no-one ever complains and Harry’s time is more important than everyone else’s time.
lecture others at length and in detail on how their jobs should be done, without any regard for the other’s skills, experience, or actual productivity
Blatantly appropriating other’s ideas as his own by copying entire emails or documents and signing them “Harry”, after-all when he owns the other person that person ideas are his own. Besides he probably inspired them anyway.

The corrupting influence of power is often about losing basic social feedback. Finding ways to give the individual feedback on his or here behaviour can be a way of making working with them at least tolerable. It can be a dangerous game though; sometimes it’s best to just stay out of the way.

2008-08-15T23:00:00.003+01:00

Mocks considered harmful

Some time ago I tired of using JMock. I’d come to realise that it was badly affecting my production and test code. I have since seen these problems consistently repeated in heavily mocked code-bases: these include incorrect production code with passing unit tests, hard to change production code, functional object decomposition, too many classes, hard to read tests, mammoth test set-ups.

Concerning mocks, stubs, fakes, test doubles

Martin Fowler’s Mocks aren’t stubs essay clearly explains the distinction between Mocks and Stubs, and the associated “Interaction-based” versus “State-based” testing. He now uses Meszaros’ terminology of “Test Doubles” to mean any object that a test substitutes for a production object and Fakes which provide completely functional but unfit-for-production “Test Doubles”. I am not going to use the Meszaros: I’m uncomfortable with “Double” as being an unobvious term, preferring “dummy object” (I would use “fake” if it hadn’t been taken); I don’t think the distinction between stubs and fakes is important or, in practice, clearly defined.

Mocks and stubs are both “dummy objects”. The distinction is important as they tend to encourage different styles of testing and production code. With mocks you would set up your expectations of its interaction with the production code, then run your test; typically integration with xUnit ensures that the expectations were met. Stubs are simple drop-in replacements for production objects, supplying canned answers to various operations. Mocks invariably come from mocking frameworks, while stubs are typically hand-rolled.

Mock objects come packaged with their own ideology: the plausible belief that classes should be tested in isolation and in terms of the way they interact with their collaborators. This is Interaction Based Testing.

Classically we would use production objects where possible, only stubbing out objects which live on the edge of the system, such as database access code. Tests would be written in terms of what is different after running the code under test, hence the retronym ‘State Based Testing’. Any interaction testing, such as checking parameters sent to the database, is done by recording method calls and arguments and checking the results by old-fashioned xUnit asserts.

Mocks make hard to follow tests

Back in my mockist phase I would often return to some tests, and be surprised at how much difficulty I had following my own test code despite the (specious) elegance of JMock’s fluent interface. The unnatural ordering of actions in a mock tests doesn’t help: mock test inverts the order of cause and effect. In a classic test the order is

set up the environment
run the test
check what happened was what we expected to happen

In a mock test it goes

set up the environment
set up the checks for what will happen (expectations)
run the test

Putting the “assertions” before running the test violates the way my brain expects the universe to operate: I’d normally expect to check what happened after it occured. Also setting up the environment often merge into the test expectations blurring the purpose of the test. Mock tests tend to come with a large amount of setup code, the sheer volume of which hampers readability.

While mock-code is hard to read, it is not correspondingly hard to write, and so abstruse code is encouraged.

Wrong code that passes the tests

Mock tester writers use more mocks than classicists use stubs. This partly because of the mockist philosophy of testing each class in isolation, and also because the existence of a framework attracts its use (while stubs tend to be hand-rolled). The risk with dummy objects is that they can embed incorrect assumptions about how the real code operates. An easy example is production code assuming one based indices or while the dummy assumes zero based.

While test-driving heavily mocked code we often needed to fire up the debugger – we had a bunch of passing unit tests, but the functional tests were failing.

Mocks hamper refactoring

Mock tests concern themselves with the behaviour of the class under test – how its objects interact with its collaborators. A mock test is all about what methods are called, and with what parameters on the mocks. The tests are concerned with implementation rather than results. Common refactorings such as ‘move method’ break these tests, rather than being supported by them.

On a recent project the first stage of a refactoring was often a purge of the test’s mocks so that it can support the changing implementation; as a side-effect we invariably rendered the test more readable and smaller. This does increase the cost of many desirable refactorings above a level consistent with adding functionality. Tests should lower the cost of change, not increase it.

Mocks encourage too many classes

There is something about Mock tests, often aggravated by dependency injection frameworks and a knowledge of GoF design patterns that tends to encourage Functional Object Oriented Programming, aka Treating Your Verbs as Nouns. At the height of my mockism I was once writing some code to convert TIFFs to PDFs by shelling out to tiff2pdf. As far as I remember, the process involved a ‘LocateTiffToConvert’ object, a ‘CreateUniqueFileName’ object, a ‘ShellOutToSystemCommand’ object, a factory for configuring the objects, and I still needed something to coordinate the process¹. Each was thoroughly tested, but it’s way too much code for a simple action.

It’s not just me, I frequently see this violation of simplicity in mockist code-bases. It can make things horribly difficult to understand, both by the sheer volume of classes involved and its tendency to obscure the domain with technical concerns

Disclaimer

Nearly all my experience with mock-objects has been with Java and JMock. I have used Ruby’s Flexmock a bit and find it more palatable: I suspect that this is because Flexmock is really at least as much a stubbing framework as a mocking one; also coding in Ruby is always more palatable than Java.

¹ I also wasn’t pairing, being the only programmer on the project. Pair programming – may help prevent you coding like a tit.

2008-08-15T18:29:00.000+01:00

Triple Programming

A question that came up during some training the other day was “if two people are better than one, wouldn’t three be better than two? Why not triple programming?”. You can come up with all sorts of reasons against 3 people coding on one computer, but real the answer is that we tried it and it didn’t work. XP is not built on a set of theories: the practices are things which have been tried and found to be successful on real projects. Beck once said that all he did was observe Ward Cunningham and write down what he did.

2008-05-14T02:05:00.004+01:00

FastRI set up on my Mac

RI is a bit like the Unix man command for Ruby, giving command line access to API docs. Trouble is that It can be slow, bordering on unusable. FastRi is miles faster. You do need the fastri-server running though. Here’s my setup.

First I installed FastRi. You can do a gem install, but running from a tarball install is faster, so I downloaded fast-ri.0.3.1.tar.gz from the Rubyforge page and untarred. From that directory I ran


$ sudo ruby setup.rb all --bindir=/usr/bin/

Then I checked it worked by running fastri-server -b to build the index, then fastri-server to run the server. In another terminal I type fri Array, and the RI documentation for Array appeared at greased-ferret speeds.

Next I want the server to run in the background on startup, so first I killed the current fastri-server and created a launchd plist configuration, /Library/LaunchDaemons/fastri-server.plist


    <?xml version="1.0" encoding="UTF-8"?>
    <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
    "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
    <plist version="1.0">
    <dict>
        <key>Label</key>
        <string>fastri-server</string>
        <key>KeepAlive</key>
        <true/>
        <key>ProgramArguments</key>
        <array>
            <string>/usr/bin/fastri-server</string>
        </array>
    </dict>
    </plist>

Next I kicked the Daemon off


$ sudo launchctl load /Library/LaunchDaemons/fastri-server.plist

Then I confirmed that fri Array works again, this time from the fastri-server daemon.

One thing still irritating me was that an RI document of any size scrolls off the top of my terminal window and I need to scroll up to read it. I added a little shell script somewhere on the path, fastri-less.sh


#!/usr/bin/env sh

/usr/bin/fri -f plain $1 | less

Next I aliased fri, and ri to use the new script. In ~/.profile


    alias ri='fastri-less.sh'
    alias fri='fastri-less.sh'

That's about it. Toying with setting up a job to reindex fastri every so-often. I'm not sure it's necessary; I'll see.

2008-05-04T08:10:00.001+01:00

From Job recruitment spam

Please note it is essential that applicants have worked in a structured development environment ideally utilising the Agile (SCRUM, XP) methodology or any other similar methods such as Waterfall, RAD or RUP.

2008-04-22T22:23:00.001+01:00

Scotland on Rails

It’s over two weeks since the Scotland on Rails conference. All the feedback, and the general feel of the event, convinces us that it was a huge success. Conferences, like parties, are complex beasts: there’s not a straightforward relationship between cause and effect, and even the success criteria cannot predicted in advance. All us organisers can do is control the starting conditions, lay down some boundaries (start-stop times, meal breaks), scatter some attractors (presentations, talks, beer and pizza), and hope something good emerges.

Nether-the-less we humans are hard-wired to see causal relationships and despite myself I can’t help believing some of the following helped:

Having one and a half tracks. There’s much to be said for having a good proportion of shared experience amongst the attendees, while the extra half track enabled us to use more of the (excellent) submissions and achieve a good balance of local, international, new, and experienced speakers.
A superb venue (by and large), with lots of room and natural light between sessions. The Edinburgh First staff were amazingly helpful; I strongly recommend them for other events.
A great T-shirt design (thanks Bruce Williams). T-shirts are important for techie conferences, establishing identity amongst the attendees. You wear the t-shirt; you reaffirm having been there.
The Crags pub opposite the venue served as a good focal point for evening meetups. It was easy to find, spacious, served food, and most people were there. Ok, it’s not a fantastic pub, and it was a pity that many of the US visitors didn’t get much further afield, but having one place to meet in the evening added to the feeling of community
Big-name, international, and up-and-coming speakers. I don’t know for certain, but it feels like our decision to invite Koz early on changed the nature of the event from a small local affair to an international conference. It certainly helped give us the confidence to go after other speakers and sponsors.
Edinburgh is a lovely city, and a world-tourist destination. I wonder how much that influenced our US peakers and delegates.

There were a lot of other factors, and we’ve learnt lessons we’ll apply to next year: particularly on the marketing side. Maybe Scotland on Rails 2009 will be even better.

2008-03-13T23:31:00.001Z

Thought for the day

Agile projects have no real defensive walls; all they can do is deliver return on investment and hope the business values it. But we all know that ROI is only a part of what moves businesses. Those in the Agile world all know of resistance to Agile from those middle managers who see it as a threat to their power to command and control. Telling such a person that her sabotage endangers the company's ROI is like an abbot standing in the path of Christian raiders and threatening them with loss of their immortal souls: sometimes it works, but nowhere near often enough. And it never works with the worshippers of Odin.

Brian Marick

2008-02-19T22:57:00.002Z

Acceptance testing with FIT

Last month Brian Swan and I gave a pretty damned good talk for Agile Scotland on Acceptance Testing with FIT. The feedback was great, anyway. The slides are here.

If you missed it, don't worry. We could be giving the talk again at Developer Day, Scotland. If you want to hear the talk, you need to register and vote for us here.

2008-02-17T22:49:00.001Z

Scotland on Rails Registration now Open

At last, Scotland on Rails (4 – 5 April 2008) registration is now open, and we’ve managed to keep the price low: it’s £180 for two days. We’ve keynotes from Michael Koziarski and David Black, not to mention a strong line-up of sessions (includes Jim Weirich for God’s sake!) from Europe and the USA.

Register here. Oh and don’t forget the charity tutorial on Thursday April 3rd. We’re firming up the details, but that’s going to be well-worth the £75 (minimum) donation to the Children’s Hospice Association Scotland.

2008-02-07T22:30:00.000Z

Scotland on Rails Speaker list

The full Scotland on Rails speaker list is now available here. It's an impressive line-up, with a good mix of "names" and local talent.

The conference will 4/5 April 2008, at University of Edinburgh's Pollock Halls. We'll be opening registration soon.

2008-01-23T23:39:00.000Z

Unit tests are best

Last year I was reading Eric Raymond’s The Art of Unix Programming and was struck by the statement that “debugging often occupies three-quarters or more of development time”. Yes, I thought, I remember when that was normal. In the old days I used to spend a few hours coding something, then the rest of the day working out how I’d done it wrong.

These days any time spent regularly debugging is a sign of something wrong. That’s a significant, and short-term, productivity gain of Test Driven Development that’s often forgotten. Done properly TDD means when you’re done, you’re pretty confident that you’re done. You can go on and do something else.

TDD is mostly about unit-testing, and the trouble with unit-testing is that it’s only the units that get tested. The interactions between the units can be left out, and that’s where the errors creep in.

Let’s say you have a class that represents a spreadsheet; another class is responsible for populating the spreadsheet. They are both thoroughly unit tested, but one assumes the row index is zero based and the other that the row index is one-based. You may have a bit of debugging ahead.

Functional tests are commonly used to plug this gap.

Functional tests are great. They are worth having to boost confidence in the general correctness of the code; but they are a safety net. They are not a good place to be catching problems: they run on a slower feedback loop than the unit-tests and when they highlight problems, and because they cover bigger chunks of code it can be tricky to find the source of a problem: they bring you back into debugging land. They also tend to take longer to run, and complicate the build. And they can be a pain to set up, especially if you need lots of supporting data.

You can reduce your reliance on functional tests by minimising the assumptions made about the rest of the code in your unit-tests. One way to do this is to steer clear of the Mock Object fetishism that is sweeping the nation(s).

Use the real objects when you can. Sometimes, though you do need to fake things.

Let’s say you’ve some Java code that produces Json to be consumed by an Ajax request from a browser and processed by Javascript. You can unit test the Java with Junit; you can even unit test the Javascript with Jsunit. But are you confident that it all works together? Selenium or Watir tests would do the trick, but bring us back into functional testing land.

How about for each of the Json states you test in the Javascript, you make sure you have a Java test that covers producing that Json. Save off the Json and use it in both tests. Now you have pretty much all of that functionality covered in Unit Tests.

Keeping the bulk of your tests is best for rapid feedback cycles and increased productivity. You may need some functional tests, but maybe not as much as you think.

This post is a rehashing of the talk I gave on the January 19 Naked Agilist podcast. I fluffed it, I’m afraid but I would still recommend listening because the other speakers were great.

2007-12-22T23:08:00.000Z

Fluent interface for numbers Kata

Taking the lead from Kevin Rutherford, I’ve had a crack at Mike Feathers’ numeric literals kata in Ruby. The idea is to allow the following sort of thing:-


    assert_equal 24, twenty.four  
    assert_equal 2100, two.thousand.one.hundred   
    assert_equal 1019000, one.million.nineteen.thousand

My solution (with tests, obviously) is here. Mike poses two questions

What qualities does a grammar need to have to create an embedded DSL which doesn’t allow nonsensical constructs?

In my example I couldn’t be bothered: seven.eleven evaluates to 18, and I don’t particularly care. A solution that takes care to enforce a strict grammar goes against the grain in Ruby, in my opinion.

If you really need to be strict then you’d probably be better going down the External DSL route, rather than implementing an Internal DSL in Ruby.

What is the minimal number of classes needed to implement it?

I went for zero. Well – kind-of. I just added methods to Object and Number. That’s the nice thing about Ruby: you don’t need that much code. Steve Yegge would be pleased.

2007-12-14T12:17:00.000Z

“Agile” – oversold, under-delivered, and over here.

Gordon Ramsey’s Kitchen Nightmares is an excellent programme about consulting and software development. Gordon Ramsey visits a failing restaurant and occasionally turns them round. It’s never one problem. A failing restaurant is typically failing at all levels: the cooking is sub-standard; management is lax; orders are badly organised; the menus are badly planned; the waiting staff are surly; the accounts are a mess. Gordon Ramsey, Michelin star chef, understands the importance of all the factors.

So, cooking is not the only factor in the failure or success of a restaurant. But it is essential. Cooking and serving quality food is what a good restaurant is about: it is at its core; it is its identity.

Clarke Ching is pissed off. He believes the “Agile Community” is spending too much time and effort worrying a about technical matters, while the key to success is concentrating on marketing and negotiation skills. I do believe these things are important, necessary even. If I didn’t I wouldn’t have done things like run, organise and arrange courses and sessions on working with resistance and team dynamics.

So, coding is not the only factor in the success or failure of a software project. But it is essential. Delivering tested features is what software development is about: it is at its core; it is its identity.

As Brian Marick says, its worse than Clarke thinks. As “Agile” is being more successfully sold at the senior level I’m seeing, and hearing about, a worrying trend of over-selling and under-delivery. Corporate executives are being persuaded to give “Agile” a chance, and “Agile” is being foisted on teams that lack the passion and skills to deliver on the promise.

We’ve overreached – it’s time to pull back and regroup to concentrate on building, teaching, and improving the core skills and techniques we need for successful delivery.

2007-12-05T12:13:00.000Z

Rails prepares for Ruby 1.9

I was flicking through the Rails 2 release candidate code and was vaguely amused to find

  unless respond_to?(:send!)
    # Anticipating Ruby 1.9 neutering send
    alias send! send
  end

(In Ruby marking a method as private is more of a hint than a command. You can get round it by using Object#send – up until now. One of the Ruby 1.9 changes is that send won’t work for private methods – you need to use send!.)

2007-11-24T01:05:00.000Z

Brian Marick on “Crossing the Chasm”

Agile’s crossed Geoffrey Moore’s chasm – it’s going mainstream.

Brian Marick’s 4 minute lightning talk here explains why this might not be such a good thing: the early majority is tiny, and the “early adaopters” (people interested in big wins) are currently wasting time and effort attempting to convert a bunch of people who don’t really care. Instead we should just give up on the “late majority” and concentrate on ourselves.

2007-11-24T01:03:00.000Z

Quick suggestion for “bug reporting”

How about using Selenium IDE as a tool to help users / manual testers submit the “how to reproduce” part of a bug report? I haven’t tried this out – just an idea a friend mentioned down the pub the other night.

2007-11-16T23:58:00.000Z

What’s the point of Spring XML configuration?

Don’t know about you but I always test, build, package, test, and deploy the entire app to release a change in config, so why is the Spring approach better than assembling my objects ourselves in code? Initialising our objects in XML is a popular option, so it must give us something.

One thing that Spring does not provide is Dependency Injection. Dependency Injection is a style of coding, and you don’t need a framework to code in a particular style. If you’re puzzled about how to do DI without Spring, take another look at the Gang-of-Four Abstract Factory and Builder patterns. Coding factories is no harder than writing XML, and even makes it easier to write chunkier Junit tests for assembled components.

What I think we get out of coding our factories using Spring XML is permission to relax the Java / OO rules during initialisation. At application initialisation we get to indulge in (lovely) dynamic typing, slightly more worrying global variables, and even the downright alarming excuse not to write tests for behaviour.

Dynamic typing

If there’s a type error it happens at runtime: its dynamic. And you’re still coding in a statically typed language because….. (*).

Global variables

The requirements change and your WidgetRepository, configured in the widget.xml, needs to get hold of a database connection to the “ooplah legacy system” configured in “ooplah.xml”. No problem – just pass in the “ooplahDataSource” bean id and you’re laughing. One of your Ooplah components needs a Widget, and the “widgetRepository” bean is ready and available. It’s all one big pot of bean soup.

Ok Spring does support hierarchical contexts, but know anyone making much use of them to partition their apps?

No need to test

So you’ve factored your code into small composable units? Well done. Your users will be delighted. And each unit is thoroughly unit tested? Excellent. (I bet you used Mock Objects, but I’ll let that go for now). Well the XML stuff is just config, so you don’t need to test that.

WRONG!

If you define behaviour by plugging your objects together in different ways then that configuration is code. No matter how well you’ve tested the individual object you need to test how they work together.

Even if you’ve automated end-to-end tests in place, you might ward away hours wasted at the debugger and fear of change by having some chunkier unit tests around your aggregate objects defining a particular behaviour.

A good side-effect of those chunkier tests is that they tend to encourage modular configuration with high adhesion within a single config file, and a few external dependencies stubbed for the test.

(*) .. because they’re paying me ;-)

2007-11-09T23:28:00.000Z

Twitter late adopter

Just joined Twitter out of curiosity. Yeah, I know that’s what they say about heroin. I’m not really sure what it’s for, or what I’ll get out of it. I suppose it goes against my assumption(**) that no-one’s really interested in what I’m doing.

We’ll see…

limiting belief?

2007-10-27T23:35:00.001+01:00

Joel wisdom

Joel’s not keen on project managers who pressure developers to reduce estimates to fit a schedule:

But you can never get 4n from n, ever, and if you think you can, please email me the stock symbol for your company so I can short it.

2007-10-03T11:33:00.000+01:00

The clever and the lazy

Pete links to Paul Duvall’s post on troublepreventing versus troubleshooting development styles. I am reminded of a quote from General Kurt von Hammerstein-Equord:

I divide my officers into four classes; the clever, the lazy, the industrious, and the stupid. Each officer possesses at least two of these qualities. Those who are clever and industrious are fitted for the highest staff appointments. Use can be made of those who are stupid and lazy. The man who is clever and lazy however is for the very highest command; he has the temperament and nerves to deal with all situations. But whoever is stupid and industrious is a menace and must be removed immediately!

2007-09-24T00:29:00.000+01:00

So, European RailsConf 2007…..

Overall, much better buzz than last year. The content of the sessions was much higher; there were fewer keynotes, which was fine. Mainly, though, there was just a better buzz.

There was a large Scottish contingent, and we’ll be giving an overview of the event at the next Scottish Ruby User Group meeting. It’s at 19:30, at The Edinburgh Training Centre, 16 St Mary’s Street, Edinburgh, EH1 1SU. In the meantime, a few random quotes (ok paraphrasings) from my notes:

Dr Nic:

Java is like Keith Richards: used to be cool, can tell you stories about itself, but not so cute anymore.

Jason Hoffman (in an aside):

The more they pay, the less they complain. If you want a difficult user base, give your stuff away for free.

Dave Thomas:

Make something beautiful. And if you do….. let me know by signing your work.

2007-09-16T22:52:00.000+01:00

More NFJS

Peter Aitken has a good account of August’s No Fluff Just Stuff event in London here. I also have more observations.

Grails

Just as I previously had not bothered to look at Groovy, I didn’t previously see the point of Grails, given Rails. Again, maybe I was wrong. Reasons for considering Grails:

it sits easily on a JVM, if that is what you need to use. Unlike JRuby, it compiles completely down to bytecode.
being Groovy it can integrate with Java Code with fewer seams.
it is layered on top of Spring and Hibernate, enabling use of Hibernates mature and reputedly excellent caching mechanisms.

I should admit that I haven’t yet used Grails in anger, so I can’t really vouch for it properly.

RIFE

RIFE is yet another Java Web Framework. It distinguishes itself by not only achieving “Rails-like” constraints in Java but by actually implementing Continuations for control flow. Which all goes to show what you can achieve if you really try.

AOP

AOP is another thing that I never so enough point in to really try out, beyond a few well-defined cases such as marking transaction boundaries. Brain Sletton introduced AOP as a tool for enforcing or monitoring policies, such as class A can only be called from classes B or C. Now this seems to be a very Directing rather than Enabling tool. My impressions was strenghtened when Brian suggested that the Junior developers could be left to write the main code, while the senior developers (architects) controlled them with AOP.

To be fair, though, he did give quite a compelling example of using AOP for good, using it to detect all the places in an inherited Swing application where threading had been incorrectly used.

Full stack frameworks

Most of the web frameworks presented, Grails, Rife, JBoss Seam were full stack. I’m guessing this is a move away from the complexity, integration issues, and burden of choice of the mix and match approach that previously held sway in Java land.

Bending Java

Of the two pure Java language sessions that I attended, AOP and Rife, both involved bending Java to be other than it was designed using byte code jiggery pokery. If you need to do that kind of thing to get the language to behavae close to how you’d like, maybe you’re using the wrong language.