Unfortunately, change is not that simple. Most people are hesitant to change, they create workarounds for problems they have and trying to make them change often fails. Resistance to change is not about politics or opposing views. Most of the attempts that try to change something and fails do so not because the change was bad, but because of the way the change process itself was managed. Here are three very important facts about change that are often overlooked, leading to almost certain failure in changing.

1. Your vision is not their vision

In the words of my friend Joakim Karlsson, change is a pull system. It may be obvious to you that if your team or organization would just do this change, you would all be much more effective. But do not expect your coworkers/manager/friends (or whoever you want to change (with)) to think so. If you try to push your change on them you are almost certain to fail.

This does not mean that you should just sit back and wait of course. Instead you need to convince them that they need the change. But it is not enough to say that things will get better, or that this new technology is proven to be better. You have to put it in context for each specific individual or group you are trying to convince. What problems are they having today, and how will the future created by this change affect them specifically? The more specific you can be about describing both the current status quo, the change and most importantly the improved future from their perspective the more likely you are to get people interested in the change. And then you will not need to push the change on them, they will be requesting it to happen.

2. It gets worse before it gets better

So you managed to convince your boss to try your idea. He will be back in a week to follow up and see the effects of it. Or maybe you did not even try convincing anyone. After all, when the change is implemented who could possibly have any objection to it when things are already much better?

Wrong! No matter how great your idea truly is, no matter how much improvement it means to your effectiveness, changing what you have now always hurts your effectiveness in the short run. People are used to doing things one way and it does not matter if that is an ineffective way of doing them, if they are forced to change they will do things worse for some time until they learn the new way and settle in with it.

There is lots to say about this curve and how to help people through it, as well as how to work to shorten the time between the change and when you are back at the starting level. For now though we will just keep it at accepting and realizing the importance of this curve. Do not expect immediate gains from the change.

3. It takes time to see the benefits

Finally, you have managed to convince and get people interested in the change, and all of you have also understood that it will be a time of chaos before things get better. But the question is, when has it gotten better? Or more importantly, when can we start reaping the benefits of the change?

It is very easy to think that as soon as the period P1 is over it will all be ok. But you have to remember that during P1 you lost effectiveness. Many change efforts fail because they expect net gains at this stage. But net gains are not achieved until you go through the period P2. Instead of getting surprised by this, set your goals for the end of P2 and keep working to support the change efforts all the way.

Keep these three facts in mind when you plan your change and improvement efforts and you will have a much better chance of succeeding with them.

For instance, you might choose to do a timeline to gather data, then a brainstorming activity to generate ideas for improvements and finally a dot-vote to decide what to do. While this can work just fine, I have found that when I am able to combine several activities so they build upon each other the result can be much better. Here is one example of how this can be achieved.

This week I facilitated a retrospective for the new development team that I have assembled at work. This was the first time that this team did a retrospective after working together for four weeks and I wanted them to start thinking about how satisfied they are with how things are working out. After getting started with an introduction to retrospectives and checking in we did a quick anonymous vote for how satisfied they were with work, in four dimensions. I chose two dimensions regarding the product increment they completed (Quality and Quantity of the increment) and two dimensions regarding how it was achieved (Teamwork and Support (-ing Environment)). Every one voted 1-5, I tallied the votes and then created a Satisfaction Histogram^[1] on a flip chart.

After a quick discussion about the results I hung the histogram on the wall and we then moved on to a second activity for gathering data, Diana Larsen’s FRIM which is one of my favorites for this. At this stage we did not talk more about the dimensions of satisfaction, they just wrote down good and bad things that happened during the four weeks and posted them on a grid according to frequency and impact. We finished with a good discussion of patterns and themes on the grid.

While the group was busy with the FRIM activity I prepared four flip charts for the next activity, doing a Force Field Analysis^[1]. For each one of the dimensions I had written the name at the top and then divided the chart into two sides. On the left (negative side) were forces that was restraining the group’s satisfaction in that dimension of work, and on the right (positive side) were forces that was reinforcing it. Now I asked the group to move the post-it notes from the FRIM grid to these flip charts. They also ranked them (using both frequency and impact plus a bit of intuitive “gut feeling”) to show which forces were larger than others.

This set of activities is an example of how you can move back and forth between gathering data and generating insights, to really get as complete a picture as you can and drill into it to really understand it. When the group was done they had a good idea of which forces were the most important to focus on and we could move into the phase of coming up with actions to do during the next iteration.

One interesting insight that one of the participants made was that it was interesting to see that there were only positive post-it notes for the dimension that the group initially voted the highest satisfaction for. Their initial instinctive feelings turned out to be very similar to the much more detailed picture they created through multiple rounds of thinking and analyzing, which was pretty cool.

Credits/references
[1] Agile Retrospectives: Making Teams Great, Diana Larsen and Esther Derby

Could you draw a copy of the image above without seeing it, acting only on someone’s description of it? What if the other person was only allowed to describe it in written text, and you are not allowed to talk to each other at all? That is the idea of an experiential exercise that I like to include in classes and workshops when I want the participants to experience the importance of instant feedback.

Basic setup

Here is the way I usually use it these days. First, the participants form pairs. One will take the role of developer, the other will be the customer. I then tell them that they will be “developing” drawings, by copying an original drawing to a blank paper. The customer is the only one who will be allowed to see original drawing, and the developer is the only one who will be allowed to draw. I then inform them that we will run two rounds.

Round 1

In the first round the customer must create a specification for the developer, by describing the original drawing in writing. Only text, no symbols or drawings. The customer and developer are not allowed to talk to each other during the entire round.

After five minutes the requirements phase is finished and they move into the implementation phase, when the developer is allowed to start drawing (if they have received a specification of course). The customer is allowed to watch as the developer draws, and if they want to they can provide further instructions in writing throughout the implementation phase. I usually place the developers and customers in different rooms and instruct the customers that they are only allowed to write at their own “desks”.

After ten minutes the implementation phase is finished and I bring everyone together, standing with their pair colleague. Each customer shows their original drawing and the developer shows their produced copy, and we have a quick vote to decide which pair got the best result.

Round 2

I ask the pairs if they want to change roles for the second round, and then introduce the new rules. In this round the customer and developer will sit next to each other. The basic rules are the same, only the customer can see the original drawing and only the developer may draw (e.g. touch the pen), but this time they can communicate in any way they want. They can talk directly and the customer can even point to the paper. The full round lasts for ten minutes and there is no requirements phase, they can immediately start talking and drawing.

Insights and learning points

Apart from the obvious fact that the results were much better in round 2, with less time to complete them, there are also many other insights that can be made from this exercise. Depending on how you play it some of them might be more clear than others. Here are a few things that usually come up when we debrief the exercise (always debrief!).

• Following made-up rules: We often find ourselves following “rules” that do not even exist, we made them up ourselves. Sometimes customers think they are not allowed to use measurement units (such as “3 centimeters wide”) to describe the drawing, even though no such rule is given.
• Creating a common language: In the pause between the two rounds the pair will often talk about their drawing and find common ways they have of describing something. For instance, some will call the solid blue circle in the drawing above a donut. This common “language” makes it easier to describe abstract things such as a drawing (or software).
• Iterating the drawing: This usually happens during the second round, where some pairs sometimes adopt a process of first quickly sketching out the basic layout of the shapes to have something to point to and discuss. They will then start on a new paper and make a better drawing, and possibly iterate like this multiple times.
• “This is just a simulation”: Very often this comes up in some way. One favorite of mine is when people say that they sit in different buildings so they have to communicate by writing to each other. Asking them if the exercise have changed their mind on the value of clearer communication and instant feedback is usually enough to get them started on planning how to make it work anyway.

Variations

I usually run the exercise the way I have described above, as part of an introduction to agile methodologies, to show the difference between trying to communicate by written specifications versus sitting down together and working collaboratively. There are lots of ways it can be altered depending on what insights and learning you want the participants to get from it. Here are a few that I have tried and some that I thought about while writing this.

• Improving through retrospectives: One of my favorite subjects is retrospectives, and variations of this exercise can help teach participants how to use them. For instance, run several shorter rounds and do a retrospective between each one, where the the pairs learn and find improvements to their process. You can choose to only work with written specifications for instance, and let the pairs use the retrospectives to discuss how the specs can be improved and a common language can be used in them.
• Include a messenger: In round 1 use a messenger (maybe call them Project Manager, or Business Analyst) who is responsible for delivering the customers written specifications to the developer and giving the customer feedback on the result. The customer is not allowed to move from his desk, so he never sees the work as it progresses and have to rely on the information from the messenger.
• Involvement of product owner in development: One of the worst anti-patterns I know is the product owner who takes part in the planning of an iteration and then disappears, until he then shows up at the demo and disqualifies the work the team has done during the iteration. Real product owners take part in the daily work of the team, and it is very simple to show this with a variation of this exercise.
• Information loss in multiple handoff situations: Let the customer describe the drawing (probably should be a simpler drawing in this case) to a business analyst, who describes it to an architect, who then describes it to a designer, who describes it to the developer (introduce as many levels as you wish) and see what results you get.

When thinking about variations I think it is important to remember that an exercise should be as simple as possible for whatever learning it should support. Remove any element that does not directly support that learning point. If you have more ideas for variations of this exercise please post a comment. Thanks!

I have uploaded a presentation on Slideshare that introduces the exercise and includes some sample drawings (basic shapes laid out in various ways) you can use.

Credits
I got the original inspiration for this exercise from James Shore and his exercise called Offing the Off-Site Customer.

Alistair Cockburn also has a somewhat similar exercise he calls The Draw-This-Drawing Game which is a bit more complex and used for more specific learning points.

This blog post is part of my Duoblog Series. For each topic I ask someone I know and respect as an expert on that topic to write a blog post with the same title as my post. We then post them at the same time without knowing what the other person wrote.

For advice on creating a great presentation I turn to Claudio Perrone. When I first met Claudio two years ago he had just been accepted to speak at a conference, his first public speaking engagement. Claudio is an amazing learner and quickly studied everything from storytelling and moviescript writing to creating powerful visual presentations. I have been fortunate enough to see him present a couple of times so I know that he can really engage an audience with stunning visuals and a great story.

Read Claudio Perrone’s answer to “What is the secret of great presentations” on his blog.

So much to say, so little time

Picture this: You have been given a chance to present your company’s new product in a 45 min presentation. You want to create a great presentation to make people really enthusiastic about it. So, you fire up Powerpoint and start making bullet points for everything fantastic you can say about your product. The more great things you mention, the better people will feel about it, right?

Unfortunately, this seems to be what a lot of presentations are about. The speaker tries to mention as many things as possible in the time they have available. Each slide has so many bullets that she does not even remember to mention all of them. When time runs out she jumps to the final slide to wrap things up, while mumbling that there were more interesting things to say if only there had been more time. The audience remembers a fraction of what was said, and probably have a hard time summarizing it.

I believe that this happens when the speaker starts by considering how much time is available for the presentation and then works to fill that time with interesting stuff, rather than the other way round.

Creating a great presentation

Start by defining what you would say if you only had a short moment to say it, no matter how much time you actually have for your presentation. There is probably a specific reason why you are giving this presentation. Whether you are talking about a new technology or an idea you have, there is something about it that you think is important enough that you want to tell others about it. This is the core message you should deliver, and it should take no longer than 45 seconds to deliver it. If you can make people more enthusiastic and wanting to hear more about the topic then you know you have succeeded, and you are ready to add more things to the presentation.

If you have more time available, think about how you can make that message clearer and more powerful. Resist the temptation to add another core message to the presentation. Instead add some supporting ideas that give some more detail, still with the core message in focus. To avoid adding too much consider what you would say if you had 10 minutes to present your idea. If you have even more time then add another level of detail, this time giving further support for the ideas introduced in the previous level. In this way the presentation scales up, and everything you say is still related to the one central idea you want people to learn from your presentation.

A powerful message that people will remember

Now that you have taken a different approach to creating your presentation you will need to think about how to frame the core message so that the audience will understand and remember it.

Put yourself in the shoes of your audience and ask “What’s in it for me?”. If you do not give people a reason to remember it, why would they? Put your message into a context that the audience can relate to. Describe a situation or problem that they will recognize from their own life, and then present your idea and how it solves or relates to that problem.

Introduce the core message very early in the presentation, right after setting up the context it should be delivered in. Also repeat it throughout the presentation. Specifically make sure that you end with the core message again, since people generally remember best what they learn at the start and end of a learning session.

Finally, do not be afraid to use Powerpoint or other visual aid. People favor different learning modes (auditory, visual and kinesthetic), and multi-sensory learning is a powerful memory aid. Seeing keywords in written form, accompanied by powerful images, can help your audience remember better. The important thing is to avoid confusing presentation with documentation. A bullet list with some key points is a great aid when later reviewing something, but that does not mean it has to be a part of the actual presentation. Instead provide a separate file for documentation.

Scale your presentation up from the one thing people should learn

In summary, creating a great presentation starts with a clear and concise core message that the audience can relate to. The presentation is then scaled up level by level to add more detail, all the time repeating that core message. If you feel the time is to short, make it shorter.

I will be updating this post with links to each duoblog post as they are written in the future. Stay tuned!

Duoblog posts

• 2009-06-29: What is the secret of great presentations?, with Claudio Perrone

The problem with considering pair programming as something we decide to do in some situations, as opposed to deciding not to do it in some situations, is that it is too easy to stick with the norm by not making that decision. “This task is too simple, that task is too complex and requires some serious thinking, I do not feel like pairing today” are all easy excuses to use when you do not have to answer why. A conscious decision of disregarding a work standard requires much more than “not feeling like it today”.

When I propose that pair programming should be the norm people often react by listing situations where it would be wrong and wasteful (according to them at least) or by identifying problems with working with someone else all the time (“what if someone smells bad?”), almost regressing to an anti-pairing opinion. I think this is because this concept is so foreign to what we have been taught for so long, and that most pro-pairing people have actually not tried pairing as the standard way of working like I propose. To this day I have never met anyone who have actually tried working this way for at least a month but would like to work any other way.

For a great story of someone who did try real pair programming I really recommend Rod Hilton’s post I Love Pair Programming. I’ll end with a quote from that post:

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time.

As I said, it should be quite obvious that most people consider their own code to be better than someone else’s code, but I think we can make some profound realizations from looking into this more closely. There are two questions that are important to think about here. First, what is the effect of this issue? Second, how do we use this knowledge when working with a development team to help them produce better code?

An escalating mess
If I encounter some bad code, I will try and make it better. Since I believe my code to be good code, I will of course try and change the bad code to become more like my code. So, the code is better and everyone wins, right? Well, what about the other guy? He sees my code, and since from his perspective his code is better than mine, he will of course try and change it so it becomes more like his code. And round and round it goes. Each of us are trying to make things better, but together we are actually producing an ever escalating mess.

So, the important question then is how can we help developers realize that their good code might not be the best for the team as a whole? My bet is on communication. Using practices of communication and reflection between the developers in a team, we can create a common understanding of what good code means to us, and break the escalation.

Talk about code
Any time spent away from programming, instead talking about code and coding, is time well spent in a development team. If we want to get a common understanding of what good code is, then we need to have some formal structures in place to insure that this talking about code happens. Do you use pair-programming as the default mode of working? Do you do code reviews, where everyone on the team sits down and talks about some piece of code to learn from each other about how it could be improved? Do you collectively break down user stories (or other requirements) into tasks, using CRC design and similar techniques for exploring what a good design would be? Are you running a study circle?

What techniques and practices does your team use to make sure that you talk about code enough to have a common understanding of what good code means to you?

An anti pattern is a repeated pattern of actions, a process or structure that initially appears to be beneficial

The Helpful Teacher

Introduction
“If we would only use test-driven development, our design would be better.”
As the self-designated technical leader of your team, you are constantly trying to help your colleagues understand and use good practices for writing high quality code. Even so, the code base is a mess and it is not getting any better. You have tried everything, from buying them books (with your own pocket money!) to showing them your own great code during a monthly meeting. The best you have managed is to convince some of them to try, but after a short while they always give up while telling you that it does not work. You are back to square one, or worse since now there are people saying that the practices you are promoting does not even work!

Description
Studies in psychology* have shown that if we ask a person about their ability and competence in some skill, most people would estimate themselves as ranking above the average. (For an example, try asking people about their driving skills.) If we ask a group of people to estimate their own competence relative to the rest of the group, again most people consider themselves to be among the “better part” of the group. In fact, as the above referenced study shows, even the most unskilled people estimate themselves above average, because coupled to the lack of competence is a lack of awareness and understanding of that skill.

To be able to teach someone to use a new skill, they must at least see some need for it. Otherwise, from their perspective, you are only trying to push something not needed on them. Since they are unaware of the problem you are trying to solve, and therefore cannot distinguish your proposed solution from their defunct practices, all of your teaching goes in through one ear and directly out the other. “We are practicing test-driven development. We write tests in a Word document and run them manually before release.”

Refactored Solution
Before you can teach someone a new skill they must become aware of the need for the skill and their own deficiencies in that area. In other words, if you want to promote good technical practices for writing quality code in your team, you must first talk about the need for high code quality. The team needs to have a common understanding of what code quality means to them, otherwise everyone will just think that they are writing quality code and they do not need to learn new practices for improving on it.

Here are a couple of things you can try with your team to increase awareness on the value of high code quality, and to create a common understanding of what it means to your team. The thing in common between them is that they all encourage reflection and discussion.

• Pair-programming
  
  The mother of all knowledge-sharing techniques. If you want to spread an idea to your colleagues you should never sit alone and program. No matter how nice code you write no one is going to notice it, and the practices you follow to achieve it will be completely invisible to the others. Try and spend as much of your time as possible working together with someone else. Do not push for all the practices you would like everyone to use, but use the opportunity to show your partner what you can do and the great results that follow.




• Code Reviews
  
  Lots of organizations use code reviews as a way to achieve higher code quality. However, in my experience they are used in a command-and-control way, where you as the developer submit your code for review to the mighty architect, who then returns it with a number of things for you to fix. While some bugs and other problems can be avoided this way (depending on how much time the reviewer has to look into the code), it is not an efficient way of promoting high code quality in a team.

  Instead, schedule a regular meeting where the entire team meets to review and discuss some piece of code from your project. As an alternative you can pick some open source project and review code from there. That way no one in the room is criticized, and it is easier to have open discussions about issues in the code sample. Rotate the role of selecting the code to be reviewed, make sure everyone has the code in advance to review ahead of the meeting, and then spend an hour or two discussing it together over coffee and a snack. If you want to you can follow up by actually implementing the improvements discussed in the meeting.

• Coding Guidelines
  
  Again, most teams have a coding guideline that prescribes what is good code. They can contain things such as naming guidelines, where to put the curly braces and how many spaces the indentation should use. Sadly though, these are documents written a long time ago, by someone who is not part of the team or sometimes even no longer in the organization. As can be expected, they are not meticulously followed and it is not uncommon for people to be completely unaware of their existence.

  Creating a coding guideline for a team should be a collaborative activity for that team. Gather everyone once a month, discuss what people think is important when writing code and find out what everyone will agree to do. Write this down, preferably on large flip-charts posted in the team room. After a month, meet again and continue the discussion. It is not really the results that are the most important, the discussions are where awareness and understanding is spread throughout the team.

