It’s been a really fun, and exhausting six months. I’ve had the opportunity to work, and live, with a lot of really smart, awesome people. People like Ryan Briones (who I owe a lot of the success of my apprenticeship to), Joe Banks, Chad Pry and Dave Hoover all made a tremendous impact on my experience as an apprentice. Obtiva does a really good job of providing their apprentices with everything they need to be successful, surrounding them with excellent people is no exception.

I managed to accomplish quite a bit too. I developed and launched a beta of my first rails app, became way more involved with the community, will be published in Rails Magazine, worked on client projects like Madmimi and Eventwax, committed to RSpec, released some open source projects of my own, and started a user group.

To wrap up the apprenticeship, I had my final milestone on the 27th of April. It started with an overview of Ignitious, looking at the interface, talking about the features, and what I plan to do with it in the future. From there we took a look at the code, the good and the bad. We spent some time looking at the tests, and where I need to refactor some ugly code.

After that I gave a presentation on an overview of things that I’ve learned while developing Rails applications (and some things that I’ve re-learned). Going into the milestone, I wasn’t too happy with the presentation, but it went a lot better than expected. I’ll be taking the feedback I got on it, and giving it again at a future Geekfest, and maybe at a local user group as well.

Overall I thought the milestone went really well. I got some good feedback on areas that I excelled at, and more importantly the areas that need improving. Apparently I wasn’t the only one who thought it went well either, because after everything was said and done, I was made a job offer to become a Developer at Obtiva.

So, while my formal apprenticeship may be over, I realize I have a long ways before I’ll ever consider myself passed the level of apprentice. In closing, I’ll leave you with a series of tweets that got me where I am today:

This was completely wrong.

I spent a ton of time architecting how the system would manage repositories. While this feature does add business value, it isn’t unique, it offers no competitive advantage over other code review tools. My time would have been much better spent polishing the actual review process.

In hindsight, I should have only allowed for single files to be reviewed, either by uploading or copy paste. This would have let me focus on the review process, and add repositories later down the road. The application would have ended up being the same (more or less), it just would have arrived on a different path. Hindsight is always 20/20 though, right? It’s obviously too late for this product, but I think it was a very important lesson to learn first hand.

It’s far too easy to fall in love with features, blinding you to what is necessary and what is fat. Next time you find yourself spending a lot of time on a feature, ask yourself, does this add business value? Does this give me a competitive advantage? If not, skim it. You can always add the feature later in the product life cycle, but leave it out of the initial version. You’ll be better off.

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.