Archive for August, 2010

Logging with a Context: Users in Logback and Spring Security

Posted in Programming, techie on August 27th, 2010 by Aviv Ben-Yosef – Be the first to comment
During this hectic time of starting an amazing adventure we find that along many of the big and important challenges we have there is an endless stream of small technical problems that solving poorly means a lot of time will go to waste.
One of these is proper logging in a way that will allow you see what your users are doing properly. Pretty quickly we came to the conclusion we want each log message to contain information about the user’s context, so we could easily understand what went wrong when a user tells us about it, and be able to track usage patterns.
The simplest thing we thought of was creating our own logger wrapper to insert our special values, but didn’t like the idea of having to write our own logging interface all over again. We’re using Logback and Spring Security, and after some googling and stackoverflowing I’ve found this solution:
We create simple Converters to insert the username and session ID to the logs, if present:

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!

    Unleashing Your Enthusiasm: Grunts Making a Change

    Posted in Programming on August 20th, 2010 by Aviv Ben-Yosef – 2 Comments

    I’ve been doing retrospection and navel-gazing lately, after deciding to join a new adventure and leaving an awesome job. I had the chance to work in XIV-IBM for just over a year, and it being my first real job I was thinking of how satisfied I am with my work there.

    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.