If you can create awareness on the need for high code quality you will not need to teach your colleagues how to do it. They will already want to learn, and all you have to do is answer their questions. (Not quite, but lets not get into that here.)

Things are changing. We are closing down Blueplane after two fun and interesting years. I have had a great time and learned a lot and I am sure my colleagues would say the same (here is what Andrés and Joakim say). Now I am looking forward to a new beginning, although I do not know where right now. If you have an idea or suggestion, please let me know. I’d love to talk.

The simplest way of doing this is to simply ask each participant to say something, for instance describe the past iteration in just one word. This activity, and some variations of it, is described as the Checkin activity in Agile Retrospectives, by Esther Derby and Diana Larsen.

However, if the group are becoming more used to participating in retrospectives, this activity can feel a little boring if used every time. This is a perfect time to spice it up with some more creativity from the participants. By having people draw something and then describe why the drew that specific picture, not only do we get a more rich picture (no pun intended) of their mood and feelings, but it also starts the creative process in everyone’s head.

Purpose
Invite participants to be active participants of the retrospective, and help them to get in a creative thinking state. Share the mood and thoughts people have with the rest of the group, including the retrospective leader.

Description
The retrospective leader asks participants to think about how they would describe the past iteration. Each person then draws a simple picture to symbolize their answer. Finally, in a round-robin fashion, everyone shows their drawing and describes what it shows.

Time needed
Ten to twenty minutes.

Materials needed
I recommend that you supply each participant with a magnetic drawing board (or even Doodle Pro for more size). A simple piece of paper and a pen could of course also work, but see the Motivation section below.

Steps

• Ask the participants a question. You could ask them about their perceptions of the past iteration, or just their current feelings. Depending on the situation, you might want to hear about their feelings of this retrospective or just the work that was done.
• Tell everyone to draw a picture that symbolize their answer.
• When they are done (or time is up), ask them in turn to describe their picture to the rest of the group. Some will just say what it shows, others might describe why they drew that specific picture.
• Listen carefully to signals indicating a safety concern. If necessary, follow up with an activity to create more safety for the retrospective.

Motivation
In Pragmatic Thinking & Learning, Andy Hunt tells us to “add sensory experience to engage more parts of the brain” in problem solving and creativity. He goes on to write that “when you involve an addition input mode, you are activating more areas of the brain – you’re bringing more processing power online [...]“. So by drawing our thoughts and feelings, instead of just speaking them, we are thinking more effectively on this ‘problem’, and also setting our brains up for creative work.

And of course, a picture says more than a thousand words! In my own experience, people who can seem very shy and quiet often draw very descriptive pictures, and are normally quite happy to talk about them.

The question of using simple pen and paper or something like a magnetic drawing board comes down to the purpose of the activity, and the specific situation you are in. The ease with which you can erase a drawing board can create a sense of safety. “It does not matter if you cannot draw very well, it is just a doodle that will be gone in a minute.” The playful nature of it, a children’s toy, also helps in this regard.

On the other hand, you might want to use the drawings later in the retrospective for some other activity, or even bring them back to the team room, in which case paper trumps.

Variants
Two specific variations of this that I know of are the Project Weather activity (I will talk about this in an upcoming post) and my friend Michael‘s Car Instrument Board activity (which I will let him write up a description for himself).

Creativity++
Alt. 1: To really get the creative thoughts going, have the participants pair up to create a drawing together two-and-two. Tell each pair to take turns adding something to the drawing. You can start them off by giving them a subject to draw, such as an animal symbolizing the past iteration. The other person then gets to add something to the drawing to change it, for instance another animal trying to eat the first. The first person ‘defends’ by adding something more to the drawing, and on it goes. After discussing their thoughts and the drawing, the pair then presents it to the rest of the group.

Alt. 2: If you only have one drawing board, and preferably a large one, start by letting the first participant draw something (or do it yourself). The board is then passed to the next person who is not allowed to erase it, but must add to the picture. Everyone gets a turn to add to the complete picture!

Finally, I also want to thank my friend Erik Emmerfors for drawing the great comic strip describing the story of the incompetent bank robber. For more information on what this story has to do with my talk, see the summary flyer on the resources page.

For a couple of weeks now I have been deliberately trying to become more effective by improving focus during daily work. I have had a lot of inspiration from Staffan Nöteberg, whose book Pomodoro Technique Illustrated is a great read. I have tried using the Pomodoro Technique a bit, but for various reasons (one being synchronizing with my colleagues) I’m trying other similar techniques such as PCEO now. Regardless of which technique I have been using I have also tried using some technology to help me focus, and that is what I wanted to write a quick post about here. Specifically there are two applications, Spaces and Quicksilver, that I have been semi-using on my Mac for a long time, but not really been able to see or draw any real benefit from.

Focus on the task at hand

When I am working I want to be able to focus on the specific task that I am doing right now. For instance, if I am writing an article I want to have Textmate (or some other application for writing) running, perhaps a couple of browser windows/tabs with some information I need for the article, and perhaps a Finder window. Just things relevant to this task, and for those applications that can have multiple windows or tabs only the relevant windows.

What I do not want to see is iTunes, Mail, an IM application, lots of browser windows/tabs with “other stuff” not relevant for this task, a development environment, Finder windows for other things, my note-taking application or anything else that could steal my focus if I would look at them.

A simple solution is of course to simply quit all these other applications. But that means it will take a lot longer to switch context to other tasks, or catch up on mail and other communication during a quick break. And perhaps I do want iTunes running since music helps me focus, I just do not want to see it because I can easily get stuck navigating songs. Minimizing all these applications is not much better than closing them, since it still makes it difficult with context switching.

The solution for me has been Spaces, the built-in virtual desktop application in Mac OS X Leopard. Using Spaces, I have arranged my desktops according to tasks. The basic setup has three desktops that always exist:

• My first desktop starts out blank. This is where I work.
• The second desktop is my communication hub. Mail, IM, Twitter, RSS reader etc, all those kind of applications are normally always running here. I also have my calendar and todo’s open and showing here all the time.
• My third desktop is my reading place. Articles, blog posts etc that I defer reading until later are dumped here.

At any given time, I normally have a couple of other desktops created. For instance, since I am interested in photography I normally have a number of browser windows open specifically for reading about photography, and also for following different communities that I take part in. I want to be able to quickly overview what is going on in that area, so I more or less always have a separate desktop dedicated for that. Other ongoing work such as sales usually have a dedicated desktop as well.

More importantly, when I am working on some task (on desktop #1) and decide to postpone it for later, I usually create a new desktop and dump everything there. That way I am ready to start a new task with an empty desktop, and I can easily get everything back when I decide to switch back to the previous task.

Finally, I really like having a communication and planning desktop. This is where I go when I come back from a quick break, to get an overview of any changes that might affect my planning.

Recovering gracefully from interruptions

When I am focused on something, possibly in a nice state of flow, I do not want to lose that focus to an interruption I did not plan for (breaks should be planned often to reflect and re-plan as necessary). However, interruptions cannot simply be ignored. The Pomodoro technique describes some good principles for handling internal and external interruptions. Usually it comes down to making a note of whatever was so important to interrupt you, and scheduling time for taking care of it later.

However, there might be some interruptions that I want to act on immediately. For instance, something as simple as iTunes switching to a song that I do not want to listen to right now. I could switch to iTunes, but that would carry the risk of ‘getting stuck’ navigating songs and thereby losing focus. Another example is sending a quick email (such as just a file that someone needs), or adding something to a todo list. The common theme for all of these are that I need to interact with some other program, but to avoid losing focus I do not want to interact with it directly.

Email a file

This is where Quicksilver really shines. With just a couple of keystrokes I can email that file to my colleague, without even seeing the mail application. It is still ‘hidden’ in another desktop, and there is no risk of me seeing that super interesting but non-urgent email lying in my inbox. Quicksilver has tons of plugins that allow me to do these quick indirect interactions with applications, which means I can recover from an interruption without losing my focus.

Pen and paper rules!

With that said however, as a final note I want to warn you not to rely to heavily on technology. Pen and paper are the base components of whatever focus-helping technique I use. Daily planning of what activities I need to do today, simple follow-up on where my time was spent, and taking notes of things to reflect upon later is best done using just pen and paper.

Further thinking led to a presentation, titled Great Developers, that I gave at the SweNUG Code Camp last summer. There I talked about what I believe a great developer to be, and how they work with code to produce a great result. I had the opportunity to do this again a couple of times during the autumn, and I also submitted the presentation for a couple of conferences during this spring.

I did however change the title, and also the abstract, since my main point in the presentation moved from ‘what is a great developer’ to ‘why are we having trouble helping good developers become great developers‘. This week I gave this presentation to 300-350 people at the JFokus 2009 conference in Stockholm, Sweden. I think it went really well, and I hope people liked it. At least one person commented afterwards:

Your presentation has been one of the most concrete, clear and to the point presentation I have heard since a long time ago, and I can mention that my motivation regarding what you have said has changed.

With the Java-people covered, I move my focus to the Microsoft TechDays conference in Västerås, Sweden on the 17th to 18th of March 2009. And if you happened to miss me on any of these occasions, there is a final chance at the Scandinavian Developers Conference in Göteborg, Sweden, on March 24th.

I hope to see you at some of these events! Take a look at the lineup of speakers for them, they promise to be great sources of inspiration and learning.

I must stress that these are my interpretations and notes of what was said, even when I refer to Jerry or anyone else.

What does experiential mean?

Wikipedia says:

Experiential learning is learning through reflection on doing [...]

In my own words, an experiential meeting (or workshop, training session etc) is a meeting that includes activities that allow you to experience something (through discussion, hands-on work, simulations or something similar) and then learn from that experience by reflecting on it. So in a sense it is about participation as opposed to just listening. But I would not describe a training session as experiential just because it includes an exercise. Without the reflection part a lot of potential for learning would be missed.

So, that brings me to the basic structure of an experiential meeting.

Exploration, Discovery, Application

Jerry described experiential meetings as having three basic components. First we Explore the topic we want to learn about, next we Discover something about it, and finally we try and find a way to Apply that knowledge. Sometimes these are used in cycles. For instance, while Applying something we learned we might move in to a new Exploration.

A style, or pattern, that I like is a session that starts with the participants exploring some concept, either individually or in small groups. They then get into larger groups (or the one group) to share their thoughts and discover patterns or key points. Next, a simulation is used where they will apply and reinforce these key points. The simulation helps the participants explore the concept further, and in the following debriefing they discover even more knowledge.

Whatever happens, happens

A basic principle of an experiential session is what Jerry described as “whatever happens, happens”. As the leader of a session, it is not your job to make sure that something specific happens, or to decide what knowledge the participants should get from it.

As a session leader you are not a trainer with knowledge to push to the participants. You are a facilitator for the learning of the group and the individuals in it. If the participants happen to take the session in a direction you had not planned for, do not automatically force them back. Of course this does not mean you should just be a bystander, or come to the session with no plan. That is not facilitating. Instead, use everything that happens to help the participants get maximum value from the session. Have a plan, and modify it as you go.

Always debrief

I guess there might be a difference for different people, but for me all the learning happens in the debriefing. Or rather, the debriefing sets my mind up for effective learning. During the debriefing I will learn a lot, but even at a later time I will realize things which I believe would have been much more difficult without the debriefing.

During the debriefing participants get to hear other participants’ perspectives. By sharing your own thoughts with others you will refine and extend your own understanding. An interesting way for the facilitator to reinforce this is to find ways to make the debriefing itself experiential. Instead of just having participants say what they thought, help them activate more parts of the brain by using alternative ways of providing feedback.

The Spectrogram activity is a good example. Ask the participants about how they feel about something. Tell them to stand up and place themselves somewhere along an imaginary line from max/agree to min/disagree. Interview people about the reason why they are standing where they are, what their context is.

As the facilitator, make sure that you ask open-ended questions of the participants. A good way to start is just asking about what they saw or heard. Move on to things that puzzled them, and next ask about insights. Finally, ask them about one thing that they can take back to work and apply. Notice the pattern? This is basically the Exploration, Discovery, Application structure again. :)

Safety and comfort

An experiential session can be very different from what many participants are used to. Make sure that everyone understands that participation in any exercise is completely optional. People can have many reasons for feeling that they do not want to be part of an exercise. For instance, Jerry told a story of someone with strong religious beliefs that would not take part in an exercise that involved playing cards. It can of course be much simpler than that, some exercises involve close contact that many people are not ok with. People who do not want to take an active part in an exercise can be given the option of being an observer for the group. They will see things that others do not, so this can benefit both themselves and the rest of the group.

When designing exercises (see more below), have safety and comfort in mind. Are the participants complete strangers to eachother, or have they been working closely together for a long time? Do not use exercises that would need paramedics to be close, or ones that single people out as “losers” (survivor-style). Giving someone a role that will make them look stupid can make them checkout of the exercise, either physically (by leaving) or mentally. Either way, it will affect their learning, and possibly the rest of the group as well.

Regarding people checking out (for different reasons), this is a strong reason (there are others as well of course) to be more than one person leading the session. Use lieutenants to help keep an eye on people. This way if a participant needs attention, the exercise can continue with the rest of the group while someone works with that person to make sure they are ok.

Designing exercises

To end with, here are a couple of tips on how to design exercises and activities for experiential sessions. To me, the most important advice is to keep the exercise itself simple, and let the learning happen in the debriefing. Think about the objective of the exercise, what do you want people to learn from it. Then think about all the steps of the exercise, all the twists it takes, and consider whether they help achieve that objective or if they distract from it. Note that I am not saying there must always be just one clear objective (the great XP game comes to mind), but that you should consider the elements of an exercise to make sure they do not distract from the objective(s).

This is also a good way to invent new exercises. An advice that was given was to try reversing the objective(s), consider how that affects the elements of the exercise, and design from there. I would recommend going further and try using all parts of a technique such as SCAMPER (not just reversal) to design new exercises with different objectives.

Finally, it can be a good idea to have backups for some exercises. Specifically if you are planning on using an exercise that takes some time, it can be necessary to have a shorter backup to use if previous parts of the session ran longer than expected.

To wrap up, in my own experience it helps a lot to include some humor and fun in the session. Try to create a positive energy, and go with that energy throughout the session. And remember, whatever happens, happens!

It is that time of the year again. Øredev, the largest software development conference in Sweden, was this week and we at Blueplane sponsored it again. This year they had a great idea. To encourage people to meet other people and actually go speak with the exhibitors, they had a game for the attendees. Each attendee had to collect a stamp from six different exhibitors to have a chance of winning some nice prizes. Not only that, by collecting those six stamps they also helped contribute money to Unicef for building schools in Africa. A great idea for a great cause!

Each exhibitor who participated in the game (by contributing money to Unicef) got to choose what they wanted attendees to do to get a stamp from them. Some just gave them a stamp when they asked for it. Boring! I wanted to maximize both our opportunity to meet people, but even more so I wanted to encourage people to talk to other attendees. So I came up with a game about collectively defining great teamwork.

To get a stamp from us at Blueplane, an attendee got one of our great looking business cards, which also doubles as a small index card. On the back side they would write a single word that defines great teamwork, according to that person.

Next, we taped the card with the word to their name badge that everyone wore around their neck, and then they had to walk around the conference looking for someone else with one of our cards with a word written on it. When they found someone (hopefully someone they had not met before) they then had to discuss and decide together which of the two words they had that were more important. Between their two words they had to assign seven points, such that the more important word perhaps got five points and the other got two points. They had to assign the points together and then come back to our booth, together, and share their thoughts and how they divided the seven points. That earned them their stamps, and we had an iPod Touch that they now had a chance of winning.

We collected the words and summed up the points they got, and then used this data to write the following definition of what great teamwork is. To everyone who helped us do this, and contributed to building schools in Africa, thank you!

Great teamwork as defined by attendees at Øredev 2008
Great teamwork builds on communication between individuals committed on a common goal. A keen interest in sharing knowledge between one another brings the team members together, creating a fun environment to work in.

I want to give credit to Tobias Mayer, who’s thoughts and description of a session he ran at Agile 2008 inspired me when I designed this game.

As I have been preparing the presentation, I have tried to identify the people will attend it. Next, to make sure that my material is relevant to these people, I have written down their reasons for being there, in a user story format. This way I can quite easily decide if an idea I want to talk about is actually relevant for the audience, or just a darling.

Here are the stories I came up with:

In order to deliver high-quality software with predictability, as a manager I want to support good developers to become great

In order to have more enjoyable challenges, work less with frustrating bugs and more with interesting problems, and advance my own skills, as a great developer I want to advance my colleagues into peers

In order to have more stimulating work and earn the respect of my colleagues, as a good developer I want to have some hands-on advice on what I can do to improve as a developer

If you want to attend the seminar on Tuesday 11 november and have a free breakfast (breakfast is served at 07.30), send an email to seminarier@blueplane.se. The place is St Gertrud Konferens, Östergatan 7b, in Malmö, Sweden. See this pdf (in Swedish) for more info.

Go check out the web site (only in Swedish) and sign up for the conference, and I will see you there!

Photo from bogenfreund’s Flickr photostream

I was recently at the Agila Sverige 2008 conference (which I guess some would call an unconference since it was made up of lightning talks and open space sessions, instead of normal 45-90 minute breakout sessions and keynotes). I presented a lightning talk version of Real Retrospectives – Not Just Talk (download pdf).

I really liked the constraint of presenting the same ideas as before, only this time I only had 10 minutes. In fact, since I am a big fan of the elevator pitch, I started by presenting my content in 45 seconds. After this I told the audience that I had now delivered my core message to them. If they thought the ideas where not that interesting or they already knew the topic, or just did not like me for any reason, they could switch to a parallel session. If not, I would spend the rest of my 10 minutes to build upon that core message and hopefully give them some more value for their time.

This got me thinking, it would be an interesting idea to have a conference start with a general session, where every speaker had to present their session in 45 seconds. This would force speakers to really think through their content and boil it down to the key ideas they want to convey, which in turn I think is a good recipe for improving the quality and consistency of the content. It would also be a lot of help to attendees who are trying to decide which sessions to attend with multiple concurrent tracks. For one thing it would of course be helpful to see what the key ideas are, but also just to see and hear the speakers in action would make the decision easier in some cases.

Photo from mag3737′s Flickr photostream

To take this idea even further, a variation could have the attendees voting for the sessions they think should be included in the schedule after getting the elevator pitches. Attendees could have an Emergency Stop button (for stopping the elevator, giving the speaker more time) to indicate that they liked the idea and would like to hear more about it by attending a full session (however long that is). This would not work for every conference of course, but it would be an interesting idea to try…

The really short summary for non-Swedish speaking is that the session started out discussing why meetings are sometimes not very effective, and moved towards defining areas to focus on to improve them. Unfortunately we did not have time to get down to how to improve in these areas, but the session concluded that the most important area to focus on (of those brought up) is to work on creating an environment that encourages involvement.

I have experienced this in many different team meeting situations, such as retrospectives or daily standup meetings. For instance, a common failure mode of daily standups is when team members address the Scrummaster (or whatever you call your role as a coach) instead of the rest of the team when they inform about their progress. While one person is interacting with the Scrummaster the rest of the team zones out just waiting for their turn.

Photo by bombom

