About a month ago Tom Janssens, who is a constant force on the DDD-CQRS mailing list and a generally smart dude, posted a link to his latest CQRS creation. Entitled Mauritius this CQRS example was an experiment around minimizing infrastructure. A lot of people get hung up on thinking they need a service bus and idempotent commands and the ability to handle asynchronous updates to their composite UI when they first look at CQRS. This isn’t the case and you can make some very simple CQRS solutions like Mauritius and Greg Young’s Simple CQRS.

Anyway CQRS isn’t the subject of this post. What I wanted to talk about what this great piece of code from Mauritius

This is basically a conversational way of checking constraints. If you were to use it in, say, an ASP.net MVC controller it would look like

Which is much easier to read and understand than the typical way of doing this

I’d really like to see more of this style of coding, to me it exemplifies the idea of self documenting code.

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.

In part 1 we took a look at canvas vs SVG for building graphs and data visualizations. We decided that SVG would probably be better for our purposes. We can build up SVGs by hand or by using a library like jQuery after all they are simply part of the DOM. If you remember SVGs are made up of a series of simple shapes. So let’s build a few little visualizations with SVG. How about a bar chart to start with? A bar chart is made up of a series of rectangles of various different heights.

First thing we need to do is include the SVG in the page. This can be done a number of ways. You can link to an .svg file, you can put it in an iframe or you can embed it directly on the page. I like embedding on the page as it saves a server trip. Now unfortunately the blogging platform I’m using doesn’t support SVG, so I’ll put in raster images instead of the SVG. There are some potential security issues with SVG so that is likely the reason the platform doesn’t support them. These issues will be ironed out just as security issues with HTML were ironed out years ago.

To start with we need to include an svg tag in the document and give it a few instructions

This renders a single bar of our bar chart. The code is pretty easy to understand. The recttag creates s rectangle with a width of 50 and a height of of 150 offset 20 pixels from the top left corner of the SVG. It looks like this:

Weeee! Okay so what next? Let’s build up the SVG necessary for a full graph. We’re going to need a few bars as well as a legend and an axis. Let’s start with a few bars

Here we’ve just added a few more rectangles and reduced the height of each. Because the origin (0,0) is in the top left we also have the change the y value for each bar. This generates

Now let’s add the axes. To do this we add a couple of lines to our SVG

We’re almost done here. Let’s add some labels and a title.

Here you can see we’re adding a series of X and Y axis labels as well as the title. Placing text in SVG so it looks nice in relation to the other elements is difficult. If we were programatically adding elements to the SVG we could calculate the length of the text and position it properly.

Now we have a full graph with a title, labels and the introduction of a kick-ass new month. I’m also comforted to know that there is always at least two monsters under the bed. It is when there is only one they get board and devour your young. True story.

All together the code looks like

In the next post we’ll look at using some libraries to make our job easier.

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.

My name is Simon Timms, I work as a freelance software developer with an interest in distributed systems, CQRS, cloud computing and ice cream. Ice cream most of all. I don’ t know if you’ve tried pumpkin pie ice cream but you really should.

In the past I’ve worked on GPS systems, been a build master, developed websites, written production accounting software and painted fire hydrants. At the moment I work for a directional drilling company on a bunch of different cool stuff.

I’ve been Microsoft MVP in ASP.net since April of 2014. I’ve also written two books with Packt publishing

I’m currently working on my third book with David Paquettewhich we’re self-publishing through LeanPub. We’re offering early access to it as we write it ““ it’s cheaper if you buy it now.

@stimms

For a while now we’ve been using either in memory SQLite or SQLCE databases for our integration tests. It is all pretty simple we spin up a new instance of the database, load in a part of our schema, populate it with a few test records and run our repositories against it. The database is destroyed and created for each test. The in memory version of SQLite was particularly quick and we could run our tests in a few seconds.

The problem was that the dialect of SQL that SQLite and SQLCE speak is slightly different from the dialect that SQL Server 2008 speaks. This wasn’t a big problem when we were building our schemas through NHibernate as it supports outputting tables and queries in a variety of different dialects. In our latest project we move to using Dapper. Instead of creating our schema through a series of fluent configurations as we did with NHibernate we used a database project. This allowed us much finer grained control over what was created in the database but it meant that we were more closely tied to the database technology.

For a while we wrote transformations for our create table scripts and queries which would translate them into SQLCE’s version of TSQL. This code grew more and more complicated and eventually we realized that we were trading developer time for computer time, which is a terrible idea. Computers are cheap and developers are expensive. The class of tests we were writing weren’t unit tests they were integration tests so they could take longer to run without having a large impact on development. We were also testing against a database which wouldn’t be used in production. We could have all sorts ofsubtlebugs in our SQL and we would never know about it, at least not until it was too late.

Instead we’ve started mounting a database on a real version of SQL Server 2008 R2, the same thing we’re using in production. The tests do indeed run slower as each one pays a few seconds of start up cost more than it did with the in memory database. We consider the move to be a really good one as it gets us closer to having reliable tests of the entire stack.