Taller Code

I recently finished reading Continuous Delivery. It’s an excellent book that manages to straddle that “keep it broad to help lots of people yet specific enough to actually give value” line pretty well. It covers testing strategies, process management, deployment strategies, and more.

At my former job we had a PowerShell script that would handle our deployment and related tasks. Each type of build - commit, nightly, push, etc. - all worked off its own artifacts that it created right then, duplicating any compilation, testing, or pre-compiling tasks. That eats up a lot of time. Here’s a list of posts where I covered how that script generally works:

• Part 1
• Part 2
• Part 3
• Part 4

The book talks about creating a single set of artifacts from the first commit build, and passing those same artifacts through the pipeline of UI tests, acceptance tests, manual testing, and finally deployment. I really like that idea, as it cuts down on unnecessary rework, and gives you more confidence that this one set of artifacts are truly ready to go live. Sure, the tasks could call the same function to compile the source or run unit tests, so it was effectively the same, but there could have been slight differences where the assemblies produced from the commit build were slightly different than those in the push build.

I also like how they mention getting automation in your project from day one if you’re lucky enough to work on a green-field app. I’ve worked on production deployment scripts for legacy apps and for ones that weren’t production yet, but still a year or so old. The newer an app is and the less baggage it has, the easier it is to get started, and getting started is the hardest part. Once you have a script that just compiles and copies files, you’re 90% of the way there. You can tweak things and add rollback functionality later, but the meat of what’s needed is there.

However you slice it, you have to automate your deployments. If you’re still copying files out by hand, you’re flat out doing it wrong. In the age of PowerShell, there’s really no excuse to not automate your line of business app deployment. The faster deliveries, more transparency, and increased confidence that automation gives you can only lead to one place: the pit of success, and that’s a good place to be.

I’ve been at Synergy Data Systems for over 7 years now (I know, the site is horrible). I’ve worked with a lot of great people on some very interesting projects, and learned a boat load during that time. Unfortunately, they can’t offer the one thing my wife and I wanted: living abroad.

To that end, we’re moving to London and I’ll be starting at 7digital in early January. I’m super excited about both moves. 7digital seems like a great company working with a lot of principals and practices that are near and dear to me, and c’mon, it’s London. For two people that grew up in small town Ohio, this’ll be quite the adventure!

I’m looking forward to getting involved in the huge developer community over there, playing with new technologies, and working with fellow craftsmen!

If you install GitExtensions, up through the current 2.24 version (which comes bundled with the latest msysgit version 1.7.6-preview20110708), and use OpenSSH for your authentication (as opposed to Plink), you’ll likely notice some painfully slow cloning speeds. Like 1MB/sec on a 100Mb network kinda slow.

Thankfully, it’s a pretty easy fix. Apparently msysgit still comes bundled with an ancient version of OpenSSH:

$ ssh -V
OpenSSH_4.6p1, OpenSSL 0.9.8e 23 Feb 2007

Until they get it updated, it’s easy to do yourself. Simply install the latest version of Cygwin, and make sure to search for and install OpenSSH on the package screen. Then go into the /bin directory of where you installed Cygwin, and copy the following files into C:\Program Files\Git\bin (or Program Files (x86) if you’re on 64-bit):

• cygcrypto-0.9.8.dll
• cyggcc_s-1.dll
• cygssp-0.dll
• cygwin1.dll
• cygz.dll
• ssh.exe
• ssh-add.exe
• ssh-agent.exe
• ssh-keygen.exe
• ssh-keyscan.exe

Checking the OpenSSH version should yield something a bit higher now:

$ ssh -V
OpenSSH_5.8p1, OpenSSL 0.9.8r 8 Feb 2011

Your clone speeds should be faster too. This upgrade bumped ours from literally around 1MB/sec to a bit over 10MB/sec. Nice.

When I first read about TDD and saw all the super simple examples that litter the inter-tubes, like the calculator that does nothing but add and subtract, I thought the whole thing was pretty stupid and it’s approach to development was too naive. Thankfully I didn’t write the practice off - I started trying it, plugging away here and there. One thing I eventually figured out was that TDD is a lot like math. You start out easy (addition/subtraction), and continue building on those fundamentals as you get used to it.

