class Essay
  include DataMapper::Resource

  property :id, Serial
  property :rating, Integer, :set => 0..5 #inline validation
  property :technical_score, Integer
  property :style_score, Integer

  # Validation for multiple properties
  validates_within :technical_score, :style_score, :set => 0..100
end

Turning of the RI and Rdoc documentation speeds up gem installs. Here, installing capistrano without docs takes about 11 seconds, whereas installing the documenation more than doubles the time to about 24 seconds.

nicks-computer-3:snap nick$ time sudo gem install capistrano --no-ri --no-rdoc
Successfully installed capistrano-2.5.10
1 gem installed

real	0m11.480s
user	0m7.262s
sys	0m0.374s
nicks-computer-3:snap nick$ time sudo gem install capistrano --ri --rdoc
Successfully installed capistrano-2.5.10
1 gem installed
Installing ri documentation for capistrano-2.5.10...
Installing RDoc documentation for capistrano-2.5.10...

real	0m23.974s
user	0m18.956s
sys	0m0.706s

If you want to turn off the documentation options, add this line to your ~/.gemrc file:

gem: --no-ri --no-rdoc

So that it looks something like this:

nicks-computer-3:snap nick$ cat ~/.gemrc
---
:bulk_threshold: 1000
:backtrace: false
gemcutter_key: XXXXX
gem: --no-ri --no-rdoc
:benchmark: false
:verbose: true
:update_sources: true
:sources:
- http://gems.rubyforge.org/
- http://gems.opscode.com

Going with the Flow

Despite my feelings that the title Dr. should be strictly reserved for those that save lives, Dr. Nic Williams does have plenty of good advice to offer (and he offers it in a nice format on his website). After having made some of the same mistakes and asked the same questions he has, I decided to try out the new and improved open-source project workflow. There are several things to be achieved from these open-source projects:

• Have fun
• Learn something new
• Share code

There are also some thing that should be avoided, less favorable outcomes:

• Write code, but don't go the full 9 yards to distribute + share it
• Spend too much time on setup/distribution
• Tie yourself down with maintaining your projects (they should set you freeeeee!)

Two great presentations can help you achieve these goals, and avoid the pitfalls. The first is a a great presentation about what an open-source project should be, what it shouldn't be, and how they can make your life better, not worse.

The next presentation is about how to quickly and effectively distribute and share your projects.

In order to get this all down, the good Dr. describes a workflow and a set of tools for each step.

• Packaging - RubyGems
• SCM - GitHub
• Continuous Integration - RunCodeRun
• Blog/Resume Integration - RunCodeRun Sexy Blog Badge

The Project

I decided to write a little ruby wrapper for the 'ddate' command, part of the 'util-linux-ng' package, that convert Georgian dates to Discordian dates. Why? Because I like it, and if you are going to pick a project to learn on, it might as well be ridiculous. I got attached enough as it was to this project, even though I don't think anybody could come up with an excuse to use Discordian dates, let alone happen to be using ruby.

Snafoos

One thing that started to bug my is the gem, class, module, and github repository names. It seems simple enough, but sometimes you are so excited to get you idea down in code that you rush through this first step. It will be around for a while, and is kind of a pain to change once you get it all set up. So take a few minutes and think about a name. One without WeIRd caps or anything that might annoy you in the future.

I also found newgem to be a little wonky. It a nice tool to have around, but I think (rightly so) it is tailored to Dr. Nic's workflows, and might not work for everybody.

Lastly, I found myself wresting with Hoe. The 'rake pacakge' task was failing if I added the Hoe require statement, and runcoderun was failing without the statement. That brings me to a little tangent. I didn't really dig into what was going on there, but this is an example of something that is unexpectedly not idempotent; you should be able to require and require and require, then run some code and everything should be fine and dandy. I'm not sure how or why requiring Hoe (when it is clearly used, anyway) would break anything, and it almost annoys me enough to find out. Almost.

Good stuff

I like RunCodeRun. It is simple continuous integration that makes sense. I also like the blog badge, although it currently looks horrible on my blog.

Stuff I'll add

Speaking of blog badges, I want to see if I can get the github projects blog badge working. Associating myself with a project is another step for creating a fully-rounded project. This badge helps integrate that step right into the existing workflow.

For learning projects, I plan on adding some non-standard notes to the README, including sections about what I learned and what would have done differently. Open source the code, and open source the learning process. Its not like I have any customers to scare away with honest comments.

As Nic Williams said, "Don't attach your self-worth to your code - your code probably isn't that good." Its true. I am a better software developer than I am a coder, and I aim to be. You can write code quite a few different ways and it all compiles down to the same thing. To me, nailing the workflow and the tools is the hard part, and the part that deserves the most attention.

Working with software, your code will always improve and you will keep learning new tricks. But too many people let their workflow and tool-set become stagnant, which can leave you further behind than knowing a few extra tricks in this language or that one.