Mister Bleigh

In the 37signals book Getting Real the authors make a compelling argument for the Agile development method and creating small apps that grow. An interesting consequence of the agile methodology can actually provide a way to keep users interested in the site and keep them coming back. Use your “push early, push often” mindset and let your users in on some of the fun.

Let’s say I have an application that has just reached the 1.0 stage. Using the principles from Getting Real, it has the absolute minimum feature set that can get it up and running. Now I take a look at my development schedule and map out releases. Instead of working in stealth and pushing out releases on an unknowable schedule, I announce that there will be a major feature added every week (or 2 weeks, or 4 days, or whatever your cycle allows). Now users have a reason to come back to the site every Monday, because they know that there will be something new for them to do.

This has already been used to much success in other industries: DVDs all come out on Tuesday, movies come out on Friday, and Xbox Live pushes out new content every Wednesday. As an extreme case, Big Fish Games pulls in users by offering a new casual game each and every day of the year. People have a natural addiction to novelty; if they know they can go somewhere and see something new, chances are, they will.

Now there are some warnings with this model: you must be able to make your deadlines and you must have interesting features to push. Changing the color on a couple of buttons isn’t going to satiate the need for novelty, and have a couple ho-hum weeks and people will stop coming back. But if you can push out interesting new content on a regular basis, you might get a following you wouldn’t otherwise find. Make your development process part of your product.

When my website started gathering dust from its year or so of inactivity, I decided it was time for a major refresh. I’ve been blogging on Intridea’s Blog and decided to gather up my posts and get my own blog rolling as well. Rather than putting it off for weeks and weeks, I’ve built up the bare minimum of a site for myself and will periodically add new content and features to it.

This blog is intended to be a resource to developers and designers. It will probably be of most use to Rails developers but I’m sure some other things will sneak in there along the way. So, without further ado, welcome to Mister Bleigh!

After developing a number of applications, there were some actions I found myself performing over and over again with each new controller in each new application. With my DRY-sense tingling, I decided to do something about it and create a plugin to clean up some of those repetitive tasks that were vital but annoying to set up. Introducing Needy Controllers.

Needy Controllers takes care of your controllers’...well, needs. You can include stylesheets, javascripts, and memoized record helpers in your controllers and views with a single command, and even use filter-chain-esque options to specify and tailor to your needs. Basically, it simplifies the process of:

1. Including stylesheets in your app on a per-controller/action basis
2. Including javascripts on a per-controller/action basis
3. Having helper functions to fetch records in common RESTful resource mappings

Installation

git clone git://github.com/mbleigh/needy-controllers.git vendor/plugins/needy_controllers

Usage

Styles and Scripts

To use Needy Controllers for styles and scripts, you simply call a “needs” option inside your controller like so:

class MyController < ApplicationController
  needs :styles => :standard
  needs :styles => :show, :only => :show
  needs :scripts => :behave, :except => :show

  def index
    # this action will have access to the 'standard.css' stylesheet
  end

  def show
    # this action will have access to the 'show.css' stylesheet
    # in addition to 'standard.css'
    # but will not have access to 'behave.js'
  end
end

Now that you have created your behavior and style chains, you need to include them in the view. Luckily, this is exceedingly easy! Just include :needs in your include and link tags like so:

<%= stylesheet_link_tag 'something', :needs %>
<%= javascript_include_tag 'prototype', :needs, 'effects' %>

An additional benefit of the style and behavior chains is inheritance: namely, any controller that inherits from a controller with a stylesheet or javascript included using the above method will automatically have the same stylesheet and javascript included in itself. This allows you to easily set up includes that are scoped to your exact needs with as little work as possible.

Model Fetching

To use Needy Controllers for fetching records, you use it similarly, and it creates a helper:

class MyController < ApplicationController
  # here's a standard problem
  needs :record => :user, :from => :id, :as => :user
end

The :from and :as options in this example are the defaults (:id for :from and :as defaults to the name of the record). This will create a method (“user” in the example) that will be accessible both from the controller and from the view as a helper. It will find the record with a matching ID to the URL parameter associated with the :from option. Therefore if you had nested resources you could call it as such:

needs :record => :user, :from => :user_id

That’s pretty much it, just a few simple ways to make your coding life easier. As always, there is a Trac available for any issues and I would love to hear any feedback you might have.

Try as I might to avoid it, there comes the inevitable point in a project when I have to start doing browser compatibility. Plenty of people use VMWare Fusion or Parallels to run Windows and OS X side by side, but I find them both slow and unreliable when it comes to real testing scenarios, which leaves me with the necessity of creating a Windows development stack for Rails. After some considerable looking, I’ve settled on what I consider to be the “best” tools for the job – though they still fall short of the OS X equivalents.

• Ruby/Rails: I use the full recommended Ruby distribution as opposed to InstantRails or similar to provide maximum flexibility and customization. I also use the MySQL Community Server for the database portion of my development stack.
• Version Control: TortoiseSVN is a very easy to use SVN front-end, but my fingers have long since learned the console commands and continue to crave them, so I use the Apache 2.0 binaries for Windows to allow me to use SVN from the prompt.
• Console: An absolutely indispensable application for me is Console. This open-source app provides tabbed command prompts in a much prettier interface with a number of other incredibly useful features. I highly recommend it.
• Editor: This isn’t a slam dunk, but the closest thing to TextMate in Windows is, well, the app that was created to be TextMate for Windows. E Text Editor is very good (though in my opinion still too buggy to be called a 1.0) and comes the closest to approximating my Mac development environment. The heavier IDEs such as NetBeans and Aptana With RadRails are also viable options, but I like the speed and simplicity of E.
• Debugging: Since the reason I end up in Windows in the first place is usually IE compatibility, I need tools to approximate the incomparable FireBug. For markup inspection, the most-helpful-least-hurtful I’ve found is Microsoft’s own Internet Explorer Developer Toolbar. Javascript debugging, the most heinous of all tasks, is made much less painful by the Microsoft Script Debugger. Don’t let the “Windows NT 4.0 and later” fool you, this is the most useful thing I’ve managed to find to get some kind of control over IE Javascript debugging.

These aren’t by any means the only tools available, and your needs/mileage may vary, but after finally getting this stack together I can develop in Windows without going into fits of hyperventilation and frustration. If you have your own indispensable tools for Rails development in Windows, I’d love to hear about them!