Clear Lines Blog

Dysfunctional team

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Tue, 14 Jul 2009 06:58:09 -1300

While shopping at PetCo the other day, I saw this scene, and couldn’t get enough of it. It’s a great illustration of what happens when teamwork goes wrong. If I saw this in real life, I would feel sorry for the team, but the mice don’t seem to be suffering (besides some confusion), so sit back and enjoy the show, guilt-free.

Regularity, cohesion, balance

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Tue, 07 Jul 2009 11:25:17 -1300

I was going through my digital camera today when I came across this:

I took this picture in the Seattle public library elevator. It’s a great building, with lots of unusual features.

Why did I take it? Because I thought the design was interesting. The typical elevator button panels has a series of buttons, each of them the same size, ordered with the corresponding floor elevation. This panel has buttons of various sizes, and given what I saw in the building, I guess the size corresponds to the frequentation of each floor, or, if you prefer, the relative likelihood that you want to go to each floor.

In my opinion, there are some flaws in the design (for instance, the buttons are very far from the labels saying what is on the floor, which slows down figuring out which button you really want to push), but I thought the idea of various button sizes was smart, and bizarrely under-utilized in computer user interfaces. If you are going to expose different functionalities to your user, chances are, some will be used more often than others, and giving them a larger button should make the user’s navigation easier.

I found an example of this on Netflix’s website, for instance:

Note how the 2 right-most elements of the tab are smaller than the rest?

So why is this design style rare? I guess it has to do with the fact that regularity looks good, without much effort. Give your buttons the same size and font, and everything looks organized, and easy on the eye. Once you start playing with elements of various sizes, it is much harder to achieve balance and cohesion. Usability might be improved, but chances are, you will need someone with a sense of visual design to help you make it look good – whereas even the most lacking in aesthetic sense can align buttons.

Illustrative Programming

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Tue, 30 Jun 2009 15:39:27 -1300

Very interesting piece by Martin Fowler; he discusses spreadsheets as a programming language, and coins the term “Illustrative Programming” to describe the corresponding development style. I quote liberally here:

One property of spreadsheets, that I think is important, is its ability to fuse the execution of the program together with its definition. When you look at a spreadsheet, the formulae of the spreadsheet are not immediately apparent, instead what you see is the calculated numbers - an illustration of what the program does.

Using examples as a first class element of a programming environment crops up in other places - UI designers also have this. Providing a concrete illustration of the program output helps people understand what the program definition does, so they can more easily reason about behavior.

I don't think that illustrative programming is all goodness. One problem I've seen with spreadsheets and with GUI designers is that they do a good job of revealing what a program does, but de-emphasizes program structure. As a result complicated spreadsheets and UI panels are often difficult to understand and modify. They are often riven with uncontrolled copy-and-paste programming.

This strikes me as a consequence of the fact that the program is de-emphasized in favor of the illustrations. As a result the programmers don't think to take care of it. We suffer enough from a lack of care of programs even in regular programming, so it's hardly shocking that this occurs with illustrative programs written by lay programmers. But this problem leads us to create programs that quickly become unmaintainable as they grow.

This piece is worth reading, if only to see such a highly respected developer as Fowler defend Excel as a programming language. Given how Excel is usually dissed by “serious programmers”, it’s refreshing.

His analysis rings true, too – spreadsheets and UI tools are very similar in their benefits (immediate focus on the end result desired by the user) and drawbacks (possible lack of structure, lack of testability…). I am not sure how to describe the “other” style, maybe “Axiomatic Programming” - first establish the principles, then useful consequences can be derived? In a way, the term “Illustrative Programming” marks one extreme on the scale of development styles: don’t program if you can’t see it – whereas the other extreme would be developing a framework– creating programs which can’t be seen until someone decides to illustrate its use.

Another way to view the trade-off is to see Illustrative Programming as focused on a specific instance, whereas Axiomatic Programming emphasized the Class. An Excel speadsheet, or a User Interface, is typically one isolated instance, focused on one unique particular illustration of a problem, and as a result, doesn’t promote thinking about generalization and abstraction, whereas the risk in framework design is to embrace generality to the point where abstractions lose connection to specific usage…

