Sunday, August 24, 2014

StackOverflow killed my blog

It's hard enough to have a full-time developer job and to also maintain a blog about development topics. Especially if you can't (or are not willing to) share content from your day-time job verbatim onto your blog.

But it gets even harder to maintain a decent presence on such a blog if you find yourself competing with the most fearsome competitor of all: yourself.

I've found that most of my relevant writing that is publicly accessible happens on StackOverflow. There is just something intensely satisfying about seeing a question there, figuring out what the person asking did wrong and then mentally diving into their brain and trying to understand why they did wrong what they did wrong.

Once I am able to figure out where the OP (Original Poster) went wrong, I try to write a comprehensive answer that doesn't just solve the problem of the OP, but hopefully will also help others in the future that make the same mistake. Because for every person asking a question, there will be 10 more people later with the same problem who are afraid (or unwilling) to ask the question on a public forum. And that is fine. StackOverflow will show up in their search results and developers tend to trust StackOverflow answers, especially those that have received a high number of upvotes.

I don't know if Google uses the number of votes on a Question/Answer as a quality indicator to determine the rank of a page. But if they don't, they certainly should.

Those votes also help StackOverflow users building reputation. And while the whole gamification frenzy luckily died down as rapidly as it started (remember "Office Hero"?), StackOverflow is one of those sites where it really still works.

So that is the long excuse of why I don't blog as much as I probably should. Or maybe I should say: why I don't blog here as much as I should. A technical blog is in part a medium to promote your own brand. And I think I've found a more efficient way to do that (at least as far as programming topics go) in StackOverflow.

I may start occasionally re-posting some of my answers (or questions) from StackOverflow here. Just to ensure that there is some curated list of "puf's best answers". Or to maybe expand on an answer beyond the scope that StackOverflow allows (although that seems less likely, unless I can start sharing more of my day-time job related writing here).

Friday, November 1, 2013

Compile and execute a code snippet from your C# program

The problem

Every so often I find myself creating little command line programs that:
  1. Gather a list of items from somewhere
  2. Perform some user-controllable operation on each item
My problem for today is in that user-controllable operation. Somehow I often end up designing and implementing a little mini-programming language.
    > ChangeDocuments "UserName = Frank" "Set RetentionPolicy=30y"

    > ChangeDocuments "Today > ExpirationDate" "Add State=Expired"
The first parameter to this ChangeDocuments program is a quite regular search query that I can feed into the system I am programming against. The system is well designed, so I can feed nicely complex search queries into it:
    RetentionPolicy = 30y AND (ExpirationDate = Null OR AnyOtherField = AnyValue)
When I am testing my little ChangeDocuments program I can clearly see that the query language was designed by people that know that sort-of stuff and parse search queries for a living.

Unfortunately that doesn't apply to me. Which means that the second parameter, the one that I have to implement myself, turns into a mini programming language that gets uglier with every step.

    Set RetentionPolicy=30y
    Add State=Expired
    Clear RetentionPolicy
    Set ExpirationDate=TodayPlus30Years()
Ouch? Did you see that last one? Not only is it ugly, but I'll have to find a way to parse that function call out of there and implement the function. And what if they want a different number of years. Sure, I could write a proper parser for that and implement function calls, call stacks, contexts and all that. But I also need it to be done today and to feel slightly more wieldy then the way I'll end up implementing it. Besides... aren't there enough people that implement programming languages for a living already?

So what I'd really prefer to do, is execute a snippet of C# code. So that the above examples can turn into something more regular, like:

    Set("RetentionPolicy", "30y")
    Add("State", "Expired")
    Clear("RetentionPolicy")
    Set("ExpirationDate", DateTime.Now + TimeSpan.FromDays(30 * 365))
Note that this is still not an ideal language. I'd prefer to have symbols like RetentionPolicy and State to be available like named variables. But short of implementing my own domain-specific language, this is as close as I could get with C# in a reasonable time.

Walkthrough

When I first dynamically compiled code in .NET, I was shocked at how simple this is.

Let's start with this code snippet:

    DateTime.Now + TimeSpan.FromDays(30 * 365)
