Recursive Creative Blog

Serve: A Rapid Prototyping Framework For Designers

2009-04-21T00:00:00-04:00

Since Adam McCrea has introduced his solution for simplifying HTML mockups over on the EdgeCase blog, I thought I would take the time to reintroduce my own: Serve.

I’ve been using Serve for almost a year now to prototype MemberHub and before that I used various forms of a simple Ruby script to power my HTML mockups.

Serve has become an indispensable part of my development methodology because it allows me to prototype the application using HTML in a DRY format independently of the work that is being done by developers. This independence is essential as we explore various facets of an application and prioritize the parts that should be developed first.

To give you an idea of how it has worked on MemberHub. I sit down with the client beforehand and discuss a feature and the initial user stories that make up that feature. On a large feature I may spend some time during this phase drawing up a couple of paper prototypes so that we can get a general idea of the shape of the feature and how it will affect the application. We can then use the paper prototypes to give a client a fairly reliable estimate of how long it will take to do the initial development.

Once the feature has been outlined in this way I can then begin work with the HTML prototype. I tend to start with the HTML prototype and not in a graphics program as it allows me to focus on the functionality without getting too caught up with how it looks initially. (I may drop back to a graphics program and “punt”, so to speak, if I’m having trouble getting the layout just right for a particular screen.)

Often while I’m working on a screen for a particular section, I will call the client over (yes, I love working onsite with my clients) and ask for their input on how it flows and feels. One of the chief advantages of developing an HTML prototype for your application is that it gives you the opportunity to explore the flow of your application before the backend development has begun. Hopefully, during the prototyping phase you will be able to iron out any problems in flow, with minimal expense because there is no backend to rework.

The “Design First” approach is huge for us, because most, if not all, of the business decisions are ironed out in the design phase. Also at the point that a feature has passed completely through the design phase we can then estimate that feature with extreme accuracy. The client also knows exactly what they are going to get when the development is done.

Once the client has signed off on a feature in the prototype, it can then be thrown over the wall to the development team. Because we use Serve, the views can be copied over from the HTML prototype to the application almost as is. This does take some effort on my part to construct the views in a way that is friendly to a Rails application, but in general this is not hard if you understand the RESTful approach that Rails encourages. This process is also eased because Serve has full support for partials and layouts with either ERB or HAML.

Does the developer find it annoying to have to copy the views over from the prototype into the application instead of having the designer work with him in the application? In general, yes and no. Yes more work is involved in copying views over into the application (particularly when views change because a feature is revisited). But no, because he doesn’t have to worry about a designer breaking tests or causing the application to fail in some way. It’s also hugely beneficial to the developer because the guesswork is taken out of a feature when it is completely developed (and signed off on) in the prototype before the development begins.

Also, I can’t emphasize enough the freedom that the two project approach gives the designer. No longer is he caught up with views that are hooked into controllers, etc… He can explore new features and focus almost completely on the HTML, CSS, and creative part of his job. With designers often juggling the roles of business analyst, creative expert, HTML/CSS/Javascript guru, asking for the two project approach small price to pay for the increased productivity.

I’ve put together a brief overview of Serve in screencast form below. Let me know what you think.

Mentioned in the screencast:

MemberHub.com in Six Minutes

2009-04-03T00:00:00-04:00

Since January of last year, I have been working with a small startup here in Raleigh building a web service called MemberHub. MemberHub has been a bit of a dream come true for me. It is the first time I’ve had the opportunity to build a subscription-based web service that has massive online appeal. If it takes off, I believe that MemberHub could be the next Facebook or LinkedIn.

Now don’t write me off just yet… Hear me out.

People use Facebook for their personal lives to help manage the relationships they have with friends. LinkedIn is useful for keeping track of your business connections. MemberHub is designed to help organizations, such as churches and nonprofits connect with their members and manage the various groups that make up the organization.

Using MemberHub, you can create online “hubs” for each of the groups that make up your organization. A hub is a simple online home for a group. It contains a home page, a calendar, a place for announcements, a discussion board/mailing list, and a place to upload files. A church, for example, could create hubs for each of its bible study groups, a hub for the homeless ministry, a hub for the singles ministry, a hub for the worship team… You get the idea.