So my suggestion to those starting down the TDD path is: don’t brush it off. Start simple. Do the simple calculator, the stack, or the bowling game. Don’t start thinking about how to mix in databases, UI’s, web servers, and all that other crud with the tests. Yes, these examples are easy, and yes they ignore a lot of stuff you need to use in your daily job, but that’s sort of the point. They’ll seem weird and contrived at first, but that’s OK. It serves a very real purpose. TDD has been around for a good while now, it’s not some fad that’s going away. People use it and get real value out of it.

The basic practice examples getting you used to the TDD flow - red, green, refactor. That’s the whole point of things like kata’s. Convert that flow into muscle memory. Get it ingrained in your brain, so when you start learning the more advanced practices (DIP, IoC containers, mocking, etc), you’ll just be building on that same basic flow. Write a failing test, make it pass, clean up. You don’t want to abandon that once you start learning more and going faster.

It seems everyone gets the red-green-refactor part down when they’re doing the simple examples, but forget it once they start working on production code. Sure, you don’t always know what your code is going to do or look like, but that’s why we have the tests. If you can’t even begin to imagine how your tests will work, write some throw away spike code. Get it working functionally, then delete it all and start again using TDD. You’ll be surprised how it changes.

Good luck with your journey. If you’re in the Canton area, don’t forget to check out the monthly Canton Software Craftsmanship meetup. There’s experienced people there that are eager to help you out.

There, I said it. Actually, I’m kind of worried that title won’t adequately state the intensity of this situation.

This is one of the fundamental reasons we have source control people, so we can go back through a file’s history and see the different revisions. Please, for the love of all that is holy, don’t comment out old code. Just delete it! Feel free to slap your own knuckles with a ruler if you start to think about commenting it. Don’t try to recreate a source control system through commented out code. Everyone knows exactly what I’m talking about:

1
2
3
4
5
6
7
8
9

// John Doe - 7/5/2011 - Changed to allow a higher limit.
// dozens of lines of old code....
 
// John Doe - 7/18/2011 - Changed algorithm slightly.
// dozens of lines of old code....
 
// random dozen lines of old code with no comment at all
 
public void ActualCode() { }

Those extra comment chunks are just crap to sift through to get to the real code, extra stuff you’ll have to parse to see if it’s relevant to the current situation, and creating more false-positives for ReSharper (and I’m guessing other refactoring tools) to pick up when you rename a variable/method that’s used inside those commented chunks. That chunk of old code at the bottom without even a hint as to why it’s commented out? That’s the worst of the worst - someone’s going to sit there and stare at it for a good while before they figure out why it was commented out, and we know when the author actually committed this file with that commented out the commit comment was blank too. Awesome.

So anyway, just remember what actually happens the next time you’re about to comment out old code and don’t do it, you’ll be doing future programers (and more than likely yourself) a huge service…

So we all know the default alert dialog box visually sucks. Any of the hundreds of jQuery modal plugins work wonderfully for replacing it with something a bit snazzier (although putting the information on the page for a user is even better, but that’s for another post). The biggest problem with most of those dialogs are either the setup cost, or the memory cost:

• Setup cost: having to set heights, widths, button names, text & title fields, yada, yada, yada. A lot of that can be skinned through CSS, and a lot of plugins reduce that noise to virtually nil, but many leave a lot on your pages. It’s ugly to look at in your code, and ugly to configure. Not to mention all those config settings spreads through your code base like the freakin’ ground ivy is spreading through my lawn as I type this. Want to change the widths for a new redesign, or localize the button names? Good luck!
• Memory cost: relates to the Pit of Success. Do you really want the burden of always remembering to use that modal dialog instead of alert? What about the new guy, is he going to know or remember? Sure, forgetting isn’t that big of a deal, but given enough slip ups and your nice consistent UI goes to hell. Tests checking for calls to alert are also possible via straight searching through files or through UI tests some how, but I can see a future of false positives ahead of that idea.

How about a better way? With some very slight Javascript-foo, you can override the default alert and confirm dialogs so not only is there nothing to copy & paste between pages, but you don’t even have to remember to use your nifty modal boxes - it’ll just happen. We’ll use the jQuery UI Dialog plugin inside a stock ASP.NET MVC app, though this is easily transferable to any other platform or with any other modal plugin.

First we’ll override the default alert method on the window object, calling the dialog function from jQuery UI and setting some default parameters:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

window.alert = function (message) {
	$("#dialog")
	.html("")
	.html('<span class="ui-icon ui-icon-alert custom-ui-icon"></span>' + message)
	.dialog({
		autoOpen: true,
		resizable: false,
		height: 200,
		width: 350,
		title: "Alert!",
		modal: true,
		buttons: {
			"OK": function () {
				$(this).dialog("close");
				return;
			}
		}
	});
};
 