For the moment, we'll put it in a variable:
     var snippet = "DateTime.Now + TimeSpan.FromDays(30 * 365)";
We'll be compiling the code using .NET's built-in C# compiler. The C# compiler can only handle full "code files" as its input, so the type of thing you'd normally find inside a .cs file.

So we'll wrap our snippet in a little template:

    using System;
    public class Snippet {
        public static void main(string[] args) {
            Console.WriteLine(CODE SNIPPET GOES HERE);
        }
    }
In code:
    var template = "using System;\npublic class Snippet {{\n\tpublic static void main(string[] args) {{\n\t\tConsole.WriteLine({0});\n\t}}\n}}";
    var code = string.Format(template, snippet);
Note that for now we simply write the result of the expression to the console. We'll see other ways to handle this later.

Next up is the bulk of our operation: compiling this code into an assembly.

    var provider = new Microsoft.CSharp.CSharpCodeProvider();

    var parameters = new System.CodeDom.Compiler.CompilerParameters{ GenerateExecutable = false, GenerateInMemory = true };

    var results = provider.CompileAssemblyFromSource(parameters, code);                                                

    if (results.Errors.Count > 0) {
        foreach (var error in results.Errors) {
            Console.Error.WriteLine("Line number {0}, Error Number: {1}, '{2};\r\n\r\n", error.Line, error.ErrorNumber, error.ErrorText);
        }
    } else {
        var type = results.CompiledAssembly.GetType("Snippet");
        var method = type.GetMethod("main" );
        method.Invoke(null, new object[] { new string[0] });
    }
That is really all there is to it.
    10/25/2043 1:21:04 PM
There are tons of additional parameters you can pass to the CSharpCodeProvider, but this minimal set tells it to:
  • generate an assembly, instead of an executable
  • keep the generated assembly in memory, instead of putting it on disk

Complete code

This is the complete code snippet that we constructed so far:
    var snippet = "DateTime.Now + TimeSpan.FromDays(30 * 365)";
    var template = "using System;\npublic class Snippet {{\n\tpublic static void main(string[] args) {{\n\t\tConsole.WriteLine({0});\n\t}}\n}}";

    var code = string.Format(template, snippet);

    var provider = new Microsoft.CSharp.CSharpCodeProvider();

    var parameters = new System.CodeDom.Compiler.CompilerParameters{ GenerateExecutable = false, GenerateInMemory = true };

    var results = provider.CompileAssemblyFromSource(parameters, code);                                                
    if (results.Errors.Count > 0) {
        foreach (System.CodeDom.Compiler.CompilerError error in results.Errors) {
            Console.Error.WriteLine("Line number {0}, Error Number: {1}, '{2};\r\n\r\n", error.Line, error.ErrorNumber, error.ErrorText);
        }
    } else {
        var type = results.CompiledAssembly.GetType("Snippet");
        var method = type.GetMethod("main" );
        method.Invoke(null, new object[] { new string[0] });
    }
I normally run this type of code snippet in LINQPad, which does something quite similar (albeit likely a lot more elaborate) internally. But if you just paste the above into the main of a command line program in your Visual Studio project it'll also work of course.

Possible changes and considerations

Use an instance method In the above code we use a static main method. If you'd instead prefer to use a regular instance method, you'll need to instantiate an object and pass it to Invoke, like this:
    var type = results.CompiledAssembly.GetType("Snippet");
    var obj = Activator.CreateInstance(type);
    var method = type.GetMethod("main" );
    method.Invoke(obj, new object[] { new string[0] });
If you do this, I recommend that you name the method something else than main, since most people will associate main with a static void method. Pass parameters to the snippet The snippet operates in complete isolation so far. To make it a bit more useful, let's pass some parameters into it:

First we'll need to modify our template to do something with the new parameter:

	var template = "using System;\npublic class Snippet {{\n\tpublic static void main(string[] args) {{\n\t\tConsole.WriteLine(args[0], {0});\n\t}}\n}}";
