Monday, July 25, 2011

Logback hack to log different levels in the same package to different appenders

Given the long title you could think that this is going to be a blog about a ridiculous edge case. It isn't, honestly! It is a blog about an edge case, but not ridiculous and not as far fetched as you think. Let's say that you have a class logging on DEBUG and TRACE. The debug messages contain (frequent) checks, but lack the full information needed to analyze the problem. This information (say a full xml message) is logged on TRACE level. Now your friendly system administrator decides that he needs this trace logging to go into a different file from the debug logging. He has good arguments and you don't want to pick a fight. Logback provides a lot of configuration options that you can do lots of neat things with. But it can't fill this requirement. Really? Well, there is a hack.

Monday, May 9, 2011

Found in the wild: uncertainty

Let met just keep this short and let the code speak for itself:

1 2 3 4 5 6 7 8 
  // The next fields counts the number of time the decide method is called
  //
  // IMPORTANT: This field can be updated by multiple threads. It follows that
  // its values may *not* be incremented sequentially. However, we don't care
  // about the actual value of the field except that from time to time the
  // expression (invocationCounter++ & 0xF) == 0xF) should be true.
  private long invocationCounter = 0;

Three letters apply here.

Posted via email from Iwein's braindumps

Tuesday, March 22, 2011

Confession of a developer junkie

I like splitting wood. It’s a simple physical activity and I’m good at it. I can tell you exactly why I like splitting wood; it is very similar to why I like doing some other things, like building software for example. There has been a lot of discussion in software development about this thing some people call craftsmanship

When you split a log (assuming you have a decent tool) things are quite simple. There are a lot of physics involved, like the direction of the grains, the cohesion between them. The moisture is important too, the momentum of the axe, the angle… But when I swing I don’t think of those. I just look at the log, know where I want to hit it and then it happens the way I saw it in my head. It doesn’t always go right, but it does a lot of times. When it goes right I know it before I register it. Right at the moment the axe has its maximum momentum and the direction is set I know there is nothing to correct and the scenario can play out the way it should. And then there is the moment when the axe hits the wood and sinks in effortlessly. There is the well articulated “chk” immediately followed by a “pang” as the tension makes the log snap apart. If you hit as hard as you can you will send two parts flying away, but that doesn’t give me most satisfaction. I like it when I hit just hard enough and two parts end up standing next to each other. I can immediately go on and take another swing without stooping over and straightening the logs. That feeling is the most addictive thing I’ve found in life. I can continue splitting wood far beyond comfort, just to get another fix of that feeling. I am not alone in this I believe.

A long time friend of mine is a baseball player. He told me a similar story about hitting a ball just right. The pitcher throws, not too slow, but you catch the ball with your eye. You swing at it and as the bat cuts through the air, you know it’s going to connect right. Then the ball hits the bat so that you hardly feel it. You just year the “ping” and you know it’s a home run. I’m not a baseball player, but apparently there is nothing like that feeling. I believe it is the same feeling that I get from splitting logs.

A related thing has been described before by Csíkszentmihályi Mihály. It is referred to as “Flow” or “The Zone”. If you haven’t seen Csíkszentmihályi’s work you definitely should have a look (feel free to copy paste now to avoid spelling errors). I believe this immediate feeling of joy as you do something right lies at the basis of flow.

With some effort I can get this feeling when developing software too. It is even possible to share this feeling with a whole team of developers. When that happens I love my job so much I’d do it for free until I starve. With some more effort it is possible to do this on a project that actually delivers business value to a customer. This means I can do this great thing without starving if I play my cards right. I need a way to get the people that stop me from doing this to get a clue and let me do my thing. You probably know the types I’m talking about: it’s the manager up high that makes me work on a virtual desktop that runs vista; it’s the architect that forces me to use a five year old version of a bad framework and makes me deploy to Weblogic 5; it’s the customer that waves three years old specs at me when I ask him a question about how he wants you to implement a feature. It is also the colleague that refuses to talk to me about my real problem if it is not related to cool new obscure technology X that somebody blogged about this morning.