The Drunkard’s Walk

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Sun, 28 Jun 2009 12:41:42 -1300

I finished “The Drunkard’s Walk – how randomness rules our lives”, by Leonard Mlodinow, a few days after Sway; I have postponed writing about it, because a minor storm of work has hit my parts – but I really loved this book, and thought I should say a few words about it.

The book’s point is that humans are very bad at drawing conclusions from observations of random phenomena. They routinely make gross mistakes when dealing with conditional probability (92% of Americans, some of them with pretty solid mathematical credentials, get the Monty Hall problem wrong), and fall prey to the Law of Small Numbers, seeing patterns where there is none, and refusing to admit the importance of randomness in shaping our fates. In the end, the message is pretty upbeat – I loved this quote from Thomas Watson:

If you want to succeed, double your failure rate.

I really enjoyed how the book builds up following the history of probability and statistics; some of the individuals who contributed to its development are truly remarkable (just lookup Cardano for instance), and the book contains a fair share of anecdotes about them. If anything, it gave me my first introduction to Benford’s law, which I am still digesting – and which has been weirdly prominent in the news, via the Iran election issue.

In short, I strongly recommend this book if you are interested in either history of sciences, probability, or decision making.

San Francisco .NET user group

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Wed, 24 Jun 2009 12:43:19 -1300

Since the longest time, I have been a member of Bay.Net, the San Francisco Bay Area .NET user group. It’s one of the largest user groups in the country (north of 4,000 members), very active, with four chapters in the Bay – and first and foremost, it’s a fantastic way to keep up with what is going on in the ever-changing .NET world, and meet fellow developers and fun people.

I initially came to attend the meetings, started to get more involved and volunteering in organizing events (if you are interested in volunteering, drop me a line!) – and I was very honored to be offered to co-chair the San Francisco chapter. The current chair, Kim Greenlee, has been doing an amazing job at lining up great speaker after another, and making the meetings fun to attend, but she wants to dedicate her energy to another Bay.Net related project, and can’t be full-time chair anymore, so… the pressure is on – I’ll do my best to keep it up!

It takes one to know one

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Thu, 18 Jun 2009 06:40:14 -1300

Mark Twain famously said “There are three kinds of lies: lies, damned lies and statistics”; in that light, I found the following anecdote – from “The Drunkard’s Walk”, a thoroughly enjoyable book so far - pretty funny.

Like most of his compatriots, Jules Henri Poincaré, the legendary French mathematician, took his bread seriously, and purchased a fresh loaf daily. Suspecting his baker was a cheat, he weights his loaves every day, and finds out the average weight is 950g instead of the 1000g advertised. He complains to the authorities – and his daily baguette suddenly becomes larger.

But now, instead of enjoying his good life, Poincaré still suspects his baker is a cheat, and keeps on measuring his bread for an entire year, and finds out that he now got mostly larger than 1000g loaves, and too few light ones. For him it’s great; but from a statistics standpoint, this doesn’t sound right: he should have roughly as many small and large loaves. Poincaré concludes that the baker is still cheating, but gives him the biggest loaf of his inventory every day to pacify him. He calls the authorities in again, who confirm he is right, and slam the baker.

The moral of the story: don’t lie to statisticians!

Sway

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Sun, 14 Jun 2009 16:44:44 -1300

While travelling to Seattle, I went shopping to the bookstore and purchased “Sway – the irresistible pull of irrational behavior”, by Ori and Rom Brafman. Each of the book’s chapter illustrates a specific bias which leads individuals to make poor decisions, through multiple experiments or real-life stories.

If you are familiar with decision theory, and specifically with decision biases – the way our brain plays tricks with us and processes information poorly, misleading our judgment – you will probably not learn much from the book. Even then, it’s a pretty entertaining read; the style is light, and the anecdotes and cases funny and very clearly explained. If you are not familiar with the topic, I recommend the book: it is a good primer to recognize traps and make better decisions!