So we just use the first parameter as the format string for Console.WriteLineargs[0], {0}). Then we pass a value for this parameter when we invoke the method:
    method.Invoke(null, new object[] { new string[] { "Expiration date = {0}" } });
And now the snippet will print:
    Expiration date = 10/25/2043 1:21:04 PM
Make the script return a value However interesting writing to the console is, it is probably even more useful if our snippet would return its value instead.

To accomplish this, we'll change the template for the main method to this:

    public static string main(string[] args) {{\n\t\treturn string.Format(args[0], {0});\n\t}}
And the invocation now needs to handle the return value:
    var output = method.Invoke(null, new object[] { new string[] { "Expiration date = {0}" } });
    Console.WriteLine(output);
Note that the snippet itself has remained completely unchanged through all our modifications so far. This is a good design principle if you ever allow the users of your application to specify logic in this way: make sure that any changes you make to your code are backwards compatible. Whatever code the users wrote, should remain working without changes. The line numbers for errors are offset If there is an error in the snippet, the script will write the error message(s) that it gets back from the C# compiler.

So when we change the snippet to:

    var snippet = "DateTime.No + TimeSpan.FromDays(30 * 365)";
We'll get this output:
    Line number 4, Error Number: CS0117, ''System.DateTime' does not contain a definition for 'No';
The error message itself is correct of course, but the snippet we provided is one line, to the line number is clearly wrong. The reason for that is that our snippet is merged into the template and becomes:
    using System;
    public class Snippet {
        public static string main(string[] args) {
            return string.Format(args[0], DateTime.No + TimeSpan.FromDays(30 * 365));
        }
    }
And indeed, this C# contains the problem on line 4.

The solution for this line number offset is to either subtract the offset from the line number in the error message or simply not print the error message. In a simple case such as this the latter option is not as bad as it may sound: we only support short snippets of code, so the line numbers should be of limited value. But then again: never underestimate the ability of your users to do more with a feature than you ever thought possible. Make the wrapper class more complete Probably the most powerful way you can extend the abilities of your snippet-writing users is by providing them more "built-in primitives".

  • Any method you add to the Snippet class, becomes like a built-in, global function to the snippet author. So the Set, Add and Clear methods of my original snippets could be implemented like that.
  • You can also make the Snippet class inherit from your own base class, where you implement these helper functions.
  • Any variables that you define inside the main method before you include the user's snippet, will become like built-in, global variables to your snippet authors.
  • I've had great success in the past with making utilities such as a log variable available like this.
Allow importing more namespaces and referencing more assemblies The template above imports just one namespace and only binds to the default system assemblies of .NET. To allow your snippet authors to use more functionality easily, you can either expand the number of using statements in the template and add additional references to the ReferencedAssemblies of the CompilerOptions.

Alternatively you can give the users a syntax that allows them to specify their own namespaces to import and even assemblies to reference. In the past I got some pretty decent results with this syntax:

   <%@ Import Namespace="Path.Of.Namespace.To.Import" %>
Use VB instead of C# There is also a compiler for Visual Basic code. If you'd prefer to use that, you can find it here:
    var provider = new Microsoft.VisualBasic.VBCodeProvider();

Saturday, April 6, 2013

Gaining knowledge is not the same as asking questions

"Does anyone know how xyz works?"

-- silence --

"Guys, I really need to know how xyz works."

-- silence --

Does this sound familiar? It's rude that nobody answers? Right? After all, somebody should know the answer. It's not like your question is difficult. Right? You are asking something relatively straightforward that certainly somebody must know. If they won't tell you, how do they expect knowledge to spread? How can you ever become knowledgeable on these subjects if others outright refuse to answer your questions? Right?

WRONG!

Knowledge is not created by people asking questions and waiting for others to provide answers. Knowledge is gained by people who do things. Instead of asking somebody else to provide the answer for you, think what you can do to find the answer yourself. In fact, first spend a moment to come up with the most likely answer. And then validate that answer, proving yourself right or wrong. Try it, you'll be surprised how quickly you can try certain things. Heck... it may well be faster to try it then to ask again and again. And even if it's not faster, you will almost certainly gain a better understanding of the thing you are working with. In addition to getting an answer to your question, you'll also have a better understanding of the why around that answer. You'll have gained knowledge and understanding.