alert("Error!!!");

The HTML is cleared out and a default alert icon (from jQueryUI) is added via the class attribute ui-icon-alert. This allows us to create a standard <div id="dialog"></div> in our master page with nothing inside it, and reuse it for alert/confirm/prompt boxes. Then a standard alert call, like the one at the bottom, gives us:

Similarly, we can override the default confirmation box. Here’s a version that’ll take the title, a message to show, and a callback function to execute if the user clicks “OK”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

window.confirm = function(title, confirmMessage, successCallback) {
	$("#dialog")
		.html("")
		.html('<span class="ui-icon ui-icon-help custom-ui-icon"></span>' + confirmMessage)
		.dialog({
				autoOpen: true,
				resizable: false,
				height: 200,
				width: 350,
				title: title,
				modal: true,
				buttons: {
					"Yes": function() {
						$(this).dialog("close");
						successCallback();
						return;
					},
					"No": function() {
						$(this).dialog("close");
						return;
					}
				}
			});
};
 
confirm("Are you sure?", "Are you sure you want to create a confirm?", function() { alert("Sweet, all done!"); });

Again, compare the results (the first question mark is an icon from jQuery UI, which can also be changed with the class written out in the confirm method above):

Pretty neat, if you ask me. This whole thing is very DRY, as everything you need is referenced in your master page (the dialog div, the javascript & css files, etc) and your individual pages don’t need to include anything - just call away. You also don’t have to remember to call special methods (or at least terribly special ones in confirm’s case). It just works.

It’s not too hard to imagine extending this system to override the default prompt box either. Just pass in a callback that’ll set whatever string you need, similar to how confirm works above. Closures work wonders.

You can grab the code used in this post right here.

I’m a huge believer in the Pit of Success. Quite a few have written about it before, though not always in development terms. Put simply, there’s two pits you can create in your application through conventions, infrastructure, culture, tools, etc: success and failure. I obviously choose the former.

The Pit of Success is when you and the other developers on your team have to think less about the mundane stuff and when there’s only one easy development path to follow. Less thinking about crap = more thinking about business problems = faster software with less bugs. In general, if I see something that’s going to be in a lot of classes/pages and it has a decent bit of setup and baggage for it, I instantly picture another developer forgetting to bring all that along when they start new features or refactor. If things break (visually or programatically) when that happens, there’s a problem. Same goes for huge chunks of documentation explaining how to use a certain feature elsewhere in the system - time to make it easier to use! Here’s a few examples of how we’ve dug out a Pit of Success on our current project:

• Need to create a new schedule task? Drop in a class and implement a simple interface. That same principal goes for a slew of other areas - missing information checks for users, HTTP handlers, sample data for geographic areas, etc. You don’t have to go hunting down a master class to add these new things to, just create the class and you’re golden.
• Security in our system isn’t that complex yet, so we’re able to consolidate everything in a nice tidy ActionFilter. It’s applied to our custom controller, and we have a unit test that makes sure all Controllers in the system inherit from that custom one. So by following the rules (on your own or with the help of a broken test), you get security handled for you auto-magically.
• We continuously deploy with our build server, so it takes care of not only making sure all our unit/integration tests pass, but that all the needed debug settings are flipped, sites are pre-compiled, everything still works once it’s live, etc. That saves us from remembering to do all that every time we push live, which is almost constantly these days.
• We completely agree with Chad Myers, Jeremy Miller, et al: if we’re working with a static language, make the best of it. Everything in our system is strongly typed, from text box ids in HTML/Javascript/UI tests to URLs and help points. You shouldn’t have to remember to go hunting and pecking through the whole system when you want to rename something, just rename it with ReSharper and move on. Same with finding where something is being referenced. The harder it is to rename things, the less they get renamed, and the crustier the system gets.
• We started creating one off modal dialogs to present information to the user. They looked great, but needed a lot of baggage and duplication to do it, so we overrode the default alert and confirm dialogs with our modal ones. Now there’s not only nothing to add to your page to get this, but in most cases you don’t even have to remember we’re overriding it! There’s a forthcoming post that’ll cover what we did in more detail.
• We have a unit test that’ll scan through all of our test files (which end with *Fixture), and make sure there’s a file name that matches (sans the Fixture part) in the corresponding directory structure in the main assembly. We constantly move files around when refactoring, and forgetting to move or rename their test files is a pain, so this test gently reminds us. Note we don’t always follow a one-class-per-fixture setup, but even when we don’t, we stick them in a matching fixture class for easy grouping and ReSharper discoverability.

