Making a Rain Barrel with Project Grow

Outside the workshop
Outside the workshop where we selected our barrel

A couple of weeks ago, my wife, Chrissy and I headed over to the Leslie Science and Nature Center in Ann Arbor, MI to take part in a workshop on building your own rain barrel. The workshop was organised by Project Grow – a private, non-profit organization supporting community gardening in the Ann Arbor area – in partnership with Maxi Container, Inc. – a local, family-owned and operated Detroit-based company.

The cost for participation in the workshop covered all the pieces in the rain barrel kit, including the barrel, brass fittings, and caulk as well as a donation towards the Leslie Science and Nature Center. The barrels used in the workshop were food-grade, having originated overseas filled with pickles, olives and other tasty morsels. Unlike their darker cousins, which are used to store solvents and other nasty chemicals, these food-safe, terracotta-colored containers are perfect for storing water that ultimately waters gardens. Their re-appropriation as rain barrels is one of several recycling kits provided by Maxi Container, which also include composters and drum stoves.

Josh Rubin tells us where the barrels came from
Josh Rubin tells us where the barrels came from

The workshop was introduced by Lucas DiGia, the Vice President of Project Grow who then handed over to Josh Rubin, the Creative Director of Maxi Container, Inc. and grandson of its founder, Max Rubin.

The back of the faucet with caulk applied
The back of the faucet with caulk applied

Josh started out with a demonstration of how to make the rain barrel, ably assisted by Lucas. Each rain barrel had been pre-drilled to provide a hole for the rain to get in at the top and another for it to get out again at the bottom. The first step was to fit a faucet in that lower hole. Caulk was applied around the back of the brass fixture where it would meet the barrel, then the faucet was inserted (with the application of a little brute force).

At this point, it was time for power tools. Even though the barrels had been pre-drilled with two holes, another hole was required for the overflow. This step had been left for us to do because its placement had to be chosen with an idea of where the rain barrel would ultimately be used. With Lucas steadying the barrel, Josh carefully drilled the third hole. The overflow fixture (suitable for attachment of any regular garden hose) was screwed into place using a wrench.

The mesh over the inlet
The mesh over the inlet

The final touch for the rain barrel was to affix a mesh over the inlet hole. This mesh not only prevents debris from entering the rain barrel but it also provides a base over which to scatter pebbles. The pebbles discourage mosquitoes from using the rain barrels for their offspring, avoiding the need for mosquito tablets to be added to the barrel.

And that was that. With Josh's demonstration over, the workshop participants were directed to complete their own rain barrels, with appropriate over sight and assistance from Josh, Lucas and the Project Grow volunteers. Chrissy and I managed to get our rain barrel completed quite quickly, barring a few arguments over who got to use the power tools. It's now sitting in the garage waiting for a sturdy base to be built for it to stand on – a full water barrel of this size will weigh over 300lbs!

Chrissy supervises while I fix the mesh in place
Chrissy supervises while I fix the mesh in place

Overall, this was a thoroughly enjoyable experience. This is in no small part due to the efforts of Project Grow and Maxi Container, Inc. I would encourage others to attend the next workshop Project Grow is considering for later in the year. If you can't make a workshop, check out the kit on Maxi Container's website. Finally, you can check out more pictures from the workshop over at Project Grow's page on Facebook.

Chrissy grinning over our new rain barrel
Chrissy grinning over our new rain barrel

Ann Arbor Day of .NET