Yet many people seem to prefer asking a question over trying to find the answer themselves. Instead of building knowledge they are trying to get other people to give them the knowledge. And while I don't mind showing off my knowledge about a topic, mine is often built from doing things - not from asking others. So ask yourself: do you want to be a knowledge sink? Or do you want to be a knowledge source?

This situation is so common that an entire subculture has arissen. When somebody asks a very open question on Stack Overflow, someone almost always comments with: "what have you tried?". Matt Gemmell even put his original blog post to that effect on a separate domain: whathaveyoutried.com. Have a look around Stack Overflow and see what type of questions solicit the "what have you tried?" response. The phenomenon has spread quite far. Often I feel bad for the person asking the question, because they clearly have no clue what they've done wrong.

Sunday, January 20, 2013

Handling asynchronicity in an API

Designing a good API is one of the more difficult tasks when it comes to software development. Unfortunately it is also one of the important tasks, since it is really hard to change an API after it's been made public. Well OK, maybe it is not hard for you to change the API, but it is hard on the users of your API: they have to update all their client programs if you decide to make changes.

Nowadays many APIs deal with asynchronous operations, especially when an API bridges the gap between a client-side web application and a server-side back-end. Whenever a web application needs some additional data from the server, it needs to initiate a (XMLHttpRequest) call to the server. And since such a call can take a significant amount of time it should (in almost all cases) be handled asynchronously.

Checking if the title is loaded

Here is how I recently saw this done in a JavaScript API:

    function displayTitle(object) {
      if (object.isLoaded()) {
        document.getElementById('title').innerText = object.getTitle();
      } else {
        function onLoaded(object) {
          object.removeEventHandler('load', onLoaded);
          document.getElementById('title').innerText = object.getTitle();
        }
        object.addEventHandler('load', onLoaded);
        object.load();
      }
    }

To display the title of the object, we first have to check if the data for the object has been loaded from the server. If so, we display the title straight away. If not, we load it and then display the title.

That is quite a lot of code, for what is a quite common operation. No wonder so many people dislike asynchronous operations!

Use a callback for the asynchronous operation

Let's see if we can simplify the code a bit.

For example, the event handler is only used once here. And although registered event handlers can be useful for things that happen all the time, clearly in many cases people will want to check if the object is loaded in a regular sequence of code - not respond to whenever the object is (re)loaded.

If we allow the onLoaded function to be passed into the load() call, things clean up substantially:

    function displayTitle(object) {
      if (object.isLoaded()) {
        document.getElementById('title').innerText = object.getTitle();
      } else {
        object.load(function onLoaded(object) {
          document.getElementById('title').innerText = object.getTitle();
        });
      }
    }

The nice thing about this change it that you can add it to the existing API after releasing it:

    MyObject.prototype.loadAndThen = function(callback) {
      function onLoaded(object) {
        object.removeEventHandler('load', onLoaded);
        callback(object);
      }
      this.addEventHandler('load', onLoaded);
      this.load();      
    };

This is mostly a copy of the code we removed between the first and second fragments above. But now instead of everyone having to write/copy this plumbing, you just have to write it once: in the prototype used for the object in question.

Note that I named the function loadAndThen, to avoid conflicting with the existing load function.

Assume asynchronicity

But when I started using the Firebase API a while ago, I noticed how natural their way of handling asynchronous operations feels. If we'd apply their API style to the above example, the displayTitle function would become:

    function displayTitle(object) {
      object.getTitle(function (title) {
        document.getElementById('title').innerText = title;
      });
    }

Since the title might have to be loaded from the server, they require you to always pass in a callback function. And they will simply call that function once the title is loaded.

Now I can see you thinking: "but what happens if the title is already loaded?" That is the beauty of it: if the title is already loaded, they simply invoke the callback straight away.

