The first option is to create individual methods that delegate to the instance variable. This option is probably the easiest to understand, but verbose. We can do better.

Another option is to use Ruby’s method missing. I really liked this option, but it felt too much like black magic, and it didn’t leave me with any control of the methods that are being implemented.

How it works: By overriding method missing, we can check to see if our instance variable responds to the method trying to be invoked. If not, we simply call the super. If it does, great, invoke the method via send by passing the method name and params.

The last option, and the one that I chose, is to use Active Support’s built in delegate method. While not as cool as method missing, this option lets me control which methods are being exposed. Implementing this is also pretty easy to comprehend.

How it works: Under the covers, the delegate method works in a similar fashion to the method missing option. When called, the delegate method writes out a function(using the send method to pass the parms and a block, to whatever the value of the :to key is in the options hash) and then evaluates the new function with Ruby’s module_eval. You can view the full implementation details here (hooray open source!).

Enjoy!

Let me start by saying, 2009 was one hell of a year. It was full of some incredibly high points, and one terribly low point.

• My first framework

  This year saw the 1.0 release of the first framework I’ve ever participated in developing. Since it’s proprietary, very few of you will ever use it, however, it was a great experience. It was my first real experience using design patterns in a way that they were actually useful.

• Death March

  This spring was also the wrap up of the death march project from hell. The project was riddled with months of wasted time, poor planning, unrealistic timelines, and a real lack of communication.

  The project ended up being ~20 days behind, which is something I consider a slight miracle all things considered. The real tragedy was that the finished program wasn’t what the business had envisioned, which resulted in 3 additional iterations and, even worse, my manager was demoted due to the project’s failure. That’s something that still pisses me off when I think about it.

  I came out of the experience learning three key things:

  1. Waterfall methodology doesn’t work at all
  2. Large corporate IT departments just aren’t my cup of tea
  3. I needed a new job
• Apprenticeship

  After the death project, I started taking a serious look at other job opportunities, which led to this tweet. That tweet triggered the events leading up to my apprenticeship. Epic win.

• Eau Claire Ruby

  While I’m no longer an active member, it was fun helping the group get up and running. It’s awesome to know that the group is still growing, and may even put on an event soon. If you’re in the Eau Claire area, make sure to check them out.

2010 Goals

I’m a believer that making goals public ends up have a net benefit. So here are mine:

• Ignitious

  The goal is to have some sort of launch by February 1st and have at least one paying customer by the end of the year. One paying customer will let me know that it solves a problem for at least one person or group. That’s a win in my book.

• Continuous Learning

  I have very little experience in front-end design and development. In an effort to change that, I will be attempting to do all of the UX design and development for Ignitious.

• Ruby (on Rails)

  It seems everyday I learn of some new helper method in Rails, or a feature of Ruby that I didn’t know about. That shit has to end.

• Public Speaking

  I will speak to at least one user group or code camp this year. Public speaking is something I’ve struggled with, so this will be a milestone.

• Publication

  In my attempt to become a better writer, I will write at least one article for Rails Magazine (or some other publication), as well as continuing to write more frequently here.

• Reading

  My girlfriend keeps nagging me to read more fiction novels (I only read 2 in 2009). So while not a technical goal, this year I’ll try and read 6.

So that’s my year in a nutshell and my goals for next year.
How was your year?
What are your goals?

class Commit < ActiveRecord::Base
  has_many :files, :class_name => 'CommitFile'
  has_many :added_files, :class_name => 'CommitFile', :conditions => {:state => 'added'}
  has_many :removed_files, :class_name => 'CommitFile', :conditions => {:state => 'removed'}
  has_many :modified_files, :class_name => 'CommitFile', :conditions => {:state => 'modified'}
end

class CommitFile < ActiveRecord::Base
  belongs_to :commit
end

'Created new records like this:'
Commit.files.create(:name => 'foo', :state => 'added')

Then I realized, using named scopes, I could move all state logic into the CommitFile class like so:

class Commit < ActiveRecord::Base
  has_many :files, :class_name => 'CommitFile'
end

class CommitFile < ActiveRecord::Base
  belongs_to :commit
  named_scope :added, :conditions => {:state => 'added'}, :order => 'filename'
  named_scope :removed, :conditions => {:state => 'removed'}, :order => 'filename'
  named_scope :modified, :conditions => {:state => 'modified'}, :order => 'filename'
end

'Create new records like this:'
Commit.files.added.new(:name => 'foo')

That’s it! The Commit class no longer cares about the implementation of the status logic. It’s a subtle change, but one that I think will help with future refactorings.

This is part of a series on my apprenticeship at Obtiva. The full series can be found here.

A major part of Obtiva’s Apprenticeship program is the pet project. So for my project, I’ve decided to develop an online code review tool. This is an app that I’ve wanted to write for awhile now, so I’m thrilled to have the opportunity to do so.

Ignitious(ig-nish-us) is an opinionated tool with a couple of goals in mind:

• Dead simple to use – I’ve made some assumptions on how I think code reviews should be done, this helps trim down on required clicks to do some tasks.
• Go from signup to reviewing code as quickly as possible – Just register with a username and password and you’re ready to start reviewing code. Doesn’t get any easier than that!
• Complete Github integration – Uses your Github username to pull available repositories. Commit code and a review is created automatically by utilizing Github’s post receive hook.
• Free for open source – In the spirit of giving back, any public repository on Github is able to be imported into Ignitious.

My goal is to launch a beta on February 1st, so if you would like to be kept in the loop, sign up at ignitious.com.

This is part of a series on my apprenticeship at Obtiva. The full series can be found here.

Earlier this week I sat down with Todd Webb to discuss my pet project (more on that soon). He put me through a process Obtiva calls “Solutions Discovery”. This is the third time I have been present in this process, the first two with clients. I really like this process, I have a feeling past projects would have been significantly easier following something like this.

During a Solutions Discovery, Obtiva gets together with a client, over the course of anywhere from half a day to a couple of days, and helps the client define what their business goals are, who their users are, stories for possible iterations, etc.

Simple Tools
The process uses very simple tools that anyone can pick up and start using. A marker board is used to draw and explain ideas that words may have a hard time with. Index cards are used to define business goals, user stories, etc. The best part of the index card? It’s an index card! If it needs to be reprioritized, move it. If it doesn’t make sense anymore, rip it up.

Business Goals
Index cards are used to define what the client considers business goals. These are then prioritized according to what the client considers important. I think these can do a really good job of preventing feature creep. When planning an iteration, it helps guide the client to only including the features that matter to the business goal that is being tackled. For instance, AJAX effects may be shiny and cool, but will they help you generate revenue?

Personas
Personas are used to describe anyone who the client expects to interact with the product. They list the whys and the hows of the interaction, and are then prioritized. This creates a common language for the client and Obtiva to communicate. Instead of referring to a faceless support analyst, we can say “Sally Support”, and everyone in the meeting knows exactly what type of user we are talking about. These also help during iteration planning. If it comes down to picking one feature over the other, the client can simply pick the one that satisfies the persona that is prioritized higher.

User Stories
Index cards are used to define user stories for the different personas. Together, Obtiva and the client list out all of the different ways that a persona would want to interact with the product. During the process, the index cards can be reprioritized and moved around depending on what new scenarios are uncovered in the process.

Once everything is layout out, work begins on reaching a minimum viable product, or in other words, what is the minimum that the product has to do before someone will use it. Stories are stripped out, into what will later be another iteration, until that minimum product is reached. It’s really amazing how a giant list of 30 ‘need to haves’ can be dwindled down to just a few.

There are a couple of other things that may happen during a Solutions Discovery, like legacy code reviews. However, this is the meat and potatoes of why I like the process so far.

Here is the, very blurry, result of my Solutions Discovery. Business goals are the pink cards on the right. The top cards are stories that will be included in the first release, and the stories pulled to the bottom will be scheduled in subsequent releases.

This is part of a series on my apprenticeship at Obtiva. The full series can be found here.

Over the last couple of days, I’ve managed to get my hands a little dirty with some client work. I paired with Sean Iams to add a CSV parser into a client’s rails application. I’ve pair programmed at previous jobs before, but never as productive as this.

Previously, one person would usually be doing all of the coding while the other tried to look at the total scope of what needed to be done. This works well in theory, but I’ve found that the other person usually degrades to a human compiler/spell checker after awhile, or worse, stops paying attention all together.

Figure 1

However, I don’t think that’s entirely the fault of the developers. In a lot of programming environments, each developer is conveniently packed into a cubicle. So, just let me just say something about cubicles:

Cubicles suck, but they really suck for pair programming.

With a cubicle, your environment dictates how you code. As you can see by my highly technical diagram to the left, pair programming in a cubicle forces one person to literally take a step back. How can you be actively involved in collaborating on code if you have to peer over someones shoulder to even see? I just doesn’t work.

At the Obtiva Studio, we all sit a together (no half walls or any of that garbage) at long, wide desks. Perfect for pair programming. Sean and I were both unfamiliar with the application, so we both needed to be looking at real code, figuring things out. Our environment didn’t dictate that this is how it should be done, but it allowed us to do so.

In the end we were able to add this functionality in just a couple of days, much less time than it would have taken me by myself. Since Sean has a lot more experience with Textmate and OSX, I also got the side benefit of learning several keyboard shortcuts that I wouldn’t have picked up on in the “sit back and dink around” cubicle approach.

I’m looking forward to more of this in the future.

This is part of a series on my apprenticeship at Obtiva. The full series can be found here.

Apprenticeship?

I suppose I should start by explaining what this apprenticeship is all about, so let’s start from the beginning…

I had a relatively stable job, people looked to me for ideas and advice, my opinion was respected. And therein lies the problem, I was quickly becoming king (well maybe not king, but higher royalty) of the hill, but I didn’t feel like I should be at that level. And worse yet, I was starting to stagnate in my personal learning.

So I did something that some said was foolish, I left that position to take on the role as a software apprentice. A role that places me at the bottom of the proverbial hill, where I am, by leaps and bounds, the worst.

