XML please, I don’t want to recompile

November 15, 2010

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

October 21, 2010

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!

April 1, 2010

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

December 21, 2009

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

December 7, 2009
public void shouldDoSomethingCool() throws Exception {


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

November 26, 2009

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

November 4, 2009

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:

#do not quote the path if it has spaces!

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 =)