The coding blog of Alastair Smith, a software developer based in Cambridge, UK. Interested in DevOps, Azure, Kubernetes, .NET Core, and VueJS.
Last night I attended NxtGenUG Cambridge's September event, featuring Guy Smith-Ferrier speaking on Multi-Touch support in Windows 7 and WPF. This was an excellent speech (as I've come to expect from NxtGen over the last year or so), and I've posted in a public Evernote notebook my notes from both Guy's talk and the nugget beforehand which provided an introduction to Kanban and Lean development.
A couple of weeks ago, I successfully sold one of my old bassoons that I no longer play, which provided me with a tidy sum to make some purchases I’d been after for a while. Top of the list was a new laptop, and after some searching around, and due consideration, I decided a MacBook Pro was the model for me.
I’ve recently been working on a new version of my personal website, which can be found over at http://www.alastairsmith.me.uk/. I wanted a light-weight site that would pull in data from my various presences across the web including my two blogs, GitHub, and Google Picasa; furthermore, as much as possible should be hosted on some form of Content-Distribution Network (CDN). Google’s CDN is serving up jQuery and jQuery UI quite nicely for me whilst minimising the amount of stuff I need to administer and maintain myself.
It’s generally a good idea when developing web applications to keep your in-development version separate from your production version; indeed this goes for many development scenarios, including in-house application testing before rolling out to users, desktop software development, and others. The backbone of such a strategy is a good source control system, and whilst centralised source control like Subversion can handle this capably, a certain amount of friction is involved in setting it up. Distributed version control systems, and Git in particular, can remove this friction.
Because my personal website is so small by design, the friction of setting up a centralised source control system for deployment scenarios for such a tiny application would have been great enough to put me off looking into it any further. Luckily, I switched to Git as my version control tool of choice about a year ago, and haven’t really looked back. Here’s how I accomplished a simple web deployment mechanism that can work for sites with a back-end component as well as a smart front-end.
This second and final post on high-quality routines will cover good routine names and guidelines for parameter usage, as well as touching on routine length and special considerations for functions vs procedures.
Last time, I rounded off the series-within-a-series on class design and usage, Working Classes. The next topic for dissection is routine design, creation and usage, and this topic will be handled over two posts. This post will form a bit of an introduction and cover design considerations for high-quality routines through the classification of different kinds of routine cohesion. So, without further ado, let’s get cracking!
This fourth and final post in the mini-series on Working Classes covers the reasons to create a class. These reasons are many and varied, but fall quite neatly into a number of groups. These groups are: modelling concepts, managing complexity, hiding information, building for the future, and classes to avoid. This post should be rather shorter than the recent ones, and hopefully more digestible as a result.
I’m also experimenting with a new method of writing up my notes that I hope will make this post more coherent; I feel that some of my recent posts in the Code Complete series have been almost a sequence of short paragraphs and possibly haven’t hung together too well. I’m interested to know whether you think this post is an improvement, dear reader.
There are a number of design and implementation issues to consider when working with classes, not least dealing with inheritance. This third post in the series of four on “Working Classes” covers my take on Steve McConnell’s thoughts on containment, inheritance, member functions and data, and constructors.
I’ve finally done it: ReelCritic has launched! The DNS changes are currently propagating through the Internet, so the link may not work for you straight away; you might want to give it another go in a few hours/tomorrow.
If you’ve been following the developer hangouts in the last few months, you’ve probably heard at least a little bit about NoSQL and document databases. You may also have read how they’re the best thing since sliced bread, and that NoSQL will be your new BFF. Contrariwise, you may have read some of the FUD surrounding the subject and have cough a less rose-tinted view of the things.
Last night, I attended the Cambridge <a href=”http://www.nxtgenug.net/ title=”NxtGen User Group”>NxtGenUG</a> meeting on this very topic, and I intend to distil some of what I learnt in this post; mostly it’ll be me riffing around the stuff that Neil covered. The talk was delivered by Neil Robbins, whose delivery was always energetic, interesting and informative. The 100mph demo at the end of the talk was both simple and powerful. He’s a great speaker even if his slides were a bit wordy (with one or two being excessively so). Check him out on Twitter.
I find the whole meta-blogging thing a bit tiresome, really, but I thought I should probably do a quick update as CodeBork is moving home! There are two main things you will notice:
As you may have already gathered from my Twitter feed, I’ve been working recently on ReelCritic, a new blog catering solely for my film reviews. For a sneak peek at the design of the new site, pop on over to http://www.reelcritic.co.uk/. Everything you find at that address is a non-functional mock-up, so please don’t try to leave comments, etc. There’s only one review available, Rachel Getting Married. I’m currently working to port this design over to Drupal’s theme engine so that I can get the blog fully up and running.
I’ve heard many good things about Windows Live Writer as a blogging tool, so I thought I’d give it a go. Drupal’s great an’ all, but entering HTML manually to format your post is so 2001. So, here’s my first post from Live Writer!
[img_assist|nid=128|title={ Insert Obligatory Image Here }|desc=Image © 2007 MichaelMaggs|link=node|align=center|width=400|height=267]
[3.5/5] This mongrel transcends the vampire genre, but the final descent into unmitigated gore ruins an otherwise interesting premise. [img_assist|nid=124|title=Daybreakers|desc=We're the ones holding the crossbows|link=none|align=center|width=400|height=268]
[4/5] This bleak and, at times, disturbing revenge flick sees Michael Caine deliver another strong performance in a story that might be considered over-egged. [img_assist|nid=122|title=Harry Brown|desc=Even in his 70s, Michael Caine is still bad-ass|link=none|align=center|width=400|height=267]
This post represents the second instalment taken from chapter 6 of Code Complete, entitled “Working Classes”. This post covers the issues to consider when designing class interfaces, illustrated with code samples. An important piece of information to keep in mind when reading this post is that McConnell is talking in terms of the public interface exposed by a class through its public members. While an interface (as defined in Java or C#) also fits this bill, some of the advice given here is specific to the idea of a class interface, and not a standalone interface.
If you’re after the executive summary (this is quite a long post, after all), there are only two things you must build into your class interfaces: good abstraction and good encapsulation. Read on to find out more.
Another day, another Code Complete blog post. I might even clear two today, looking at the number of notes I have for this one.
The last post rounded off the contribution to the discussion around the problems of designing software. A new chapter means a new topic, and chapter 6, titled “Working Classes”, deals with tips on, and the issues around, creating classes in your program. First up is the topic of Abstract Data Types: what they are, why you should be interested, and how you should use them.
Wow, it’s been quite a while since I updated my Code Complete series, and I’ve got quite the backlog to wade through now! Looking at the last save date on this post, it’s been sat around for three months waiting to be written, so I’m sorry for being so slack, and I’ll get on with writing it now…
This post covers some key design practices, and is the last post on Chapter 5, Design in Construction.
[4.5/5] This moving story of a teenager growing up in 1960s London charms, startles, amuses, shakes and delights in equal measure. [img_assist|nid=120|title=An Education|desc=L-R Dominic Cooper, Rosamund Pike, Peter Saarsgard, Carey Mulligan|link=none|align=center|width=400|height=266]
You may remember from my previous blog post on mocking frameworks that I’m a bit of a fan of this kind of tool. They’re great for simplifying unit testing, and can also help guide you in to writing better, more loosely-coupled code via Dependency Injection.
Last night I spent some time porting some of my unit tests for a side project I’m working on from NMock 2 to Moq 4 (currently in beta). My reasons for switching were three-fold: first, NMock can only mock interfaces which was causing problems with testing some parts of my code that relied on elements of the ASP.NET MVC framework; second, NMock is unable to support some of the newer features of .NET as it was written to target .NET 2.0 (whilst each version of Moq is matched to the respective version of .NET, so the Moq 4 beta can utilise the C# 4.0 goodies like dynamic typing); last, the NMock project doesn’t seem to be as active as it once was, with the last official build released in January 2008.
As a result of this switch, I’m in more of a position to critically evaluate NMock and Moq than I was when I wrote my original post. Here’s a summary of my thoughts and experiences.
On Wednesday 28 October 2009, Joel Spolsky and Jeff Atwood brought their Stack Overflow sideshow to London’s Kensington Town Hall, and I was lucky enough to be one of the ~1000 people attending.
Windows 7 introduces a whole bunch of cool features, as I’ve mentioned here previously. Sometimes the simplest ones are the most effective, however, and there’s nothing simpler or more effective than the in-taskbar progress indicator. If you haven’t seen this already, when you copy a file in Windows Explorer, download a file using IE, or perform any of a number of similar actions that might take a while to complete, the progress information is displayed in the task bar icon for that application.
| [img_assist | nid=116 | title=Windows 7 Taskbar Progress | desc=This screenshot also illustrates the “Icon and Text” display mode | link=none | align=center | width=400 | height=234] |
That busy period at work that I mentioned hasn't really ended, and by the sounds of things it won't be any time soon. As such, it's likely that my Code Complete series is going to be put on hold for a while longer as we ride this current and move on.
Ok, so this is my first post on Code Complete for a little while; it turned out the busy period at work lasted a good couple of weeks longer than I thought it would! It was a quite a while back that I made these notes (mid-June, in fact), so if the post seems less coherent or I've got something obviously wrong, please leave a comment. Here be dragons. This post deals with design heuristics. We've already touched on what heuristics are in the Software Development Metaphors post, so you might want to refresh your understanding before reading on. Inside, I will cover McConnell's description and critical evaluation of the most common design heuristics. These can be viewed as smaller steps in a larger process, or as individual methods to use at different stages of the design process. Note: this is a long post! [img_assist|nid=103|title=Chocolate Heuristics|desc=Copyright © 2006 maadmob|link=url|url=http://www.flickr.com/photos/maadmob/|align=center|width=400|height=330]
Design is essentially an exercise in managing complexity, and it is incredibly important to manage correctly. Dijkstra (1989) stated that a single person working on a software development project needs to grapple with anything from one bit to a few hundred megabytes: this is 9 orders of magnitude. Given that software is always increasing in complexity, McConnell posits that this figure could be as much as 15 orders of magnitude or more today. This post covers in some depth the issues around managing complexity, ways to attach it, and the importance of doing so. It will also cover desirable characteristics of design, and the different levels of design. Note: this is a long post!
This is a relatively short post, covering the key construction decisions Steve McConnell highlights in his book Code Complete.