Ethical Software by Alex Bunardzic

We’ve been through a couple of quick Rails tutorials, and now’s the time to delve some more into the real-life Rails development.

Last year I became aware of the Disposable Software phenomenon. After using Rails on a couple of initial projects, I also became aware that the reality of disposable software is upon us. Today, I’m going to show you an example from my recent practice. This example will hopefully support my hunch that the age of disposable software is dawning.

Group Dynamics

As we’ve already discussed in my previous post, life consists of a never ending string of decisions. In business environment, all these decisions pertain to the group. There’s always a group of people that needs to somehow get harmonized, and often times they may need a software product to help them put everything in order and sort out any discrepancies.

The original disposable software platform is Microsoft Excel. This platform is used all over the world for cobbling up quick-and-dirty software driven systems. From soccer Moms’ flaky game schedule to the local community center Fall pottery class schedule, Excel spreadsheet are the reliable workhorses pulling the carts of social and group dynamics.

The problem with Excel spreadsheets is that they are not networked. They tend to be flaky little islands of information, with a tendency to clone themselves and then deteriorate over time. The end result is that many of these social groups end up with eighteen versions of the same schedule in eighteen different spreadsheets, and no one knows for sure which version is the correct one.

Because of that, group dynamics is much better served on the web. But web is notoriously difficult to program, and thus we haven’t seen the Excel equivalent emerge on the web.

Not until Rails emerged, that is. With Rails, it gets almost as easy to cobble up a little ‘web spreadsheet’ if you will, which will enable groups of varying sizes to synchronize their activities.

Once the group, using the tailored ‘web spreadsheet’ built in Rails, achieves its equilibrium, the ‘web spreadsheet’ can be tossed into the trash.

And because it was so easy to build that ’spreadsheet’, it also gets very easy to get rid of it. No fuss, no muss, less ballast, more elegance, everybody’s happy.

So the challenge now is to show you how you can quickly build your first easy-peasy ‘web spreadsheet’ that will let people participate in the group activity over the network, interact and share important information. And because it took you less than 30 minutes to build the goddamn thing, you won’t mind when, two days later, the thing goes to the shredder. There isn’t even any need to give it a decent burial.

Problem Domain in a Nutshell

In order to give this demo some street cred, I will describe a real life situation that happened to me recently, and how I’ve solved it using the above mentioned ‘web spreadsheet’ approach.

It all started when myself and my business partners started kicking around a brand new idea for a business venture. To cut the long story short, the group dynamics reached a problematic point, because we needed to harmonize and synchronize our brainstorming about the business domain name. Basically, all of us started thinking a mile a minute, blurting out all kinds of catchy domain names. The challenge was how to reach a collective agreement on which domain to register for the business.

It all started verbally, then migrated to email, and then it came dangerously close to reaching out for an Excel spreadsheet. At which point I knew the time has come for — wait for it — disposable software!

Ta-da! Rails entered the picture. I’ve made a lightning fast decision to whip up a quick web site (a ‘web spreadsheet’). Let’s see what decisions I’ve had to go through before I could offer this ‘web spreadsheet’ to the group.

Problem Narrative

Group of stakeholders needs to amass desired domain names and then vote on them.

Design Decisions

This was outside the technology, so I’m not going to count those decisions in. Basically, I had to decide on two abstractions: domain and vote. Domain is characterized by its name, vote is characterized by its rate (from 1 to 10), its voter (a person voting), and the optional comment.

In addition, each domain can have more than one vote associated with it. Each vote belongs to only one domain.

With this, the business analysis portion was completed. Time to move on to the implementation.

Ready, Set, Go!

As we move into implementation, let’s try and make some notes on the decisions we’ve had to make along the way.

Decision #1

First, create the workspace — I call mine disposable:

rails disposable

Decision #2

Create the disposable_development database.

Decision #3

Create model and migration scripts for the domain and vote:

ruby script/generate model domain

