Code Emporium

Today I revisited some Google tech talks given by Miško Hevery about writing testable code. I seem to watch a lot of Google tech talks and the ones given by Miško have got to be some of my all-time favourites. Not only is he fortunate enough to have a cool name, but coincidentally has a great talent when it comes to breaking down and explaining technical topics.

Back a year ago or so the phrase “dependency injection” kept rearing its ugly head and I couldn’t get away from it. Although I spent some time reading about it and could explain what it was, I never really understood it in terms of application. Then one day I stumbled across one of these videos while having lunch and it all started to make some sense, now that it had been given some context.

I’ve written a reasonable number of tests before on past projects but truth be told I’m still probably a bit of a n00b with the whole thing. Keep in mind though, the videos discuss how to write code that’s testable, not the tests themselves… Either way, what I like most about Miško’s talks is that the methods he demonstrates for writing testable code seem to enhance the overall quality of the code in a number of other dimensions. Now I just need a project to start applying all this stuff to. Yeah yeah, onto the videos…

Video 1

Video 2

Video 3

Video 4

For anyone new to Google tech talks, there’s a whole bunch more from other people also. I’ll continue to be taking my favourite ones and posting about them here.

So I’ve just graduated from university. No longer having that on my mind, I’ve taken the opportunity to take a step back and have a look at what’s important for me to be working on over the longer term. One of the things that I feel I should be doing is to ensure that I continue reading and learning autonomously while I’m out of educational institutions. Idea being, if I learn just a little more with each new day, I might wake up one morning (or afternoon) and find that I’m not half bad at this whole software thing (or just suck less). Label it self-betterment if you like, but I promise running over hot coals won’t become a part of my repertoire (or at least if it does, I’ll destroy all evidence of this post).