I use a very simple technique when this happens. I simply look away, or perhaps step behind someone else, to break direct contact with the team member addressing me. As simple as this is, I find it very effective. Even if I only look down for a second, when I look up again the person talking has usually gotten contact with someone else in the group and is now addressing the group as a whole.

Furthermore, when a great developer encounters code that is difficult to understand or that makes it difficult to add the new functionality they are working on they do not work around it, or add to the mess by adding more code to an existing big ball of mud. Instead, they follow the mantra of first simplifying the existing code to make it easier to understand, then improving it to make it easier to change, and finally they make the changes necessary to add the new functionality.

Finally, a great developer never leave code in worse shape than what they found it in, but they do not always strive for perfection. They achieve a balance between improving existing code and adding new functionality (in Swedish we call this “lagom”).

This was the message of a presentation entitled Great Developers, Principles and Patterns for writing good code, that I gave at the Swenug Code Camp in Gothenburg last week (pictures available on the Blueplane Flickr photostream, link to slides and code at the bottom of this post).

The presentation had two major parts, each accompanied by a demo with code. In the first part I talked about how developers differ in how much they care about the code they work with, using the story of stonecutters and cathedral builders. I often hear people complaining about how their team members do not care about code the way they do. They then go on to talk about how they have tried teaching them design patterns, Open-Closed Principle, low coupling and separation of concerns etc. I think that although this is important knowledge, the first step towards becoming a cathedral builder is not to learn about such things but to understand and get into the mindset. To do this we need to teach simple work patterns, how a cathedral builder thinks when he encounters code that is not easy to work with. If we can influence someone to think about improving code using something as simple as extracting short code fragments into named methods they will be well on their way towards thinking like a cathedral builder.

In my first demo I played the role of a developer with the task of adding some new functionality to a system that already has some very similar functionality implemented. The existing code was implemented in the PictureListController class, shown below:

	public class PictureListController
	{
		private PictureListView view;

		public PictureListController(PictureListView view)
		{
			this.view = view;
		}

		public void ShowTopPictures(int age)
		{
			// Is visitor allowed to see pictures?
			if (age < LoadsaPicsConfig.MinimumAge)
			{
				Logger logger = Logger.Instance;
				logger.Log("Under age violation!");
				throw new NotOldEnoughException();
			}

			PictureRepository repository = new PictureRepository();
			List allPictures = repository.GetAllPictures();
			allPictures.Sort(
			    delegate(Picture first, Picture second)
			    {
				    return second.Views.CompareTo(first.Views);
				});

			view.SetPicturesToShow(allPictures);
		}

		public void ShowPicturesByRank(int age)
		{
			if (LoadsaPicsConfig.MinimumAge - age > 0)
			{
				Logger.Instance.Log("Under age violation!");
				throw new NotOldEnoughException();
			}

			PictureRepository repository = new PictureRepository();
			List allPictures = repository.GetAllPictures();
			allPictures.Sort(
			    delegate(Picture first, Picture second)
			    {
				    return second.AverageVote.CompareTo(first.AverageVote);
				});

			view.SetPicturesToShow(allPictures);
		}
	}

My task was to implement a new way of listing pictures, this time ordered by most downloads. Instead of simply creating a new public method ShowPicturesByDownloads and copy-pasting code from the other methods, I instead decided to improve the existing code to make it easier to add the new functionality. I first simplified the two methods a bit and found out that they really did the same thing in the first part, so I could extract that into a common method. I noted that I should probably move that method somewhere else sometime, but right now I was OK with leaving it there (lagom). With that code extracted, I noted that the two methods was exactly the same except for the delegate used to sort the pictures. Since the client code that calls this code was also part of the same system I had the option to change the public methods of PictureListController and update any callers accordingly. The final result is shown below:

	public class PictureListController
		{
			private PictureListView view;
			private IComparer sortAlgorithm;

			public PictureListController(PictureListView view,
			            IComparer sortAlgorithm)
			{
				this.view = view;
				this.sortAlgorithm = sortAlgorithm;
			}

			public void ShowPicturesSorted(int ageOfVisitor)
			{
				VerifyOldEnough(ageOfVisitor);
				List allPictures = GetPictures();
				SortPictures(allPictures);

				view.SetPicturesToShow(allPictures);
			}

			private static void VerifyOldEnough(int age)
			{
				if (age < LoadsaPicsConfig.MinimumAge)
				{
					Logger logger = Logger.Instance;
					logger.Log("Under age violation!");
					throw new NotOldEnoughException();
				}
			}

			private static List GetPictures()
			{
				PictureRepository repository = new PictureRepository();
				return repository.GetAllPictures();
			}

			private void SortPictures(List pictures)
			{
				pictures.Sort(sortAlgorithm);
			}
		}

Now I can extend the functionality with infinite sorting orders, simply by instantiating the controller with different IComparers. This led me in to the second part of my talk, where I discussed principles such as Single Responsibility Principle (SRP) and Open-Closed Principle (OCP). I ended with a demo where I showed how a piece of code could be refactored from an implementation that did not follow SRP or OCP, into one that was very open for extension and had clearly separated responsibilities.

My slides and all of the demo code is available on Blueplane’s web site (or download zip file directly).

Take a look at the code fragment below:

	public void readSomeData(int x, int y) {
		int position = x / y - this.z;

		startReadingFromPosition(position);
	}

That first line of code calculates a value according to some rules that are not quite clear from just seeing it. Lets say that this specific calculation is called the UltraMegaAlgorithm. Naturally we need to document this to help readers know that we use this algorithm. But why not simply write a comment? What is the difference between the two alternatives below?

	public void readSomeData(int x, int y) {

		// Use UltraMegaAlgorithm to calculate starting position
		int position = x / y - this.z;

		startReadingFromPosition(position);

	}

	/* -------------------- */

	public void readSomeData(int x, int y) {

		int position =
			calculateStartingPositionUsingUltraMegaAlgorithm(x, y);

		startReadingFromPosition(position);

	}

	private int calculateStartingPositionUsingUltraMegaAlgorithm(
		int x, int y) {

		return x / y - this.z;

	}

Some will argue that it is much easier to read the comment than the camelCased method name. And I agree, it is really unfortunate that method names are often written this way (I think Ruby’s calculate_starting_position_using_ultra_mega_algorithm is at least better, but it is difficult to get Java and .Net programmers to change their old policies). But I would still argue that the second alternative is better. I could argue that we might want to do more than simply extracting into a new method. Perhaps we want to Move Method into another class. Perhaps this might become a strategy implementation. But I think there is a much simpler reason.

My main motivation for extracting into a method lies in considering what is important to us when we read the code to try and understand it. We want to see that readSomeData uses the UltraMegaAlgorithm to calculate a starting position, and then starts (doing whatever it does) from that position. We are completely oblivious to how the UltraMegaAlgorithm is implemented! The information in the comment is what is interesting to us here, not the implementation following it. In fact, that line makes it harder to understand what readSomeData does, since we will stop to consider the implementation even if we do not want to.

My rule of thumb is that the steps of a non-private method should be easy to understand by simply glancing at it. The way to achieve this is to make it read like normal language, which means that unclear one-liners with comments should be replaced with a method call that hides the implementation that the comment describes the reason for. If I trust the implementation of calculateStartingPositionUsingUltraMegaAlgorithm to be correct I can decide for myself if I just need to know that the code does this, of if I want to drill down and learn about the implementation as well.

In fact, with inspiration from Lawrence Lessig, we tried to condense our entire presentation into a short “refrain” (if our presentation would have been a song):

We have to constantly adapt our method to our current reality.
To adapt our method effectively, we have to think together.
Thinking together is hard, and requires focused effort.

We showed these lines several times throughout the presentation, sometimes reading them out loud, sometimes just flashing through them. And as we ended the presentation by showing the refrain a final time we also read it together which produced a few laughs. I think this worked very well and hopefully will help the audience to remember our message. All credits to Andrés for suggesting this and convincing me that it would work.

Our slides and also some pointers to further reading material are available at Blueplane’s web site. The site is in Swedish, but just look for Real Retrospectives and the links in that section. However, I do not think that the slides will be of much value if you did not attend the presentation, so I will try and cover some of what we said in future blog posts (and I am sure Andrés will do the same).

Regarding the conference, I was very happy to see a track called People Matters Too! at a very much developer oriented conference. I was even more happy to see so many people turn up for our session as well as the other sessions in this track. I am sure this will continue next year with at least a full day track like this one. See you there!

I used to have the latin phrase Docendo discimus (We learn by teaching) as my personal motto, but I think Jason Yip really nails it with:

There’s no substitute for sharing knowledge

Jason says you should always explain why, especially to children and others who really have no idea why something happens the way it does. Never just say it’s magic or so. I couldn’t agree more.

On a somewhat similar note, Paul Duvall discuss why you should “fire your best people … reward the lazy ones“. Now, the title is of course a bit misleading although there is some truth to it, but the message of the post for me can be boiled down to the following quote from the post:

If the knowledge is locked in your head, you are a less valuable, not more valuable, resource.

To me, these posts say that it is always important to take the time to share the knowledge instead of just “making it so”, whether it is something we implement in software or just something we say to someone.

The article that inspired my thought was Stan Lippman’s column entitled “Is Programming an Art?”, where he compares software development to art. I like calling software development an art, in the same way as the process of creating a Scotch Blended Whisky is often called an art (as opposed to creating malt whisky which is called a science, since it is mostly about following a protocol). When creating a blended whisky, the Master Blender will use nothing but his nose to select the combination of malt and grain whisky to include in the blend. Sometimes a blend will include up to 50 different sorts of whisky. And every batch of blended whisky that is produced must consistently taste and smell the same way. Anyone interested in Single Malts knows that whisky from different batches, even different barrels in the same batch, will have different characteristics, so being a “Noser” (which is a much cooler title than Master Blender) is truly a difficult job with no easy way of simply following a protocol.

This art of “nosing” in many ways remind me of creating software. Although many would like it to be, software development is not about following a simple process of pressing a couple of buttons and drawing some lines. Producing software requires coding, and no project is ever the same as another one.

Here’s another thought: Maybe this means we can finally retire the term Architect? Lets start using Noser instead, at least for architects doing real work. :D

* Ironically, this was right after I had listened to Don Box and Chris Sells on .NET Rocks!, talking about how no one actually reads magazines anymore and they could not remember when the last time they saw a copy of MSDN magazine was. I think that was the main reason I picked it up and browsed through it. :)

bq. I’m not sure that C# will ultimately the language that will let BDD really shine on the CLR. Without some kind of DSL ability like what can be had from Ruby and Boo, it’s kinda hard to conceive of specification syntaxes that won’t be fraught with C# line noise.

Here is a thought I had while reading this: _Is C# ultimately the language we will use on the CLR, period?_ (VB guys, substitute C# for VB.NET if you want)

Or, to put it in another way, which has the longest lifetime, C# or the CLR platform? For instance, on the Java side of things, here are two slides from “Polyglot Programming”:http://www.sda-india.com/conferences/jax-india/sessions/Neal_Ford/Neal_Ford-Polyglot_Programming-slides.pdf, a presentation by “Neal Ford”:http://memeagora.blogspot.com:

bq. Another language will supplant Java as the primary way people code the Java Platform

bq. Start treating Java as the assembly language of the Java Platform

In the future, will C# be the primary way of programming the .NET platform?

It is a very short post, so go read it if you want. For the even shorter summary, it tells the story of a company that brought in a contractor, Paula, to help with a Java project. She was apparently handed some work to do, and for a few months she reported good progress during the weekly status meetings. However when the deadline came closer she asked for some help to finish it in time, and then it became clear that all she had produced was a couple lines of code that could do nothing more than return a misspelled string.

I guess all posts at WTF has to be taken with a grain of salt, but for now let us consider this one to actually be true. Like I said, it is really absurd, but what is it actually that is most absurd here? While there is no question that Paula was not a very good programmer, can we really blame her for this mess? If the story is true, this is clearly an example of a “process problem”:http://silkandspinach.net/2006/04/02/people-problems-vs-process-problems/. Why did no one notice there were no commits from her? Why did no one review her code? How did she ever get hired? There are so many ways this mess could have been avoided. For instance if Paula would have been pair-programming, her lack of skills would have been noticed at day one. With smaller tasks it would have been clear that she where having problems much earlier.

Unfortunately, even if the story turns out to be untrue, I do not think it is that uncommon. Change a few of the extremes of the story (the ridiculously low amount of code produced, the quite long time period, the insanely large task she must have been working on to be given so much time) into more realistic ones and I think most of us will recognise situations that we have been in. Maybe not situations that ended up the same way, but definitely situations that had the potential to do so. Things such as not testing the code and application enough, not having code reviews, and working on too large tasks with individual responsibility for the programmer that is given them all have the potential to end up in disasters such as The Brillant Paula Bean. When they do, instead of just pointing fingers at the person who screwed up, ask how it happened. Find out what is the root cause and eliminate it.

5.times do |i|
  print i
end

# equivalent for loop over a range
for int i in 0...5
  print i
end

I do not know about you, but I definitely like the 5.times way better. With the new C# 3.0 (as part of Linq) feature extension methods it is a trivial thing to make it possible to write very similar code in C#:

// using a lambda function, also a C# 3.0 feature
5.Times( i => Console.WriteLine(i) );

// or using a "simple" C# 2.0 delegate
5.Times(delegate (int i)
{
  Console.WriteLine(i);
});

So how does this work? By creating an extension method for int and bringing that into scope (with a using statement) all ints will now be extended with the method Times. Actually, int has of course not really been modified “on the fly” to include a new method, it is really only syntactic sugar for a method call such as @IntExtensions.Times(5, i => Console.WriteLine(i));@. Here is the simple extension method:

public static class IntExtensions
{
  public static void Times(this int count, Action block)
  {
    for (int i = 0; i < count; i++)
    {
      block.Invoke(i);
    }
  }
}

So what do you think? Am I crazy for even thinking about writing my C# (3.0) code in this way? Would you get confused and angry by looking at the code?

Take a look at the photo to the right. Notice anything specific about it? Here is a hint: think about enforcing rules. See it now? That is right, there are no lanes, road signs, pedestrian crossings or similar. Other than the give-way markings on the ground, the intersection is completely clear of anything that rules how you should act here.

The photo shows a “traffic calmed” roundabout in the city of Drachten, Holland. Most of the city centre is actually completely free of the traffic ruling items mentioned above. But does this not lead to a lot of incidents? Surely there is some meaning behind this idea, but how can this possibly work? The simple answer is that the lack of road signs and such leads people to such a crazy thing as to actually take eye contact with each other. Instead of taking an “I have the right to do this”-attitude, “people actually take responsibility and work together to avoid incidents”:http://www.smallingerland.nl/index.cfm?sid=175. How many accidents involving cars and pedestrians are not the result the pedestrian simply walking straight out onto a pedestrian crossing expecting any cars to stop. The fact that there is a sign that says it is a pedestrian crossing combined with a law that says cars should stop for pedestrians does not mean that every car will automatically stop! The only thing that this really means is that cars have a responsibility to stop for pedestrians, but pedestrians do not have a right to walk right out into the street.

Although I know analogies can be dangerous, the reason I mention this is that I came to think about it after having a discussion over lunch regarding programming languages and how the code turns out in different ones. The discussion started with “Martin”:http://blog.upplopp.se/ talking about how he writes better code in C++ than he does when using C#. And I can vouch for his abilities in both languages, so it is not as simple as that. The reason, he said, was that C++ was more complex than C# and it is easier to get things wrong, so therefore he paid more attention to what he does when coding in C++. Instead of relying on the (sometimes dubiously) safe environment to help you, taking a step back to actually think for a second or two and make sure that what you just wrote not only solves whatever it should but is also meaningful to someone reading it later makes a huge difference.

The fears and skepticism people have about the lack of road signs in the Drachten intersections can be noted when developers skeptic to dynamic languages describe how they feel about them. “Does not the lack of structure make people do all sorts of crazy things? If someone can just open up a class at any time and modify a method (or add new ones), how can it possibly work out in a collaborative environment such as a typical software development project?” For the same reasons as the Drachten intersections lead to fewer accidents. By removing the “secure” environment of compile-time checking, people are actually forced to think and talk to eachother. Developers use better names for classes and methods, and also use tests to specify their intentions, both to the test runner and to other developers.

I want to use one last example. One practice common in agile development (and elsewhere of course) is continuous integration (CI). The idea is simple, integrate whenever any changes to the system are saved. Unfortunately it is also quite common to see this interpreted as “set up some CI server software, then we are done”. While a CI server can definitely be of use, people forget that “CI is really just an attitude”:http://www.jamesshore.com/Blog/Continuous-Integration-is-an-Attitude.html and “has nothing to do with having a CI server”:http://www.jamesshore.com/Blog/Continuous-Integration-on-a-Dollar-a-Day.html. The CI server becomes the road signs of the intersection. Instead of thinking in terms of what your responsibilities are when checking in, you trust the CI server to solve all problems for you.

To summarize: Be sure to not allow yourself or your team to get a false sense of security from processes and rules. Instead focus on the social parts of software development. Individuals and interactions over processes and tools is what it is all about.

–

Photo downloaded from “sociate’s flickr account”:http://www.flickr.com/photos/sociate/, used under a “Creative Commons Attribution-ShareAlike 2.0″:http://creativecommons.org/licenses/by-sa/2.0/ license.

* Verify that an event subscriber really wires up a listener to an event
* Verify that an event subscriber does what it should when that event is fired
* Verify that an event publisher fires an event when it should

The first two are basically the same. If we can verify that some action that should be taken when an event is fired really does happen then we have of course also verified that the subscriber does listen to the event. But I prefer to start simple with my tests and therefore often end up with a small test like the following one for testing the wiring only:

using System;
using NUnit.Framework;

namespace TestingEvents
{
  [TestFixtureAttribute]
  public class EventsFiringTests
  {
    [Test]
    public void SubscriberWiresListenerToListenToMeEvent()
    {
      FakePublisher publisher = new FakePublisher();

      new SubscriberUnderTest(publisher);

      Assert.AreEqual(1, publisher.ListenToMeSubscriberCount);
    }
  }

  public interface Publisher
  {
    event EventHandler ListenToMe;
  }

  public class FakePublisher : Publisher
  {
    public event EventHandler ListenToMe;

    public int ListenToMeSubscriberCount
    {
      get { return ListenToMe.GetInvocationList().Length; }
    }

    public void FireListenToMe()
    {
      ListenToMe.Invoke(this, EventArgs.Empty);
    }
  }

  public class SubscriberUnderTest
  {
    private string message;

    public SubscriberUnderTest(Publisher publisher)
    {
      message = null;

      publisher.ListenToMe += IAmListening;
    }

    private void IAmListening(object sender, EventArgs args)
    {
      message = "I heard that!";
    }

    public string Message
    {
      get { return message; }
    }
  }
}

This test only tests that the subscriber actually does wire up a listener to the ListenToMe event of the publisher it is instantiated with. The next step is to verify what it does when the event is fired from the publisher. The next test takes care of that.

  [Test]
  public void MessageIsSetWhenListenToMeIsFired()
  {
    FakePublisher publisher = new FakePublisher();
    SubscriberUnderTest subscriber = new SubscriberUnderTest(publisher);

    publisher.FireListenToMe();

    Assert.AreEqual("I heard that!", subscriber.Message);
  }

