I gave a quick Firestarter talk at the San Francisco .Net user group yesterday about .less. .less (‘dot-less’) is an open source .Net library, which extends the functionality of CSS (it works with your existing CSS files), adding features like variables, using a syntax close to CSS. If you find that working with CSS causes some teeth-grinding , you should probably have a look!

Download the slide deck here

I have been using test-driven development since I read Kent Beck’s book on the topic. I loved the book, I tried it, and adopted it, simply because it makes my life easier. It helps me think through what I am trying to achieve, and I like the safety net of having a test suite which tells me exactly what I have broken. It also fits well with the type of code I write, which is usually math-oriented, with nice, tight domain objects.

So when I decided recently to write a C# implementation of the Simplex algorithm, a classic method to resolve linear programming optimization problems, I expected a walk in the park.

(Side note:I am aware that re-implementing the Simplex is pointless, I am doing this as an exercise/experiment)

Turns out, I was mistaken. I have been struggling with this project pretty much from the beginning, and unit testing hasn’t really helped so far. Unfortunately, I didn’t reach a point where I fully understand what it is that is not flowing, but I decided I would share some of the problems I encountered. Maybe brighter minds than me can help me see what I am doing wrong!More...

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.

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 M-V-VM seminar of last month inspired me to finally get serious about WPF. The best way to learn a technology is to write some code with it, so I have begun working on a project of my own, which I hope to complete by end-March (in spite of being working full bore on a project for a client).

So far, working with Model-View-ViewModel and WPF has proven easier than what I expected. Once you get the logic, things flow pretty naturally. One of my recent stumbling blocks was binding with a collection. Now that I got it to work, it seems trivial, but maybe this will help some other WPF beginner on the path to enlightenment!

Imagine that your model contains a list of persons, and that you want to display two things:

1) the list of persons,
2) detailed information about the selected person

More...