Now the concept of a hub is nothing new. There are plenty of services online today that offer similar features. Many organizations are using services like Yahoo Groups or Google Calendar with great success. MemberHub’s chief strength—and differentiator—is that it provides these features in a way that is friendly to organizations and members.

For the organization, MemberHub makes it easy to setup and organize secure online homes for each of your groups. For the member, MemberHub makes it easy for you to keep up with multiple groups and even multiple organizations in one convenient location! One of the most incredible features of MemberHub is that it can take all of the events across all of the hubs you are affiliated with and display them on one convenient calendar. Imagine never having to enter events in for your organizational activities again!

We’ve really worked hard to make MemberHub simple and intuitive. Below is a brief, 6-minute video that will give you a bit of the bigger picture of what MemberHub can do for you:

If you’d like to learn more about MemberHub, visit http://memberhub.com. And do let me know if you have questions or comments.

AnnounceIt Beta Program

2009-03-28T00:00:00-04:00

Adam Williams and I are working on a new project together. It’s called AnnounceIt.

AnnounceIt is a super easy way to put up a teaser page on a domain to start collecting e-mail addresses. It’s great for an “Announcements Only” mailing list for an event, web site, or web application that is being developed. You can see an example of a “teaser page” for a Web application here and here (yes we are using it to announce our own web application).

If you’d like to be notified when we launch AnnounceIt, signup for our mailing list at announceitapp.com.

If you’d like to be part of our beta program send us an email at us@recursivecreative.com or reply to the @rcreative user on Twitter.

HTML Canvas Test

2008-12-28T00:00:00-05:00

Meet Dataset: The Fixture-Killing, Data-Loading Framework

2008-12-12T00:00:00-05:00

My good friend and partner Adam Williams has just finished bolting the doors on his new YAML-fixture-killing Rails plugin: Dataset. Dataset is the next generation of a plugin that Adam and I wrote last year called Scenarios.

Why the need for a new plugin? The Scenarios plugin was originally built inside of a Rails application that we were working on. At the time we threw it together rather haphazardly. There were few tests (if any). The main thing was to prove that the idea was good. Scenarios worked so well for us that we soon extracted it and used it in our next application. A friend added support for Test::Unit. Pretty soon the implementation our “simple” fixture replacement plugin had grown quite complex. It was becoming hard to maintain.

This year Adam and I have been working on a rather large Rails application. The run time for tests in our application had almost become unbearable. In an effort to speed up those tests and fix some of the outstanding issues in the Scenarios plugin, Adam decided to start from scratch and rewrite the plugin from the ground up using the test first approach.

We have christened the rewrite “Dataset”. It is virtually a drop-in replacement for the Scenarios plugin. Our initial tests suggest that it is significantly faster than its predecessor.

Folks our experience with it over the last year leads me to believe that Dataset is the solution to the Rails fixture debacle. If you haven’t tried it out yet give it a try!

Installation

Like most other Rails plugins you can use the script/plugin install command to download the plugin into your current project:

./script/plugin install git://github.com/aiwilliams/dataset.git

Once the plugin is installed, you will need to add the following lines to test/test_helper.rb:

require 'dataset'
class Test::Unit::TestCase
  include Dataset
  datasets_directory "#{RAILS_ROOT}/test/datasets"
end

General Usage

The basic idea behind Dataset is that creating and using fixture-like data for your application shouldn’t be a chore. To this end Dataset encourages the use of Ruby code for generating your models. A set of Ruby models can be wrapped up for easy usage in a “dataset”.

For example, suppose I’m writing tests for the my application’s authentication system. I could create a dataset with two users in it with the following code (assuming the User model is defined):

# in test/datasets/users_dataset.rb
class UsersDataset < Dataset::Base
  def load
    create_record :user, :john, :name => 'John', :password => 'doodaht'
    create_record :user, :cindy, :name => 'Cindy', :password => 'whoot!'
  end
end

Above, I’m using the create_record method to insert records for two people into the Users table. The create_record method takes three parameters. The first is the singular name of the table to insert the record into, the second is the symbolic name of the record (for referencing the record in a test), and the third is a hash of the attributes of the record.