That takes care of testing that a subscriber does what we expect it to when the event it subscribes to is fired. The final thing that needs to be tested is that a publisher actually fires an event when we expect it to. Lets add a new class, PublisherUnderTest, and another test.

  [Test]
  public void PublisherFiresListenToMeWhenAngry()
  {
    PublisherUnderTest publisher = new PublisherUnderTest();

    bool listenToMeWasCalled = false;
    publisher.ListenToMe += delegate { listenToMeWasCalled = true; };

    publisher.GetAngry();

    Assert.AreEqual(true, listenToMeWasCalled);
  }

  public class PublisherUnderTest : Publisher
  {
    public event EventHandler ListenToMe;

    public void GetAngry()
    {
      if (ListenToMe != null)
      {
        ListenToMe.Invoke(this, EventArgs.Empty);
      }
    }
  }

The test simply assigns an anonymous method to listen to the event from the publisher. In the anonymous method a boolean value is set to true to indicate that the event was fired.

* During the first evening after the opening introduction and “technical” presentation they moved everyone into “the party house”. This was where the unfortunate latest employees of Miracle (the conference organizers) happened to live. Note that everyone means about a hundred people, in one small house meant for 4-8 people.
* The party house had free beer, brewed by Miracle themselves (or rather their sister company that is in the beer brewing business).
* Friday night was beach party. The conference was held at Lallandia, a vacation resort in Denmark with a big indoors waterland. Networking is just so much easier in a jacuzzi with a beer in your hand.
* Most conferences try for a 80/20 mixture of serious stuff (sessions) and fun stuff. At SSOW they go for a 50/50 mix. That does not mean there is less serious stuff, just a lot less time to sleep. :)

I gave two presentations. The first one was a completely new one called Working with SQL Server in an agile development environment (though I think I will change that to Agile Data Practices if I give it again). Even though there where only a few attendees I still had a good time, since it was easier to get a good discussion going.

The other presentation was Understanding CLR Integration which I did for the fourth time. I think it went very well, with a lot of good interaction from the audience. I think it was the atmosphere at the conference that encouraged this, I know I saw it in other presentations as well. Two specific things where mentioned in the talk, which I promised to address here:

* Regarding user-defined aggregates (UDAggs) that can be created as CLR objects, we discussed the problem of the 8000 bytes limitation for “MaxByteSize”:http://msdn2.microsoft.com/en-us/library/microsoft.sqlserver.server.sqluserdefinedaggregateattribute.maxbytesize.aspx. As I said, this limitation really makes it impossible to use UDAggs for a lot of cases where they would otherwise be an option, for instance the often used examples of calculating a median or concatening strings. However, the really interesting bit is that I posted a “feedback item regarding this”:http://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=124559 to Microsoft Connect during the SQL Server 2005 beta testing period. What I said was that the maximum needs to be higher, possibly even indefinite. As the feedback item shows the response from Microsoft was that this was a reasonable request but since it was a non-trivial change it would not make it into SQL Server 2005 (RTM). Wednesday evening however this feedback item was closed and marked as fixed! Unfortunately it does not say how it was fixed or in which version (future service pack of SQL Server 2005, or Katmai the next version of SQL Server?) it is fixed. I am hoping that this gets clarified in the feedback item and also discussed it with Mark Souza from Microsoft who was there (with Lubor Kollar) as speakers and Microsoft representatives.
* The other thing was a question regarding the fact that not all system assemblies can be loaded in SQLCLR. The question was if the list of approved assemblies is available somewhere. I found “this blog post”:http://www.sqlskills.com/blogs/bobb/2006/05/28/NewSQLCLRapprovedAssemblyInSP1.aspx by “Bob Beauchemin”:http://www.sqlskills.com/blogs/bobb/ to be a good answer.

*Download the presentations* (as PDFs):

* Working with SQL Server in an agile development environment (with demo code)
* Understanding CLR Integration

All in all I had a great time. If you are a SQL Server speaker I would definitely recommend putting in an abstract for a session next year.

Actually, even though I really think that “public fields should not even be allowed by the language”:http://gbracha.blogspot.com/2007/01/representation-independent-code.html, I confessed that I do sometimes use them in “test doubles”:http://xunitpatterns.com/Mocks,%20Fakes,%20Stubs%20and%20Dummies.html that I create for my unit tests (for instance for setting a value that I want some method to return when it is called in a test). But this is the only time I use public fields and I am trying to get away from it.

My friend did not agree with me and pointed me to “a post by Jeff Atwood”:http://www.codinghorror.com/blog/archives/000654.html. We did discuss this further that evening over a couple of beers, but I am not sure if I managed to persuade him. Probably not. :)

Some “other”:http://jimmynilsson.com/blog/posts/PropertiesVsFields.htm “smart”:http://blogs.msdn.com/ericgu/archive/2007/02/01/properties-vs-public-fields-redux.aspx “people”:http://blogs.msdn.com/jaybaz_ms/archive/2007/02/08/properties-vs-fields-again.aspx at least seem to agree with Jeff and my friend, but I do not buy into the arguments. It seems there are three main arguments given by proponents of public fields:

* *Performance*: Rico Mariani, performance guru at Microsoft, discusses performance differences between public fields and properties (as a part of a larger performance quiz on using value types for performance) in “two”:http://blogs.msdn.com/ricom/archive/2006/08/31/performance-quiz-11-ten-questions-on-value-based-programming.aspx “posts”:http://blogs.msdn.com/ricom/archive/2006/09/07/performance-quiz-11-ten-questions-on-value-based-programming-solution.aspx. This is the only reason that I can actually sometimes accept. It is of course impossible to argument against it since the numbers are pretty clear, but in general most applications do not see any real difference from these issues. And if the language, and VM of course, did not even allow public fields I think more work could be done there to avoid problems.

* *Trivial properties are just meaningless wrapper code*: I really do not understand this argument. I guess these are the same people who name a variable of type Window to wnd instead of window, or a method that inserts a new value into some container to InsVal. Sure, silly examples, but my point is that typing is not really an issue with modern IDEs. Type prop and hit tab and you have got a property backed by a private field. More lines to read with properties? Sure, but seriously, how is that an issue? Personally I think the code is more readable and understandable with consistent use of properties for accessing an objects internals. And again, if the language did not allow public fields and instead had some syntactic sugar for easily creating properties backed by private fields, like @public property string Name;@, this would not even be an issue. C# 3.0 by the way seems to have something similar, as you can use @public string Name { get; set; }@ to accomplish this, although I think the previous one would be better.

* *Creating a trivial property is a premature decision because they will most often stay trivial forever*: I do not like this. Even if you think trivial properties makes it more difficult to understand the code, calling “YAGNI”:http://en.wikipedia.com/wiki/YAGNI on the decision to create one instead of using a public field to me is a misinterpretation or misuse of YAGNI. What it says that “you should defer making a decision until the *latest responsible moment*”, not simply “defer it until the latest possible moment”. What happens if you create a public field and then later change it into a property when it is used by clients? That is a “breaking change and clients will need to recompile from source”:http://blogs.msdn.com/abhinaba/archive/2006/04/11/572694.aspx. Not a very responsible thing to do.

