February 24th, 2007
Finally I’ve got iG:Syntax Hiliter to indent code in blog posts in WordPress. You need make sure you’re not using the rich text editor, to do this there may be two options you need to uncheck: the “Users should use the visual editor by default” under Options/Writing and “Use the visual rich editor when writing” under Users/Your Profile.
What did we do before Google?
Posted in WordPress | 3 Comments »
January 25th, 2007
If I was to ask you to quote the Agile Manifesto what would you say?
- People and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, whilst there is value in those items on the right, we value the items on the left more.”
That’s what I’d say and what I’ve heard others say, however it isn’t actually all of the Agile Manifesto, there are a couple more lines at the start.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
It’s a shame these get missed because there is a lot in them. “We are uncovering”, note the tense here, it is present not past, it is still ongoing, we are still learning. “Better ways” – by saying better rather than best it’s acknowledged that this isn’t the definitive answer or that any previous methods didn’t work at all. “By doing it and helping other do it” – this is not some untested theory, this has been reached through real world experience.
Posted in Agile, Agile Manifesto | 1 Comment »
January 2nd, 2007
At last no more messing about copying junit.jar or modifying your system classpath to get JUnit to work with Ant. Version 1.7 allows you to specify its location in a classpath element in your build file.
See the last point from the manual page for the JUnit task:
Note: You must have junit.jar available. You can do one of:
1. Put both junit.jar and ant-junit.jar in ANT_HOME/lib.
2. Do not put either in ANT_HOME/lib, and instead include their locations in your CLASSPATH environment variable.
3. Add both JARs to your classpath using -lib.
4. Specify the locations of both JARs using a element in a in the build file.
5. Leave ant-junit.jar in its default location in ANT_HOME/lib but include junit.jar in the passed to . (since Ant 1.7)
One thing to be careful of, make sure you include the junit.jar file that you want, you probably want to make the classpath element specifying the location of the junit.jar file the first classpath element in your junit task – I spent quite a bit of time trying to work out why the tests annotated with the new JUnit 4 @Test annotation weren’t getting run only to eventually find a JUnit 3.1 junit.jar file from the Spring Framework in the classpath before the JUnit 4 junit.jar file.
Posted in Ant, JUnit, Java, Unit Testing | No Comments »
December 30th, 2006
As a comment to a 37Signals post “Predicting ‘06: Enterprise is the new legacy” (probably more on that at some later date) Chad Fowler made the very good observation:
Careful. “Legacy†isn’t a bad word. “Legacy†usually means tried, true, and of enough value that it lasted long enough to be old and outdated.
To mock “Legacy†is to look at the successes of the past and to declare that they aren’t to be revered or respected. Most of what runs our economies is “Legacyâ€.
In the future, I hope that the software I’m creating now was highly regarded enough that it’s still around and being referred to as “Legacyâ€.
Posted in Uncategorized | No Comments »
December 30th, 2006
Many still seem to doubt the capabilities of small agile teams. Small agile teams go against conventional wisdom – they might be able to handle simple problems but for real problems you need big teams, you couldn’t build a team of only high ability people, they wouldn’t be capable (due to character clashes etc) of self organizing and working together – so the arguments go.
The British SAS are arguably the most highly regarded special forces unit in the world. A team in the SAS:
- consists of a small number of highly motivated individuals
- is made up of generalizing specialists – each team member has an area of expertise but is more than competent in other fields
- is self organizing, able to respond as the situation changes
- given a problem the team will amongst themselves work out how to tackle it, they are responsible for their own plan
If you don’t think such a team can work you can go and pick an argument with the SAS.
The above description is also an accurate description of an agile software development team*.
When the SAS was formed it went against conventional wisdom and many doubted its worth. Time has taught us otherwise.
* As I sit here comfortably in front of my PC I am well aware that the problems and risks I face day to day are nothing like those faced by those in the armed services. I don’t mean to cause offence to anyone in the armed services, I just think it’s an unusual but powerful example of “individuals and interactions over processes and tools“
Posted in Agile | 1 Comment »
December 29th, 2006
At last, a simple to understand description of OSGi. Now I start to understand what the fuss is about.
Posted in Java, OSGi | No Comments »
December 29th, 2006
Are we nearly there yet?
Ivan Moore
This started with the presenter giving his experiences with tracking on agile projects and then became an open discussion with those present sharing their thoughts and experiences.
A couple of points that struck me:
- you can track done story points on a graph, if the graph flatlines for a few days it maybe an indication that the stories are too big – the team I’m in have recently (prior to XP Day) started tracking done story points in addition to tracking remaining estimated hours, I was dubious about what we would get from this but it’ll now be interesting to see what we get
- mark cards as done and not done (or a finer resolution, under development, ready for test, tested etc), e.g. using little coloured stickers, but don’t overwrite or replace one mark with another. If you see cards appearing with the same mark on them multiple times indicating they are bouncing back and forwards between states, e.g. not done and done, it’s a good indication there’s a problem somewhere.
One thing that did strike me was how comfortable everyone was in the room with doing different things at different times and in different situations – more than once someone started with “sometimes I’ve …” and the inexact nature of plans. I know I shouldn’t be surprised by this – responding to change over following a plan, continuous feedback and adjustment are all part of Agile – but it was reassuring to see, working in a company that’s trying to become Agile but with a long way to go where fixed scope and timescales still predominate where most still believe in the infallibility of ‘the plan’.
Posted in XP Day | No Comments »
December 29th, 2006
Are your tests really driving your development?
Nat Pryce and Steve Freeman
I won’t write much about this because should this be presented again and you attend knowing too much about it, it will, I think, spoil it a bit – but if you do get a chance to see this do, Nat and Steve very effectively make their point.
So, hopefully, without giving things away…
Do your tests really communicate their intent?
- don’t use magic numbers in your tests just as you wouldn’t in your production code
- consider creating value types where you might typically use primitive types – a parameter to a method of type PhoneNumber rather than just a simple String conveys far more information, even if the PhoneNumber class is just a very simple wrapper around a String
- a comment here and there can make a big difference
- where a method under test is returning a numerical result based on values passed to the method, express the expected result in terms of the values passed to the method, e.g.
assertEquals(2+2, billingService.caclculateCharge(2,2)) rather than assertEquals(4, billingService.caclculateCharge(2,2))
Posted in Behaviour-Driven Development, Unit Testing, XP Day | No Comments »
December 29th, 2006
Awesome Acceptance Testing
Dan North, Joe Walnes
There’s nothing wrong with having asserts in your tests that are unrelated to what you are actually trying to test but instead check the sanity of your test so that when they fail it’s easier to workout why.
As an example:
You have a test that logs into the system, goes to a search page, fills it in and checks the results. One day this test suddenly starts to fail, it turns out that the password for the user the test is login in as has expired, if after the login step you checked that the title of the page was “Welcome” proving that you had logged in successfully it would be very easy to spot that the test failed as a result of failing to log in rather than something being wrong with the search functionality.
How fast do your acceptance tests run? Joe’s rule of thumb is about 100 ATs/minute.
How do you go about setting up test data – do you do inserts directly into the database using SQL or do your tests click about in the GUI creating data for use later in the test? Why not use the code for the domain model you’ve written to set up the data – so you’ve written your own blogging system, rather than poking around in the database to create a blog entry with a comment for the test or getting the test to click around in the GUI to create the blog entry and comment why not just instantiate a new Blog domain object and Comment object and persist them to the database using your BlogDAO object. Of course to be able to do this your AT must be implemented in the same language as your domain language but I think thats quite a strong argument for doing so (or of course now if your system is implemented in Java you can write your tests in Ruby but still access you domain code via the magic of JRuby ).
How readable are your ATs? Could someone who doesn’t know, for example, Java read them? With the grouping of steps into carefully named methods you can end up with something very readable.
Implicit assumptions:
You complete a story, later you think of a new scenario, do you reopen the old story? If this situation comes up it suggests that your initial story had an implicit assumption so rename your original story to include that assumption explicit and create a new story for the other case. e.g. you write a story for withdrawing money from an ATM – WithdrawMoneyFromATM. You then think “What happens if the network connection from the ATM to the bank is flaky?”. The original story had the implicit assumption that the ATM was working correctly so rename it WithdrawMoneyFromWorkingATM making it explicit that it’s for a working ATM and add a second story WithdrawMoneyFromFlakyATM.
Given – When – Then – Behaviour Driven Development
Dan explained the ideas behind Behaviour-Driven Development and the idea of splitting a test down into a precondition – the given – an event – the when – and the expected result – the then. I quite like this idea, if done properly it makes the test very readable. Some code was presented from jBehave, a BDD tool for Java, illustrating the idea. The code (if I understood right) represented the latest thinking of those working on JBehave and was being carried out in private, what is present on the jBehave site is out of date.
Posted in Behaviour-Driven Development, XP Day | No Comments »
December 11th, 2006
Refactoring databases for fun, profit and sanity
Sam Newman and Graham Tackley
DBDeploy – a new open source tool from ThoughtWorks – whilst in its current form it’s new but variations of it have been used in numerous projects for a while.
It currently supports 4 databases – Oracle, SQLServer, Hypersonic, Sybase, more coming soon including MySQL and ProgresSQL.
Incremental changes are specified, as ANSI standard SQL, in files named with numerical prefixes. DBDeploy checks which have already been applied and generates an output file containing the changes as database vendor specific SQL that have not yet been applied. This output file can then be applied, after being examined by a DBA if necessary, to the database.
DBDeploy also supports downgrades. Think carefully before using this capability (and this advice applies to any similar tool) – do you really need to be able to rollback a change. The time you really need a script to undo changes is when the easy option of doing an export before the upgrade and reimporting it if something goes wrong is not possible due to the large volume of data involved would mean it takes too long.
If you use the downgrade functionality don’t forget you need to test peforming downgrades as well as upgrades.
Posted in XP Day | No Comments »