If we'd like to implement such an API on top of our example, we could implement getTitle like this:

    MyObject.prototype.getTitleAndThen = function(callback) {
      if (this.isLoaded()) {
        callback(this.getTitle());
      } else {
        function onLoaded(object) {
          object.removeEventHandler('load', onLoaded);
          callback(object.getTitle());
        }
        this.addEventHandler('load', onLoaded);
        this.load();      
    };

Like before I gave the function a suffixed name to prevent clashing with the existing getTitle function. But of course if you end up implementing this in your own API, you can just stuff such code in the regular getTitle function (which probably reads the title from a member field of this).

If you think this is a lot of code to add to your framework, look back at our first example. If you don't add the code to your framework, every user will end up adding something similar to their application.

Conclusion

By assuming that certain operations are (or at least can be) asynchronous, you can reduce this code:

    function displayTitle(object) {
      if (object.isLoaded()) {
        document.getElementById('title').innerText = object.getTitle();
      } else {
        function onLoaded(object) {
          object.removeEventHandler('load', onLoaded);
          document.getElementById('title').innerText = object.getTitle();
        }
        object.addEventHandler('load', onLoaded);
        object.load();
      }
    }

To this:

    function displayTitle(object) {
      object.getTitle(function (title) {
        document.getElementById('title').innerText = title;
      });
    }

The biggest disadvantage I see in the second example is that users of your API are more directly confronted with closures. Although I hang around on StackOverflow enough to realize that closures are a real problem for those new to JavaScript, I'm afraid it is for now a bridge that everyone will have to cross at their own pace.

Sunday, April 3, 2011

What I use my iPad for - one year later

Last year on April 3rd Apple released the iPad. I stood in line to get the new device day one and one week later I wrote a post here about what I was using the iPad for. Today marks the iPad's one year anniversary. So it's time to see if my usage has changed over the past year and if my usage patterns hold up for others.

Games


When I pick up my iPad it is still very often to play a quick game on it. It really is the perfect device for playing games: the screen is large enough to show a decent play field and touch controls are natural for many of the casual games that I've grown to like over the years.

The number one game for me of the iPad's first year has been Plants vs. Zombies. You can play the Flash/PC version of this tower defender game for free on the vendor's web site, but I only every played the $9.99 iPad rendition. It has quick play, mini games and a fun campaign mode that I must've played through half a dozen times by now.



Although Plants vs. Zombies by far ate the most of my time in the past year, there are many other games that I play or played regularly. There's the inevitable Angry Birds, which is nice but gets boring and frustrating for me after a while. It shares that problem with the beautifully made indy game Steam Birds.


Angry Birds


Steam Birds

You'd almost think I don't like games that are difficult, but I regularly play both Rush Hour and Sherlock as proof that that's not true. Sherlock is a classic puzzle game that my wife and I have been playing since the good old DOS (EGA graphics) days. Seeing it revived on iOS is wonderful and I gladly paid the $2.99 admission fee.


Rush Hour


Sherlock

More recently I've been wasting too much time with My Kingdom for the Princess, which is a time/resource management game with a very cute look. Click the link to play it for free on your PC. And Trade Nations has also been keeping my attention. I'm not sure what it is with these building games, but keep playing them - even when I've clearly mastered their mechanics.


My Kingdom for the Princess


Trade Nations

The last game that deserves a mention is Tiny Wings, which has firmly confirmed my suspicion that iPad games must include birds and physics to be successful.

Tiny Wings

Reading



After playing games I probably spend most time on my iPad reading. Instapaper is still a favorite, as ability to transfer web pages to my iPad with one-click (while improving their readability at the same time) makes it a killer app for the iPad in my book. If only I would spend less time on games, so that my reading stack would get somewhat smaller.



While Instapaper is great for reading articles, I still don't like the iPad as an e-reader for books. In the past year I read three books in the sames series: two on my Sony Reader and one on my iPad. The reading experience on the iPad is nice, with cool animations at times. But I stick to my opinion that lengthy reading sessions are simply less strainfull on an e-ink screen than they are on the iPad's LCD screen.

That said, the iPad has grown into my favorite reader for all shorter length reading. In addition to Instapaper I now also regularly read my RSS and twitter feeds on the iPad. While many people like Flipboard, I couldn't really get used to it and (for the moment) stuck with two specialized clients: Reeder for RSS and TweetDeck for Twitter.


Flipboard


Reeder


TweetDeck

Video


I wasn't too much into watching video on my iPad at first, but that has changed over the year. The iPad is of course great for watching video while on the plane, as long as you remember to buy and download the videos before boarding. But I also now use my iPad for watching video while exercising on my indoor rowing machine. Before getting an iPad I used to listen to audio books, but the iPad has solidly taken the Shuffle's place here.

Video from iTunes of course work great, but comes at a price. For the past few months I've actually been watching content from iTunes/U, which has lots of great material for free. For the techies amongst you: download CS193P and learn iOS programming while you exercise. This does by the way require the use of wireless (bluetooth) headphones.

Aside form iTunes, I also subscribe to Netflix and Hulu+. Although both have great content, I've been having some problems keeping the wifi connection stable while exercising. I have no idea what could be causing this as the iPad is literally less than 15 feet from the wireless access point. But I also haven't bothered too much figuring it out: iTunes/U for the moment has enough content to keep me "entertained".

Creativity


An unexpected category of apps doing well on the iPad are the creative creation apps. While the iPad has proven more a consumer than a producer device, this seems untrue of creative applications. Think of music creation apps (my favorite subcategory), image editing apps and video editing apps. The large multi-touch screen of the iPad has proven a great "build your own instrument/control" option for some of the more creative uses.

Although I don't spend nearly as much time in these apps than I should, I have a few favorites that I regularly return to. Everyday Looper is one of those. It is extremely simple in concept and user interface: you record multiple audio-loops in rapid succession. Doing this allows you to build a song in relatively little time. While I wish the app came with a few more features (such as repeating a "background" loop or creating patterns of the loops you've recorded) it is powerful already enough to keep me coming back every once in a while.