The part which was new to me was the chapter “Compensation and Cocaine”. It seems that monetary decisions and altruism are processed in completely different parts of the brain (no surprise so far), but also that when one is active, it shuts down the other. Furthermore, the monetary decision brain is processed in the same place as the center of pleasure derived from sex, drugs or gambling (not sure what this says about the financial sector…), which has very practical implication in designing incentives. From what I gather, altruism provides a stronger motivation than money – but surprisingly, mixing both doesn’t add up: the pleasure center will completely override altruistic motivation, which is then ignored – and reduces overall motivation.

Overall, fun read – recommended!

Dude, where is my log?

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Mon, 08 Jun 2009 08:53:44 -1300

No matter how much you think you have your bases covered, users will do unexpected things with your application. Writing good unit tests: priceless. For everything else, there is logging. So I decided to add exception logging to Akin, and opted for NLog.

NLog rocks. It is very easy to configure: basically, add the NLog dll to your project, a configuration file defining what you want to log, and where it should go, and you are set. My configuration file looks something like that:

<?xml version="1.0" ?>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <targets>
    <target name="file" xsi:type="File"
        layout="${longdate} ${stacktrace} ${message} ${exception:format=message,type,method,stacktrace}"
        fileName="${basedir}/logs/${shortdate}.log"
        concurrentWrites="true" />
  </targets>
  <rules>
    <logger name="*" minlevel="Trace" writeTo="file" />
  </rules>
</nlog>

Which I use then to log exceptions this way:

try
{
    // try to open a file
}
catch(Exception e)
{
    logger.TraceException(string.Format("Failed to open {0}.", path), e);
}

The exception gets appended to a file like 2009-06-08.log, in the logs folder located in the application folder, in that case, C:\Program Files\Akin; if the file or folder do not exist, it gets automatically created. This worked like a charm, once I realized I also needed to add the config file to the installer.

And then I deployed on a Vista machine. Everything looked fine (I checked that logging to a message box worked), except that… there was no log file to be found. Damn.

After much anxiety and help of StackOverflow, I found my logs. Turns out, there was a log file, but not where I expected it to be. Vista uses File System Virtualization, and writes the log to another location – in my case,

C:/Users/JohnDoe/AppData/Local/VirtualStore/Program Files (x86)/Akin/Logs/

So if you can’t find your log files, no worries. It’s just Vista playing hide-and-seek with you…

Ars Mathematica

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Mon, 01 Jun 2009 07:23:30 -1300

Via Aleks Jakulin, amazingly beautiful surfaces generated by Paul Nylander using Mathematica:

#warning: the power of in-your-face

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Wed, 27 May 2009 13:36:05 -1300

The iterative nature of writing code inevitably involves adding code which is good enough for now, but should be refactored later. The problem is that unless you have some system in place, later, you will just forget about it. Personally, I have been trying 3 approaches to address this: bug-tracking systems, the good old-fashion text to-do list, and its variant, the task list built in Visual Studio, and finally, comments embedded in the code.

Each have their pros and cons. Bug tracking systems are great for systematically managing work items in a team (prioritization, assignment to various members...), but work best for items at the level of a feature: in my experience, smaller code changes don't fit well. I am a big fan of the bare-bones text file to-do list; I tried, but never took to the Visual Studio to-do list (no clear reason there). I hardly embed comments in code anymore (like 'To-do: change this later'): on the plus side, the comment is literally tacked to the code that needs changing, but the comments cannot be displayed all as one list, which makes them too easy to forget.

Today I found a cool alternative via Donn Felker’s blog: #warning. You use it essentially like a comment, but preface it with #warning, like this:

#warning The tag name should not be hardcoded
XmlNodeList atBatNodes = document.GetElementsByTagName("atbat");

Now, when you build, you will see something like this in Visual Studio:

It has all the benefits of the embedded comment – it’s close to the code that needs to be changed - but will also show up as a list which will be in-your-face every time you build. I’ll try that out, and see how that goes, and what stays in the todo.txt!

Data driven tests with NUnit 2.5

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Sun, 17 May 2009 02:25:46 -1300