If I can get these people to grow up by talking to them about Agile, XP, or Craftsmanship, or Lean, or Oompa Loompa’s; I will do it. I’m a junky remember? I want to get my daily flow fix! When Robert Martin said we were tired of writing crap, it didn’t ring true with me. I’m not tired of it at all. I’m prepared to write a lot of crap to get it right just once. If we do have a nice bit of marketing on the word craftsmanship I’m fine to surf that wave for now. Next year we’ll call it Real Engineering, the year after Real Development. Why the hell not. As long as some of us get what it is about and they are in my team I’m totally cool with it.

Posted via email from Iwein's braindumps

Ja tegen proteïnen, nee tegen vieze shakes

Ongeveer een half jaar geleden kreeg ik last van mijn rug. Het advies van de dokter en fysiotherapeut was om zo veel mogelijk te bewegen en zo weinig mogelijk achter de computer te zitten. Omdat ik vastbesloten was, mijn rug (en buik) zo snel mogelijk in vorm te krijgen, heb ik het advies opgevolgd. Deze blog heeft daar enigszins onder geleden, maar omdat ik nu een slanke en fitte dertiger ben, mag ik weer lekker lang achter mijn computer zitten ;-). 

Gezond eten en regelmatig bewegen zijn onmisbaar om een gezond lijf te krijgen en te houden. Als je eenmaal lekker aan het bewegen bent geslagen, wordt het een sport om steeds iets meer te tillen en langer door te gaan. Op het feestje van Wouter, kwam The four hour body' ter sprake. Om een goddelijk lijf te krijgen hoef je volgens Timothy Ferriss slechts 4 keer in een maand te trainen en moet je 100 gram extra eiwitten per dag eten. Als je bedenkt dat er in een eitje hooguit 7 gram proteïne zit, moet je dus al gauw 14 eieren per dag eten... Ze zijn niet gemakkelijk weg te werken, want eieren vullen goed. Je  gaat van eieren enorm stinken. Bovendien is een eenzijdig dieet niet gezond. Dus op welke andere manier krijg je dan 100 gram proteïnen per dag extra binnen?

Saturday, February 26, 2011

Curing distributed Agile Illnesses: Diagnosis

In my session on 'When Agile Offshoring fails' at AgileNCR this Saturday I decided to harvest ideas from the attendees on different illnesses. The results were beyond my expectations; in this blog I will share a few of them and give a few preliminary comments on the result. The general plan is described better with the following diagram.

First I would ask the attendees to come up and write down all the symptoms related to failing distributed agile teams on a sticky. These we put on one part of the walls of the room. Then I would ask them to write causes for symptoms on stickies and put them on another part of the wall. Finally we would all try to come up with a possible mitigation for each cause. It worked beautifully, let me show you.

Thursday, January 20, 2011

Easy peasy websockets with node.js and socket.io

With our Web Sockets incubator we had a rough start on Atmosphere grinding through the samples. There is no intention to bash Atmosphere, it looks like an interesting approach. However, it should be a lesson to all aspiring framework builders out there: getting your samples in top shape matters a lot. This week we tried out socket.io and I wasn't too hopeful as I had planned all kinds of things throughout the evening. The result of a 40 minute pairing session with Sonny Gill was pretty good and I'll share the basic highlights here in a very short post.

First we installed node.js and used npm to install socket.io. Next we moved on to create a simple app that exposes a socket on the server. Finally we created a client that opens a socket and sends some test string over the wire.

The code you can find on github as usual: https://github.com/xebia/app-incubator-web-sockets/blob/master/socketio-sample. All in all it is less than 50 lines of javascript and html and it simply works as expected. Not bad for less than an hour of fiddling! In our next session we'll look into the possibilities of streaming video over Web Sockets, or maybe we will look at another framework to see if it performs any more interesting magic tricks. That's all for now, stay tuned!

Posted via email from Xebia App Incubator

Tuesday, January 11, 2011

Force breakthrough by forcing mistakes