Everyday Looper

I really wish I could add GarageBand to this category. But unfortunately I haven't yet been able to test it on my iPad. The download from the appstore keeps failing. Maybe this will solve itself when I finally take the time to update my iPad to iOS4.

If you're more visually oriented there are multitudes of drawing and photo editing tools on the iPad. Given the gorgeous multi-touch screen, that was bound to happen. The image creation app I am most happy to see on the iPad is ArtRage. For a while I used this program extensively on my laptop, using a Wacom trackpad for drawing. Even though I've never painted in the real-world, the controls were very intuitive and precise. That this is in a large part to thank to the Wacom trackpad and its stylus becomes very obvious when you start using the iPad version or ArtRage. Although the interface is very similar, some of the more precise control is definitely lost. That said, it is still very much fun to use a photo from your albums as a background and start painting on top of it using water paint, oil paint of even chalk. The auto-color picker makes it incredibly easy to produce reasonable pieces of "art". Fun!


ArtRage

Work


The last category of apps I use regularly is sort of a mish/mash, but I think they all have to do with using my iPad for work. Only in the past few months have I started noticing that I tend to open my laptop less often in the morning. I like reading most RSS feeds, tweets and emails before I head out to the office. I used to do this on my laptop, but since early this year notice that I do this more and more on my iPad. The iPad is the ultimate media consumption device in this sense, which fits great with my morning pattern: I read/scan a lot, but respond fairly little - leaving longer responses until I get to the office.

Of course being a software developer means that I also use my iPad for development. Not for writing code (although I would love that), but to test if our software works sufficiently on mobile safari. Somehow my searches for "software to program for the iPad from the iPad" haven't resulted in anything too useful yet.

But since I bought a Bluetooth keyboard an iTeleport Connect, I can access the MacMini at home while I'm at the office. Using the keyboard for text input and the touch screen as a (not too accurate) mouse. While the experience isn't perfect, it does allow you to get some things done without having access to the physical machine. I can't wait to see what will happen when VMware launches their iPad viewer app. The iPad is completely silent, using very little power - it may well be the ultimate thin client.




Two more work-related uses, those are the last... I promise.