Even if I would agree with the above arguments, there are enough quirks and problems that you might get into from using public fields that I still recommend avoiding them. These include problems with parts of the .NET framework (databinding and reflection for instance), naming convention questions, and of course most importantly how changing from a public field to a property can break code in several ways, requiring recompiling from source. See the comments to Jeff Atwood’s post above (also summarized by himself in the updated part of the post), and the comments Eric Gunnerson’s post (summarized in a “follow-up post”:http://blogs.msdn.com/ericgu/archive/2007/02/02/more-on-properties-vs-fields.aspx) for more info.

To create a binding on a normal statically declared property, code like the below would work:

Binding binding = new Binding();
binding.Path = new PropertyPath("SomeProperty");
binding.Mode = BindingMode.OneWay;

FrameworkElementFactory textElement = new FrameworkElementFactory(typeof(TextBlock));
textElement.SetBinding(TextBlock.TextProperty, binding);

DataTemplate template = new DataTemplate();
template.VisualTree = textElement;

GridViewColumn column = new GridViewColumn();
column.CellTemplate = template;

With this code in place I now have a column containing a single textblock. The Text property of that textblock will contain the value of the property SomeProperty for each object in the collection that is set as the ItemsSource of the listview. However, as I mentioned above, the problem was that my object (or rather, the object’s type) did not have a static property called SomeProperty. Instead it has a property called Properties, which is a Dictionary containing a “dynamic” set of objects each representing some property (in the general meaning of the word, not in the C#/.NET vocabulary) of the object I am showing on the current row of the listview.

public class ShownInList {
  ...

  public Dictionary Properties {
    ...
  }
}

public class PropertyObject {
  ...

  public string Name {
    ...
  }

  public object Value {
    ...
  }
}

As seen above, each property has a name and a value. What I now want to do is to create a column and bind it to a property with a specific name, so that it will show the value of that property. The intuitive thing to try was to create the binding with a PropertyPath initialized with a string such as “Properties['SomeProperty']“. This did not work however, and neither did the different ways I tested to write the property path string.

Some Googling later I found the solution. Instead of binding to a property using a PropertyPath I could skip setting up the path at all and instead use a custom converter. Here is what I did:

Binding binding = new Binding();
binding.Converter = new PropertyObjectConverter();
binding.ConverterParameter = "SomeProperty";
binding.Mode = BindingMode.OneWay;

...

public class PropertyObjectConverter : IValueConverter {
  public object Convert(object value, Type targetType, object parameter, CultureInfo culture) {
      ShownInList obj = (ShownInList)value;

      string key = (string)parameter;
      return obj.Properties.ContainsKey(key) ?
        obj.Properties[key].Value :
        null;
    }

    public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture) {
      throw new NotImplementedException();
    }
}

The binding is set up to call a converter to get a value to show. The converter is called with the object, of type ShownInList, that is the source for the current row, and a parameter describing which property in the dictionary I want to bind to. If the dictionary contains a propertyobject with the name as key then it returns the Value property of that object, otherwise it returns null.

If anyone has a better solution than mine then please add a comment about it.

Do not get me wrong here, how we work should definitely not be a once-and-for-all decision that we can never change. Quite the contrary, we must reflect regularly on the process and how we work, make changes as necessary and then follow up on those changes. But the point here is that we make these changes from some known base and we make them based on experiencing that something does not work for us. Most importantly changes are introduced at regular points in time (after an iteration), and we try them for some period of time long enough to be able to measure and decide whether they help us or not. What I am referring to with endless discussions about methodology is when a team starts out without having a process that they collectively agree upon and understand.

*Executive summary*: Before the start of a project, gather all the team members and collectively discuss and decide upon the process that the team will follow.

This reminds me of a card game we played in school at a class in Organizational/Group Theory (or something similar). The teacher started by telling us that starting now, *we were not allowed to talk to each other*. No oral communication whatsoever was allowed.

We were then divided into groups, I think there were five groups of five people each (but it’s not important). Each group were placed at a table that had a sheet of paper and a deck of cards. On the paper she had written down the rules for the card game we were going to play. Silently the paper was passed around between the five people at the table so that everyone knew the rules. I do not remember the rules exactly, but it was a very basic kind of “trick-taking game”:http://en.wikipedia.org/wiki/Trick-taking_game. The person who took the highest number of tricks was the winner.

When everyone at the table had read the rules she collected all the papers and told us to start playing. There were no “official” scoring (we had nothing to write on) so it was mostly for fun, but as always the winning instinct in people set in and we had a good time playing. Sometimes you would win a trick and throw your hands in the air in triumph, but noone was allowed to say anything or make any noise. After playing for a while we were stopped and *one person from each table were instructed to move counter-clockwise to the next table*.

Play then commenced again and everyone was happy. Until it happened for the first time that this new person and someone else reached for the trick to collect it at the same time. Confusion arose, the two “winners” looked at each other in anger (maybe not that much anger), and everyone wondered what was going one. Was this new guy trying to cheat? No talking was allowed, so after a while of looking and gesturing someone more or less just grabbed the trick and play continued. This problem was intensified when another person from each table was moved to a new one, this time clockwise. Now it was suddenly a very chaotic game of trick-taking with a lot of silent arguing going on. I think we switched one more time before we finished and discussed what had happened.

What did happen was of course that *each table started out with slightly different variations of the same rules*. When we were not allowed to discuss them then everyone, especially the “stronger” ones, just did things their way. Some “weaker” individuals just did not care and gave up their wins, even though they knew they had won, when someone else reached for the cards. I seem to remember that there were even someone who after figuring it out just started faking a win by reaching for the cards, bullying the others away from them.

The reason we did this exercise was to understand and experience the dynamics of team membership and disagreement. The strong natural leaders often came out winners while others did not win anything. But the reason I compare this with methodology discussions is the fact that we had different sets of base processes (rules) that we tried to follow. Sure, if we would have been allowed to talk about it I think we would eventually have decided upon some common rules that we could all follow. But the person that had to give up a trick that he thought he had won would not be happy, and the discussions would most likely be lengthy and tiresome. *What we should have done was of course to make sure that before we started the game everyone agreed upon the same rules*.

This is how it needs to be done in our projects as well. Before starting a new project a team should sit down and decide how they want to work, and make sure everyone commits to following the process decided upon. This might be as simple as saying “we will follow XP by the book” or you can go the Crystal way of deciding which practices to use. The important thing is that it is perfectly clear what is decided upon and that everyone commits to following it. Even if someone does not agree that a certain practice is a good one they should commit to following it if the team collectively decides to include it. After a couple of iterations the practice can be evaluated and changed if it did not work out. And this process of pinning down the methodology needs to be done *before the project starts*. Just like in the card game, having these discussions when everyone is busy doing Real Work^(TM)^ unfortunately guarantees that they will be lengthy and tiresome, and some people will get run over and feel bad about it.

*To sum up*: Before starting a project, make sure that everyone in the team understands and commits to the process the team is going to follow. But do not forget to reflect regularly and change the process as the team sees necessary.

[Test]
public void CanCreateAndShowWpfWindow()
{
  Console.WriteLine(Thread.CurrentThread.GetApartmentState());

  System.Windows.Window window = new System.Windows.Window();
  window.Show();
}

NUnit (both the GUI and console version) by default runs it’s threads in a multithreaded apartment (MTA), which can be verified by looking at the Console.Out tab. As the message says, instantiating a WPF Window requires that the calling thread is running in a single-threaded apartment (STA).

The simplest way to make this work is to configure NUnit to run tests in an STA thread. Create a config file for NUnit to use (see the docs for info on how to name it) and add the following XML configuration (or just add to your existing one):


<configuration>
  <configSections>
    <sectionGroup name="NUnit">
      <section type="System.Configuration.NameValueSectionHandler"
               name="TestRunner"></section>
    </sectionGroup>
  </configSections>

  <NUnit>
    <TestRunner>
      <add value="STA" key="ApartmentState"></add>
    </TestRunner>
  </NUnit>
</configuration>


Config updated with changes proposed in comments by JohnD. Thanks!

This tells NUnit to run all tests in STA threads. However, if you just want a single test (or some but not all) to run in STA (or MTA, if you have used the above configuration to set the default to STA) you have to resort to code. You need to start a new thread and set the apartment state you want, and then run your unit test in that thread. I used CrossThreadTestRunner (from Peter Provost) and just added support to choose which apartment state to create and run a thread in. The following code example shows how to use it:

[Test]
public void CanCreateAndShowWpfWindow()
{
  CrossThreadTestRunner runner = new CrossThreadTestRunner();
  runner.RunInSTA(
    delegate
    {
      Console.WriteLine(Thread.CurrentThread.GetApartmentState());

      System.Windows.Window window = new System.Windows.Window();
      window.Show();
    });
}

My modified CrossThreadTestRunner class looks like this:

using System;
using System.Reflection;
using System.Security.Permissions;
using System.Threading;

namespace UnitTestThreadApartmentState
{
  public class CrossThreadTestRunner
  {
    private Exception lastException;

    public void RunInMTA(ThreadStart userDelegate)
    {
      Run(userDelegate, ApartmentState.MTA);
    }

    public void RunInSTA(ThreadStart userDelegate)
    {
      Run(userDelegate, ApartmentState.STA);
    }

    private void Run(ThreadStart userDelegate, ApartmentState apartmentState)
    {
      lastException = null;

      Thread thread = new Thread(
        delegate()
        {
          try
          {
            userDelegate.Invoke();
          }
          catch (Exception e)
          {
            lastException = e;
          }
        });
      thread.SetApartmentState(apartmentState);

      thread.Start();
      thread.Join();

      if (ExceptionWasThrown())
        ThrowExceptionPreservingStack(lastException);
    }

    private bool ExceptionWasThrown()
    {
      return lastException != null;
    }

    [ReflectionPermission(SecurityAction.Demand)]
    private static void ThrowExceptionPreservingStack(Exception exception)
    {
      FieldInfo remoteStackTraceString = typeof(Exception).GetField(
        "_remoteStackTraceString",
        BindingFlags.Instance | BindingFlags.NonPublic);
      remoteStackTraceString.SetValue(exception, exception.StackTrace + Environment.NewLine);
      throw exception;
    }
  }
}

A final note: As opposed to NUnit, both TestDriven.Net and Resharper’s Unit Test Runner run tests in STA threads. I got bitten by this recently when all the tests where green on my machine, but when I committed the build server went red on me. I was using Resharper to run the tests, while NUnit-Console was used on the server. Hope this might help someone else in the same situation.

While I can hope that this might change (as said by others, some IDE competition would be great) I am afraid that it will not happen anytime soon. So what can we do in the meantime? I think it is important for those of us who are using OSS tools (or simply tools from other vendors) to promote them in the .NET community. I am not saying that there always exists a better alternative to Microsoft products, often there does not, but it is important that we help the rest of the community see and evaluate the alternatives. I think some good work is being done here. At öredev, the largest developer conference in Sweden, the .NET track consisted of ten seminars and two half-day workshops. Half of these (one workshop and five seminars) discussed some new technology from Microsoft (Atlas, .NET 3.0, Linq etc), but half of them where mostly about educating the .NET community about professional development using TDD, domain-driven design and AOP. These are competencies that are much more common and standard knowledge in the Java community than what they are in .NET.

At the latest SNUG meeting I did my presentation on testable user interface code and Joel Fjordén and Richard Houltz discussed tools for developer productivity (CodeRush/Refactor and Resharper was also mentioned), coding guidelines (from outside of Microsoft, sort of) and how to enforce them using Joel’s CodeStyleEnforcer plugin. This is what we need to do, getting the .NET community together at meetings and facilitating discussions about professional development and creating better code, by showing what tools are available. This of course includes Microsoft tools, but we should not be limited to this one major vendor.

I started out by showing a demo application, built in the all too common way of simply having all code in one form. Naturally, this was only an example so a real application would have multiple forms and maybe even reusable code in the form of some custom user controls. The problems with this application is that it is difficult to test the behaviour of it. Automating some sort of user interface driver to test it creates tests that are much too brittle and difficult to maintain (there are even those that take a screenshot of the UI and then compare the screenshots created by a test to the “correct” ones!).

I then showed how to take the first step to a better design, by separating the domain logic from the UI class. To my surprise only about half of the audience raised their hands when I asked how many do this in their applications. I guess that it might be that some just did not bother to raise their hands, while others did not really associate with the example I showed (maybe they are using a “Transaction Script”:http://www.martinfowler.com/eaaCatalog/transactionScript.html style rather than the “Domain Model”:http://www.martinfowler.com/eaaCatalog/domainModel.html I showed). This step is what Martin Fowler describes as “Separated Presentation”:http://www.martinfowler.com/eaaDev/SeparatedPresentation.html. My examples are very similar to the ones in Fowler’s texts, so it should be very easy to read his detailed writings and take a look at the examples I created to get a good understanding of the things I discussed in the presentation.

The next step I discussed is to move presentation logic from the UI class to a separate class, often called a presenter. The UI class will simply delegate user input to the presenter class, so I think a simple name for this pattern would be Delegated Input Handling (or similar), although I have never heard it called something like that. The common name for this is of course Model-View-Presenter, but I tried to avoid discussing Model-View-Presenter and Model-View-Controller until later in the talk. The demo (in my code) is called “Passive View”:http://www.martinfowler.com/eaaDev/PassiveScreen.html, since the view (the UI class) contains no logic at all. The view does not do anything else than signalling the presenter when user interaction happens (delegated input handling) and then acts as a getter/setter for the various UI elements that the presenter needs to control.

After this I showed a variation of the step above, where the presenter was simplified by replacing the simple plumbing logic with data binding. To accomplish this the presenter exposes the model (domain objects) to the view so that the view can bind the UI elements to properties of the model. The reasoning for doing this is that data binding is “automatic” and included in the framework, so we can safely use it even though we can no longer test this part of the presentation logic. Martin Fowler calls this pattern “Supervising Controller”:http://www.martinfowler.com/eaaDev/SupervisingPresenter.html (though I would call it Supervising Presenter as he discusses in the article), since the presenter now only supervise things by reacting to user input and letting the view automatically show the current state of the model. However, as a supervisor the presenter will also take control of those situations where automatic handling such as data binding is too difficult or impossible. In those situations it will work with the view in the same way as in Passive View. My demo has an example of this.

Finally, I showed a demo of “Presentation Model”:http://www.martinfowler.com/eaaDev/PresentationModel.html. This pattern is kind of similar in intention to MVP (Passive View and Supervising Controller), but it is differently realized. Here instead of having a presenter we create a separate class, PresentationModel, to hold the current state of the UI. The UI class then does nothing but delegate input handling to the presentation model, and synchronize it’s UI elements with the current state exposed by the presentation model. One of the good things about this is that unit tests become easier to write, since there is no need to fake out the view and test the interaction between the view and the presentation model. With the presentation model completely unaware of the view it is also easy to create the presentation logic (in the presentation model) without any view at all while testing.

Some other relevant links that where in some way mentioned in my talk are listed below.

* “Active Record”:http://castleproject.org/activerecord/index.html is a productive way of setting up a data access layer.
* “MonoRail”:http://castleproject.org/monorail/index.html is an MVC-based web framework for the .NET platform.
* Finally, I mentioned the “Agile öresund”:http://mawi.org/agileoresund/ user group that “Marcus Widerberg”:http://mawi.org/ and I are starting up with some others. If you are interested in meeting quite informally to discuss agile topics, please take a look at the wiki.
* And if you missed it in the text above, you can download the demos and presentation I gave in a zipped file.

On behalf of myself and “SNUG”:http://www.snug.se/, I want to thank those who attended the meeting an hope to see you again at the next meeting which will be in February.

There is nothing in YAGNI (or other things in XP) that says you cannot “give yourself credit for knowing something”. From the C2 page linked above, here is a relevant quote:

bq. This doesn’t mean you should avoid building flexibility into your code. It means you shouldn’t overengineer something based on what you *think you might need later on*.

I do not interpret YAGNI the same way as Magnus does. I definitely agree that there is a need for some balancing critique of popular things such as agile and terms such as YAGNI. But I think that it will be difficult to come to a conclusion when the different sides have such different interpretations of what they are promoting/critizising. The readers will have to decide for themselves which interpretation they agree with.

What I find that Magnus is doing here is taking something he does not really like (YAGNI), looking at it from some angle and/or interpreting it in one way which makes it look like a bad thing, and then saying that this is the essence of that thing, so naturally it is a bad thing.

To me, YAGNI is just XP’s way of implementing the lean principle of deferring decisions until the latest responsible moment. I do not think that anyone can complain about how this principle works for Toyota and other lean (non-software) companies, but at the same time I realize that what I am doing is just the same thing as Magnus. I am looking at something that I like (YAGNI), from an angle that makes it look like a good thing, and saying that this is the essence of that thing, so naturally it is a good thing. Debates like these will never have any winner, but then again I do not think the meaning of debating is winning. By discussing it everyone is a winner, since hopefully we all learn something in the process. :)

On the smaller scale, YAGNI and TDD says that we should try and solve our problem (get to green) as fast as possible, cutting corners while doing so. This might result in us adding a “public IADAL AAccess” property. However, when we are at green we are encouraged to think, to remove duplication and to improve our design. In this case though we might just be happy with our implementation and add the next test, the one for the IBDAL. Since we need to get to green fast, we would again just add the “public IBDAL BAccess” property. However, now we start to see duplication. At this stage we must refactor to improve our design.

If we do not continuously refactor to improve the code and design, everything will turn into a “BigBallOfMud”:http://www.laputan.org/mud/. Therefore I do not agree that YAGNI will turn into YAGFI (You Ain’t Gonna Fix It!). Agile practices require a lot of disciple, more so than any other method I have encountered, and being professional and always thinking about how the code and design can be improved is part of this.

On the slightly larger scale, YAGNI says that we should “Always implement things when you *actually* need them, never when you just *foresee* that you need them.” It does not say anything about how we should implement things (e.g. “you are not allowed to use a generic version!”). I like to think about it as “do not design for future requirements, but do design for flexibility”. So what would be YAGNI then? Lets say that we “know” that in the future the DALAccess class will need to support feature X (maybe serialization or whatever). We “know” this because there is a story that has been created but not selected for this iteration* which will need this functionality. Lets say that we have done this sort of thing lots of times before, so we “know” that by simply creating an IXable interface and letting our class implement that (or maybe even just returning dummy values for now, the important thing is that the architecture is correct, right?) we will be good for the future. Doing this is violating YAGNI. First of all we do not even know if we need the feature. Implementing it, or at least designing for it now, will take unnecessary time and produce code that might possibly be unnecessary in the end. Next is the question of whether or not this design is the correct one. Based on our experience and what we know now we might be able to say that this design is the correct one. However, if we defer the decision to when we actually need the feature we will know even more and be able to make an even better decision.

So, from my positive point of view, YAGNI is a great guideline that helps me create software that is as simple as possible, but no simpler.

*: ~Again, this is an example of how YAGNI makes more sense for anyone really doing XP, since the fact that there exists a story does not even mean it will ever be selected for implementation.~

Now there might of course be situations when it makes sense to have more than one assert. However, what is important to note about those situations is that they should not change the Arrange-Act-Assert structure of a test. So if there are multiple asserts in a test, they should all be at the end of the test. Definitely do not let your tests become Arrange-Act-Assert-Act-Assert-Act-Assert or similar.

However, even with nicely structured tests, I have come to think of multiple asserts as a kind of smell that the test (or rather the fixture) might not be really thought through. There is one specific situation that I have seen a couple of times where people say that the test is so simple that there is no reason to write it in multiple test methods. Let me show a typical example:

[TestFixture]
public class FooBuilderTests
{
  [Test]
  public void FooIsBuiltCorrectly()
  {
    string fooThis = "foobar";
    string fooThat = "barfoo";
    FooBuilder fooBuilder = new FooBuilder();
    Foo foo = fooBuilder.Create(fooThis, fooThat);

    Assert.AreEqual(fooThis, foo.This);
    Assert.AreEqual(fooThat, foo.That);
  }
}

What we are testing is a simple builder class (FooBuilder) that is used to create object instances of the class Foo. It takes two strings which we expect to be set correctly on the appropriate properties of the Foo instance returned. Simple enough, right? Why would we ever want to create two separate test methods for these two asserts that are so linked to each other?

As I said, I smell something wrong here. And it is very obvious to me what it is. FooBuilderTests is not a good name for a test fixture, or rather the fixture is not a good one. We should not simply have a single “generic” fixture for every production class. What the fixture is all about is setting up everything in a specific state and then testing things in that state. So what would be a better fixture in this case? Look at the setup that is common for the tests that will be in the fixture. How about we call it AFooCreatedByAFooBuilder. This also makes it quite natural to use the setup method of xUnit frameworks, as I discussed in the “post mentioned earlier”:/articles/2006/10/22/to-setup-or-not-to-setup, although it of course works equally well to do setup in a method called directly from the test methods. Here is what this fixture would look like:

[TestFixture]
public class AFooCreatedByAFooBuilder
{
  private Foo foo;
  private string fooThis = "foobar";
  private string fooThat = "barfoo";

  [SetUp]
  public void InitPerTest()
  {
    FooBuilder fooBuilder = new FooBuilder();
    foo = fooBuilder.Create(fooThis, fooThat);
  }
}

With this fixture it becomes quite natural to create two separate tests for the two asserts. Here is the code that goes for the tests:

  [Test]
  public void ThisIsSetCorrectlyOnFooInstance()
  {
    Assert.AreEqual(fooThis, foo.This);
  }

  [Test]
  public void ThatIsSetCorrectlyOnFooInstance()
  {
    Assert.AreEqual(fooThat, foo.That);
  }

If we strive to organize our tests in a fixture oriented approach instead of a per-production-class oriented approach, I think having one assert per test method comes natural. By the way, with Behavior-Driven Development I do not think this would ever be an issue. With the contexts and specifications of BDD we write this way naturally. Even though BDD is not really a lot more than a different wording from TDD, it makes it so much easier to think correctly about writing your tests/specifications.

One such “rule” that has developed over time is that I tend not to use the SetUp and TearDown methods that the xUnit tools have. These are used to execute some piece of setup and/or teardown code before/after every test method is executed. The reason to use these is of course that you might have some code that is needed to setup the system under test, and this setup code tends to be the same for all test methods in a fixture. To keep things “DRY”:http://en.wikipedia.org/wiki/Don’t_repeat_yourself you will naturally want to put this code in a single place and have it executed along with each test. The xUnit tools have different ways of accomplishing this. NUnit for instance uses reflection to find methods marked with the SetUpAttribute in a class and executes them before each test method is executed.

As I started out doing writing unit tests these methods seemed like a great idea. As soon as I learned about them all test fixtures would have them, in fact the first thing I did when creating a new fixture was to add these methods with a “copy-paste template” (or using snippets or similar when they exist). However, after a while a feeling of something being wrong started showing. Discussing the matter with “others”:http://www.taylor.se/blog and doing some “online reading”:http://www.agileprogrammer.com/dotnetguy/articles/SetupTeardown.aspx led me to the conclusion that SetUp/TearDown was *evil incarnated*.

One of the best things about using TDD is that you almost never need to do any debugging. One of the reasons for this is that when you do some modification to your code and then run the tests, if there is anything wrong you will instantly get feedback about it from a red test. You read the name and location (fixture) of the test and take a look at it, and if you have done things right the test will tell you exactly what it does. With this you will hopefully be able to more or less immediately figure out what you did wrong, and fix it. However, if the test is not well written and does not quickly and easily tell you what it does, then you lose this feedback, or at least a part of it. So what has this got to do with SetUp/TearDown? Well, when the test called Foo in fixture Bar blows up on you and you take a look at it, you want to quickly see what it does. If you are using a SetUp method then you will not get the full picture by simply looking at the test. You also need to take a look at the SetUp, and possibly the TearDown (and then TestFixtureSetUp/TestFixtureTearDown if it is really bad). And, of course we must also know that our xUnit tool works this way, since the test method code shows no evidence of a setup method being called. So, instead of using these tools that xUnit gives us, we should instead be refactoring the common setup code into a separate method and then call that method “explicitly” from each test method. That way it is clear when we look at the test method what it does.

Here is an example of a test fixture written this way (in C# using NUnit):

using System;
using NUnit.Framework;
using SystemUnderTest;

namespace SystemUnderTest.Tests
{
	[TestFixture]
	public class AccountWithBalance100_WithoutSetup {
		private Account account;

		private void Init() {
			account = new Account(100);
		}

		[Test]
		public void Depositing50LeavesBalanceOf150() {
			Init();
			account.Deposit(50);
			Assert.AreEqual(150, account.Balance);
		}

		[Test]
		public void Withdrawing50LeavesBalanceOf50() {
			Init();
			account.Withdraw(50);
			Assert.AreEqual(50, account.Balance);
		}

		[Test]
		public void Withdrawing100LeavesBalanceOf0() {
			Init();
			account.Withdraw(100);
			Assert.AreEqual(0, account.Balance);
		}

		[Test]
		[ExpectedException(typeof(ArgumentException))]
		public void Withdrawing101ThrowsException() {
			Init();
			account.Withdraw(101);
		}
	}
}

So, that is the end of that story the, right? Well, I started out this blog entry writing about BDD, not about SetUp/TearDown. So I guess I need to tie this together now. As I said I have been trying BDD instead for a while now. Apart from calling tests specifications and fixtures contexts, there is not a whole lot different between TDD and BDD. At least on the surface, that is. The whole reason to change the terminology is to “force” people in doing TDD the right way. This means using the tests (specifications) to specify behavior, not testing bugs. This means that you will think a bit differently, depending on how you are used to thinking with TDD. It might not be a huge step for all, but for me it has made me reflect a bit.

I did not notice it until after a while, but one interesting reflection I make now is that I do not follow some of my old house-rules when specifying in BDD. Take this example, in “Boo”:http://boo.codehaus.org/ using “Specter”:http://specter.sourceforge.net/:

import System
import Specter
import SystemUnderTest

context "An account with a balance of 100":
	account as Account

	setup:
		account = Account(100)

	specify "Depositing 50 should leave a balance of 150":
		account.Deposit(50)
		account.Balance.Must.Equal(150)

	specify "Withdrawing 50 should leave a balance of 50":
		account.Withdraw(50)
		account.Balance.Must.Equal(50)

	specify "Withdrawing 100 should leave a balance of 0":
		account.Withdraw(100)
		account.Balance.Must.Equal(0)

	specify "Withdrawing 101 should throw an exception":
		{ account.Withdraw(101) }.Must.Throw(typeof(ArgumentException))

This code example shows a typical BDD context and specifications the way I have been writing them. Note the setup part. Specter, the “xUnit tool” I am using here, sees this and executes the setup code before each specification is executed. I used it without even thinking about it. The way the specs are qritten, following the *Given* _an account with a balance of 100_, *when* _a withdrawal of 50 is made_ *then* _there should be 50 left_ style, it seems so natural to setup the context in this way. I suppose it is also largely due to the way specifications is so often written using only a single row, or at least very short.

So, when I made this reflection, I thought that if you write unit tests following the one-assert-per-test-method rule, and of course write short test methods, and (maybe most important of all) create a test fixture per “situation” (or context…), then why should it not feel as natural to use setup here? Here is an example of the same tests as above but this time with the init code moved into a SetUp method.

using System;
using NUnit.Framework;
using SystemUnderTest;

namespace SystemUnderTest.Tests
{
	[TestFixture]
	public class AccountWithBalance100_WithSetup {
		private Account account;

		[SetUp]
		public void Init() {
			account = new Account(100);
		}

		[Test]
		public void Depositing50LeavesBalanceOf150() {
			account.Deposit(50);
			Assert.AreEqual(150, account.Balance);
		}

		[Test]
		public void Withdrawing50LeavesBalanceOf50() {
			account.Withdraw(50);
			Assert.AreEqual(50, account.Balance);
		}

		[Test]
		public void Withdrawing100LeavesBalanceOf0() {
			account.Withdraw(100);
			Assert.AreEqual(0, account.Balance);
		}

		[Test]
		[ExpectedException(typeof(ArgumentException))]
		public void Withdrawing101ThrowsException() {
			account.Withdraw(101);
		}
	}
}

I am not quite finished with my thinking about this, so I am not sure if I think this is better. But I do not think that one of these tests, when blowing up in the test runner, would give me less information than the ones in the example without using the SetUp method. Since I know that the failing test is in the “AccountWithBalance100″ fixture I can easily guess what the variable account holds. But I guess if the setup is more complex then it might not be as easy to name the fixture and/or understand the code.

Comments? Anyone else using BDD that find themselves using setup differently from when doing TDD?

The EXPLICIT mode of the FOR XML clause is to be used when you need to create XML of a specific format that cannot be done with AUTO or RAW modes. You can use EXPLICIT to generate xml of more or less any format you wish. It is also the most complex mode to use. The AUTO and RAW modes are normally used to transform the result of an existing query from a tabular resultset into an xml stream. The key word in that sentence is existing, by which I mean that whether or not you want the results in xml or not you still use the same query. Just add the FOR XML clause and you’re good.

With the EXPLICIT mode it is not that easy. The transformation engine that creates the xml stream from the result of a query requires that the resultset is designed specifically for this task. The concept you must understand is what is called a universal table. This table will have all the information that is needed for the transformation engine to generate xml of the format you require. So what is a universal table then? I think it is easiest to start with an example:

Tag | Parent | Employee!1!Id
 1  | null   | 280

So what does the above mean? First thing to note is the column names. This metadata is used by the transformation engine to create the nodes in the resulting xml output. We must make sure that the query we run (the one we use the FOR XML EXPLICIT clause with) returns a resultset like the one above.

The first two columns must always exist with those names. They are used to describe the hierarchy of elements in the xml output. Every element that should exist in the needs to be represented by a row in the universal table. Every unique “type” of element (ie an element name at a specific level in the hierarchy of the xml fragment) needs to be uniquely idientified by an arbitrary tag number, which is specified in the first column. If the element is nested inside a parent element then the tag number of the parent element should be included in the column for that.

The rest of the column names (in this case only one) specify the names of the nodes in the resulting xml fragment. In our example we have Employee!1!Id. This cryptic combination says that the element tagged with number 1 should be called Employee, and it should have an attribute called Id. Then, for all the rows in the table the value in this column will end up in the Id attribute of element Employee. So the very simple xml fragment we get from the universal table above would look like this:

This is about as much as the course documentation says about FOR XML EXPLICIT and universal tables. Well, it contains a little more but it is quite difficult to see how to use it for more complex examples than what you can easily create with the other modes. So I decided to create an example that does a little more, but still should be quite simple to understand.

Lets say that we have a requirement to produce an xml fragment like the one below.

        
                
                
                ...
        

What we want is an xml fragment describing a specific employee (id=280 in this case) and her customers. The data we need for this can be returned by the following query (run in the AdventureWorks database):

SELECT Employee.EmployeeId Id
	, Employee.LoginID [Login]
	, SalesPerson.SalesLastYear
	, Store.CustomerID CustomerId
	, Store.Name
	, Customer.AccountNumber Account
FROM HumanResources.Employee Employee
INNER JOIN Sales.SalesPerson SalesPerson
	ON Employee.EmployeeId = SalesPerson.SalesPersonId
INNER JOIN Sales.Store Store
	ON SalesPerson.SalesPersonId = Store.SalesPersonId
INNER JOIN Sales.Customer Customer
	ON Store.CustomerId = Customer.CustomerId
WHERE Employee.EmployeeId = 280
ORDER BY EmployeeId, CustomerID

This result includes all the data that should go in the resulting xml fragment. However it does not tell transformation engine how to create it. If we would simply add FOR XML AUTO or RAW we would not at all get the result we want. What we need to do is to create a query that will return a universal table consisting of the data above but in a resultset that includes the metadata needed to create the xml. The following query will do the trick:

SELECT 1 AS Tag
	, NULL AS Parent
	, Employee.EmployeeId AS [Employee!1!Id]
	, Employee.LoginID AS [Employee!1!Login]
	, SalesPerson.SalesLastYear AS [Employee!1!SalesLastYear]
	, NULL AS [Customers!2]
	, NULL AS [Store!3!CustomerId]
	, NULL [Store!3!Name]
	, NULL [Store!3!Account]
FROM HumanResources.Employee Employee
INNER JOIN Sales.SalesPerson SalesPerson
	ON Employee.EmployeeId = SalesPerson.SalesPersonId
WHERE Employee.EmployeeId = 280
UNION ALL
SELECT 2
	, 1
	, NULL
	, NULL
	, NULL
	, NULL
	, NULL
	, NULL
	, NULL
UNION ALL
SELECT 3
	, 2
	, NULL
	, NULL
	, NULL
	, NULL
	, Store.CustomerID
	, Store.Name
	, Customer.AccountNumber
FROM Sales.Store Store
INNER JOIN Sales.Customer Customer
	ON Store.CustomerId = Customer.CustomerId
WHERE Store.SalesPersonID = 280
FOR XML EXPLICIT

As you can see, what we have is a query that is really built up of several queries (three in our case) unioned together. Each query must include all the columns that it needs itself as well as the ones necessary for the other queries. The queries assign arbitrary tag numbers to the three different kinds of elements in our expected output (remember we had Employee, Customers and Store) and also hierarchically arrange them under their direct parent element.

Each of the queries returns the data that is necessary for the elements at a specific depth in the xml tree. For the columns that specify other elements at other depths they just specify null. Note that all the column names are aliased in the first query, since the union operator will use those names for the unioned resultset. Also note specifically how the second query will always return one row and is only used to add the Customers element (that’s why the column name is only two parts and does not include an attribute name) to use as parent for the Store elements.

Today I stumbled upon a .NET 2.0 feature that helps solve this. I was setting up an assembly with attributes and noted one I had not seen before:

@InternalsVisibleToAttribute (string assemblyName)@

That sounded like something interesting, so I decided to try it. I created a new solution and added a class library project called Code to it. I then added a second class library that I named Tests, which referenced Code (and NUnit.Framework). In the AssemblyInfo.cs for Code I added the following:

@[assembly: InternalsVisibleTo("Tests")]@

Now I was ready to start testing. In Code I created two classes, publicclass.cs and internalclass.cs as shown below.

// publicclass.cs
namespace Code {
  public class publicclass {
    internal bool internalmethod() {
      return true;
    }
    public bool publicmethod() {
      return true;
    }
  }
}

// internalclass.cs
namespace Code {
  internal class internalclass {
    public bool publicmethod() {
      return true;
    }

    internal bool internalmethod() {
      return true;
    }
  }
}

In the Tests project I then added InternalsVisibleToTests.cs, shown below:

// InternalsVisibleToTests.cs
using NUnit.Framework;
namespace Tests {
  [TestFixture]
  public class InteralsVisibleToTests {
    [Test]
    public void AccessPublicClassMembers() {
      Code.publicclass foo = new Code.publicclass();
      bool condition1 = foo.publicmethod();
      bool condition2 = foo.internalmethod();

      Assert.IsTrue(condition1);
      Assert.IsTrue(condition2);
    }

    [Test]
    public void AccessInternalClassMembers() {
      Code.internalclass foo = new Code.internalclass();
      bool condition1 = foo.publicmethod();
      bool condition2 = foo.internalmethod();

      Assert.IsTrue(condition1);
      Assert.IsTrue(condition2);
    }
  }
}

As you can see these tests refer to both internal types and members in the Code assembly. The solution compiles and the tests are green!

Even though my libraries often do not need this (most of the stuff is public anyway), it is a very useful technique to have access to. It should be noted of course that this means that anyone can create an assembly named Tests and access the internals in my Code assembly, but there are of course ways around that.

Then on Monday 12/12 the local .NET user group that I am co-founder of, “Skånsk .NET User Group (SNUG)”:http://www.snug.se/ will have our last meeting for 2005. We have some maybe not as famous speakers but still very interesting presentations to offer; Marcus Widerberg from Dotway will talk about Developing with Generics in .NET 2.0 and then Kim Gräsman from TAC (and C++ MVP) will talk about Continuous Integration and CruiseControl.NET. If you are in the Malmö/Lund/Helsingborg/Köbenhavn area and interested then “take a look at the forums”:http://cs.snug.se/forums/86/ShowPost.aspx#86.

A couple of months ago (well about half a year ago actually, don’t know why I haven’t thought about this again until now) I was preparing a presentation on SQL Server 2005 that I was to present at a breakfast seminar at Dotway. Since I was going to speak Swedish I wanted to try and include as little Swenglish as possible (very common in the Swedish IT community otherwise, though usually called ‘Svengelska’ which would be the Swedish ‘translation’ of the ‘English’ word Swenglish). So I was looking to translate as much of the terms I could. But one term where I completely stumbled was _aggregate functions_.

*What do you call Aggregate Functions in Swedish?*

Or more specifically, I was going to describe user-defined aggregate functions in SQL Server 2005, and wanted to avoid Swenglish. To make sure we have the same English definition here, what I mean by an aggregate function is a function that calculates a single value based on a set of values as input. I guess more or less as it is defined in “Princeton Wordnet”:http://wordnet.princeton.edu/perl/webwn?s=aggregate, but with a little more database context to it.

The first one that came to mind was the probably very Swenglish ‘*Aggregatfunktioner*’. To someone familiar with SQL Server it sounds very correct, but I guess that is precisely because they (and I) recognise the English word that is actually in there. And the only definition of the word ‘aggregat’ I have found in Swedish does not provide a lot of help here:

*aggregat* [agreg'a:t Uttal] aggregatet aggregat aggregaten subst.
grupp av sammanbyggda maskiner

A typical use of this is a word like ‘värmeaggregat’ (something like a heater). And that is nowhere near what I am looking for..

Next try was ‘*Aggregeringsfunktioner*’ and immediately after that came ‘*Aggregerande funktioner*’. These feel more Swedish, and the first one is actually used in the “IT word dictionary of PC World”:http://pcforalla.idg.se/tjanster/dataordboken/ (look up ‘aggregera’), as much as you want to use that as a source.. But they still do not sound quite correct (and fully Swedish), and they definitively do not feel right to say. So I actually went ahead and used the Swenglish ‘*aggregatfunktioner*’ in my presentation, which I think worked very well and everyone understood what I meant (in a typically Swenglish fashion).

Today when I somehow came to think about this again I contacted “Jesper Holmberg”:http://blogs.msdn.com/jesperh/ at Microsoft and asked him what he thought about it. Jesper works with the Swedish localization of Windows and other Microsoft products (and possibly more, sorry if I missed something) and has a very interesting blog as well. He was really quick at answering and his suggestion was ‘*mängdfunktioner*’, apparantly the recommended translation at Microsoft (remember other products, such as Excel, have aggregates as well). This is a great translation that really conveys the meaning like I wanted, but unfortunately it feels like noone ever use that word in Swedish. So I fear half of the audience (if I were to give the presentation again) would not realize what I was talking about, at least not immediately. But I do think that I will actually use ‘*mängdfunktioner*’ next time unless I get a better suggestion.

So, anyone with other ideas, please post a comment…

As I mentioned in the “preview post”:http://www.hedgate.net/blog/2005/12/06/coming-user-group-meetings/ both presentations at the meeting was given by Dr. Michael Rys from Microsft and member of the ISO SQL committee and W3C XQuery committee. Michael knows a lot about XML and his presentation on XQuery was very interesting. Personally I do not see me storing XML in SQL Server even with the new support in SQL Server 2005. Michael mentioned scenarios where you want to store “semi-structured data” as one example where it would be a good idea to store it in an XML datatype column. But to me the word “semi-structured data” has as little meaning as “denormalization”. It does not have a specific meaning, and the general explanation “data that is not relational” is no good since all data is best managed in a relational management system in my view. Using XML and XQuery in stored procedures is a different case, where I have many thoughts with lots of further sidetracks, but that part of my brain is to incoherent right now to write anything about it. Look for more on this in the future.

The other presentation Michael gave was a general overview of SQL Server 2005, actually the same presentation that he gave on the SQL/VS2005 launch events lately. So there was not a lot of interesting news to me there, but again it was interesting to listen to Michael since he gave his personal view on different items. I asked him about the possibility of row-value constructors finally appearing in the next version of SQL Server. He agreed that it was definitely one of the important parts from the SQL standard missing in SQL Server and a top candidate for being implemented, but also recommended letting them know about it by sending an email to “sqlwish@microsoft.com”:mailto:sqlwish@microsoft.com. I guess another request for row-value constructors won’t hurt.. :)

And one last thing, regarding the next version of SQL Server. Although Bill Gates has already mentioned it in an interview and I have seen it in a couple of blogs (Microsoft and non-Microsoft), this was the first time I heard a Microsoft-employee use the codename “Katmai” for the next version of SQL Server in speech. I wonder if all of the attendees understood what he meant when he said “will be fixed in Katmai”. :)

All in all it was a great meeting and as always well worth the time and effort to go there. Now I am looking forward to the local SNUG-meeting this monday.

Disregarding any environmental and economical factors, which alternative would you choose? Most of us, I think, would choose the car. Now compare this to software design. Which one of the two alternatives best resembles the way most people design software? Unfortunately the bus is a lot more common than the car. Requirements are ’set in stone’ initially even though they are not fully known (and they can’t be of course). The developers then try and implement some of the requirements and when they are done they leave it for QA (and/or the customer) to test and give them feedback on the direction. Sure, there are lots of processes and ideas on how to refine the bus trip to make it as smooth as possible, but the fact is you are on that bus and you are not driving. You can only get feedback (or at least react to it) when the bus stops, and as soon as you get on the next bus you are once again working in unknown land until the next stop.

The way we use the car instead of the bus trip in software design is that we increase the frequency of feedback. By testing first, continuously integrating, evolving the design and ‘requirements’ and always communicating with the customer (in fact putting the customer in the passenger seat of our car) we get feedback as often as possible which lets us adapt to the current direction we need to be moving in.

Performance tuning and troubleshooting in SQL Server has always been something of a black art. To be effective at it you need to know how to use a large set of tools, including Profiler, Perfmon, DBCC commands and stored procedures. Sometimes it can seem almost random which tool you should use for a specific issue. They will often affect performance themselves, so you might not always be able to use them. [...] SQL Server 2000 can be seen as a black box that can be quite difficult to penetrate. SQL Server 2005 changes all this by introducing the new Dynamic Management Objects.

I have written a short “article on Dynamic Management Objects (DMVs and DMFs) in SQL Server 2005″:/writings/dynamic-management-objects for the “Quest Pipelines newsletter”:http://www.quest-pipelines.com/newsletter-v6/newsletter_1205.htm.

If you have not listened to the webcast I definitely recommend you do so, it is filled with great advice. Below are some notes from it, posted here mostly so that I will remember them myself. But I have also added some comment where appropriate.

* Do not forget to do reflection when you are planning. As Peter Provost comments, this is simply following the process since the process tells us to reflect on the past iteration while we are planning the current iteration. But somehow this part is often forgotten. To add to that, you should of course not only reflect while planning the current iteration, reflection should be done as often as possible.
* Manager approval and sponsorship is very important to agile projects. For instance, a common problem is that people are used to being judged by their individual achievements. But agile advocates that the whole team and the results it produce (in particular) is what is important. Therefore it is a manager’s job to make sure that the importance of setting aside your ego and instead working for the team is communicated to everyone.
* One specific area is pair-programming. Developers (who have not tried it) can be reluctant to do it. A similar problem is pairs that never change, e.g. some or all of the pairs are always comprised of the same developers. Peter suggested a pairing chart to help with these issues. List all the names of the developers in a matrix and note down when two developers pair. The goal is to have all the columns in the chart filled. Someone added that a pairing session should not be more than a couple of hours long, spanning a “single coherent logical thought”. After that you should move on to another partner and problem.
* A particularly interesting part (to me) was remote pairing. The P&P team includes a number of consultants that are not present in the warroom at Microsoft at all times. Some of the work was done by people in South America. All the time though people where pairprogramming. They tried a number of different setups, including Skype, VNC and LiveMeeting, similar to what “me and Andrés”:/articles/2005/11/22/distributed-pair-programming/ tried. Although this seems to have worked very well for them, they where also quick to note that when they where actually pairing at the same physical desk theyfelt much more productive and focused.
* The final thing I want to mention was the discussion on how to get people (developers, management, customers etc) interested in working with agile principles. This was interesting since Andrés recently did a presentation with similar ideas called Guerilla Agile at Dotway’s latest competence weekend (actually I ended up presenting his material since he got sick the night before). The most obvious way is to simply show them how well it works. For instance, write your code using TDD even if you are the only one. It should soon be obvious that your code is better. :) When someone presents a design as a diagram, ask if you could state it as a test to document it. Pairprogram whenever you can, soon pairing will be the default instead of the other way round. And my favorite quote from Peter Provost: “If you do not have a warroom, steal one”. Book a conference room for weeks, days, hours or whatever it takes. Share the reservations between the team members, finally management will understand that you really do need a dedicated room.
This is just a small set of all the great advice from the webcast. I hope you are not satisfied with my notes and go listen to the whole thing ASAP.

