To make logback know where to find these converters, we add this little guy:

And now all that’s left are configuration changes. Make your pattern contain our cool new keys (“%user” and “%session”):

And this last part is needed for the session context thingie to work (as I was instructed on Stack Overflow). We need to add a certain listener to our web.xml:

And that’s about it. Happy logging!

As I’ve mentioned in previous posts, it’s not easy taking the software craftsmanship road when joining a team with a large code base and practically zero tests. I joined in order to help introduce automated testing to the team’s development process, but making these changes is never easy.

I recently read an amazing book called Apprenticeship Patterns, which collects the different patterns we share in our industry on our track to professionalism. Of those patterns, reading “Unleash Your Enthusiasm” suddenly made me understand more clearly what I’ve been doing that year.

When I just joined the team, I naturally tried to get the vibes of the team and “go with the flow”. The first small projects I did on my first few weeks to get my feet wet weren’t a craftsman’s best work, to say the least. I barely wrote any tests, and since Python doesn’t have decent refactoring tools, that made me refactor less. After a couple of weeks I was already getting angry with myself, and once I noticed thinking of changes to the code made me twitch it was clear something was wrong (after all we’re all for “embracing change”, aren’t we?).

I decided to return to the good path. Catching up on some best practices for unit testing in Python and adopting once more the Red-Green-Refactor cycle did the trick for me. I haven’t stopped TDDing since and didn’t look back. But here is where the story got more interesting.

Working on a project mainly by myself meant I had it easy in making sure the code base is tested the way I liked it. My manager thought, as a good manager does, that as long as the outcome is good he shouldn’t care if I do something no one else on the team does. This allowed me to have my fun, but still something was missing. I really found it hard seeing my teammates having troubles that could have been easily avoided with a good suite of tests. More than once I saw people in a debugging spiral or fighting a refactoring gone wrong.

Being the loud-mouth that I can be, I made sure to help people see how much fun I had writing code as code was meant to be written. Parading my Clean Code wristband, posting certain manifestos on the walls and sending the team links or snippets was a good start.

After a while, some people wanted to hear more. I gave a unit testing talk that pretty much got people hooked after I deleted random lines of code and showed them the tests captured it every time, and the knock out was Gary Bernhardt’s awesome kata that showed TDD won’t slow you down.

Seeing that team’s lack of testing slowly transforming to a suite of tests that kept getting closer and closer to the FIRST principles made me understand how a young developer can really unleash his enthusiasm to make real changes happen. No one has made the jump to TDD yet, but I think the whole team can be proud for adding hundreds of tests to their code base in less than a year. Remember, if you work with excellent people, sometimes all it takes is a little push to get them on a better track.

This taught me yet again that being a craftsman is about sticking to your principles. Craftsmanship of Crap all the way.

You should subscribe to my feed and follow me on Twitter.

After I finished it, I felt a bit weird writing a blog post about it, because, just like the previous books I’ve blogged about, I found this book simply awesome. Then I thought about the fact it’s simply because I’m reading those books that show up enough in other contexts that I upped them in my reading queue enough to get on top.

The book is about practical, low level details of writing good code. There are chapters about comments, naming, functions, you name it. In a way, it reminds me of Code Complete, other than the fact you can see it’s oriented for more practiced developers.

Like in his Agile Software Development book, Uncle Bob made sure to fill this one with code. Actually, this book has a lot more code. There are many examples of code still being worked on. It actually fills the gap I’ve felt in Agile Software Development of seeing the actual coding steps, test by test. The last chapter shows a really thorough (and actually quite mesmerizing) example of refactoring, with each change explained beforehand, including tests and alternatives considered.

In Agile Software Development, there were a few co-authored chapters. In Clean Code Uncle Bob took this a step further. Almost every chapter was written by a different author, each of very big caliber in the Agile and Software Craftsmanship world. This really resonated with me, because it’s kind of a “many in one” deal, and because I could actually hear a different tone in each chapter, and yet all were in harmony with the motive of clean code.