Jumping over to my test case, I can now write:

# in test/unit/user_test.rb
class UserTest < Test::Unit::TestCase
  dataset :users
  
  def test_do_something
    user = users(:john)
    assert_equal "doodaht", user.password
  end
end

In order to use a specific dataset in a given test, you must declare that the test depends on it with the dataset class method. In the example above I’m declaring that UserTest depends on just UserDataset, but I could easily declare dependancies on multiple datasets by passing multiple parameters to the dataset class method (similar to the way that the Rails fixture method works). Once the dataset is declared you can reference specific models using the appropriate reader method (almost exactly the same as with Rails fixtures). In the example above, I loaded “John” with the reader method users and the symbolic name :john. Remember that in UsersDataset I declared that “John” should be accessible through the symbolic name :john. The users reader method can also retrieve an array of models if you pass it multiple symbols: users(:john, :cindy).

Create A Variety of Datasets for Each Model

When you load a dataset with the dataset class method, only the data declared in the dataset will be available to tests that use it. This is by design. Part of the dataset philosophy is that datasets should be small containing only a fraction of the data needed for your entire test suite. Instead of creating one massive file with all of the data needed for a testing a certain model in different states (like you would with Rails fixtures), create multiple smaller datasets and load only the data you need for each test.

Composition

As the complexity of your application grows there are times when it is useful to declare that a one dataset depends on another. The Dataset plugin allows you to do this through composition. You can declare that dataset C depends on dataset B. Then, when a test declares that it needs dataset C, dataset B will be loaded first and then C. If B depends on A, dataset A will be loaded first, then B, then C, and so forth.

Here’s a simple example using posts and comments:

# in test/datasets/posts_dataset.rb
class PostsDataset < Dataset::Base
  def load
    create_record :post, :first, :title => "First Post"
    create_record :post, :second, :title => "Second Post"
  end
end

# in test/datasets/comments_dataset.rb
class CommentsDataset < Dataset::Base
  uses :posts
  
  def load
    create_record :comment, :first, :body => "Nice post!", :post_id => post_id(:first)
    create_record :comment, :second, :body => "I like it.", :post_id => post_id(:first)
    create_record :comment, :third, :body => "I thoroughly disagree.", :post_id => post_id(:second)
  end
end

In the example above, CommentsDataset declares that it depends on PostsDataset with the uses class method. This means that if a test declares that it needs CommentsDataset, PostsDataset will be loaded first and then CommentsDataset.

(Note that inside the load method I’m using another form of reader method which simply yields the ID for a symbolic name. In this case: post_id. This is useful for making associations without needing to load the model, as done here with comments and posts.)

Helper Methods

Another way of simplifying your datasets and tests is through helper methods. Helper methods are declared inside the helpers block of a dataset:

# in test/datasets/users_dataset.rb

class UsersDataset < Dataset::Base
  def load
    create_user "John", :email => "john@example.com"
  end
  
  helpers do
    def create_user(name, attributes={})
      defaults = { :email => name.gsub(/[,. ]+/, '.') + "@example.com" }
      create_record :user, name.downcase.intern, defaults.merge(attributes)
    end
    def login_as(user)
      @request.session[:user_id] = user.id
    end
  end
end

Any of the methods declared inside a dataset’s helper block are available to the dataset in addition to being mixed into datasets and tests that use it.

In the helper block above I’ve defined two methods. The first, create_user, gives me an easy way to create new users with sensible defaults. (I would highly encourage using factory methods like this to remove duplication from your test data.) The second method, login_as, is a helper method for integration tests. You can see it in action below:

# in test/integration/projects_test.rb
class ProjectsTest < ActionController::IntegrationTest
  dataset :users, :projects, :todos
  
  def test_should_show_active_projects
    login_as users(:john)
    get :projects
    assert_tag '#active_projects'
  end
end

What About Machinist, Factory Girl, and the Other Fixture Replacement Plugins?