bq. If your user story does not fit on a card, get a smaller card!¹

The reasoning for this is of course that you are not really writing user stories, you are writing something that is bigger (too big). The story should not include a lot of detail, that part is for the conversation [about the story]. By making sure that the stories are not too large you also make sure that you are not spending too much time gathering requirements and thinking too much about details.

bq. If a project is finished on time with all the specified requirements implemented, then chances are that it will not be considered a successful project after some time!²

If a project finishes all the specified requirements on time, then chances are you did not really ‘find’ all the requirements that the customer really wants to have. Project management is all about deciding which requirements that are to be implemented now, later or left behind. You should always have more stories than you have time for.

bq. If a project/team/company is completely dependent on one programmer, get rid of him!³

The longer you wait, the more dependent you become and the more of a bottleneck, or constraint, this programmer becomes. Note to ‘trigger-happy’ management: you do not really need to fire the programmer, there are “other ways to remove the constraint”:http://www.nayima.be/about/TheoryOfConstraints.html.

If you have similar wisdoms then please post them in the comments.

References:
fn1. This one I picked up in Mike Cohn’s book “User Stories Applied: For Agile Software Development”:http://www.amazon.com/gp/product/0321205685/, but he further attributes it to Tom Poppendieck.

fn2. I am not quite sure where I first heard this, but I know Ron Jeffries has written about “similar issues”:http://www.xprogramming.com/xpmag/jatmakingthedate.htm.

fn3. I am not sure if I have read this one specified in this way or just made it up myself, but in any case it is such a common idea that no one source can be attributed.

Although I am sure that most of my readers are smarter than me and would figure out what the problem was in an instant, I thought I’d just make a note of it here anyway. First I thought about the DataAccess and SystemDataAccess parameters of the SqlFunction attribute. It seemed strange that they should be involved, but I tried experimenting with them anyway. No luck. After a while of thinking some more I did what always works, went for a cup of coffee. The answer came to me just about the same time as the cup was brewed. Functions are not allowed to send results to the client, whether implemented in CLR or T-SQL. Using a PRINT statement in a T-SQL UDF results in the following error when trying to create it:

@Msg 443, Level 16, State 14, Procedure test, Line 3@

@Invalid use of side-effecting or time-dependent operator in ‘PRINT’ within a function.@

So, I ended up using the Visual Studio debugger for my purposes, just as I should have from the start of course. Debugging by outputting text strings is not the best way of debugging. I just had one problem with the debugger though. I was using Niels Berglund’s excellent SQLCLR project add-in for Visual Studio for creating, deploying and debugging the code. I am not sure if the Visual Studio CLR project type behaves the same way, or even if it was just me doing something wrong, but the debugging mode were always abruptly ended with a message that the deployment took too long and timed out. Has anyone else had this problem?

The other thing was that BOL is not 100% accurate in the description of what the property WindowsIdentity of SqlContext can return. In BOL it says that if you are running integrated security this returns the token for the caller of the code, but if SQL Server security is used it returns NULL. What is missing is that if a SQL Server login which is a member of the sysadmins fixed server role (such as sa) is the caller of the code then WindowsIdentity will return a token. There is no meaning in calling the Impersonate method on it though, as it is the token for the SQL Server service account. Since SQLCLR code by default executes as the SQL Server service account there is not a lot of meaning in impersonating it..

Consider the following C# 3.0 code:

// Foo.cs
namespace thirdpartylib {
  public class Foo {
    private int x;
    private int y;
    public Foo(int x, int y) {
      this.x = x;
      this.y = y;
    }

    public int DoFoo() {
      return this.x + this.y;
    }

    public int X { get { return this.x; } }
    public int Y { get { return this.y; } }
  }
}

// ExtendFoo.cs
using thirdpartylib;
namespace extensions {
  public static class ExtendFoo {
    public static int DoBar(this Foo theFoo, int z) {
      return theFoo.X - theFoo.Y - z;
    }
  }
}

// Program.cs
using System;
using thirdpartylib;
using extensions;
namespace LINQConsoleApplication1 {
  class Program {
    static void Main(string[] args) {
      Foo foo = new Foo(1, 2);

      int i = foo.DoFoo();
      int j = foo.DoBar(3);

      Console.WriteLine("DoFoo: {0}", i);
      Console.WriteLine("DoBar: {0}", j);
    }
  }
}

When this little program is executed it prints “DoFoo: 3″ and “DoBar: -4″ to the console. For those that have not seen C# 3.0, the interesting part is the static class ExtendFoo with it’s static method DoBar. The keyword @this@ before the first parameter is what is new in 3.0, and it is what lets us extend the Foo class to seemingly have a DoBar method that the program can call. By simply bringing them into scope (with the @using extensions;@ line) the compiler adds any static methods on static classes with the first parameter ‘decorated’ with the @this@ keyword to the applicable classes. Note though that this is only syntactic sugar, what is really happening (and which can easily be seen by reviewing the IL generated) is the same as if we would have written this:

int j = ExtendFoo.DoBar(foo, 3);

So, coming back to method overload resolution. For extension methods the rule is that the extension method is used if it does not clash with an instance method on the extended type. So, now consider what happens when this code is added to Foo:

    public int DoBar(short z) {

      return this.x * this.y * z;

    }