I think this is truly a masterpiece, and after reading, would recommend it to be read before Agile Software Development. Due to its greater technicality and the fact it’s quite new, it makes a really good read for developers, and it will have an effect on your coding a few pages in (pages! not even chapters).

The only thing that bothered me was that in the last chapter (which is also the best) I had to, as the introduction warned me, flip back and forth quite a bit, which was a bit hard at first since I’m not used to reading code on paper. I’d really love seeing some interactive version of this, but regardless of that, the book is really good.

I can’t recommend enough this concentrated piece of wisdom and experience.

Stay tuned, a review of Apprenticeship Patterns is nigh.

You should subscribe to my feed and follow me on twitter.

In the past year I’ve been mainly working on a single project, the longest I’ve worked on a project with TDD. Putting aside how fun it is (TDD saved me quite a few times for me to be sure it’s worthwhile), working on a project for so long I finally got to see some of the main problems people have against TDD.

With the hundreds of test you have, refactoring on the class-interface level (that is, the interfaces of classes, and not inside classes) can be problematic, with you having to update all the tests.

I’m still learning how to handle this efficiently, and would like to share an experience I had today. This is an example of a problem regarding 2 collaborators and an interface change. Such refactorings in a TDD environment weren’t mentioned in the excellent “TDD by Example” book and similar works, so I’m pretty much guessing here.

The example:

The change we’re interested in is making “eject” simply open the lid, without rewinding, and making the rewind operation public. This is in order to allow LazyPerson to take the tape out, without having to wait. Gary Bernhardt wrote about this kind of changes a bit. I agree, the fact I need to make such a change is against the OCP. What can I say, I’m not perfect and made a design mistake. Saying “that’s not OCP” doesn’t help me – I’ve got this code and tests, and I need to change them.

I used to succumb to the temptation and make all the changes in one sweep. That means changing all the tests and the classes, then running the tests and hope they still pass. This, of course, is a crappy way of doing this. Had I been able to actually perform such tasks, I’d write less tests. The secret is baby steps. The pressure Kent Beck puts on baby steps and gradually working towards change made me consider this and force myself to find a safe way of doing this.

I decided to start with the VCR and its test (the AutomaticPresenter doesn’t use the VCR itself but an interface, and the tests use test doubles. This means changing one part won’t break the other’s unit tests). The path to enlightenment lies in finding the baby step that allows starting the refactoring without breaking the rest of the tests. I decided to add a test for the should-now-be-public “rewind” operation, while not breaking the existing tests.

The solution is adding a default value for telling the “eject” function whether it should rewind or not. This means existing users (be them tests or not) will still get the previous behavior, and new tests can start work with the new interface (in Java I’d probably do this with method overloading):

This got me to green pretty fast. Now I can slowly remove every rewind-related assertion from the old tests and also add the “should_rewind=False” flag to them, all with quick-green cycles. And we’re done with the first half.

The next move is to change the AutomaticPresenter to call “rewind” before “eject”, which is now really easy to do in the tests. Once we hit green, we remove the “should_rewind” flag and be done with the refactoring. Baby steps save the day:

Being able to get the refactoring working so easily makes me happy, but I’m still not sure this is the smartest way, and there are harder refactorings to master ahead. Yet, I hope this will help TDD adopters see that it’s possible to handle refactorings even with many tests, because once the right baby-step is found, each test can take practically seconds to convert.

I’d really love getting feedback on this cycle.

You should subscribe to my RSS feed or follow me on twitter!

I’ve been the only TDDer in my team for about a year now. When I just joined the team, my TDD ways were looked at as a weird fad. Nevertheless, I kept working in my ways, know that, at least for me, it works best.

Working like that can be very frustrating. You make sure your code is clean, well tested and refactored. Then comes along someone that makes a small change and your tests no longer cover that part of the code. You open up some other part of the system, see bad code and though you try to follow the boy-scout rule, you can’t because you’d need to harness 10 computers and a goat to test the code in its current state.

A few months ago I asked Uncle Bob what is a programmer to do in such a situation. His response:

It’s frustrating and difficult. But what choice do you have? All you can do is keep at it. Shame the others by keeping to your disciplines.

And boy was he right. As months passed, and people glancing over saw me running hundreds of tests in a second and being able to make quick changes without fear (or very little), I noticed a weird pattern.

Whenever people asked me to lend them a hand with a piece of code, the presentation of the code started with a disclaimer: “Never mind how ugly it is“, and “I know it looks bad”.

At first, my ego always happy to boast, I took it as a compliment. Later, it dawned on me that it’s not that my code looks like pure prose simply because it’s TDDed.

What that apologizing means is “I’m sorry I don’t care about the code as much you do“. Uncle Bob was right, people were actually ashamed. Sounds weird right? But then again, if you do care, why haven’t you removed the need to apologize after the second time?

Get out of this shame-phase. Being ashamed means you care, do something with it. The next step is simply making the code cleaner. Some of my team-mates have already started down the enlightened path.

Remember, coding is a social activity. When you disrespect the code, you disrespect your friends. When you rock on, you all enjoy. As a wise man said, keep working on your code till you’re ready to project the code onto the wall for the whole team to see.

And if you’re in my shoes, keep it up. Sometimes all it takes is a little push.

You should subscribe to my feed and follow me on twitter!

A Code Retreat is a concept that was born in the beginning of 2009. It’s a day that consists of a bunch of programmers working in pairs about a problem – a session is 40 minutes long and after each pairs rotate and the start from scratch.

This code retreat was a bit special. It wasn’t a public one. My previous employer liked the concept and I was asked to help with running one for some of their coders. The group consisted of 15 coders that are in the company at least 2 years.

Most of the people don’t pair at work and none TDD (only some unit test). Because of this we’ve decided before starting not to make TDD a must, but introduce it and encourage trying it out.

One of the things that surprised me was that after 3 sessions, some people asked if it was possible to get a different exercise. I haven’t heard of a code retreat with more than 1 exercise and I’m puzzled why this team has brought this up. Currently, my only guess is that the Israeli temper and to-the-point attitude (“Dugri” or “Takhles” in Hebrew)  caused it (even though there were many wicked implementation ideas running around). I’m still not sure giving them another option was a good thing, as I believe squeezing more ideas from one exercise is where things get really interesting (and some preferred staying with the original one).

Another point was that some people said they would have appreciated more structure/direction – what to do in each session and getting a list of implementation ideas for Game of Life.

We were also asked for longer sessions – 40 minutes felt like too little and our single 50 minutes session felt more like it.

A bit unsurprisingly, when we performed the String Calculator Kata to demonstrate some TDD, most people thought this was going overboard with tests for such a simple thing. I hope some got the message and I think that the fact we actually had bugs caught instantly by the tests helped!

To sum it up, I think that all-in-all people had a good time. I practically had to pull some from the keyboard at the end of sessions. Can’t wait for the next one! I’m thinking of getting a bunch of Clean Code wrist bands to give away.

For future reference, here’s the list of Game of Life ideas people have tried:

• Cell centered
• Board/Universe centered
• if-less (as possible)
• Uber-threaded (each cell is a thread)
• Performance-centered (board is a byte array)
• Focus on the neighboring-connection (the “lines” between cells)
• Implement in a few different languages and their idioms (we had Java, Python and some C)
• Different topologies (hive-like and 3D)
• Calculate results by hashing certain parts of the universe and the expected results for them

And, the second problem that was given is the Poker Hands Kata:

• Go through the cards and seek the best hand
• After each card is added to the hand, hand-types that are no more possible are removed
• Encode the hand as a 64bit number, and then find better hand by subtracting the numbers

You should subscribe to my feed and follow me on twitter!

Disclaimer: Buildbot is a pretty awesome building/continuous integration system that I use and contribute code to regularly. Indeed, it is far from perfect, but none of the coders should take offense.

So, what is the Single Responsibility Principle (SRP) ?

A class should have one, and only one, reason to change.

If a class has more than one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.

