I've heard some talk on twitter, blogs, and at various user groups and conferences for a while now about using the command/query object pattern instead of the repository pattern for a data access layer, and all the benefits of doing so.

So, I decided to explore it for myself. I converted over my Ledger project, since it used repositories, has some complexity, but is not particularly large.

Ledger already uses Dapper, so I started with Dustin Brown's post on using command/query with Dapper. For the most part, I followed what he did exactly (I also had to finally get Ledger using an IoC container, which I had been putting off for a while). These are the four files I used to get started with the pattern:

Note that mine differs from Dustin's only in that his IDatabase contains two methods named Execute, whereas mine contains one named Query and one named Execute. Note that except for IDatabase, these all depend on System.Data.IDbConnection (which is what Dapper uses). So, if you want to use a different DB access library, you'll have to change these.

Now, you need to create queries and/or commands. A query returns data, a command manipulates data. Here's a command that uses Dapper to create a new ledger:

Note that the information for the new ledger is passed via a constructor. And here's an example of a query that returns a single ledger, given an ID number (note that the ID is a constructor parameter).

Here's an example of both of those command/query objects in action inside of a controller.

That's the mechanics of it. It was much simpler to code than it might sound.

I don't know if I'm ready to draw any definitive conclusions about this pattern yet, but here are my thoughts:

• I'm not particulary happy with the ceremony involved when doing this in C#. Compared to repository, it's a bit of extra noise and typing to use Execute + new keyword + constructor parameters + private fields to hold arguments.
• Organizationally, I don't have to think about which method goes to which repository anymore. Organization, then, is strictly a matter of folders and/or namespace, and changing those is not as costly. I like that.
• I also like that instead of 2, 3, or even more repositories, I only need one IDatabase member in my controller.
• I haven't gone hands-on with unit testing, but I don't anticipate it being much harder. I could also forsee that this pattern is less likely to result in broken tests when making changes to a repository's interface.

I am impressed, but I am not entirely convinced yet. I think this may need further research, especially when it comes to unit tests.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• Are you watching AMC's Halt and Catch Fire? So far, a decent show. Lots of nerd meat in there: topical 80s computer industry references, Mythical Man Month contributing to a plot point, and so on. It's mostly fictional, but what makes it unique to me is that it's not a story about all the gleaming genius visionaries in Silicon Valley like Microsoft, Apple, Xerox, etc., but about hackers everywhere, scratching out market share, challenging IBM, and grinding out results.
• AMC posted a web version of Colossal Cave Adventure to promote the show. Why Colossal Cave Adventure? Because it's a plot point in the show. See? You should be watching.
• I've said it before, but one of the best things about this show is the intro credit sequence. Though I think it stands on its own, the music, colors, graphics, everything, also fit the tone of the rest of the show well.
• In a recent episode, Ada Lovelace (featured in a Brief Bio) was mentioned, as was Grace Hopper (subject of an upcoming Brief Bio).
• There's lots of stories and urban legends about the "Halt and Catch Fire" phrase. I'm sure most of them are apocryphal, but it's entertaining apocrypha.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Welcome to the latest installment of the Brief Bio series, where I'm writing up very informal biographies about major figures in the history of computers. Please take a look at the Brief Bio archive, and feel free to leave corrections and omissions in the comments.

Tommy Flowers

Tommy Flowers was born in London in 1905. He was the son of bricklayer (not a banker). While working as a mechanical engineer's apprentice, he tooks night classes to get an EE degree. It's interesting to compare his father's profession with others in this series. Sons of bankers seem to very math and theory oriented, while Tommy Flowers seems to be more mechanically and hands-on oriented. There's plenty of overlap, and all are brilliant, of course.

From 1935 on, Tommy Flowers seemed to be most focused on phone exchanges, and was interested in making them completely electronic.

Were it not for the start of World War II, Flowers might have devoted his entire career to phone exchanges. In 1941, Alan Turing (whom I will definitely get to later), working at the famed Bletchley Park, asked for Tommy Flowers to build a decoder for the Bombe. This decoder wasn't ever completed, but this was the start of a professional relationship between Flowers, Turing, and the best code-breakers in England.

One of the codebreaking devices created at Bletchley Park was the Heath Robinson. Tommy Flowers built the "combining unit" for this machine. This module used vacuum tubes (the British call them "valves") to implement boolean XOR logic. This may sound trivial now, but the use of vacuum tubes was a key innovation here that Tommy Flowers would later apply to the Colossus.

