In an informal code review today we came across some code which was nowhere near as performant as we needed. It was taking about 4 seconds and we needed it to be well under a second. After some print line debugging we found that the problem was in theapplicationof a chain of responsibility pattern.

The problem we were addressing was a series of token replacements. The value of each token could be provided by any one of half a dozen different token replacers.

Each of the replacers basically looked like

The problem with this is that the database is queried even if there is no token to be replaced by that particular replacer. I’ve been reading a bit about functional programming making a come back as of late so I thought I would take the opportunity to apply some of it here.

C# 3.0 introduced lambda functions which are, I would guess, mostly used for LINQ. In fact I would bet that 90% of programmers only use lambdas for LINQ. That’s a shame because they’re a very powerful tool. Really lambdas are just anonymous function which can be passed around as first class citizens. Using a lambda here coupled with lazy evaluation allows us to only perform the expensive database query when it is actually required. Thus all we need to do is update our code to make use of Lazy which is shockingly easy.

In our case this improved our performance by about 90% and allowed me to lecture people about functional programming.

Note: I will be presenting a talk on data visualization in HTML5 on February the 14th at the Calgary .net user group. Keep an eye onhttp://www.dotnetcalgary.com/ for details. This blog is one in a series which will make up the talk I will be giving.

Sometimes I look back at theexcellentinternet archive and laugh about what bit websites looked like a few years ago. Take a look at CNN from the year 2000or Blizzard from the year 1998in comparison with these same sites today the quality of the design is dreadful. There has been a real revolution in the quality of the sites on the Internet. I’m delighted that this is the case but it does raise the bar for those of us who build websites. Everybody expects our sites to be more attractive and for data to be presented in a more useful fashion than it has been in the past.Fortunatelya number of the key improvements in HTML5 have been around presentation of data.

If you talk to anybody I’ve worked with they’ll tell you that I love graphs. I love the little guys. I love bar charts, I love pie charts, I love spark lines, I don’t love gauges, but I love line charts. I love them so much I want them on my receipts. HTML5 offers a couple of mechanisms for creating drawings(which is what graphs are): Canvas and SVG.

Each of these has their advantages which is why theargumentsI’ve seen people having about which one is better overall to be a bit silly. Sometimes a spoon is better and sometimes a fork is better. a spork is almost always the worst solution, but that might just be because I’m sporkist.

Canvas is a raster format which means that you canmanipulateimages in it very easily. If you were looking to build a graphics editor or perform analysis of an existing image then canvas would be for you. Also if you were looking to build a game this is most commonly done using canvas because of the difficult nature of building game graphics in a vector format. As a graphics professor of mine use to say “Raster is faster, but vector is better”. There is pretty good support for canvas on major browsers and even in older versions. If you’re trapped in a company where the IT department have totally failed to keep up with the times and are still running Windows XP there is some hope, you can use excanvasto add support to older versions of IE. It is a lot slower and doesn’t render things perfectly. You should probably sigh loudly and shake your head in woe that your company hasn’t grasped how important IT is.

Now for SVG. These are scalable vector graphics which means that the graphic is made up from a series of lines and curves. It is surprising how impressive the things are you can build with what amounts to a pile of shapes. Being made of a bunch of lines means that you can scale the images up and down as you see fit. So if you want to zoom into a section of the graphic it can be done without losing any of the quality as you would see in a raster image. I like to think of them as the format in which all video recorders record in most crime dramas. Browser support for SVG is about the same as canvas. As most charts and graphs are made up of lines and the such this seems like an ideal solution.

SVG data is stored as part of the DOM which means that it can be manipulated with standard javascript and that you can easily assign action listeners to objects within the canvas.Add to this is the fact that SVGs support declarative animation and you’ve got yourself a graphics solution for data visualization in HTML5.

You can read a bunch more about SVG vs. Canvas in a number of places like here, here.aspx)and here.

In the next part we’ll look at how to use SVG.

I’m really excited by the proliferation of databases which aren’t relational in nature. There are almost too many variations to name now. The argument for making your data layer reallyplug-ableis much more compelling now. I was never convinced of the need previously because it seemed like such a zero-sum game to switch from SQL Server to Oracle to MySQL. The performance profiles were, for the most part, not all that divergent and any cost savings would probably be swallowed by retraining and updating the application. But now there can be significant differences in performance for certain tasks between SQL database and other types. This means that a decision which use to be easy, “Which database should I use?”, is vastly more complicated. As with all complicated decision in system design it is best to delay them until you have as much information as possible.

With all the choices available to developers for storing data I worry a bit that relational databases will be ignored in favour of other storage mechanisms. There is sill plenty of data which makes sense in a relational database. Heck, I would even claim that most of the data we deal with on a day to day basis makes the most sense in a relational database.