A week or so ago I started to play Math Workout to rekindle my degenerated calculation skills. After a while I got stuck at a certain speed, making no mistakes anymore. I tried to push myself to go faster, but without making mistakes but that just didn't work. Then I tried a different approach: I forced myself to go fast, mistakes or no. After a couple of sessions, I went back to making no mistakes and to my surprise I was around 8% faster. I have a theory about why this is and I'm applying it to life without hesitation from now on, so read on if you want to share the fun.

<!-- more -->
What's Math Workout
I'll give you some background on Math Workout first, so you can understand the example. Math Workout is a game that let's you solve simple calculations and times you while you do so. The main goal is to be as fast as you can. For example, on easy level the hardest addition is 8+7 and the hardest multiplication is 4*6 (I'm considering 5*6 easier). Dead easy as you can see. The trick though is that you need to solve 20 of these problems in less than 23 seconds, and I can tell you that's tricky enough because you need to read the problem, come up with the answer and type it correctly in about a second.

What goes wrong if you don't make mistakes
Somehow I got into a rhythm. See the numbers, see the operator, answer pops up, type it. There are probably a few more steps that I was doing unconsciously, but the point is that I was taking a fixed amount of time for each step. Sometimes I found myself breaking the rhythm just before I punched the wrong number and then taking some fixed amount of time again to correct myself. Whenever that didn't happen my time would be between 26 and 27 seconds consistently. Basically I had put a few safety checks in (which I probably didn't need most of the time) that were slowing me down. Whenever I pushed myself, I would occasionally parse the wrong operator, type the wrong number, pop up the wrong answer and quickly revert to the strategy that worked. Once I noticed this, I knew I needed to break the pattern.

Forcing errors
I decided to change the pattern, and ignore the mistakes at first. I decided to ignore the operator check and assume that my brain would be able to pick up the numbers and the operator in one go. I made 5 errors out of 20 questions and decided that I was bad at picking the operator, but it must be working somehow, otherwise I would have seen more in the range of 10 mistakes. I gave myself positive feedback by thinking I was a smart cookie for figuring that out.  I repeated it a few times and saw the errors go down and the times with it, more positive feedback. After a mere 5 runs I focussed on making no mistakes again, and I was below 25 seconds. Mind you, before that, trying for over 50 runs there was no way in hell that I was going to go under 26, my top times were averaging around 27.5 seconds. By forcing the errors I had broken the pattern and found a more optimum way of behaving. Much faster than waiting for some luck would have done.

What's going on here
When you make a mistake you tend to give yourself negative feedback "aww shoot!" and this tells you to avoid the behavior that led to this the next time. When you don't make mistakes and you have a better time than before you give your self positive feedback and reinforce the behavior that led to the result. When you try something new and it doesn't pay off immediately, you will give yourself negative feedback. We crave positive feedback, so we keep on aiming to get that result improving, even if our method is flawed and we're in the wrong rhythm. It's hard to break a pattern that reasonable results but is suboptimal. The main reason here is that when left to it's own self learning devices, the variation in methods goes down rapidly. It takes a conscious effort or a lucky coincidence to break out of the suboptimum. The lucky coincidence becomes less and less likely the more you reinforce the suboptimal behavior. This is caused by a thing called Extinction Burst which is intended to pulls you back into the behavior that worked in the past.

Download now or preview on posterous
PastedGraphic-3.pdf (21 KB)

What's to learn?
It pays off to try things, even if the first results are not impressive follow through for a bit and see if you might just be crossing a chasm and things are better on the other side. I've seen this pattern not only in my own behavior, but also in the behavior of groups of students and teams of software developers. As long as we didn't plot the graph of all possibilities the only way to find out that behavior is suboptimal is to explore and find a better type of behavior. With Math Workout this is easy, because if I can't make the required time my behavior must be the problem. If there is no required time and nobody knows which goals to set (like in Software development, or any kind of creative work really) you can never be sure of what works best until you've literally tried everything. The trick is to find a way to reward yourself for trying the new thing that doesn't relate too much to the old reward of squeezing every last drop out of a poor method.

I'm not saying you should be trying everything right now, but how about trying one thing each week? That would already be a huge improvement for most of us I'm sure.

Posted via email from Iwein's braindumps