It’s worth noting we didn’t set out from day one to build all this stuff. Its all grown over time as the project and our stakeholder’s needs have changed. We always strive to keep KISS in mind (even if it is hard) and not build anything until it’s absolutely needed. Don’t try to create infrastructure to handle everything for you when a project’s in its infancy. Harvest it out later.

There’s also exceptions to all of these rules. Is automatic security always the right thing to do? No - if you need highly configurable security, put it out in the open and remember to set it on each request. Don’t force things into the infrastructure if they’re fighting you and have lots of exception cases. Perhaps there’s another route of attack that’ll solve the problem and still keep you circling around the Pit of Success.

You’ll create your own Pit of Success on your project just by falling into the bigger Pit of Success that is the SOLID principals. The majority of the examples up there were arrived at by just adhering to the Open/Closed Principal or the Single Responsibility Principal. They create a sort of recursive pit, I suppose.

What have you done on your projects to help create a Pit of Success?

Just a quick reminder about the next Canton Software Craftsmanship meeting on June 6th. It’s the usual 6pm at Stark State College with free pizza and drinks, and sponsored by Synergy Data Systems this month (who’s coincidentally looking for another junior C# developer, if you’re interested). Asher McCune will be giving a talk on the Open/Closed Principle (the O in SOLID) and we’ll be doing more katas together, trying to push the pairing aspect and getting everyone to work with different partners.

Hope everyone can make it! Please don’t forget to register right here so we have a head count for pizza.

I added a page listing a bunch of code katas, mostly for my own reference, but I guess you guys can mooch off of it too.

Let me know if I’m missing any. I’ll expand the page as I stumble across more.

I went with a few co-workers to Stir Trek this past Friday. They’ve put an event on for the past two years, but this was the first one I’ve been to. It was an excellent event. Good talks, very well planned out, and a pretty decent movie to boot! Here’s the talks I went to:

• Are You Satisfied With Your Tests? (Jim Weirich) - Jim gave a good overview of testing (do it, make them fast, etc.) and tips (clear naming, refactoring, when to combine/split tests, etc.). Overall pretty good. My co-workers gave a laugh as I harp on many of these points all the time already.
• Node.js - Show and Tell (Leon Gersing) - A neat explanation of this async javascript framework. Leon gave a demo of a simple client/server chat setup, and a run down of a slightly more advanced website. I hadn’t seen any Node.js stuff other than very broad overview articles, so it was cool to get the explanation of when/where to use it, and look at working examples. Unfortunately he ran out of time before getting to the testing examples, but I guess that give me a place to start in my personal learning.
• Testable Object-Oriented JavaScript (Jon Kruger) - One of the better talks I attended, as it tilted more towards the intermediate/advanced level than others. Jon walked through a live demo of building out a simple Twitter client by test-driving the javascript with Jasmine to run the tests, and his custom JS View framework to fake out the HTML. Pretty darn neat, and I’m looking forward to digging into it a bit more for our new features, as they’ll be far more client-side dependent than previous ones, and we haven’t gotten to the UI part just yet.
• Getting Started with User Research: DIY Quick Course (Carol Smith) - Carol went over the basics of user research via interviews, observance, and card sorting, which helps you structure you application’s layout to match how users would expect it to be. Very helpful for a high-level overview talk, and gave me a few tips to pursue with getting information on our application.
• Testing Web Applications with Selenium (Jim Holmes) - I was definitely looking forward to this talk the most, and it didn’t disappoint. We use Watin at work and have only dabbled once in Selenium, so seeing how he structures his tests was helpful. Unfortunately he spent 80% of the time going over a basic UI test and overview of Selenium. By time he got to the lessons he’s learned from running 14,000 some-odd UI tests, he ran out of time. Booo. It was actually quite comical… “OK, now the most important things you need to know… I’m out of time, aren’t I?”. A few of the database/browser handling tips will come in handy for our UI test suite though, and I’m looking forward to giving them a shot.

I really wanted to hit up the GitHub talk, executable requirements, and a mobile talk or two, but I guess there’s always next year. Overall it was an excellent conference, and the peeps that ran it did a great job. Thor itself turned out to be pretty decent flick, too.

They already scheduled next year’s version in May: StirTrek Avenger’s Edition. Looking forward to it!