If you’ve taken the time to read everything above I hope you can see that Dataset is more than just a new way to construct models for testing. Dataset gives you an easy, declarative method for constructing sets of data to be used in testing. It is a data loading framework. This is in contrast to Machinist and Factory Girl which focus only on making it easy to create new models for testing, but have no solution for loading sets of data. For the record you can use Dataset with Machinist or Factory Girl, though my personal preference is to create my own factory methods for each model.

As to the other fixture replacement plugins? Frankly, I haven’t seen anything that comes close to providing the power and flexibility of Dataset. But don’t take my word for it! Try it for yourself and experience the difference.

Radiant Sprint on December 13

2008-12-03T00:00:00-05:00

Just in case you missed the news we are planning another Radiant Sprint on Saturday, December 13. Several prestigious members of the Raleigh Ruby Brigade plan to attend along with some of the more questionable characters (like me!).

The plan is to continue working to implement the next version of the Radiant UI and bring some of the internals up to snuff. Radiant has recently been upgraded to use the more modern RESTful approach, but there are still plenty of tests to write and other improvements to be made.

This is the perfect opportunity to gain a little insight into the Radiant development process and get up to speed on some of the tools we have been working with (RSpec, HAML, Serve, Spec Integration, and Dataset, to name a few).

It will be hosted at Red Hat here in Raleigh. We’ll get started around 9 am and continue until about 6 pm that evening. RSVP if you want to come along for the fun. Everyone is welcome to attend, even if all you want to do is heckle.

Create Facebook-like Windows with Popup.js

2008-07-17T00:00:00-04:00

Over the past couple of months I’ve been working on a little library for a client that allows us to create Facebook-like popup windows with ease. It’s called popup.js. The library depends on Dan Webb’s excellent Low Pro and comes complete with it’s own behavior for easy unobtrusive use.

So how does it work? Well, once you have the proper plumbing in place you can declare a simple popup window like this:

<div class="popup" id="test" style="display: none">
  <h3 class="title">Popup Window</h3>
  <div class="popup_content">
    <p>Hello world!</p>
    <p><a href="javascript: Element.closePopup('test')">Close</a>
  </div>
</div>

This markup assumes that you are using the included facebook.css stylesheet, but the only thing that is necessary to have a functioning popup window is a div with an ID attribute. You should also set style=“display: none” to ensure that the div is not visible when the page loads.

Popping up the window is as simple as linking to it:

<a href="#test" class="popup">Popup</a></code>

Links with the class of “popup” get the Popup.TriggerBehavior which will trigger the popup when clicked. Note that the href should be set to the ID of the element to popup. If you prefer you can set the href to a URL that returns the HTML for the popup and an AJAX call will be made to that URL.

For more information about this little lib, see the README in the GitHub project:

http://github.com/jlong/popupjs/tree/master/README

And investigate the test project:

http://github.com/jlong/popupjs/tree/master/test

Special thanks to Five Points Solutions for their help debugging this library. They have contributed several Internet Explorer bug fixes in addition to funding much of the initial development.

Pragmatic Programmer Site Live!

2007-10-27T00:00:00-04:00

This may be old news for some of you, but the Pragmatic Web Site got a face lift a couple of weeks ago. I was thrilled to have the opportunity to work on the site with Mike, Dave, and Andy. Most of the design work was done this summer, while the finishing touches on programming and the data import pushed the launch date back to the beginning of October. (Site credits here.)

If you haven’t seen it yet, I’d encourage you to head on over to the site and buy a book or something!

Introducing Serve: Now With Gemmi Goodness!

2007-09-25T00:00:00-04:00

Based on my HAML Server for Web Designers article, I’ve created a small gem “serve” which makes it extremely easy for a Web Designer to get up and running with Haml and Sass:

$ sudo gem install haml redcloth bluecloth serve
$ cd ~/Workspaces/prototype
$ ls . * 
.:
index.haml

images:
logo.gif

javascripts:
prototype.js        dialogs.js         tabset.js

stylesheets:
application.sass        dialogs.sass
$ serve
[2007-09-25 02:11:42] INFO  WEBrick 1.3.1
[2007-09-25 02:11:42] INFO  ruby 1.8.5 (2006-12-25)
[2007-09-25 02:11:42] INFO  Serve::Server#start: pid=1626 port=3000
...

And voila! I can now access the files in ~/Workspaces/prototype at:

http://localhost:3000

Serve isn’t just a HAML or SASS server. With the proper gems it can also handle Textile and Markdown (not to mention plain Jane HTML!).

Serve also plays nicely with Rails. If you have a file named “script/server” in the current directory, Serve will execute that script instead of launching the normal WEBrick server.

Complete usage information is available with:

$ serve --help

Learn more about the project over at Ruby Forge…

A HAML Server for Web Designers

2007-09-04T00:00:00-04:00

I have a script named serve in my bin directory that let’s me quickly startup a Webrick server in any directory. This is handy for serving HTML mockups or other files. Today, updated it to work with HAML:

#!/usr/bin/env ruby
require 'webrick'
require 'rubygems'
require 'haml'

class HamlHandler < WEBrick::HTTPServlet::AbstractServlet

  def initialize(server, name)
    super
    @script_filename = name
  end

  def do_GET(req, res)
    begin
      data = open(@script_filename){|io| io.read }
      res.body = parse_haml(data)
      res['content-type'] = 'text/html'
    rescue StandardError => ex
      raise
    rescue Exception => ex
      @logger.error(ex)
      raise HTTPStatus::InternalServerError, ex.message
    end
  end

  alias do_POST do_GET

  private
    def parse_haml(string)
      engine = Haml::Engine.new(string,
        :attr_wrapper => '"',
        :filename => @script_filename
      )
      engine.render
    end

end

WEBrick::HTTPServlet::FileHandler.add_handler("haml", HamlHandler)