Even with these choices it seems that a good many shops remain coupled with SQL databases. I don’tentirelyblame them. If there is one technology which has been pretty slow to change it is databases. This is partly because for years we were complacent in thinking that SQL databases were the solution to all data problems andpartiallybecause there is so muchperceivedrisk in changing database technologies.

Therelationallyof most data coupled with the comfort that IT departments and developers have with relational SQL databases shouldn’t be ignored when looking at data storage solutions. I would also consider that these databases have been around for many years and no matter what vendors like 10gen say they’re likely to have more bugs than established SQL databases. Before you decide on using a newer database technology you need to be sure that there is a real need for it and you’re not falling into the trap of doing whatever is new and cool. If you build in that data layer then swapping out the entire database or portions of the database is much easier.

I don’t know about everybody else but when I publish code on github or even in a mailing list post I try extra hard to make it not suck. Of course it still sucks but at least I know that it’s because I’m notcompetentand not because I’m lazy. Putting code out there for others to read forces you to think just that little bit more about how good it is and, hopefully, make it a bit better.

The extra though is one of the reasons that I’m a big advocate of code reviews. Lately I’ve been thinking a lot about coupling code reviews inside my group with code reviews from outside my group. The culture in the rest of the company I’m with is not really conducive to having other people review my code but that’s never stopped me before. We have a github organization and whenever people areinterestedin our code I grant them read access and tell them we accept pull requests. Typically this gets the old squint of confusion. Even afterexplanations the squint usually remains.

The problem is that with most large companies the idea that people who don’t work directly on the product can see the code is totally foreign. If you ask around nobody is really sure why that is so they throw out the excuse of security.

If people can see the code then they might be able to break into the system or they might steal the code and give it away.

The first part of this argument is a terrible one. Security through obscurity has never workedvery well. The second part is slightly better but if you don’t trust the people you have working for you whey are they working for you? There have been code leaks in the past but I have been unable to find a notable case where the leak was caused by an employee leaking the code.

What I’m proposing is that software development of internal tools in a company should be open within the company. There are a number of tools I use which could be improved with a few minor changes. The developers of these tools are either too busy or too out of touch with their user base to make the changes themselves. If these tools were internally open sourced then I could have submitted a pull request to the team ““ saving their time and improving the product. If everybody should learn to codethen the obviouscorollaryis that all code should be open.

I have a lot of crazy ideas while I type things into the glowing boxes which live on my desk. I’m never going to have time to make something of them but maybe somebody else will. Maybe that person will make a bunch of money from the idea. And maybe that person will send me a finder’s fee and I can retire. In a hot climate. With a drink that has a little umbrella in it and some pineapple. A real man’s drink.

Today’s idea is about how businesses interact with the public and more specifically with geeks. As a geek when I’m dealing with a company I have different needs from what I’m going to call “regular people”. Let me explain with an example: I have a friend who just had a house built. He’s one of us, a geek. So when he interacted with the building company he had geeky requirements. He didn’t want people calling him he wanted e-mails. When he went to pick out a kitchen he didn’t want to flip through a book of draw handles he wanted a tablet app which gave him the ability to see renderings of draws and handles in his kitchen.

What he needs is a geek proxy service. This proxy transforms regular interactions into geekier ones. Geekier? How? The service would act as an intermediary and provide somebody who will work with the house building company and with my friend so his interactions are what he wants.

I think another great example is around grocery receipts. This is what I typically get

Yawn

This is just a big long list of what I bought. That is really only useful for a couple of things

1. Knowing the price of an individual item
   2. Using the receipt as proof of purchase

I don’t feel like either of these are common use cases. Most stores now allow you to return goods based on the records they have attached to your frequent buyer card and in a grocery store who cares how much you spend on an individual good?

Wouldn’t it be neater to get

And that’s what the startup could do. Figure out geekier ways to communicate information and, instead of waiting for businesses to step up, just step into the gap themselves.

Over the Christmas break I thought I would play a bit with MonoDroid or Mono for Android as I guess it is now called. Things were going pretty well until I decided to split the data access components into their own library. I was on v3.05 and compiling resulted in an encounter with thediabolical issue 7905. The fix suggested in that was altering

/Library/Frameworks/Mono.framework/Versions/2.10.9/lib/mono/xbuild/Microsoft/Portable/v4.0/Microsoft.Portable.CSharp.targets

To change

to

This did get me most of the way there but I ran into the error

targetframeworkversion v1.0 could not be converted to an android api level

Digging around a little bit with that I found that in the same file altering thepropertiesdefined at the top to

Corrected the issue. It was a bitdisappointingthat this didn’t work out of the box. I would have thought that creating portable libraries would be a pretty common use case for Mono for X platforms.