XML please, I don’t want to recompile

There’s one quite naive argument that sometimes determines the technology choice. I want to write about it because this argument I’ve been hearing on and off for years. It’s about favouring XML to avoid recompilation.

I remember in the late days of EJB2, one of the selling points of Spring was that you can reconfigure the wiring of your beans without recompilation. At that time I was quite enthusiastic about this feature… even though the argument was almost completely negligible.

My friend said today:

“Another advantage [of XML workflow] is you can do some modification to the flow without recompiling the whole app”

It’s true that you don’t need to recompile. However, if you want fully implement the change to the XML workflow you probably still have to:

• run tests
• validate the app works
• check-in the change to your VCS (new revision created)
• make sure the integration build on newly created revision works OK
• validate the application (built with the new revision) works on the integration box
• …

In most cases, updating XML by hand on the integration/prod box is not practical. Don’t fall for the ‘no recompilation’ argument because it is negligable. Usually you still need a build & QA cycle.

This post is not intended to claim that XML is bad for you (although I probably agree with that statement =)). This post claims that ‘no recompilation’ argument is void.

Nevertheless, If I have to use a workflow in my java app it will declared in java and not in xml. I’m great fan of fluent, type-safe & intellisense-ready configurations!

Code Retreat in Wroclaw

Next weekend there’s a Code Retreat in Wroclaw: http://coderetreat.wroclaw.pl. I’ll be there so If you want to cut some code together retreat with us =)

The book is out!

Toni, Felix and the gang invited me to contribute to the brand new book. The Practices of the Proper Christian Programmer will be available on Amazon shortly!

Guerrilla Developers

Not sure I like the punchline but the story is real.

Once upon a time there was a project, pretty bad one actually. The were big performance and stability issues. The were no docs about functionality whatsoever. The code base quality was disastrous. There was even a local framework implemented that dealt with mapping java classes and fields into database tables via annotations (hmmm… this kind of framework does sound familiar…)

Several smart developers where thrown into this project. Officially, they didn’t have time for technology upgrades because new clients were waiting for this software. Developers couldn’t deal with the crap they ended up with. They started guerrilla development. All the efforts occurred under the radar: refactoring, automated testing, improving migration scripts, performance & debugging capabilities. They were stealing work hours, cheating on estimates, doing 2AM check-ins, staying late at work, etc.

After ~1 year of guerrilla development developers finally sorted out the project. Cost of introducing new features was reduced substantially, migrating new clients was blind fast, there were very little bugs, fixing & patching the production system was quick & easy.

Higher management was very happy with the quality of the product. The project was doing well and apparently it didn’t need so many developers to maintain it. So they rewarded developers… by transferring them into even worse project. The project was bigger, uglier and had large number of existing team members that stopped caring long time ago. Half year passed and there is no sign of improvement. Guerrilla developers are pretty much disillusioned because there is no groove in the team for sneaky improvements plus they still remember the reward after fixing similar project last time…

//given //when //then forever

@Test
public void shouldDoSomethingCool() throws Exception {
    //given
	 
    //when
 
    //then

}

I like to call it the Ultimate Test Template. I’m so fond of those 3 little comments but surprisingly, I didn’t buy it at first. Micheal (it’s you, tapestry-maven-iPhone fan boy =), friend from ThoughtWorks showed me it a couple of years ago. Actually, he didn’t show it to me – I just overheard him coaching a young dev about it. That day I thought I didn’t need any hip comments because my tests were great anyway. It was foolish.

Don’t be a fool like me and start writing //given //when //then today. Life is too short for messing around – you want to get level 85 in software craftsmanship soon, right? Here’s the deal: use the template for 1 iteration and if you don’t like the results then I will give you your money back. Seriously, no matter what you think about it – buy it! BTW. If you need to document some ‘exceptional’ behavior in your test somewhere there is the template for tests with exceptions.

Lately, I’ve been selling //given //when //then quite relentlessly. I even try to sell it via Mockito api. (The link also shows how to install the template in Eclipse so don’t miss it!)

I tried to lobby for the Church of given-when-then in Krakow, Warsaw & Kiev. I heard rumors that Wroclaw develops a growing number of brothers and sisters in faith =)

I think I forgot to thank Dan North for given-when-then and Liz Keogh for the idea of BDD aliases in Mockito. There you go!

TDD unlimited

So I read a short rant that questions TDD (or unit testing – it’s hard to figure). Here’s my message:

If you want to learn your trade don’t get too excited about gurus that outsmarted the Universe and found cracks in TDD. There are way more IT celebrities that successfully practice TDD. They blog about, they teach and you know what? Their code kicks ass big time. So… Write loads of tests, try TDD, taste BDD. Learn it yourself and at some point you won’t be needing blogs to decide what side to take (Alliance or the Horde? =).

Now, if you already know your trade please try to influence others to write more tests and learn TDD. How much inspirational is this or that! Anyway, it’s just my humble request to the world. Of course, you can write whatever you want, dear influential blogger!

hgsubversion on windows

Who likes mercurial? I do. Lately, I even started using mercurial as a client for subversion repositories. Let me describe the hgsubversion installation steps that worked for me; on my laptop that is boldly supplied with The Only Right operation system…

I heavily borrow from excellent entry by Ben Collins-Sussman and from outrageously diligent post by Dave Cameron. I want to focus on the smallest possible installation routine on windows. Also, I want to emphasize that you don’t have to build anything on windows. All the prepackaged installables or binaries are ready, waiting for you to grab them.

Oh right, here are the steps that worked for me:

1. Install mercurial (TortoiseHg)
2. Clone hgsubversion
3. Configure hgsubversion extension
4. Start cloning svn repos!
5. Understand the gotchas
6. Stay happy

1. Install mercurial (TortoiseHg). I installed TortoiseHg (mercurial + tortoise). Your cmd should nicely take: hg version.

In theory you can install different Mercurial client. However, there is a huge advantage of installing TortoiseHg: you don’t have to install python, svn python bindings & make your Mercurial use it. All because TortoiseHg comes with python+svn bindings (thanks Afriza for a hint!).

2. Clone hgsubversion:

hg clone http://bitbucket.org/durin42/hgsubversion SomeFantasticFolder

In my case SomeFantasticFolder is c:\projects\open-source\hgsubversion. At the moment I cloned hgsubversion the tip was the changeset 500.

3. Configure hgsubversion extension. Add extensions to your USER_HOME/.hgrc, which on windows is Documents and Settings\SomeFabulousName. In my case SomeFabulousName is sg0897xxx (after years in IT industry I’m still just a number…). Note that hgsubversion is duplicated at the end – that’s fine. Your .hgrc should contain something like:

[extensions]
rebase=
#do not quote the path if it has spaces!
svn=c:\projects\open-source\hgsubversion\hgsubversion

Your cmd should print enabled extensions at the bottom of the screen when you do: hg help extensions

4. Start cloning svn repos!

Instead of cloning repos with “hg clone” I suggest to “hg pull” instead. Pull is better because it can continue in case something breaks (cloning very large repo can takes hours).

hg init example
cd example
hg pull http://example-for-hgsubversion.googlecode.com/svn example-for-hgsubversion

5. Understand the gotchas.

• gotcha 1. If svn requires authentication, you may be asked to enter user/password… 3 times. Don’t worry, just enter correct credentials patiently. Three shall be the number thou shalt count, and the number of the counting shall be three. (update) Augie Fackler, the mastermind of hgsubversion points out svn+http or svn+https can be used to work around this gotcha
• gotcha 2: After updating changes from svn (hg pull, hg update) never use ‘hg merge’, instead use ‘hg rebase’. Merges are not yet supported by hgsubversion I heard. If you accidentally do hg merge you probably have to rollback the merge in order to push.
• gotcha 3: (new) From my experience it is better to clone entire repo, not only trunk. Cloning trunk worked for me but I noticed exceptions thrown during unsuccessful rebase. Working with full repo clone was smooth for me so far.
• gotcha 4: (new) Commands you should know:

  hg help svn
  hg rebase --svn
  hg svn info
  hg svn rebuildmeta
  

• last gotcha: I’m not a mercurial expert so feel free to comment & give feedback. Also, newer (different) versions of before mentioned installables should work as well. If links to binaries are dead then get creative and google for it – I don’t guarantee all links will work forever.

6. Stay happy. Are you kidding me? You know what to do =)

Mockito in Zurich

I will have a pleasure presenting Mockito at Jazoon in Zurich. My session is on Thursday – make sure you don’t miss it. During the session I’m going to show few slides and do live TDD with Mockito & other mocking frameworks. I’m going to use Infinitest. Guys, it’s huge. Brett Schuchert wrote about it, Bartek told me to try it several times. Finally I did and I must say I’m impressed. Infinitest is like transcending to a real TDD.

is debugger a modern translator?

Couple of days ago we interviewed a young adept of the craft. We let him code but he got stressed out a bit and wrote very complicated code. At some point he stopped understanding the code he wrote. So he started using debugger to figure out the meaning of the code. This is when debugger became sort of a modern electronic translator.

The thing is we probably don’t want to use debugger as a translator. We prefer to understand the code we write. Instead of debugging I usually recommend writing a small test that covers the logic in question. You can try this exercise next time you are about to launch the debugger.

Don’t get me wrong – debugger is a handy tool in every developer’s kit. It’s just the less you use it the better you are in producing high quality code. Actually, it’s probably other way around – when you get fluency with TDD/simple design you will soon discover how rarely you use debugger.

excuses for not doing dev testing

Yesterday I heart loads of excuses why the tests have not been written. I immedietaly remembered Misko Hevery‘s session at amazing geecon conference (be sure to attend next year!). Misko told a story about influencing developers to write more tests, testable code and TDD. I liked his slide where he collected all the excuses he heart from devs explaining why they haven’t written tests. Basically, Misko’s conclusion was that the only valid reason of not writing tests/TDD was lack of skill. TDD or ability to write tests is a skill like any other and it is no shame if you haven’t acquired it yet!

However, some of the excuses I heart yesterday were beyond any common sense:

• this is not really worth testing
• this is a small application
• we don’t have time
• (my favorite one) tests would make it harder to refactor

That was all bullshit and the only reason the tests were not written was that it was hard to write them. Devs didn’t know how to write tests for the DAO layer (how to ensure db is in correct state, how to maintain test database, etc.). Devs didn’t know how to write integration tests because of lack of experience with tools like Selenium. So they didn’t write any tests, not even plain jUnits.

Half a year ago, the same development team wrote loads of tests achieving high quality code base & high test coverage. Those days they wrote a django application. Django is a modern framework with built-in means of testing. It significantly contributed to the fact that developers wrote tests without cheating themselves with it’s-not-worth-testing kind of excuses (complete list above).

The interesting thing about the situation I encounter yesterday was this: junior developer wanted to write tests for some DAO code that did not have any tests (actually, there were zero tests at all…). So I asked senior developer responsible for architecture to help out setting up a TestCase that can prepare connection to test database, etc. Instead of helping, the senior guy started his mantra of excuses trying to convince junior developer not to write tests. Fortunately, I was there…