Another nice improvement coming with NUnit 2.5 is the mechanism for data-driven tests. NUnit 2.4.7 included an extension by andreas schlapsi which permitted to write row tests, using the [TestRow] attribute.

NUnit 2.5 eases the process with the [TestCase] attribute. Unlike [TestRow], the [TestCase] attribute is available within the NUnit.Framework namespace, and doesn’t require including additional references.

Why do Data-driven tests matter? They are not technically necessary: you can write the same tests as easily using the standard [Test] attribute. However, it comes handy when you are testing a feature where you want to verify the behavior for multiple combinations of input values. Using “classic” unit tests, you will end up duplicating test code, and you will have to find different name for tests method which are in essence the same test.

Using [TestCase] instead, here is how it looks. Suppose your class MyClass has a method “Divide” like this one:

public class MyClass
{
    public double Divide(double numerator, double denominator)
    {
        if (denominator == 0)
        {
            throw new DivideByZeroException("Cannot divide by zero."); 
        }
        return numerator / denominator;
    }
}

One way to test that feature would be with a test like that one:

[TestCase(2.5d, 2d, Result=1.25d)]
[TestCase(-2.5d, 1d, Result = -2.5d)]
public double ValidateDivision(double numerator, double denominator)
{
    var myClass = new MyClass();
    return myClass.Divide(numerator,denominator);
}

Each TestCase will match the arguments of the test method with the arguments provided in parenthesis (e.g. the first test will pass a numerator of 2.5 and a denominator of 2.0) and verify that the return value matches the value provided as “Result”.

One feature I really like in the new implementation is that it also supports exceptions testing. If a certain combination of input values is expected to throw an exception, it can also be expressed as a test case, without writing a dedicated test method:

[TestCase(2.5d, 2d, Result = 1.25d)]
[TestCase(-2.5d, 1d, Result = -2.5d)]
[TestCase(1d, 0d, ExpectedException = typeof(DivideByZeroException))]
public double ValidateDivision(double numerator, double denominator)
{
    var myClass = new MyClass();
    return myClass.Divide(numerator,denominator);
}

When you run this in the NUnit GUI, you will see something like this, displaying the “mother” test, and the result of each data set:

As an aside, this post made me realize that dividing a double by zero was not throwing a “DivideByZeroException”, as I naively thought it would, but returns a double.PositiveInfinity (or NegativeInfinity, depending on the numerator). Goes to show that nothing beats writing unit tests when trying to understand a feature of a language!

Live Messenger Hackathon

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Thu, 14 May 2009 01:10:58 -1300

Update: here is the event page.

Microsoft is hosting a Windows Live Messenger Hackathon on the 27th May 2009 at Microsoft's offices on 835 Market St in San Francisco. The event starts at 5:30, there will be a discussion on social media, how to use the Windows Live API in your website, a coding contest, prizes, free beer and pizza… Sounds like fun!

Testing for exceptions with NUnit 2.5

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Sun, 10 May 2009 23:24:44 -1300

Compared to the recent releases, NUnit 2.5 contains quite a few significant changes. One notable change is in the area of exception testing – and it is for the better.

Until NUnit 2.4.8, testing for exceptions was done by decorating tests with the [ExpectedException] attribute. NUnit 2.5 introduces a new assertion instead, Assert.Throws.

Why is this better?

I see at least 2 reasons: it makes it much easier to catch the exception precisely where it is expected to happen, and working with the exception itself is now a breeze.

While the ExpectedException attribute is typically sufficient, it is a bit of a blunt tool. What it does verify is that the code under test throws the expected type of exception; what it doesn’t tell you is where. The tests are not fully explicit, and sometimes, they can result in unexpected “false positives”.

Consider the following situation: a class MyClass exposes a method that takes a positive int as argument, and throws an ArgumentException if a negative is passed. A test for this behavior would look something like this:

[Test]
[ExpectedException(typeof(ArgumentException))]
public void FalsePositive()
{
    MyClass myClass = new MyClass();
    // This call is test setup, but will
    // throw an unwanted ArgumentException.
    myClass.SomeMethodThatThrows();
    // We want to check that this call throws.
    myClass.SomeMethodThatRequiresAPositiveArgument(-5);
}

Unfortunately, our setup contains a call to another method, which due to an error in our code, will throw an ArgumentException, too. The right type of exception is thrown, but absolutely not where we intend it – and the test will pass. Not good.

Granted, the example is pretty contrived, but situations like these do happen. To avoid this, you need to catch the exception “red handed”, exactly where it is supposed to take place – which requires cumbersome code code like this:

[Test]
[ExpectedException(typeof(ArgumentException))]
public void PainfulCorrectTest()
{
    MyClass myClass = new MyClass();
    try
    {
        // if the setup throws the test fails.
        myClass.SomeMethodThatThrows();
    }
    catch
    {
        Assert.Fail();
    }
    // We expect an exception in that portion of the code.
    myClass.SomeMethodThatRequiresAPositiveArgument(-5);
}

By wrapping the setup in a try/catch block, you can ensure that any exception that happens there will result in a failure of the test; the only “tolerated” exception has to occur after that block.

With NUnit 2.5, this problem disappears. The [ExpectedException] attribute is gone, and replaced by an assertion that verifies if a specific method call throws an exception:

[Test]
public void DelegateBasedTest()
{
    MyClass myClass = new MyClass();
    // We don't need to do anything about the setup.
    myClass.SomeMethodThatThrows();
    // The exception is expected here.
    Assert.Throws<ArgumentException>(
        delegate { myClass.SomeMethodThatRequiresAPositiveArgument(-5); });
}

This is really nice: the test pinpoints what exception is expected, AND exactly where it is supposed to happen. And with the “special” [ExpectedException] attribute gone, the syntax is more consistent.

The cherry on the cake is that Assert.Throws returns the actual exception that is thrown; it is totally straightforward to validate the state of the exception itself:

[Test]
public void RetrieveException()
{
    MyClass myClass = new MyClass();
    ArgumentException exception = Assert.Throws<ArgumentException>(delegate { myClass.SomeMethodThatRequiresAPositiveArgument(-5); });
    Assert.AreEqual("The Message.", exception.Message);
}

I really like this change in NUnit 2.5. The syntax does look a bit more intimidating, but the tests gain in clarity – which is crucial in a test suite. Tests are your best specification, and anything which reduces ambiguity there is a good thing!

Website spring clean-up

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Thu, 30 Apr 2009 17:35:14 -1300

After much postponing, I finally cleaned up the layout of Clear Lines. I had cobbled together the previous design over a few days when I started, and, because it's not a crucial aspect of my activities, I left it at that until now. I like my new design better (I hope you do, too!), it feels much cleaner than the previous one. The main motivation was not the looks, though, but rather flexibility. I will add a few pages soon, and need to easily integrate them into the site navigation, so I finally replaced my hard-coded links by an ASP.NET menu. And while I was at it, I got inspired by Peter Kellner's beautiful menu for the Silicon Valley Code Camp site, and started looking into Css Friendly Control Adapters.

I like the fact that the whole menu layout is pure css, instead of tables, but I struggled quite a bit with getting css to play nice. Not the adapter's fault, rather my own limitations with css... In the end, I managed to get roughly the look I was after. That being said, if you open the page in IE7, it will render differently than in any other browser I tried: for some reason, I couldn't get IE to change the background color of the menu links on hover, or to render properly a border-bottom. If anyone has an idea what's wrong with my css, I would love to hear it!

Next step: upgrade the blog to BlogEngine 1.5, and probably add a sub-menu to the pages, similar to the Code Camp site.

Times a-changin'

mathias.brandewinder.nospam@nospam.clear-lines.com (mathias) — Tue, 28 Apr 2009 16:23:10 -1300

You know times are changing when such a venerable institution as the Victorinox Swiss Army Knife publishes an ad asking:

"how impressed would you be to see a Swiss Army Knife running a PowerPoint presentation?"

(Picture from Engadget)