Why software projects die


Great post over at sourcemaking.com today, 40 Reasons Why Software Projects Die. One recent job I had suffered from many of these AntiPatterns, specifically

  1. Death by Planning
  2. Design by Committee
  3. Irrational Management
  4. Cover Your Assets
  5. Project Mismanagement
  6. Lava Flow
  7. Mushroom Management

and so many more… it’s a great list and a good read if only so you can recognize these success-killers and avoid them.

Testimony Part V: What’s in a Name?


Last time, I promised that we’d make our testimonial application more friendly for users and less so for spammers and that’s what we’re going to do today, among other things of course. Let’s get’r done!

Somehow, we overlooked the user’s name when we created the schema for the testimonial leaving us only the email address to use as an attribution. Fortunately Rails’ migrations makes it trivial to add the new field. Drop into the shell and generate a migration:

script/generate migration AddUserName
     create  db/migrate
     create  db/migrate/004_add_user_name.rb
end

Open that in your editor, and make it look like the following. I think 64 characters is long enough to hold a name for this app.

class AddUserName < ActiveRecord::Migration
  def self.up
    add_column :testimonials, :name, :string, :limit => 64
  end  
	
  def self.down
    remove_column :testimonials, :name
  end
end

Alright, now we’ve added a place to store the user’s name.; we’ll let ActiveRecord handle the CRUD for us but it’s still our task to ask the user to enter their name. To that end, we need to edit the form that is used to edit a testimonial. We factored that out of the add view into a partial named _form.rhtml. Let’s ask for our customer’s name before we ask them to give up their email address, that seems more neighborly, don’t you think? At the top of the form, add the following:


 Read more…

Application Configuration


While working on the Testimonial application, I needed a way to store application specific configuration details — the parts that are specific to a deployment: site name, url, etc. A quick search turned up the ApplicationConfiguration plugin which does exactly that, using YAML. It’s based on the technique described by Dmytro Shtefluk and uses OpenStruct to parse the config file and supports RAILS_ENV specific settings.Borrowing Dmytryo’s example:

common:
  support_email: admin@myhost.com
  root_url: myhost.com
  photos_max_number: 6
	
production:
  email_exceptions: true
	
development:
  root_url: localhost:3000
  photos_max_number: 10

In your application, it’s pretty simple to get at these values. Each value specified is stored as a member in the ::AppConfig structure:

AppConfig.photos_max_number
AppConfig.email_exceptions

I did run into one problem using the plugin; it uses config as the name of the structure, which conflicts with Rails, or some other gem that I’m using. I edited the plugin source and changed the name of the struct to AppConfig and now I’m happily keeping my configuration data DRY.

Thinking in code


I was reading the Pickaxe book today, brushing up on my Ruby skills and came across a passage that had me thinking about how our approach to programming affects our job and career. It started simply enough, explaining Ruby boolean expressions

Ruby has a simple definition of truth. Any value that is not nil or the constant false is true.

But then it got worse:

However, C, C++ and Perl programmers sometimes fall into a trap. The number zero is not interpreted as a false value. Neither is a zero-length string. This can be a tough habit to break.

Read more…

Rails 2.0: It’s here!


Those guys over at 37signals have done it again and given us a nice shiny present for Christmas: Rails 2.0! Head on over to the Ruby On Rails weblog for the full details. The big feature for me is the debugger… it’s back! It’s just a

        gem install ruby_debug

away! I’ll be covering how to upgrade the testimonial project to Rails 2.0 in the coming days.