I couldn’t be happier.

Over the next six months, I’ll be working at Obtiva as a software apprentice. Obtiva’s apprenticeship program takes people who are passionate about software development, someone with lots of potential, but not a whole lot of marketable skills, and guides them into being a software craftsman.

Here’s an excerpt from Obtiva’s website:

Joining Obtiva as a Software Apprentice means that you’ll be working shoulder-to-shoulder with experienced Obtiva craftsmen on exciting client projects. A successful apprentice is focused, passionate and hungry for knowledge. Our apprenticeship program has proven that our one-on-one teaching, directed study, and client projects leads to rapid growth in the skills and abilities of our apprentices.

The end goal of this apprenticeship is to prove that I have what it takes to be a consultant at Obtiva. Which, judging from the massive amount of talent they have acquired, I’ll have my hands full. I’ll be working on a variety of things over the next 6 months to get to that point, but there will be an overall pet project that will be used to asses my growth as a developer. Over the next couple of days I plan to iron out the details of this project, I’ll be sure to post when that is finalized.

Change in Culture

One of the things that has been the hardest to get acclimated to, is the change in culture. I went from a company that employed thousands of people in all different business aspects, software just happened to be something that needed to be done, much like accounting and janitorial duties. Don’t get me wrong, I learned an incredible amount during my time there, but it did leave me wanting more from my place of employment. Transitioning into a small agile company that not only lives off the software they develop, but is also deeply passionate about it, has been refreshing so far.

One major cultural difference I noted, happens to be something rather insignificant. At my previous employer, I couldn’t take a piss or get a drink of water without punching out, so you can imagine my shock when I learned that Obtiva provides soda(!). It’s the little things like that which tell employees, “Hey, you’re a real person, not just a code producing blob that sits in a chair”.

I’m sure this is a topic that I will revisit a lot over the next six months. I’ve always found the ways employers treat their employees and general office culture a fascinating thing to write about.

Moving Forward

After writing this post, I’ve come to the realization that weekly installments may not work as nicely as I thought. There’s just too many topics to write about. Writing about a whole week leaves the post feeling strained and unorganized. In the future I’ll probably do several posts with specific topics in mind.

Hardware

• HP dv2000 Laptop – $500 Best Buy open box haggle special
  • 15.4 inch screen
  • AMD Turion 64 X2 1.9 GHz
  • 120 GB HDD
  • 3 GB RAM
• 22″ Acer LCD Monitor – woot.com is your friend
• Microsoft wireless laptop mouse

Software

• Ubuntu – This is my primary operating system. A little bloated, but until #! Linux matures a bit, it will do
• Windows Vista – I don’t care what you all say, I’ve never had a problem with Vista
• Redcar – Redcar aims to be a Textmate like editor for Ubuntu. It’s got a lot of growing up to do, but I’m liking it so far
• Visual Studio 2008 – For those times that I need to do some C# work while in Windows, it can’t be beat
• MonoDevelop – This one is new to my arsenal, but the more time I spend in it, the more I enjoy it
• Firefox – The one area that I’m not a minimalist. I couldn’t live without my hundreds of extensions

Hosting

• ZenSix – Dirt cheap hosting for static web sites
• SliceHost – Great VPS providers with a ton of tutorials for setting up a server (I need all the help I can get in that area)

As you can see, my hardware setup is very minimal. I would say 70% of the time I don’t even have my external monitor or wireless mouse hooked up. I love the flexibility this gives me. It’s no longer a hassle to go down to the local coffee house to work, just grab the laptop and go. Downtime waiting for a plane? No problem, just pull out the laptop and it’s the same as if I were at home.

Granted this setup isn’t for everyone, but I think it will be awhile before I find the need for a desktop again.

I just finished reading The Passionate Programmer*, and it is already one of my favorite programming books. The Passionate Programmer is a great set of guidelines that is a must read for anyone looking to cultivate an awesome career in software development.

While I was pleasantly surprised to see that most of the guidelines described are things that I just instinctively do, it kind of shocked me that they needed to be listed at all. Things like practicing your craft and choosing what language/platform to specialize in seems like it should be common sense. With that being said, I think that Chad Fowler does an excellent job of outlining a path from turning your job into a career using a mix of real life stories (like the origin story of Github) and practical advice (like not investing entirely on one platform).

I really enjoyed the “Act on it!” sections at the end of each chapter. They provide ways to take the advice and guidelines from the chapter and apply it to your daily life almost instantly. I think this fills a gap that a lot of other books miss. Without being able to clearly see a way to apply what they’re reading to their daily lives, I think a lot of readers get lost in the warm fuzzy feeling they get when reading about how great they will be.

My only criticism is that some of the chapters do seem to be lacking, specifically the “Make Yourself a Map” chapter. The chapter explains why you should create yourself a map to the career you wish to have. The only issue is that he doesn’t explain how to create this map. Maybe it’s my lack of creativity, but I can’t envision how this map should look, so an example would have been nice.

*Yes, the Amazon link is a referral link. Any revenue generated will be used to fund various user groups, code camps and open source projects that catch my attention.