Now the behaviour of our program has changed into printing "DoBar: 6" instead of "DoBar: -4". Considering the IL that is generated with extension methods this is not at all strange, but I anticipate one or two developers might get caught by this. Microsoft does include a warning about extension methods in the PDC preview bits (??"Extension methods are less discoverable and more limited in functionality than instance methods. For those reasons, it is recommended that extension methods be used sparingly and only in situations where instance methods are not feasible or possible."??), but this in particular feels kind of creepy.
]]>
			http://www.hedgate.net/articles/2006/10/04/extension-methods-and-method-overload-resolution/feed/
		1
		
		
		
		http://www.hedgate.net/articles/2006/10/04/troubles-with-shared-state-and-anonymous-delegates-in-sqlclr/
		http://www.hedgate.net/articles/2006/10/04/troubles-with-shared-state-and-anonymous-delegates-in-sqlclr/#comments
		Wed, 04 Oct 2006 02:14:01 +0000
		Chris
		
		
		
			Earlier today I set out to create “a SQLCLR function for splitting a comma-separated string including ranges”:/articles/2006/01/27/splitting-a-comma-separated-string-with-ranges-included/ (such as “2,5,7-9,13”) into a set of values. I encountered some problems that I think is valuable to document here. The code below shows what I initially wrote:

SqlFunction(
  DataAccess = DataAccessKind.None,
  SystemDataAccess = SystemDataAccessKind.None,
  IsDeterministic = true,
  IsPrecise = true,
  FillRowMethodName = "FillRow")]
public static IEnumerable SplitWithRanges(SqlString input) {
  // First expand ranges
  Regex rangeExpander = new Regex(@"(?\d+)\-(?\d+)");

  string expandedRanges = rangeExpander.Replace(
    input.Value,
    delegate(Match match) {
      int startOfRange = Int32.Parse(
        match.Groups["RangeStart"].Value);
      int endOfRange = Int32.Parse(
        match.Groups["RangeEnd"].Value);
      string[] values = new string[endOfRange - startOfRange + 1];
      for(int i = 0; i < values.Length; i++) {
        values[i] = (startOfRange + i).ToString();
      }
      return String.Join(",", values);
    }
  );

  // Now split the string containing the comma-separated values
  string[] splittedValues = expandedRanges.Split(
    new char[] { ',' },
    StringSplitOptions.None);

  return splittedValues;
}

public static void FillRow(Object obj, out SqlString tuple) {
  tuple = new SqlString((String)obj);
}

However, when I tried to add this assembly to SQL Server I ran into problems. The CREATE ASSEMBLY statement failed with the following message:
@Msg 6212, Level 16, State 1, Line 8@


@CREATE ASSEMBLY failed because method 'SplitWithRanges' on type 'Functions' in safe assembly 'Splitting' is storing to a static field. Storing to a static field is not allowed in safe assemblies.@
I know that assemblies must be registered in UNSAFE to use shared state. The reason is that if an executing thread suffers a thread abort exception (for instance due to a stack overflow or out of memory exception being thrown by something it does) and there is any shared state in the application domain where it is executing, then the entire application domain is unloaded. It does not matter whether or not this specific thread was using the shared state, as a safety precaution the application domain is unloaded. Therefore SQL Server tries to restrict you from using shared state in SQLCLR.
But where does the C# code above use any shared state? A little reflecting with Lutz Roeder’s Reflector gave me the answer. The row with the anonymous delegate above is actually compiled into IL that matches C# code similar to this:
if (Functions.<>9__CachedAnonymousMethodDelegate1 == null) {
  Functions.<>9__CachedAnonymousMethodDelegate1 = new MatchEvaluator(
    Functions.b__0);
}
string text1 = regex1.Replace(
  input.Value,
  Functions.<>9__CachedAnonymousMethodDelegate1);

Functions is the name of the class containing my code, so what this does is use a static field for storing the delegate. The static field is defined as below:
[CompilerGenerated]
private static MatchEvaluator <>9__CachedAnonymousMethodDelegate1;

So there we have the shared state. To get around this there are two solutions. I can either define a function to use as the delegate, like this:
private static String ExpandRanges(Match match) {
  int startOfRange = Int32.Parse(
    match.Groups["RangeStart"].Value);
  int endOfRange = Int32.Parse(
    match.Groups["RangeEnd"].Value);
  string[] values = new string[endOfRange - startOfRange + 1];
  for(int i = 0; i < values.Length; i++) {
    values[i] = (startOfRange + i).ToString();
  }
  return String.Join(",", values);
}

Then I just change the row calling the delegate to this:
string expandedRanges = rangeExpander.Replace(
input.Value,
new MatchEvaluator(Functions.ExpandRanges));

The second “solution” is to use a variable local to the function SplitWithRanges inside the anonymous delegate. The reason this works is that the compiler now generates a private nested class with a function that is used as the delegate. So, if I for instance declare a variable @bool foo = true;@ outside the delegate and then simply do @foo = foo;@ in the code of the anonymous delegate then the compiler will actually create this:
[SqlFunction(
  DataAccess=DataAccessKind.None,
  SystemDataAccess=SystemDataAccessKind.None,
  IsDeterministic=true,
  IsPrecise=true,
  FillRowMethodName="FillRow")]
public static IEnumerable SplitWithRanges(SqlString input) {
  Functions.<>c__DisplayClass1 class1 = new Functions.<>c__DisplayClass1();
  Regex regex1 = new Regex(
    @"(?\d+)\-(?\d+)");
  class1.foo = true;
  string text1 = regex1.Replace(
    input.Value,
    new MatchEvaluator(class1.b__0));
  char[] chArray1 = new char[] { ',' } ;
  return text1.Split(chArray1, StringSplitOptions.None);
}

As I mentioned above, class1 is a private class defined (by the compiler) in my class Functions. So under the covers this solution is very similar to the previous one. It is just a question of where the function is placed. Although I love anonymous delegates, in this case I went with defining the function myself and using that for the delegate.
]]>
			http://www.hedgate.net/articles/2006/10/04/troubles-with-shared-state-and-anonymous-delegates-in-sqlclr/feed/
		0
		
		
		
		http://www.hedgate.net/articles/2006/10/04/splitting-a-comma-separated-string-with-ranges-included/
		http://www.hedgate.net/articles/2006/10/04/splitting-a-comma-separated-string-with-ranges-included/#comments
		Wed, 04 Oct 2006 02:03:40 +0000
		Chris
		
		
		
			While browsing the SqlServerCentral.com forums earlier today I saw a question that interested me. The person asking it wanted to split a string containing a repeating group of values into a set of values. I remembered that Eric Gunnerson is running a series of regular expression puzzle questions and that “one of the recent ones”:http://blogs.msdn.com/ericgu/archive/2006/01/16/513644.aspx was about just this, just not with the SQL Server variant. So, here is what we want to be able to do:

SELECT *
FROM dbo.SplitWithRangesExpanded( '1,3,7,12,15-20,23,27-29' );

The result should be this set { 1,3,7,12,15,16,17,18,19,20,23,27,28,29 }. The following code in C# can be used to define a streaming table-valued function in SQL Server.
using System;
using System.Collections;
using System.Data.SqlTypes;
using System.Text.RegularExpressions;
using Microsoft.SqlServer.Server;

public partial class Functions {
  [SqlFunction(DataAccess = DataAccessKind.None
    , SystemDataAccess = SystemDataAccessKind.None
    , IsDeterministic = true
    , IsPrecise = true
    , FillRowMethodName = "FillRow")]
  public static IEnumerable SplitWithRanges(SqlString input) {
    // First expand ranges
    Regex rangeExpander = new Regex(
      @"(?\d+)\-(?\d+)");

    string expandedRanges = rangeExpander.Replace(
      input.Value,
      new MatchEvaluator(Functions.ExpandRanges));

    // Now split the string containing the comma-separated values
    string[] splittedValues = expandedRanges.Split(
      new char[] { ',' },
      StringSplitOptions.None);

    return splittedValues;
  }

  private static String ExpandRanges(Match match) {
    int startOfRange = Int32.Parse(
      match.Groups["RangeStart"].Value);
    int endOfRange = Int32.Parse(
      match.Groups["RangeEnd"].Value);
    string[] values = new string[endOfRange - startOfRange + 1];
    for(int i = 0; i < values.Length; i++) {
      values[i] = (startOfRange + i).ToString();
    }
    return String.Join(",", values);
  }

  public static void FillRow(Object obj, out SqlString tuple) {
    tuple = new SqlString((String)obj);
  }
}

Note that the original code I wrote used an anonymous delegate for the regular expression match evaluator, but due to problems with shared state I had to explicitly define the function to use for it. Read the "companion post regarding these technical issues":/articles/2006/10/04/troubles-with-shared-state-and-anonymous-delegates-in-sqlclr/ for more info.
]]>
			http://www.hedgate.net/articles/2006/10/04/splitting-a-comma-separated-string-with-ranges-included/feed/
		1
		
		
		
		http://www.hedgate.net/articles/2006/10/04/index-lookups-seeks-and-scans/
		http://www.hedgate.net/articles/2006/10/04/index-lookups-seeks-and-scans/#comments
		Wed, 04 Oct 2006 01:20:52 +0000
		Chris
		
		
		
			In my latest article entitled “Dynamic Management Objects”:http://www.hedgate.net/pages/articles/dynamic-management-objects/ I describe a great new feature in SQL Server 2005. With Dynamic Management Views (DMVs) and Dynamic Management Functions (DMFs) we can get a lot of real-time information regarding what have been going on in the server since the latest restart. I was looking through some of these recently and while testing the DMV called sys.dm_db_index_usage_stats I noticed something that intrigued me. Among a lot of other interesting columns in the output there are three called user_seeks, user_scans and user_lookups. Now, I know what scans and seeks are, but how is a lookup defined? In particular, how does it differ from a seek? I had a hunch that I knew what they indicated, but to verify it I did some quick testing, which is described in the below script.



USE AdventureWorks

GO
– Empty result set (when server is just restarted of course)

SELECT * FROM sys.dm_db_index_usage_stats

WHERE OBJECT_ID = OBJECT_ID(‘Sales.SalesOrderHeader’);
SELECT * FROM Sales.SalesOrderHeader;
– IndexId 1: 0 user_seeks, 1 user_scans and 0 user_lookups

SELECT * FROM sys.dm_db_index_usage_stats

WHERE OBJECT_ID = OBJECT_ID(‘Sales.SalesOrderHeader’);
SELECT * FROM Sales.SalesOrderHeader

WHERE SalesOrderID = 70875;
– IndexId 1: 1 user_seeks, 1 user_scans and 0 user_lookups

SELECT * FROM sys.dm_db_index_usage_stats

WHERE OBJECT_ID = OBJECT_ID(‘Sales.SalesOrderHeader’);
SELECT * FROM Sales.SalesOrderHeader

WHERE SalesOrderID BETWEEN 70875 AND 70879;
– IndexId 1: 2 user_seeks, 1 user_scans and 0 user_lookups

SELECT * FROM sys.dm_db_index_usage_stats

WHERE OBJECT_ID = OBJECT_ID(‘Sales.SalesOrderHeader’);
SELECT * FROM Sales.SalesOrderHeader

WHERE CustomerID = 28220;
– IndexId 1: 2 user_seeks, 1 user_scans and 1 user_lookups

– IndexId 5: 1 user_seeks, 0 user_scans and 0 user_lookups

SELECT * FROM sys.dm_db_index_usage_stats

WHERE OBJECT_ID = OBJECT_ID(‘Sales.SalesOrderHeader’);
SELECT * FROM Sales.SalesOrderHeader

WHERE CustomerID IN (28220, 25925);
– IndexId 1: 2 user_seeks, 1 user_scans and 2 user_lookups

– IndexId 5: 2 user_seeks, 0 user_scans and 0 user_lookups

SELECT * FROM sys.dm_db_index_usage_stats

WHERE OBJECT_ID = OBJECT_ID(‘Sales.SalesOrderHeader’);


One thing to note about sys.dm_db_index_usage_stats is that the numbers in all of these columns show the number of ‘operations’, not the number of pages or rows or anything. So, as this script shows, a user_lookup is the operation used in a clustered index (or heap) to fetch a full data row (or rows) using the key(s) returned from a seek operation of a non-clustered index.
]]>
			http://www.hedgate.net/articles/2006/10/04/index-lookups-seeks-and-scans/feed/
		5
		
		
		
		http://www.hedgate.net/articles/2006/10/04/more-on-magic-numbers/
		http://www.hedgate.net/articles/2006/10/04/more-on-magic-numbers/#comments
		Wed, 04 Oct 2006 01:16:06 +0000
		Chris
		
		
		
			I recently posted a recommendation about “avoiding magic numbers in stored procedures”:/articles/2006/01/12/stored-procedure-guidelines-avoid-magic-numbers (and other t-sql routines of course). Yesterday I updated that post with some important info that invalidates the recommendation from a performance view. Please read the updated post if you have not seen this. However, I still think the advice of avoiding magic numbers to make code more readable is important.

So what can we do to write readable code and still have good performance? Well, the simple answer is unfortunately that we cannot in this case. In SQL Server 2005 we an use the new query hint OPTIMIZE FOR to allow us to use a variable instead of a literal in our code, but I am not sure I would say the code below is more readable than simply using a literal:


DECLARE @StartOrderDate datetime

SET @StartOrderDate = ’20040731′
SELECT * FROM Sales.SalesOrderHeader h, Sales.SalesOrderDetail d

WHERE h.SalesOrderID = d.SalesOrderId

AND h.OrderDate >= @StartOrderDate

OPTION (OPTIMIZE FOR ( @StartOrderDate = ’20040731′ ) )


This query will produce the same plan as if we just used the literal instead of a variable. If the literal represents a value that is not at all easily understood (unlike the date literal above) then maybe we could say that this code is more easily readable than the alternative, but for most cases it will just look silly.
However, when thinking about this I came up with another idea. What if we could use named (declared) literals in our code, just like constants in a language such as C#? We could declare a constant with a read-only literal, and then use that constant in the query. The effect would be the same as using the literal by itself. Some examples of how this could look is shown below:


DECLARE @SomeConstant int = 42

DECLARE !SomeConstant int = 42

CONSTANT @SomeConstant int = 42

READONLY @SomeConstant int = 42


So what do you think? Am I just too concerned with making stored procedures readable, or is this something you would like to see in a future version of SQL Server? How should it look and work?
]]>
			http://www.hedgate.net/articles/2006/10/04/more-on-magic-numbers/feed/
		5
		
		
		
		http://www.hedgate.net/articles/2006/10/04/stored-procedure-guidelines-avoid-magic-numbers/
		http://www.hedgate.net/articles/2006/10/04/stored-procedure-guidelines-avoid-magic-numbers/#comments
		Wed, 04 Oct 2006 01:10:23 +0000
		Chris
		
		
		
			*UPDATE*: I have just read a post by “Ian Jose”:http://blogs.msdn.com/ianjo/default.aspx from the “Query Optimizer team”:http://blogs.msdn.com/sqlqueryprocessing/default.aspx that sort of invalidates this recommendation. He writes that you should “use literals, or at least unchanged parameters, for query inputs”:http://blogs.msdn.com/ianjo/archive/2005/11/10/491538.aspx. As his post shows, using variables as I write below can often have a negative impact on performance. I think this is a real shame, since using magic numbers in this way definitely makes the code less readable. Possibly the best way to go is to move the query to a separate procedure and pass the magic number from the ‘outer’ procedure as a parameter to this new procedure, like Ian describes in his post. That way we would avoid magic numbers and still get the best plan, although I am not sure the readability is helped by this added complexity. I will leave my post as it was originally written because I think it is still good advice to think about the readability of code. The part about watching out for non-SARGable where clauses is also still valid, which Ian hints about in “another post”:http://blogs.msdn.com/ianjo/archive/2005/11/10/491541.aspx.

Most programmers are aware of the pitfalls involved with using magic numbers in code (at least I hope so). For instance, instead of writing something like @if(foo == 42)@ you should create a constant and use @if(foo == MeaningOfLife)@, since not everyone knows that 42 equals the meaning of life (you might think that all computer geeks know this, but they actually do not). For some reason though the good practice of not using magic numbers seems to be forgotten when it comes to writing stored procedures, or just sql scripts in general.
In stored procedures you often see something like @WHERE somecolumn = 42@. There’s a magic number right there. In a situation where somecolumn should be compared to a parameter that was passed to the procedure it would instead be @WHERE somecolumn = @someparameter@. My advice is that the same style should be used even when the number is not a parameter but just a hard-coded value. So:
*Avoid using magic numbers in SQL statements. Declare them as variables and use the variable instead.*


– Bad code, do not use this style

SELECT …

WHERE somecolumn = 10 
– Good code, use this style

DECLARE @somevariable SMALLINT

SET @somevariable = 10
SELECT …

WHERE somecolumn = @somevariable

 
Apart from making the code more readable, this advice can also be important for performance reasons. The literal 10 used in the example above is seen by SQL Server as an integer constant. This means that if the data type of somecolumn is not integer then an implicit cast needs to be done to be able to compare the values. Now, consider what happens when somecolumn has the data type smallint. The data type precedence rules for SQL Server state that a smallint is converted to an integer. So, the where clause in reality becomes @CAST(somecolumn AS INT) = 10@. Not only are we wasting CPU cycles casting the value of somecolumn for every row, even more worse is that this clause does not confirm to the SARG rules. These state that to be able to use an index seek for evaluating a where clause it needs to follow the formula @column operator expression@. With the CAST function the clause becomes @expression operator expression@, so a table (or index) scan is used.
This problem is of course easily avoided by casting the integer constant to a smallint (@somecolumn = CAST(10 AS SMALLINT)@), but then we would still have the magic number. And it is easy to forget to cast the literal and forget about the implicit cast. Avoiding magic numbers force us to think about what data type we actually want.
]]>
			http://www.hedgate.net/articles/2006/10/04/stored-procedure-guidelines-avoid-magic-numbers/feed/
		1
		
		
		
		http://www.hedgate.net/articles/2006/10/04/review-pragmatic-unit-testing-in-c-with-nunit/
		http://www.hedgate.net/articles/2006/10/04/review-pragmatic-unit-testing-in-c-with-nunit/#comments
		Wed, 04 Oct 2006 01:00:03 +0000
		Chris
		
		
		
			I read “Pragmatic Unit Testing in C# with NUnit”:http://www.pragmaticprogrammer.com/starter_kit/utc/index.html this morning. I love the fast-paced to-the-point writing style of “Andy Hunt”:http://www.toolshed.com/blog and “Dave Thomas”:http://blogs.pragprog.com/cgi-bin/pragdave.cgi (and the other authors in their publishing house), and this book was no different than other books in the Pragmatic-series. Most of the contents was stuff that I already knew, both practically (how to) and theoretically (why), but it was still a good read to get another person’s (or two in this case) view of these matters. I also learnt a couple of smaller things about NUnit that I did not know before, such as the [Suite] attribute that can be used to create test suites of test fixtures.

For anyone new to unit testing and TDD (and specifically in C# or at least the .NET world) I would recommend this book along with Kent Beck’s “Test-Driven Development: By Example”:http://www.amazon.com/gp/product/0321146530/. Even more so if you are just starting up a project where you will be using unit tests and have to get up to speed quickly. It starts with a good explanation of why you need unit tests, then proceeds to describe how to do this using NUnit and finally discuss how to write better unit tests and how to incorporate unit tests into a project. All of this in just 176 easy-to-read pages (I finished it in just over an hour, though I could read quite fast since most of it was not new to me).
]]>
			http://www.hedgate.net/articles/2006/10/04/review-pragmatic-unit-testing-in-c-with-nunit/feed/
		2
		
		
		
		http://www.hedgate.net/articles/2006/10/03/design-patterns-in-ruby-chain-of-command/
		http://www.hedgate.net/articles/2006/10/03/design-patterns-in-ruby-chain-of-command/#comments
		Tue, 03 Oct 2006 23:35:20 +0000
		Chris
		
		
		. “GOF”:http://www.amazon.com/gp/product/0201633612/ p.223 In the book, the GoF mention how in Smalltalk it [...]]]>
			Chain of Responsibility:

bq. Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.
p>. “GOF”:http://www.amazon.com/gp/product/0201633612/ p.223
In the book, the GoF mention how in Smalltalk it is possible to do a very different implementation using the @doesNotUnderstand@ mechanism. Ruby of course has a similar one in @method_missing@, so I thought that I would use this in an implementation example of Chain of Responsibility. There is also an alternative implementation beneath it that does not use @method_missing@.


# Generic implementation for Chain of Responsibility

module Chainable

  def next_in_chain(link)

    @next = link

  end
  def method_missing(method, *args, &block)

    if @next == nil

      puts “huh?”

    return

  end
  @next.__send__(method, *args, &block)

  end

end
class X

  include Chainable
  def initialize(link)

    next_in_chain(link)

  end
  def do_x

    puts “x”

  end

end
class Y

  include Chainable
  def do_y

    puts “y”

  end

end
y1 = Y.new

x1 = X.new(y1)
x1.do_x

x1.do_y

x1.do_z


Now, I guess it might not be a good idea to define method_missing in a module (comment anyone?), so you could of course change it to let the classes handle that themselves. I also did this alternative implementation that does not use method_missing but is still fairly generic.


# Alternative implementation for Chain of Responsibility

module Chainable

  def next_in_chain

    nil

  end
  def handle_message(message, *args, &block)

    if self.respond_to?(message)

      self.__send__(message, *args, &block)

    else

      next_in_chain.handle_message(message, *args, &block) unless next_in_chain.nil?

    end

  end

end
class X

  include Chainable
  def initialize(link)

    @next = link

  end
  def next_in_chain

    @next

  end
  def do_x(x)

    puts x

  end

end
class Y

  include Chainable
  def do_y

    yield ‘y’

  end

end
y1 = Y.new

x1 = X.new(y1)
x1.handle_message(:do_x, ‘x’)

x1.handle_message(:do_y) {|y| puts y}

x1.handle_message(:do_z)


]]>
			http://www.hedgate.net/articles/2006/10/03/design-patterns-in-ruby-chain-of-command/feed/
		0
		
		
		
		http://www.hedgate.net/articles/2006/10/03/design-patterns-in-ruby/
		http://www.hedgate.net/articles/2006/10/03/design-patterns-in-ruby/#comments
		Tue, 03 Oct 2006 23:29:25 +0000
		Chris
		
		
		
			One of the cool things about working at Dotway is the Design Patterns study group that we have. We have been meeting weekly/biweekly/sometimes for a while now and each time we discuss one of the GoF patterns in detail. We like to find out how they are used, what variations there are of them and how they are used in the .NET Framework (which is what we normally work with). However I thought I would use this as an opportunity to get to know Ruby better. So, I will try and write up an example of a Ruby implementation of each of the patterns we discuss. We are already through more than half of them so maybe I will be thinking about the ones we have already done as well.

I am not saying that my implementation is optimal, in fact in many cases it will only be an example. Please chime in with comments about alternative implementations or anything else if you want. The first pattern I will write about will follow this post immediately.
]]>
			http://www.hedgate.net/articles/2006/10/03/design-patterns-in-ruby/feed/
		2
		
		
		
		http://www.hedgate.net/articles/2006/10/03/setting-the-contents-of-a-wpf-richtextbox/
		http://www.hedgate.net/articles/2006/10/03/setting-the-contents-of-a-wpf-richtextbox/#comments
		Tue, 03 Oct 2006 07:46:42 +0000
		Chris
				

		
		
			In the project I am currently working on we are using Windows Presentation Foundation for building the GUI. This means there are a lot of new things to learn. Even the small things take some time when you do not know which of the new controls to use are what properties and methods to use on these. (Of course it does not help that Resharper 2.0 does not know anything about XAML).

One such problem that I just had was working with a RichTextBox. The application should contain a text box where the users can enter text, using all the standard functionality such as bold, italics etc, and this information (text and markup) should be stored in the database. This was not as straightforward as it used to be in .Net 2.0 (or earlier). Since I guess other people will likely want to do the same thing I am posting the code I wrote to do this.
public string InputText
{
  get
  {
    string text = "";

    using(Stream stream = new MemoryStream())
    {
      TextRange contents = new TextRange(
        textBoxInputText.Document.ContentStart,
        textBoxInputText.Document.ContentEnd);

      contents.Save(stream, DataFormats.Xaml);

      stream.Position = 0;

      using(StreamReader reader = new StreamReader(stream))
      {
        text = reader.ReadToEnd();
      }
    }

    return text;
  }
  set
  {
    textBoxInputText.Document.Blocks.Clear();

    if(value != null && value.Length > 0)
    {
      using(Stream stream = new MemoryStream(
        UTF8Encoding.Default.GetBytes(value)))
      {
        TextRange contents = new TextRange(
              textBoxInputText.Document.ContentStart,
              textBoxInputText.Document.ContentEnd);

        contents.Load(stream, DataFormats.Xaml);
      }
    }
  }
}

The property InputText is part of the view interface for this page in our Model-View-Presenter architecture. The presenter uses this property to show/collect the value in the model.
]]>
			http://www.hedgate.net/articles/2006/10/03/setting-the-contents-of-a-wpf-richtextbox/feed/
		0
		
		
		
		http://www.hedgate.net/articles/2006/10/03/active-record-presentation-at-snug/
		http://www.hedgate.net/articles/2006/10/03/active-record-presentation-at-snug/#comments
		Tue, 03 Oct 2006 07:43:55 +0000
		Chris
		
		
		
			Wednesday evening we had the last “SNUG”:http://www.snug.se/ meeting before summer. The meeting was hosted Dotway. We had a great turnout with around 30 people apart from us that arranged it, even though we informed about the meeting as late as two weeks earlier. First we had Jim Christensen from Commentor in Denmark tell us about the .NET Compact Framework and his experiences with mobile development. After that we had a break with Subway sandwiches and some great discussions. Finally I presented a session on the Active Record pattern that Martin Fowler describes in “P of EAA”:http://www.amazon.com/gp/product/0321127420/.

I have uploaded a zip file with the C# examples that I showed. They show how the Active Record pattern works in it’s most simple implementation and then how to use Castle project’s ActiveRecord framework to avoid having to do all the work yourself.
I also showed an example of how a dynamic language such as Ruby can take this even further for extreme productivity gains. The code below shows how to use the ActiveRecord implementation in Ruby on Rails by itself in a simple script.
require 'active_record'

ActiveRecord::Base.establish_connection(
  :adapter => 'sqlserver',
  :host => '127.0.0.1\SQL2005',
  :database => 'blogs',
  :username => 'blog_user',
  :password => 'secret')

class Blog < ActiveRecord::Base
  has_many :posts
end

class Post < ActiveRecord::Base
  belongs_to :blog
end

blog = Blog.new
blog.name = 'Chris Hedgate'
blog.uri = 'http://www.hedgate.net/'

post = Post.new
post.title = 'Hello, SNUG!'
post.contents = 'TBW'

blog.posts << post

blog.save

blogs = Blog.find_all

blogs.each do |blog|
  puts "#{blog.name} (#{blog.uri})"

  puts 'Posts:'
  blog.posts.each do |post|
    puts " -- #{post.title}"
  end

  puts ''
end

Finally, I promised to post some links to various things I talked about in the session.
* "Active Record pattern in P of EAA":http://www.martinfowler.com/eaaCatalog/activeRecord.html

* "Data Mapper pattern in P of EAA":http://www.martinfowler.com/eaaCatalog/dataMapper.html

* "Castle ActiveRecord implementation":http://www.castleproject.org/index.php/ActiveRecord

* "NHibernate":http://www.nhibernate.org/ Object-Relational Mapper

* "NHibernate Generics":http://www.ayende.com/projects/nhibernate-query-analyzer/generics.aspx, Ayende Rahien’s nice contrib for working with generics

* Mats Helanders tool "ObjectMapper":http://www.objectmapper.com/Home/Default.aspx
Thanks to all the people who attended the meeting. Kim, Daniel, Henrik and I look forward to seeing you at new SNUG meetings after the summer.
]]>
			http://www.hedgate.net/articles/2006/10/03/active-record-presentation-at-snug/feed/
		6
		
		
		
		http://www.hedgate.net/articles/2006/10/03/microsoft-certified-technology-specialist/
		http://www.hedgate.net/articles/2006/10/03/microsoft-certified-technology-specialist/#comments
		Tue, 03 Oct 2006 07:35:55 +0000
		Chris
		
		
		
			I just noted in my MCP transcript that I passed the Beta Exam for 70-431 TS: Microsoft(r) SQL Server(tm) 2005 – Implementation and Maintenance. This means that I am now a Microsoft Certified Technology Specialist (MCTS) for SQL Server 2005. Curiuosly though, I do not feel any different. :)

It is nice to see some results from the busy months I have had behind me though. First a lot of reading for beta exams (next one coming up in March) and then a lot of writing, both an article for SQL Standard magazine and also the presentation on CLR Integration. I gave the second presentation last Thursday in Stockholm at the Swedish SQL Server User Group. It went quite well, although there were unfortunately not as many in the audience as I had hoped. So now it is two down, one to go, and the final one is the big one at PASS Europe in Barcelona. I have also spent a lot of time preparing a presentation of the Ruby programming language for my colleagues next weekend, but that is a different story.
]]>
			http://www.hedgate.net/articles/2006/10/03/microsoft-certified-technology-specialist/feed/
		1
		
		
		
		http://www.hedgate.net/articles/2006/10/03/pass-europe-2006-over/
		http://www.hedgate.net/articles/2006/10/03/pass-europe-2006-over/#comments
		Tue, 03 Oct 2006 07:30:15 +0000
		Chris
		
		
		
			I am back home after attending PASS Europe 2006 in Barcelona, where I also presented a session myself. I have uploaded a zip file with the presentation that I did (Understanding CLR Integration in SQL Server 2005). I will be posting a followup post about some of the things that I discussed with attendees to my presentation as soon as possible.

Overall I had a good time. The best part as always was spending time and talking with the other attendees and speakers. Me and “Andres”:http://www.taylor.se/blog/ spent a lot of time with “Haidong Ji”:http://www.haidongji.com/, Marin Mamic and “James Luetkehoelter”:http://sqlservercentral.com/cs/blogs/james_luetkehoelter/default.aspx. It was great meeting you guys. Talking with people such as Kevin Kline, Ken Henderson and Randy Dyess is always a great inspiration.
Unfortunately there are not that many people that attend PASS summits in Europe. The good thing about that is that it is easier to network with the ones that are there, but I was expecting more people to attend my session than what I normally get back home at Dotway. Andres and I are thinking of submitting an abstract for PASS in Seatlle later this year, so hopefully I will be at the bigger event as well. We discussed the reason there are so little interest for PASS Europe with Kevin. The things we specifically thought was part of the reason was that the cultural differences in Europe of course make it difficult to attract people outside the country the event is hosted in. I think many people are thinking they will not understand all of the information since the English might be bad, but I do not think that is a problem. All of the speakers I heard was great in English.
We spoke about perhaps running smaller shows, like one day maybe, in several countries would be a better idea. I think it is an interesting idea if PASS can pull it off. Like I said to Kevin, the PASS summits are still the best (and almost only) source for SQL Server-focused sessions so people should be interested in them. Another idea could be to team up with some other more developer-oriented conference, but I am not sure that would be an optimal solution. If you have any thoughts on these issues I am sure “Kevin”:http://www.sqlmag.com/Authors/AuthorID/718/718.html would be really interested in hearing them.
]]>
			http://www.hedgate.net/articles/2006/10/03/pass-europe-2006-over/feed/
		0
		
		
		
		http://www.hedgate.net/articles/2006/10/03/getting-things-done-with-tdd-and-pair-programming/
		http://www.hedgate.net/articles/2006/10/03/getting-things-done-with-tdd-and-pair-programming/#comments
		Tue, 03 Oct 2006 07:25:06 +0000
		Chris
		
		
		
			

Last week me and Andres where in Barcelona for three days. The main reason we where there was that I was presenting a session at the PASS Europe 2006 conference, and we of course wanted to see as much as possible of the other sessions at the conference as well. However, being the geeks we are, we also wanted to find some time to work on an as-of-yet unnamed project we started a couple of weeks ago. We have had trouble finding time to get anything done, especially since it does not feel good for the one of just us working singlehanded an evening.
So, now that we where not tied with client projects or had any private obligations we used every minute we could find to work on the project. A half hour after breakfast before the conference started, what was left of lunch break when we where finished eating, even timeslices as small as 5-10 minutes between sessions where used. And we managed to get quite a lot done, especially counting all the refactoring and design changes we made.
Now this is only speculation of course, but I cannot see how we would have gotten nearly as far (or probably anywhere at all) if we had not used test-driven development while doing this. We also did everything on a single computer pair-programming all the time. TDD really helped us stay focused and to get right into the action whenever we had a break. Even if we only had 10 minutes over we could simply continue right where we left off earlier. If it was not as simple as where the cursor was currently positioned it was at least never further away than running the tests and finding the red one. Pairing helped us stay disciplined enough to stick to writing good tests, small enough that we could often get them done in these 10 min coding sessions.
I am of course not saying that TDD and pairing is only useful in this kind of “extreme” situation, it is always helpful and the right way to go. But it was really interesting to see how we really got a lot done in this situation.
]]>
			http://www.hedgate.net/articles/2006/10/03/getting-things-done-with-tdd-and-pair-programming/feed/
		3
		
		
		
		http://www.hedgate.net/articles/2006/10/03/getting-feedtools-to-work-with-sql-server/
		http://www.hedgate.net/articles/2006/10/03/getting-feedtools-to-work-with-sql-server/#comments
		Tue, 03 Oct 2006 07:15:34 +0000
		Chris
		
		
		
			I have been trying for a few days (hey, I’m on vacation and have been spending time with my girlfriend, son and dog so I have not spent a lot of time with this) to get “FeedTools “:http://rubyforge.org/projects/feedtools/ to work with a Rails application I am working on. I had a couple of problems getting up and running, despite following “tutorials”:http://sporkmonger.com/articles/2005/08/11/tutorial/ that I found online and starting with a “really simple example”:http://sporkmonger.com/articles/2005/08/11/tutorial/. First I encountered some problems with example code that did not work with the current version of FeedTools, but that was easy enough to fix. However, even with that fixed I could not seem to get the database cache to function, which meant I could not use FeedTools at all (I want to cache of course).

Whatever I tried I always got stuck at FeedTools saying that the cache was not initialized properly, even though I knew it was there in my database. I was puzzled for a while until I finally took a peek in the log file. There seemed to be a SQL query failing with an error message saying @”Incorrect syntax near ’1′”@. At first I thought it was strange since I had not yet tried to retrieve a feed. But looking through the code I found the problem. When FeedTools initializes the database cache it calls @DatabaseFeedCache.table_exists?@. What this method does is try to retrieve the first row from the table where FeedTools stores the cached feeds. However, it does this by calling the execute method and sending it a specific SQL query to execute. This query uses the MySQL syntax @LIMIT 1@ to restrict the result set to one row. But I am using SQL Server 2005 as my DBMS, and the @LIMIT@ keyword is not included in T-SQL (SQL Server’s SQL dialect). So I get the incorrect syntax error.
To fix this I just needed to make a small change in the @DatabaseFeedCache.table_exists?@ method. This is what the old code was:
def DatabaseFeedCache.table_exists?
begin
  ActiveRecord::Base.connection.execute("select id, href, title, " +
    "link, feed_data, feed_data_type, http_headers, last_retrieved " +
    "from #{self.table_name()} LIMIT 1")
  rescue ActiveRecord::StatementInvalid
    return false
  rescue
    return false
  end
  return true
end

And my modified version is this:
def DatabaseFeedCache.table_exists?
begin
  ActiveRecord::Base.connection.select_one("select id, href, title, " +
    "link, feed_data, feed_data_type, http_headers, last_retrieved " +
    "from #{self.table_name()}")
  rescue ActiveRecord::StatementInvalid
    return false
  rescue
    return false
  end
  return true
end

I have created a patch and have -been trying to submit- submitted it to the FeedTools project at RubyForge , -but I keep getting timeouts-. You can get “the patch here”:http://rubyforge.org/tracker/index.php?func=detail&aid=4871&group_id=775&atid=3063 (or from my site), or simply update your DatabaseFeedCache.rb file manually with the code above.
]]>
			http://www.hedgate.net/articles/2006/10/03/getting-feedtools-to-work-with-sql-server/feed/
		1
		
		
		
		http://www.hedgate.net/articles/2006/09/08/assert-isempty-blog/
		http://www.hedgate.net/articles/2006/09/08/assert-isempty-blog/#comments
		Fri, 08 Sep 2006 04:52:02 +0000
		Chris
		
		
		
			A while ago my host had a major mishap with a server, resulting in my blog getting “lost” and moving to a new server (at the same host though). Unfortunately it also meant my content was lost, and as far as I understand there are no backups (my bad). I do have some of the older stuff stored and will try and restore the interesting pieces when I get the time for it.

]]>
			http://www.hedgate.net/articles/2006/09/08/assert-isempty-blog/feed/
		0
		
		
		
		http://www.hedgate.net/articles/2006/09/04/really-simple-faking/
		http://www.hedgate.net/articles/2006/09/04/really-simple-faking/#comments
		Mon, 04 Sep 2006 02:04:42 +0000
		Chris
		
		
		
			Interaction based testing is a technique that is often made much more difficult and/or magical than it needs to be. Any experienced TDDer will have lots of arguments for and against using a mock framework for doing interaction based testing. Personally I have been very much for and very much against (using home-made fakes instead) at different times. However, I am very much against using them at all times. Sometimes what you want to test is just really really simple. For instance, here is a simple method that I want to test:



public void SetupInput()

{

    input = inputFactory.Create();

}


The variable @inputFactory@ is a field holding a reference to a factory object passed in with the constructor, an example of dependency injection (another technique often made sound much more difficult than it really is). All I want my test to verify is that my class calls the Create method of the factory it is holding. I have other tests, probbably integration tests, that verify that it then uses this input correctly.
Here is the simplest way I can think of to test this:


private class FakeInputFactory : InputFactory

{

    public string MethodsCalled = “”;
    public Input Create()

    {

        MethodsCalled += “Create;”;
        return null;

    }

}
[Test]

public void CreatesInputUsingFactory()

{

    FakeInputFactory factory = new FakeInputFactory();

    ClassUnderTest cut = new ClassUnderTest(factory);
    cut.SetupInput();
    Assert.AreEqual(“Create;”, factory.MethodsCalled);

}


With this simple and stupid (ok, it knows how to record stuff) fake I have verified that my class under test actually calls Create in inputFactory. I think this test is as readable as any so it serves it’s purpose well. Sometimes I use a mocking framework, sometimes I do simple stuff as this. All tools in the tool box are good to have.
]]>
			http://www.hedgate.net/articles/2006/09/04/really-simple-faking/feed/
		2