Back at university I was kept well busy with plenty of prescribed texts to read. I also made time to read a few other non-prescribed texts, but never as many as I would have liked. Now that I’ve got some time, I’m making a point of reading some of the other software texts that have been on my “to read” list for quite some time. As I make my way through these books, I’ll voice my thoughts on them here. Anyway, the book which I’ve just finished reading (or victim #1) is Facts and Fallacies of Software Engineering by Robert L. Glass.

I heard about this book a while back. It sounded like an interesting enough read so I grabbed a copy.

So what is there to be had out of this book? Well, as you might have guessed, or at least been hoping, there are some interesting facts (and fallacies) about software engineering contained within. When talking about facts, here’s the overarching topics the text discusses:

• People
• Tools and Techniques
• Estimation
• Reuse
• Requirements
• Design
• Coding
• Error Removal
• Testing
• Reviews and Inspections
• Maintenance
• Quality
• Reliability
• Efficiency
• Research

Most of the facts in each of these sections are rules of thumb; “generally speaking” type statements. A few quick example facts:

Fact #3: Adding people to a late project makes it later.
Fact #31: Error removal is the most time-consuming phase of the lifecycle.
Fact #42: Enhancements represent roughly 60 percent of maintenance costs.

The facts take up the majority of the book; fifty-five facts in total. There’s only ten fallacies, which according to Glass are what many in the software engineering field believe to be true, but turn out to be false upon closer inspection. For example:

Fallacy #1: You can’t manage what you can’t measure.
Fallacy #6: To estimate cost and schedule, first estimate lines of code.

If you’d like an exhaustive list of the fifty-five facts and ten fallacies, then check out revisiting the facts and fallacies of software engineering.

I think my personal favourite fact out of this book was Fact #5: “Hype (about tools and technology) is a plague on the house of software”. It’s noted that most software tools and technique improvements actually account for about a 5 to 35 percent increase in productivity and quality, and yet at one point or another someone will invariably have touted “order of magnitude” benefits. Glass points out that the sources of such hype almost always have some form of vested interest, whether it be product sales, high-priced courses or research funding. Admittedly you could label me a hypocrite at this point, having linked that book cover to my Amazon associate sales account just a few paragraphs back. I’ll do my best to remain objective though, and I certainly won’t be claiming order of magnitude benefits from reading this single book.

The discussion of hype in fact five reminded me very much of a Ruby on Rails course I took at university. Even if it had have been the greatest thing since sliced bread, there was nothing like a bunch of dogmatic pseudo-cultured Mac user stereotypes to turn me off the product. Ruby on Rails as a technology was fine, but there’s only a certain amount of narcissism one can ingest. Strangely enough, it didn’t work half as easily for me as it did for the guy giving the paid seminars. For anyone who has ever gotten caught up in the hype of a technology or methodology, only to find yourself bitterly disappointed that it couldn’t in fact single-handedly cure cancer and eradicate poverty, then reading this book should make you feel somewhat better.

To be fair, and while on the subject of narcissism, I think Glass has easily earned the “most references to my own work” award with this book. The text seems to be laced with pointers to other books or journal articles that he has authored. Then again, the book does come across as somewhat of a summary of much of his earlier findings which makes the heavy self-referencing (or self-promotion?) a little more forgivable.

I’d like to kick back by the fire with a glass of whiskey and a cigar and reminisce about the good old days, noting how many age-old lessons and timely reminders are contained within Facts and Fallacies of Software Engineering. The problem is, I don’t smoke, I don’t have a fireplace and I’ve only been working in software for two and a half years (and as an undergraduate). With the new alcohol taxes in Australia, I probably can’t afford whiskey either. Anyway, you’ve probably deduced that I’m no portrait of experience. It’s therefore not my place to pontificate on how all this stuff is congruent with the last n decades of my professional career. Nonetheless, I did identify with some of the facts and fallacies in the book; a.k.a. lessons that I’ve already learnt the hard way. The other facts and fallacies I’ll keep in mind and see how well they align with my own experiences over the coming years.

All in all it was a pretty good read. It’s relatively short (224 pages) and is the kind of book that you can read away from the computer. You certainly won’t learn the quickest way to sort one million 32-bit integers and if that’s the level of technical detail your after then find another book (and don’t ask Barrack). Some might even say the book is a little too high level, without enough meat to it. You can at least be assured that there’s plenty of references to more detailed works (even if half of those works are the author’s own ink). If I had to compare it to a fairly popular yardstick, I’d say it’s like a Code Completebut with a little less detail and a little more controversy. This shouldn’t be too much of a deterrent though, as Glass still makes plenty of valid points and the book still provides a pretty good summary of issues in the field of software engineering.

Facts and Fallacies of Software Engineering is the kind of book that you don’t need to invest a lot of time in and one that you can pick up right where you left off if you find yourself interrupted. Because of this I found the book perfect for filling those sporadic segments of idle time that have a habit of creeping into my life. Still, it was interesting enough that I wanted to come back and continue reading it, even outside of those “idle” periods. For anyone that reads software engineering texts on a regular basis, I imagine that much of this book will come as old news. Still, it’s the kind of book that you’d want to read even as a refresher on everything you’ve learnt and forgotten about software engineering over the years.

Lately I’ve been reflecting on just how much I love modern search. And I don’t just mean Google search, but search in general.

I didn’t really begin discovering the wonders of search until I was already a year into my IT degree, which scarily enough wasn’t all that long ago (circa 2007). Of course I was familiar with Internet search engines (I might have been pursuing the wrong career path if I wasn’t), but I’d never really used search much outside of it.

My first revelation in search came when I started using the humble Ctrl + F to find text in Visual Studio.

That’s right – for my first two terms of uni I’d been coding up my C++ assignments without once using the find feature in Visual Studio. Not to mention all the time I’d spent coding in high school without it.

Find is such a simple feature really and one which is in so many programs that deal with text. Needless to say, after I actually started using Ctrl + F in Visual Studio, I soon started using it in other programs like Notepad and Word too. This had been a definite blind spot for me; a rudimentary feature that had been around so long and yet I’d never really taken advantage of it. And yeah yeah, before anybody picks me up on it, I realise that Visual Studio has incremental search which is often the better option, but I didn’t know about it at the time and some search was better than no search.

Now that I use the find feature, I rarely bother scanning through more than a few pages worth of text when I’m looking for something particular, regardless of whether it’s Visual Studio, Word, Notepad or some other text editor. I’ll just Ctrl + F it instead. Lazy perhaps, but sometimes laziness is good. It’s strange how something so simple can completely change how you work and save you so much time when you know what it is you’re after.

For me the next advance in search came when Windows Vista was released in 2007. Putting aside all the hatred that’s been directed towards Vista, there’s one feature in it that I’d truly miss going back to Windows XP – the ability to quickly search for programs from the start menu.

It takes just one stroke of the Windows key to to open the Vista Start Menu, and after having typed the first 3-6 letters in the name of the program I want to launch, it’s generally listed within the top three results, requiring a maximum of three more keystrokes; two with the down arrow and one for Enter. All in all I’d say that 95% of the time I use less than 10 keystrokes in total to launch a program. It’s a hell of a lot quicker than using the mouse to navigate through the start menu folders Windows XP style, especially when the program you’re after has been stashed off in some deeply nested and obscure folder, the path to which you might not even remember.

I’m constantly trying out new software and applications. Being able to type the name of the program I want to run rather than dig through the program list is what I consider one of the single best features of Windows Vista. Without a doubt the improved start menu in Vista has been instrumental in enhancing my laziness.

My next notable advance with search came when I actually started using Google Desktop in 2008. I’d had it installed for some time previous, but like so many other applications, it’d found its way through my Install > Try > Forget cycle that often occurs when I find no immediate use for an application. In retrospect, I’d been looking at Google Desktop from the wrong perspective. I’d always considered file system search tools as utilities for finding something when you lose it. Eventually though, I started seeing them as a means of cutting down on superfluous clicks and navigation. Instead of using Google Desktop to find files I’ve lost, I now mostly use it to quickly open up files I usually already know the location of.

The initial indexing Google Desktop performs can take some time, but once it’s done, it retrieves results lightning fast. Of course one might ask why you wouldn’t just use the search built into Windows Vista which is considered to have become quite reasonable. In practice I’ve found that Google Desktop has been quicker and provided superior results when searching for files, but your mileage may vary, so test for yourself.

I see Google Desktop as analogous to the Vista Start Menu Search – it’s not there just to help you find what you’ve lost, but to save you the clicks of navigating to stuff you already know about. It generally requires a similar number of keystrokes too. Two hits of the Ctrl key and the search box is up. Another few keystrokes to type the first few letters of what it is you’re after and you’ll usually have the correct result in front of you. On average I’d say there’s a similar number of keystrokes involved in opening a file through Google Desktop as there is in starting a program from the Vista Start Menu. Compare that to opening up Windows Explorer and navigating through a folder hierarchy and I can think of very few instances where desktop search is slower.

So by this point in time I was pretty happy with myself and thought I’d done a reasonably good job of speeding up common tasks like finding my way through text files and opening up a program/file. It wasn’t then until Google Chrome was released as a beta in September 2008 that I found myself experiencing a new level of search awesomeness. Prior to the release of Chrome, I hadn’t been too fussed about which web browser I used as I’d considered them all to be more or less the same. Truth be told, had I given Firefox more of a chance, I probably would have switched over to it from Internet Explorer back before Chrome existed. Given that I have a soft spot for Google though, I figured it was worth giving Chrome a shot when it was announced.

After using Chrome for a few weeks I couldn’t believe the kind of search I’d been missing out on. Coming from Google though it does makes sense that Chrome is a browser centered around search. From the moment I opened Chrome, performing common tasks seemed crazy fast compared to Internet Explorer. And I’m not even talking about page load times, but interacting with the browser itself. I quickly fell in love with the Chrome omnibox, the speed and utility of which I believe has notably increased the number of searches I perform (Google’s plans have unfolded well).

Not only is the omnibox great for standard search, but adds a subtle feature that I’ve really come to appreciate over time. That’s the ability to issue a specific search on a website without having to load the site first. Take Amazon for example, which I’ve visited previously. Now when I type the letters ‘am’ in the omnibox, the first suggestion that comes up is www.amazon.com and it’s given me the option to press tab to start a search there.

A feature so simple, but one I now find myself using over and over again.

The other search feature of Chrome that I find myself using all the time is incremental inline search (searching for text within a page). I used search every now and then back when Internet Explorer 7 was my primary browser, but it never really did much for me. Search in Internet Explorer 7 was like search found in so many other programs – a dialog box that didn’t provide results incrementally as each new letter was typed. Although this kind of search worked moderately well for me in Visual Studio, I found it didn’t really help me out as much on the web. In Google Chrome, I soon found inline search that was incremental and all instances of the search string were highlighted on the page as each new letter was typed.

Furthermore, there was no dialog box obscuring the view – the search was tucked nicely up in the top right hand corner of the page. All of a sudden, I started finding inline search useful on the web.

To be fair, Firefox had this long before Chrome was even released. In fact, Microsoft seem to have learnt their lesson too with Internet Explorer 8 and have adopted a similar inline search approach. The one thing Chrome’s inline search still has over both IE and Firefox is that it gives a visual indication of where in the page the search term appears by placing small yellow markers in the scrollbar on the right hand side, as illustrated above.

Anyone that’s used file comparison software before would probably have seen a similar visualisation being used to show where the differences exist between two files.

It’s hard to describe just how useful inline search can be when you’re dealing with a large page of text (or even a small one). I recently completed a university course where an electronic copy of our prescribed reading (~420 pages) was made available online. When it came time to do an online quiz, I was able to use inline search to pinpoint a topic which made working through the answers much easier (although I can’t say the university necessarily intended the electronic text to be used in this way). There are some things you just can’t do with a printed text.

The final application of search that I believe has had a notable effect on my productivity has been when I started using the Beyond Compare file comparison software. I kind of consider file comparison software as a way of issuing searches that are non-specific; they just say “I’m looking for what’s different, whatever that may be”.

For me file comparison software was another one of those things that didn’t sound so useful, until I started using it. I now use it frequently and would hate to go back to a time without it, manually eyeballing every line of code in two files looking for the difference that’s caused one file to break.

So there it is. My approach to search over the past few years has evolved to include:

• Using the generic find feature found in most text editors to save looking for things manually
• Using the Vista Start Menu search to launch applications
• Using Google Desktop to open files I know exist
• Using Google Chrome to speed up searching on the web, including inline searches and search within a site
• Using Beyond Compare to do file comparisons

If I were to go back in time a few years and give myself some general advice, here’s what I’d be saying:

• Don’t spend ages trauling through lengthy text files looking for something specific – use the find feature
• Use something that allows you to quickly launch applications and files (whether it be from Microsoft, Google, other)
• Use a browser that does a good job of search, including inline (Google Chrome, Firefox, Internet Explorer 8 )
• Don’t bother trying to manually look for differences between two files or folders – use file comparison software (Beyond Compare among others)

Had I been using these search techniques back then, I think I would have saved myself a substantial amount of time. What are your favourite search techniques?

Quick Downloads:
Image Shack API Wrapper Library
ImageShack Wrapper and Demo App Source
Compiled ImageShack Demo App

So after recently starting up a local online classifieds forum I was looking for a cheap and effective way to host pictures of the stuff users are selling. I thought using an external image host like ImageShack was a good idea, but wanted users to be able to upload their images without leaving the classifieds site. Unfortunately, I wasn’t able to find any ready made plugins for the VBulletin forum software that could do this. The best I could find was one which let a user upload an image to ImageShack but took the user to a new browser tab from which they’d manually have to copy and paste the thumbnail link back into their forum post. Sure – not that much effort, but if the link address was returned through the ImageShack XML API instead and automatically placed into the user’s post it’d make their experience a little nicer.

Anyway, my knowledge of PHP approaches zero, so instead of attempting to code up the PHP VBulletin plugin straight off the mark, I thought I’d first try and get the whole image submission/return of XML thing worked out in something I was familiar with – C# and .NET. Which brings me to what this post is really all about. I’ve created a reusable .NET code library wrapper around the ImageShack XML API that allows you to upload images to ImageShack with a simple method call and have the uploaded image details returned. The method is overloaded to give the option of resizing the image on upload if desired. I’ve also written a small demonstration Windows Forms application that uses the code library to upload an image to ImageShack and display the details of the hosted image.

Here’s what the code library’s IImageShackUploader interface looks like:

using System;
using System.Collections.Generic;
using System.Text;

namespace Brycestrosoft.ImageShackAPIWrapper
{
    public interface IImageShackUploader
    {
        UploadedImageDetails UploadImage(string fileName);

        UploadedImageDetails UploadImage(string fileName, int resizeWidth, int resizeLength);
    }
}

And here’s what the returned UploadedImageDetails data object looks like (the private field’s respective public properties have been omitted for brevity):

using System;
using System.Collections.Generic;
using System.Text;

namespace Brycestrosoft.ImageShackAPIWrapper
{
    public class UploadedImageDetails
    {
        private string _imageLink;
        private string _thumbLink;
        private string _adLink;
        private bool _thumbExists;
        private int _totalRaters;
        private double _averageRating;
        private string _imageLocation;
        private string _thumbLocation;
        private string _server;
        private string _imageName;
        private string _donePage;
        private string _resolution;
        private int _fileSize;
        private string _imageClass;
    }
}

And here’s what the example Windows Forms application looks like:

The class which actually does the work of sending the data off to ImageShack and returning the image details is the StandardImageShackUploader which implements the IImageShackUploader interface. To keep the length of this post down I haven’t shown the StandardImageShackUploader class code here, but it is available in the download.

I thought that while writing the code to send off the information to ImageShack and accept the returned XML data it would be useful to be able to see exactly what was being sent and received on the wire. So I downloaded a copy of Fiddler which gave me a pretty good idea of what was being sent out in my requests and what I was receiving back in ImageShack’s responses. This proved to be indispensable when troubleshooting and for anyone thinking of modifying the request/response code I’d highly recommend it. Here’s a quick screen shot of what’s getting sent out across the wire and what’s getting sent back:

Some things I noted about the information that ImageShack returns:

• thumb_link is only a valid link if thumb_exists is true. If the image you upload is smaller than the size of ImageShack thumbnails, then it looks as though ImageShack doesn’t actually create a thumbnail, but they return you an imaginary thumbnail link regardless.
• ImageShack returns a total_raters and ave_rating value, even though you’ve only just uploaded the image and it’s not going to have any ratings. I’m guessing this is ImageShack provisioning for other image querying features in their XML API in future.
• If you opt to resize your image, the resolution value that ImageShack returns may not match the dimensions you specified if your dimensions don’t scale the image up/down proportionately. In other words, it appears that they’ll let you resize an image, providing that you keep its width and height in the same proportion as the original image. If you don’t keep it in proportion, they’ll force the resize to be in proportion and one of the dimensions may not come out the way you’d expected. Either way, I’ve provisioned for both the resize height and width to be sent off to ImageShack because this is what their API takes and in future they might even change it so that images don’t have to be resized proportionately.
• Generally speaking, there’s probably a fair few details returned by the ImageShack XML API that there is no real use for at this point. Things like image_location, thumb_location and server probably aren’t particularly useful pieces of information, especially considering that it appears as though this information could be derived with some string manipulation on some of the other data that ImageShack sends back. However, for the sake of completeness, I’ve made all of the information returned by the ImageShack API available through the wrapper so that if someone does have a use for it then it’s there.

Props go out to the msdn thread here which I borrowed some code/concepts from.