Desert Code Camp Recap 2009

Just got back from this year’s Desert Code Camp at Devry in Phoenix.  Overall the event was pretty good, got to meet some new people that aren’t at the usual events and listen to topics that aren’t discussed as often.  It’s also nice to have an event strictly focused on coding since I don’t believe there are very many in Phoenix, maybe I’m wrong.

Metaprogramming in Ruby

My first session was Metaprogramming in Ruby by Michael Cowden which was a really good overview of Metaprogramming in Ruby.  He covered topics such as good uses for metaprogramming, bad uses and a general overview of ruby.

I knew there was method_missing, but didn’t know there was method_added and method_removed. method_missing is the function that is called last before raising an error.  Rails uses this to hook into the dynamic finders that it has such as User.find_by_first_and_last_name and many other uses.

Forgot about this trick too, grep your method names or attributes when you are looking for something specific.

object.methods.grep().sort

Michael also brought up another method within Ruby called “undef_method” which is short for undefine method. What that function does is remove the method from the current class. But there’s more to it…

undef_method "calculate" # prevents the current class from responding to that method

In comparison to another method in Ruby called remove_method. The difference with remove_method being that you can still call that method on the current class it is just going to look to the super classes for that method. The method no longer exist in the current class but if that method exists in one of the super classes then that one will be called, in order of inheritance.

remove_method "calculate" # removes the method from the current class and then any call to that method looks at the super classes

The Secret of Easy “Full Stack” Testing with Cucumber & Webrat

Update: Clayton just posted his slides and example code from the event.

Cucumber is phenomenal, there’s no doubt about that.  It has greatly improved BDD and user story implementation with projects.  Clayton did a great job of going over some examples of typical user stories and features with Cucumber.  The key points besides the general overview out of the presentation were about the step Transforms, before/after hooks and tags.

Cucumber has before and after setup hooks that are pretty powerful since you can specify tags to specifically run before and after on.

Hooks

# run before every scenario
Before do
end
 
# run after every scenario
After do
end
 
# only run before sections tagged as "@sometag" or "@anothertag"
Before('@sometag','@anothertag') do
end
 
# only run after sections tagged as "@sometag" or "@anothertag"
After('@sometag','@anothertag') do
end

<span style="background-color: #ffffff;">Depending on your situation you might also want to check out </span><span style="font-family: Georgia, 'Times New Roman', 'Bitstream Charter', Times, serif; line-height: 19px; white-space: normal; font-size: 13px; background-color: #ffffff;"><a href="http://wiki.github.com/aslakhellesoy/cucumber/background" target="_blank">background</a> instead of before and after hooks.  Another option too is to use nested user steps which setup a set of steps for a typical chain of actions.</span>

Scrum 101 and Scrum Artifacts

Scrum is a development life cycle process, just like Waterfall is a development life cycle process. There is a huge difference between the two. The Waterfall process involves gathering all of the requirements and doing everything all at once, no user feedback along the way and just hoping that the end product is close to the customers requirements, ick. Scrum focuses on communication amongst key stakeholders within the project, short release cycles, and tons of feedback.

Ken Ward taught three different talks today, the first two being the exact same(intro), the third one focusing on burndown charts and velocity or in normal terms “amount of work complete and throughput of work”. Although thankfully Chris Conrey was there to provide some more insight at a few times throughout the presentation since some subjects were a little fuzzy or done a very archaic way.

Scrum is a heavily covered topic so this is just a brief overview of the session.

The process

Everything that needs to be done for the project is put into the product backlog. A sprint is an iteration of development, sprints can range in time from a week to about 3 weeks at the most.  It’s important to keep the sprints short, Scrum is all about constant feedback and being able to show production ready code along the way.  Instead of just the complete application at the end.  Items are taken out of the product backlog and put into a sprint backlog, this backlog is what will be processed while going through the sprint. Repeat the process and adjust as needed.

The meetings

• product backlog planning – stakeholders and team involved. Define the goal, define the next sprint goal.
• sprint backlog planning – Product owner and team. Team decides which tasks/items will go into the next sprint
• daily scrum standup – no sitting. Each day, same time, same place. What have you done since the last scrum? What are you doing for the next scrum? What is preventing you from doing your work? Not a status meeting, a communication meeting among your team members.
• sprint review – show what was completed during the sprint, show it to stakeholders and owner. Determine if sprint goal was acheived, if not put items back into the backlog.
• retrospective – What went well during this sprint? Bad? Improvements?

3 roles

• Product Owner – key stakeholder, impress this guy.
• Team – a mix of developers, testers, and UI. Depends on the project what your mix is though. The team should always work together in the same room.
• Scrummaster – no control, no command, more of a facilitator. Conducts and runs meetings. Finds solutions to any problems the team is having.

Key objectives

• short release cycles with a usable, shippable product at the end of each cycle.
• communication & feedback are crucial