At one point I was about to board for a transatlantic flight when I got an email with the ever-interesting combination of question marks and exclamation marks: "why isn't this done yet ?!?!?" I had completely forgotten about a report I promised to write days earlier. The long flight and the iPad proved to be job-savers here: the flight was long enough to get a decent version of the report drafted before touch down and the iPad is small enough to fit in front of me on the table in coach.

Lastly I sometimes use my iPad for presenting. Our company is a Windows shop, so everything get prepared in Powerpoint. But once the PPTX is done, I drag it into dropbox, open it on my iPad and use keypad to present it. Now if only the projectors we use were as silent as an iPad...


Summary


So in summary I don't think my iPad usage has changed too much over the year. It's still the "computer" that is closest by when I want to do something for a few moments: whether it's a quick game, looking up a video that we're talking about with friends or doing some catching up on articles and blogs on the couch. It's taken over quite a few tasks that I previously used laptops for and has come up with new tasks that I previously simply wouldn't do.

Friday, September 17, 2010

Color-coding your scrum board

At my company we've been using Scrum for a few years now. And even though I'm quite sure we're not living up to Schwaber's and Sutherland's standards, we seem to have found a way to make the process work for us across many projects.

Like many companies we started out with a simple physical scrum wall:



Later we started putting the burndowns on our intranet, so that everyone could see them. And we started using colored post-its for indicating different types of work.

In our case we use yellow for development tasks, pink for non-development tasks (i.e. testing and documentation) and orange for defects. There's no specific reason for using these colors. They just happened to be the post-it colors we had available when we started using colors. Since then my mind got used to them and I haven't yet heard a reason to switch. Although some of our tech writers are frowning at being "the guys who do the pink work".



As we've been growing our use of Scrum, we've also been using more and more tools. First was the online burndown charts. And then we started using a virtual scrum wall, so that we could share the same wall between distributed teams. It was a great boost for our distributed development, although most team members still sometimes long back for the days when they had a physical wall. Nothing beats the satisfaction you get from moving a physical post-it across 5 inches of whiteboard space.

We've been using Scrum for Team System for a while now to keep track of our stories and tasks. And I thought we were quite happy with it. Sure, we lost the ability to color code our task types. But the task board we used has nice colors too, although it uses them to code the columns. So "done" is green, etc.

But recently I noticed that it was difficult to quickly understand the status of a sprint from simply looking at their board:



So is the status of this project? It's hard to say without looking at the details of each task. It could be that everything is going fine, it could be that things are horribly wrong. There is no way to tell which one it is, unless you get closer to the board and read.

So over the weekend I re-encoded one of our boards with the colors we used back in our "physical days". Now look at the same board where we've used colored post-its:


Yellow = development tasks, pink = non-development tasks, orange = bugs

When we applied this color coding to our existing scrum board, I was shocked at the amount of insight it could add.

So I wrote a quick tool to generate these color-coded task boards for us. The process is purely automatic: read the data from team system, apply a few simple rules (e.g. anything with the word "bug", "defect" or "issue" in it, must be a defect) and output a HTML version of the data. But even with such a simple system we've been able to more easily get a feeling of where all projects stand by simply glancing at the board.

So what is your experience with scrum walls? Do you have any tricks you use to help visualize the data?

Sunday, June 13, 2010

Block font

Many people seem to doodle while they're in meetings. Doodling is a nice way to distract yourself with something, while ensuring that you can still follow what is being presented. I guess that's why those meeting centers hand out those incredibly thin notebooks.

My doodles typically consist of writing down words that have to do with what is being presented. Now before you say "that is called: taking notes" - I take my notes in elaborate fonts.

One of the fonts I came up with this time is a 'block font'. And since the meeting was rather long, I decided to create all letters.



I should apologize to the speakers, because I wasn't paying too much attention near the end of their presentation. Coming up with all letters in a single style is hard work.

I'm quite happy with most of the letters, but there's some that I really can't get to look decent. The I and the J are especially painful. Is there somebody with real designer skills that can show me how to do those character properly in this style?