On Saturday (29th Oct), I attended the Ann Arbor Day of .NET. I thought it would be nice to summarise what I heard. I doubt these notes on their own will be greatly useful, but I hope they act as a launch pad into deeper dives on the topics covered as well as a review of what topics were covered. There were five different tracks for the day: Cloud, Framewords & Platforms, Soft Skills, Tools and Mobile. I chose talks from the first four of these based on the talk itself, rather than the track to which it belonged (I ruled out presentations that I had seen a variation of before such as David Giard's (@DavidGiard) Introduction to Microsoft Windows Workflow and Jay R. Wren's (@jayrwren) Let's Go to C# On The iPhone, though they were excellent when I saw them).

Be A Better Developer

I started out the with Mike Wood (@mikewo) and his session, Being A Better Developer. This was a soft skills talk, meaning it was not there to show off some cool .NET feature or technology, or teach me all about C#. Instead, the focus was on what makes a great developer and what we can do to attain that status.

Mike explored the various roles that developers have to take on, the hats we have to wear. From the student learning new things everyday, to teacher imparting knowledge to those around them. From janitor—maintaining what already exists, to researcher—investigating and choosing frameworks, languages, platforms, etc. Using these roles as a foundation, we then moved on to some tips such as setting up time blocks in which to work. If the time limit is reached and the problem isn't solved, turn to someone else for help (or somewhere else, like the Internet1) to avoid thrashing and time wasting. This seems somewhat obvious and yet I'm betting that many of us don't do it as often as we should. The other tips were equally useful, obvious and often compromised in our daily development lives:

  • organize
  • prioritize
  • know your tools
  • set SMART2 goals
  • be a catalyst for change
  • be lazy…

Right, that last one is maybe a little less obvious, but the point wasn't: don't do more than you have to.

One of the best pieces of advice from this talk was to choose a good mentor. I was very fortunate when I started out my career to have several excellent mentors and I miss working with them almost every day. Even now, I imagine what they might have said in order to guide my efforts3. For an hour, Mike filled that role.

There was much more to this talk than what I've written here. This session was an excellent way to spend an hour. While much of what Mike presented could be considered commonsense, it was reassuring and also provided some new tricks for my arsenal to be deployed in any situation, not just day-to-day software development.

Things to check out after this talk


How I Learned To Love Dependency Injection

Next, on to James Bender (@jamesbender) and his presentation on how he much loves dependency injection4. This talk started out looking at the way things were and the ideas behind a loosely-coupled system; a system where each component knows as little as possible about the other components in its parent system, whether it uses the services those components provide or not. Tightly-coupled systems don't promote reuse, create brittle systems and are inherently difficult to test.

James told a compelling story, starting out with familiar concepts—a constructor that takes various interfaces through which the created object can obtain various services, the factory pattern, etc., but soon we were looking at an overview of dependency injection frameworks, what they do and how they do it.

And then, code. Code about cooking bagels. The only bad part about this was the lack of bagels to eat5. The talk moved quickly on to the various features of Ninject, an open source dependency injection framework. I would've preferred it if there was more emphasis on dependency injection, using Ninject to provide examples, rather than the "how to use Ninject" approach that was given. However, this was still very informative and laid a path towards the next part of the talk which showed how dependency injection and TDD6 go hand in hand. This in turn led to an introduction of mocking (the mock framework of choice in these examples was Rhino Mocks, but James recommended Moq for new work).

Things to check out after this talk


A Field Guide for Moving to the Cloud

We're back with Mike Wood (@mikewo) for this one. I've never done any Cloud development but I'm really interested in it and what it may do for me and the work I do, so I'm hanging a lot on this introduction (no pressure, Mike).

Mike started off with a Batman reference, tying the reason why I'm so tired (Batman: Arkham City) with the reason why I'm here. He then fired off some acronyms: IaaS, SaaS, PaaS. This is a great starting point for me as terminology is often the last refuge of miscommunication and I hate not understanding what all those acronyms and terms mean. One participant immediately asked, "What's the difference between IaaS and PaaS?" and most of us nodded, realising we didn't know either. To paraphrase, IaaS gives the most control as you're responsible for patching your OS, upgrading the frameworks, etc. PaaS manages all that for you. Mike did a great job explaining this (unlike my paraphrasing—Mike used a whiteboard and everything) and we moved on, that bit more informed and ready to learn more.

At this point, Mike gave us a run through of the Windows Azure platform, again making sure we're all talking the same language as the presentation progresses. Mike's presentation style is nice and fluid, taking questions and interruptions in his stride, and he clearly knows his topic well (Mike is an Azure MVP, after all). He walked us through the various parts of Windows Azure, Microsoft SQL Azure and Windows Azure AppFabric before we moved on to planning for our move to the Cloud.

Mike discussed identifying suitable applications for moving to the Cloud, scale of the application and the independence of scale, the services used and tight integration with loose coupling (not the first time we've heard this today but I would hope, not the first time in our careers either, otherwise, you're doing it wrong), usage patterns, latency, security and many other facets to be considered when moving to the Cloud.

The final point related to whether the move would save money or not and the importance of answering that question before making the move. This kind of information was great to see and may prove very useful when talking with project managers or business development types. Mike also pointed out using techniques like multipurpose worker roles and disposable compute instances to save as much as 50% in costs.

And then it was lunch.

Things to check out after this talk


Develop IT: Intro to PowerShell

I admit it, I have only ever used PowerShell for things that I could've done from a regular command prompt, so this talk was one I didn't want to miss. I want to know more so I can do more. I feel like PowerShell is an exclusive club for productive individuals and I'd at least like to take a look inside, so this was my opportunity. Sarah Dutkiewicz (@sadukie) was the presenter for this session, a C# MVP and co-author of Automating Microsoft Windows Server 2008 R2 with Windows PowerShell 2.0. This talk was entirely presented using PowerShell, which certainly made it stand apart from other presentations given so far today.

The initial examples given by Sarah quickly demonstrated how PowerShell provides similar behaviour to the traditional command prompt but also how it is different, providing .NET objects ( dir w* | Get-Member demonstrated how dir provides an object—very cool). We then learned all about the standard PowerShell syntax that provides an easily dicoverable set of commands (known as Cmdlets in the PowerShell world) and some useful Cmdlets like Get-Help and Out-GridView (which outputs things to its own filterable grid in a window).

Sarah continued introducing us to a variety of PowerShell concepts and features including but not limited to:

  • functions
  • modules
  • manifests
  • PowerShell ISE7
  • providers
  • aliases
  • registry interaction

My biggest takeaway is how easy it can be to work with the registry from within PowerShell (just open PowerShell and enter cd hkcu: then dir to see what I mean). Overall, a great introduction that has given me a starting point for exploring PowerShell and becoming more efficient.

Things to check out after this talk


Stone Soup or Creating a Culture of Change

For the final session of the day, I rejoined James Bender (@jamesbender). I was really looking forward to this having faced many challenges in changing culture as part of my efforts for meeting the requirements of CMMI8. This was expected by event organisers to be a popular talk and I still feel that it should have been; however, the turnout was disappointingly low. This made for a more intimate session and certainly did not detract from the informative content. James expressed that this was probably the last time he would present this talk, which is a shame as I found the anecdotes and the lessons that were drawn from them to be very insightful.

The things I've learned will definitely help me in my work and elsewhere. Things like:

  • Go for low hanging fruit
  • Don't change too much at once
  • Support the change and let it simmer
  • Don't judge
  • Know your tools
  • Only introduce changes you believe in
  • Understand the business
  • Know when to say when
  • Evangelize
  • Build a network of like-minded people
  • Be a politician
  • Be a therapist
  • Realise that it might be difficult to reach everyone
  • When all else fails, buy doughnuts
  • Be patient

There's not much more I could say about this talk that would do it justice (not that my notes have really given justice to the earlier talks), but suffice to say this presentation was very relevant to me and I am very grateful to have been able to see it.

Things to check out after this talk


To conclude, I had a great day. The organisers, sponsors and speakers deserve a huge "thank you" for setting up and supporting this event. Wandering the hallways of Washtenaw Community College, attending talks in rooms and lecture halls reminded me a little of being back at university, but the speed at which the day flew by certainly did not. It was a very informative and enjoyable way to spend the day and among the best $10 I've spent this year.


  1. Use Internet search before you ask someone. 

  2. Specific, Measurable, Achievable, Realistic/Relevant, Trackable 

  3. Besides, "Shut up, Jeff!" 

  4. An appropriate amount as allowed by law. 

  5. Mmm, bagels. 

  6. Test Driven Development 

  7. Integrated Scripting Environment 

  8. Capability-Maturity Model Integration 

Firecracker 5K 2011

11th annual Ann Arbor Firecracker 5K banner

This July 4th weekend, we headed downtown for the Firecracker 5K. Congratulations to everyone else who took part, I hope you all achieved your goals. Even though I had completed two other 5K events this year (DXA2 and the Motor City Triathlon as part of a sprint relay team), I had not managed to run the entire 5K distance (3.1 miles) since the Big House Big Heart run in October 2009*, so I had that goal in mind.

The weather was cool and breezy and the course was the same as last year, nice and flat and taking in some of the best parts of downtown Ann Arbor. With coffee helping to keep my eyes open (I'm not fully functional in the morning, especially on holiday weekends), I pinned my bib on, stretched and found my pace marker in the crowd (around 12 minutes , I was hoping).

After setting out a tad fast it was beginning to feel like I had scuppered my chances of finishing without stopping for a lovely stroll. However, with Cardiotrainer's robot voice giving me pace and distance information over the top of my music (streaming on my phone via the fantastic Audiogalaxy) I was able to focus on my goal and just over 30 minutes later, I was insanely sprinting over the finish line.

My time was 34:01.3, a personal best beating my 2009 Big House Big Heart time of 35:54.6 and my 2011 DXA2 time of 37:39.0 (it also totally blows away my time from last year's Firecracker 5K, 46:50.1). My next goal is to break 30 minutes; when and where that will be I don't yet know.

* I injured myself playing soccer with delusions of skill
† Also know as "somewhere near the back"

Humble beginnings

I saw friends do it, I saw professionals do it and I wondered, "Why don't I do it?"

Ever since I started taking part in Stack Overflow, I have been frustrated to find that sometimes, there is so much more to write than just a question, an answer or an occasional witty comment (or perhaps, more correctly, occasionally witty). Things the likes of Jon Skeet, Eric Lippert, Jeff Atwood and many other Stack Overflow participants blog about all the time, things born from hours and days spent making mistakes solving problems at home or at work, things NSFF (Not Suitable For Facebook – I like my friends just enough not to geek out in front of them like that).

But wait, there's more1

Not only did I have blog envy, but this year I started attending the Ann Arbor .NET Developers group meetings. Through AADND, not only have I met some fascinating people, but I have also learned about some fascinating things. From the .NET Micro Framework to the Windows Workflow Foundation (did you know version 4 was a complete rewrite? me neither), my mind was awash with ideas, projects and procrastination and while I tinkered with and tweeted about these things, deep down, I harboured a desire to do more and to say more. I could not contain it any longer, so here we are.

I intend to blog about anything and everything from my songwriting and recording to my DIY disasters improvisations, but mostly, I expect I will blog about programming. I hope that I'll provide some useful insight or perhaps just useful instruction so others don't have to repeat my mistakes, but most importantly, I hope that I'll learn a few things along the way.

So far in life I've been a software engineer, a strawberry picker, an ostrich farmer, a barman, a sarcastic git, a singer, a runner, a cook, an ex-pat and a gamer (sometimes several at once). I'm often amazed at the things I don't know and I'm always somewhat abstract. I saw friends do it, I saw professionals do it and I wondered, "Why don't I do it?" So I did.

Thanks for stopping by.

1it would be a short blog if there weren't