args = ARGV.join(' ')
args.gsub!(%r{^http://}, '')
args = args.split(/[ :]/).compact

server = WEBrick::HTTPServer.new(
  :Port => args.pop || 3000,
  :BindAddress => args.pop || '0.0.0.0',
  :DocumentRoot => Dir.pwd
)

trap("INT") { server.shutdown }

server.start

Just an Experiment

2007-08-26T00:00:00-04:00

OK, this has nothing to do with what I’m working on in Adam’s basement, but here’s a starfield simulation I’ve been working on for a small game in Javascript. It’s an interesting example of what is possible in Javascript on a modern Web browser (tested on Safari 3 and Firefox 2). Be sure to check out the source. Prototype makes this type of thing extremely easy.

Constraints, Frameworks, and Adam’s Basement

2007-08-25T00:00:00-04:00

It’s official. Adam Williams and I are now working feverishly in his basement on our little idea for a web app. We’re both pushing off other obligations for the next 3 months so that we can concentrate on building a quality product.

One of the fun things about building your own application is that you can truly make it whatever you want it to be. If you’ve been in an environment (like me) where you are constantly building things for other people, working on your own project can be liberating. As a creative person I love this! The sky is the limit. No idea is a bad one. Every idea is worth considering.

But wait a minute! Even though we are now working on our own project we still have constraints. We don’t have an unlimited amount of time or money that we can devote to this. We eventually need to ship a working product even if it isn’t everything we initially visualized it would be. In fact, we have to be brutal about what we allow into the app and what we throw out. If we aren’t brutal we’ll end up with something sub-par. Either the app will lack the really useful features when it ships or it will never ship.

This week we’ve worn our creative hat a lot. One of the mistakes I think that we have made is that we have focused a lot on system architecture issues and not enough on application features. I’m beginning to realize that on the front end of this process it is extremely important to focus on application features. We can always refactor the application in the future when we know more about what the system architecture issues are. The features will help clarify that.

Extract a framework from your application. Resist the urge to invent a framework before working on features.

Better Modularization for Rails 2.0 (or What Rails Can Learn from Django)

2007-06-15T00:00:00-04:00

In my previous post about Rails and Engines, I talked about some of the issues I’d like to see resolved in Rails 2.0. Specifically, it seems that we need to rethink modularization in Rails and make it easier for people to share complete slices of applications.

One of the primary hinderances of the present Rails architecture to modularization is the directory structure.

Consider the typical rails app directory:

app/
  controllers/
    application.rb
    account_controller.rb
    blog_controller.rb
    comments_controller.rb
  helpers/
    application_helper.rb
    account_helper.rb
    blog_helper.rb
  models/
    user.rb
    blog.rb
    post.rb
    comment.rb
  views/
    account/
      signup.rhtml
      login.rhtml
      edit.rhtml
    blog/
      index.rhtml
      archive.rhtml
      post.rhtml
    comments/
      view.rhtml
      remove.rhtml
    layouts/
      application.rhtml

Now at first glance, the Rails directory structure seems quite helpful. There is a place for everything and everything is in its place. Models go here, views here, controllers here… The entire MVC in 3 different directories. Wait a minute! Compare this to the Django directory structure for the same application:

account/
  __init__.py
  urls.py
  models.py
  views.py
  templates/
    account/
      account_login.html
      account_signup.html
      account_edit.html
blog/
  __init__.py
  urls.py
  models.py
  views.py
  templates/
    blog/
      blog_list.html
      blog_archive.html
      blog_detail.html
    comment/
      comment_view.html
      comment_remove.html

Wow! See the difference? Django divides the application up not according to file type, but according to logical structure. Related files are together. This makes it easy to share entire chunks of an application. All you have to do is create an svn:external to the appropriate directory of another app and instantly you have access to an entire slice of the other application.

Imagine if Rails took the same approach. The new app directory could look something like this:

app/
  application/
    application_controller.rb
    application_layout.rhtml
  account/
    _config.rb
    _routes.rb
    account_controller.rb
    account_helper.rb
    account_edit.rhtml
    account_login.rhtml
    account_signup.rhtml
    user.rb
    user_migrations.rb
  blog/
    _config.rb
    _routes.rb
    blog_controller.rb
    blog_helper.rb
    blog_index.rhtml
    blog_archive.rhtml
    blog_post.rhtml
    comment.rb
    comment_migrations.rb
    comments_controller.rb
    comments_helper.rb
    comments_view.rhtml
    post.rb
    post_migrations.rb

Now I’ve changed things around just a bit to accommodate the new directory structure and support better modularization. Views are now prefixed with the name of the controller that they are associated with (this allows us to avoid having to put them in a separate directory). I’ve also changed migrations around so that all the migrations for a particular model are in the same file (we would probably need a new domain language for this). Also note that the config.rb and routes.rb files give us a convenient place to store configuration for a particular slice of our application (the underscore prefix would sort them to the top of a directory listing).

So that’s my big idea for Rails 2.0. It would be a radical departure from the present directory structure. So radical that it would effectively make Rails 2.0 applications incompatible with Rails 1.0 apps. But we are already dropping support for deprecated features in Rails 2.0, so perhaps it’s time to rethink the directory structure.

Update: There is some interesting discussion going on about this on the Rails-Core mailing list.

Two Rails Testing Plugins

2007-05-03T00:00:00-04:00

I just released two Rails plugins that should make testing a little easier for some of you.

The test_helpers plugin makes it easy to DRY up your test cases by moving shared code into modules. It includes the handy dandy “test_helper” class method to make requiring and including a snap.
The abstract_testcases plugin makes it easy to create abstract test cases that don’t complain about tests not being defined. If you’d rather not go the module route, this is the plugin for you.

Installation is just like any other Rails plugin:

$ script/plugin source http://wiseheartdesign.com/svn/plugins/
$ script/plugin install test_helpers
$ script/plugin install abstract_testcases

Comments and feedback are welcome.

Setting Up Ubuntu for Rails

2007-05-03T00:00:00-04:00

I just found a wonderful little screencast by Geoffrey Grosenbach of Peep Code Screencasts on setting up the full Rails stack on Ubuntu. He’s uploaded it so that anyone can watch it over on the ShowMeDo website.

From the description:

This 10 minute demo shows how easy it is to install Ruby, Rails, Apache, Mongrel, Subversion, and MySQL on an Ubuntu server. Capistrano and the deprec gem (deployment recipes) are used to automate the installation process with only a few commands. It finishes with a deployment of a Rails app to the newly built server!

The demo is done with Parallels on a Mac, but would work with any machine that can boot from the Ubuntu 6.06 Live CD.

Props to Geoffrey for his great work with helping Rails newbies (and even “old timers” like me) get their feet wet.