Vacuum tubes are all but obsolete these days--mainly replaced by the transistor for most applications. The "T" in "CRT" stands for tube, so maybe you have a few of those still around. Traditional light bulbs are also vacuum tubes. Here's a video on the many applications of vacuum tubes. In particular note, at 7:10, it talks about how tubes are used for amplification. If you then move ahead to 13:14, you'll see that the same grid used for amplication can also be used for control: closing, opening, or modifying a circuit (closing and opening being useful for logic, but computers aren't mentioned in this video).

Flowers is most famous for the design and creation of Colussus, which is often considered to be the first electronic, programmable computer. It was used for code breaking, and especially key in the Normandy invasion. This machine used around 2000 vacuum tubes, which is over 10 times as many as other electronics (like RADAR) used and put reliability into doubt: they often broke and/or just wore out. That's a headache when you depend on a handful of tubes; it's debilitating with thousands. However, Flowers previous work with vacuum tubes caused him to believe that keeping the tubes running continuously was key to improving their reliability.

There are a lot of videos and information out there about Colossus, so I thought I'd link to a few that I found particularly interesting.

• A short film created by Google that focuses on the people who built Colossus and it's ultimate, unfortunate fate.
• A rebuild of Colossus at the Bletchley Park museum - part 1, and part 2. Lots of information about how the machine works and how it's operated.

After the war, Flowers went back to work on phone systems at the Post Office Research Station, where he continued to advance electronic phone exchanges. He retired in 1969, and he published a book on telephone exchanges in the early 70s. It wasn't until the 1970s that Flowers's work on Colussus was able to be made public. Until then it was a closely guarded secret that Flowers couldn't even tell his family about. They just knew it was important, top secret work. Flowers went on to write about Colossus in The Design of Colossus. He started receiving general recognition for his accomplishments, and received many awards and honors.

He died in 1998 at age 92.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• I've been exploring the Command/Query Objects pattern, specifically with the idea of replacing the repository pattern. I've started with Dustin's Brown post about Command/Query Objects with Dapper.
• How to setup Twitter Cards for your site (specifically WordPress, but blog post is helpful for everyone else too).
• Rob Gibbens posted about using Fody.PropertyChanged (an AOP plugin to the Fody IL rewriting framework) with Xamarin to use the MVVM pattern.
• EconTalk is one of my favorite podcasts. Check out this episode about the "sharing economy", in which they discuss the impact of technology like Uber, AirBnb, and so on, featuring my favorite guest: Michael Munger. Especially interesting to me is the discussion about taxi medallion investments.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

We take the internet for granted. I can send information to just about anyone without a stamp, without ink, without waiting for a truck to come pick it up.

However, some parts of the world are still mired in actual paper work, for whatever reason: legal lag, technology costs, fear of change, etc. So, despite the fact that I can book a hotel, refill my prescriptions, start an LLC, and a thousand other things over the web, there are often times where I still have to send faxes, sign documents with a pen, and lick envelopes.

I have come up with some ways of insulating myself from some of these primitive forms of communication. Often this means I have to take a PDF, print out one page, sign it, scan it, and then reconstruct that PDF. Or, with an expense report, I'll take multiple scans/photos of receipts and have to stitch them together into one PDF. A long time ago, I couldn't figure out how to actually stitch PDFs together into one document without something like Adobe Acrobat installed (which I don't want to buy and don't want to install). So, I created a little tool that I called MattDoc.

I called it that because it needed a name and I was in a hurry (as you'll see by the interface). I have decided to make this tool open source, as part of my ongoing code garage sale.

Here's how it works. Suppose I have three PDF files: page1.pdf, page2.pdf, and page3.pdf. I want a single PDF that consists of these three documents in series. I click "Browse" to add each file, in order. Then I click "Save to 1 PDF". PdfSharp does the work here. It also works with images.

The UI is very unpolished. It could use some work, and a couple more features (for instance, right now there's no way to reorder or remove files from the list).

Hopefully this will help you stitch documents together (or maybe there's a much easier way that I don't know about) or maybe this will help you try out PdfSharp for the first time.

P.S. If you check out the git history, you'll see that I wrote this before NuGet was really a thing (or at least a thing I knew how to use): I've been using it and getting value out of it that long.