But this turns out to be wrong. Say we tried to execute ‘nosetests‘, the actual command that will be executed is ‘nosetests -v -v‘ (which is harmless, but you might have guessed my real use-case wasn’t adding the ‘-v‘ flag). The reason is, as the Buildbot manual will happily tell you, that every step is also its own factory.

Wait, what? Given the fact the a certain step will need to be run in multiple builds on multiple slaves, a new one needs to be created every time. But, as a user you only instantiate the step once. Turns out that behind the scenes, Buildbot will save the arguments given to the command’s constructor and call it with them again every time it needs a new instance.

This means that in our case, we must find a way to tell in the constructor whether we’re instantiating the factory or being instantiated by the factory, and add the flag only in one case but not both. My cute example turns to this mess:

(If you’re really bothered with understanding every detail, read the manual, but I’m sure you can get the gist of it without doing so.)

Now, if you’re anything like me, you’re looking at this and wondering something along the lines of “what the hell were they thinking?“. That feeling, that tingling in your code-sense, is the smell of an SRP violation.

Because this class has to also act as its own constructor, the coupling between the two actions is high, and as the definition clearly states, the class now has 2 reasons to change.

Surely, separating this to 2 different classes (the actual step and a factory) will have solved this problem elegantly. Given that this might be considered “advanced” usage I’m willing to accept that creating a factory will be optional. But really people, this addFactoryArguments screams HACK.

If you liked this post, you’ll definitely want to read the PPP book.

You should subscribe to my feed and follow me on twitter!

All you have to do is this (code is based on this blog post, with adaptations to work on slaves that don’t share directories with the master, since the createSummary method runs on the master):

It’s like coding with the Uncle himself

The thing I liked the most about the book, is the way it walks through (relatively) huge amounts of code. Uncle Bob shows several programming problems and walks through his design process and the implementation of the interesting parts. Reading it (even though it was written almost a decade ago) you can’t miss the fact the author has so much experience. Whenever I tried coding a solution myself before reading on, I later found out exactly where I went wrong because he somehow managed to cover every decision I made.

When I say it’s like coding with him, I really mean it. I don’t know how, but whenever I looked at a code sample I didn’t like for some reason, I was astonished to read “You may be wondering why I did X” the next paragraph. And, maybe less fun, is when I read something, totally agreed with it, and he went on to explain why it sucks.

The feeling throughout reading the book is that you get to pair with one of the best software craftsmen ever.

You get experience in every paragraph

A big part of the book is dedicated to talking about XP and design patterns. I’ve read several books about both and yet I didn’t find those parts in the book redundant. The reason is because Uncle Bob has managed to put a few grains of experience into whatever he talked about. Even though I’ve coded my fair share of Factories, he made me realize a few interesting concepts about them. And although I’ve done Visitors, I suddenly am a bit in love with them (which means I have to fight myself extra-hard not to introduce them everywhere).

If you don’t have people around you that care about coding a lot (enough to send out awesome Clean Code wristbands, one of which I own) you’ll quickly grasp what I’m talking about. The whole writing is of an experienced mentor (which might explain why his company is called “Object Mentor”).

It simply changes the way you look at coding

Having gone through the SOLID principles, my whole designing process and way of thinking has changed. I can’t think of a sane developer that will refuse to put his hands on a set of principles that the best coders of the past decades have deemed as necessary for quality code.

Do yourself a favor and get your hands on this piece of software-craftsmanship gold-mine!

Stay tuned for the next part of this series, Uncle Bob’s Clean Code!

You should follow me on twitter and subscribe to my RSS feed, it’s free!

When using nose on Solaris machines, simply running nosetests without specifying the file names will not work if you are the root user. To fix this, you must either not be root, or pass nose the argument --exe. That’s it.

Gory details: by default, nose ignores executable files. Each file it encounters it checks with os.access(test_file, os.X_OK) to see if it’s executable. Problem is that Solaris’ access function always returns success for root, regardless of actual file permissions. This is discouraged by POSIX, but known behavior.

I hope this saves someone the 3 hours it wasted for me