ruby script/generate model vote

Decision #4

Edit the 001_ create_ domains.rb script.

Define the domain entity. Specify its attributes, as defined during the business analysis (see details above).

class CreateDomains < ActiveRecord::Migration
   def self.up
      create_ table :domains do |t|
         t.column :name, :string
      end
   end

   def self.down
      drop_ table :domains
   end
end


Decision #5

Edit the 002_ create_ votes.rb script.

Define the vote entity. Specify its attributes, as defined during the business analysis (see details above). Don’t forget to associate vote with a domain by adding the domain_id attribute to it.

class CreateVotes < ActiveRecord::Migration
   def self.up
      create_ table :votes do |t|
         t.column :rating, :int
         t.column :voter, :string
         t.column :comment, :text
         t.column :domain_ id, :int
      end
   end

   def self.down
      drop_ table :votes
   end
end


Decision #6

Migrate the sucker!

rake migrate

Decision #7

Now you’re ready to generate Ajax scaffolds:

ruby script/generate ajax_scaffold domain

and

ruby script/generate ajax_scaffold vote

Decision #8

At this point, you’ll have the ability to maintain domains and votes, but you still won’t be able to link them together. In other words, when you create a vote, it will not be clear which domain is the vote for.

To remedy this, we need to tell Rails about the associations. So our decision here boils down to how to associate domains and votes. A common-sense analysis tells us that each domain may have more than one vote. At the same time, each vote belongs to its domain.

In Rails, the place where we declare these associations is the model. Edit the /app/models/domain.rb and /app/models/vote.rb, respectively.

require 'ajaxscaffold’

class Domain < ActiveRecord::Base
   has many :votes
end


require 'ajax_scaffold'


class Vote < ActiveRecord::Base
   belongs_ to :domain
end


Decision #9

Finally, we need to associate votes with domains in the view. The view is the layer responsible for rendering the information and for soliciting input from the user.

If you go to the /app/views section in your Rails workspace, you’ll see that Rails had created three folders:

1. layouts
2. domains
3. votes

You’d want to add the link to a domain to your votes views. Specifically, you should edit the /app/views/_form.rhtml partial view, and add the following division to it:

<div class="form-element">
   <label for=”vote_ domain”>Domain</label>
   <%= select ‘vote’, ‘domain_ id’, Domain.find_all.collect {|v| [ v.name, v.id ] } %>
</div>

Add the above snippet immediately after the rating division (before the voter division).

What this piece of code will do is insert a drop down menu containing all available domains for the user to choose from.

You are now ready to fire up your new web site and enter some domain names and then vote for them.

Decision Summary

Out of the 9 decisions listed above, only 3 were a bit more involved. The first important decision is to link the vote with its corresponding domain. This association was then accomplished in two places — at the table definition level (decisions #4 and #5), and at the model level (decision #8).

Finally, our ‘web spreadsheet’ needed the ability for the users to choose the domain they are voting for. We had to go into the view (in this case, into the /apps/views/votes) and modify the partial view for the form (decision #9).

In the end, we see that we haven’t spent more than 10 minutes implementing these 9 easy decisions. And yet a fairly functional, AJAX-enabled web site is waiting for its users to define domains and to vote for them. The nice thing is that this ‘web spreadsheet’ is fully networked and offers centralized management of the candidate domain names and their corresponding votes.

Demystifying Software Development

Once you get to the point where you can whip up a simple web site in approximately the same amount of time it usually takes you to create a memo or write an email, you’ll get to the realization that many software products are sort of disposable. In this case, we needed a quick ‘web spreadsheet’ that would help us go through our initial domain name proposal and the subsequent voting procedure. The lifetime of that web site was incredibly short (less than a week).

Once we’ve arrived at the most popular pick of the litter, we had absolutely no reason to hang on to that web site. We were able to send the code off to the shredder. Less code, less ballast, more sanity. That’s the promise of the disposable software.