Robby on Rails

It’s been about six weeks since the last Rails Business “Weekly” Review on here, so perhaps it’s worth changing the name to cut me some slack on not being consistent. ;-)

Since the last post, we’ve gone from around 400 members to 555 as of this morning. We’ve had 562 messages as well, so there hasn’t been a shortage of discussions taking place. I’d like to take a few moments to highlight some of the discussions that have taken place and encourage you all to consider participating, if you’re not already.

Licensing and Client Agreements

Tim Case writes,

“My client sent me this agreement drawn up from their lawyer that included the following:

(c) the Contractor shall not bundle with or incorporate into any Work Product any third-party products, ideas, processes, software, codes, data, techniques, names, images, or other items or properties without the express, written prior approval of the Company;”

Tim then goes on to ask how his applies to using Ruby on Rails, which as a MIT license and how other consultancies are handling these types of situations. Follow the discussion…

Escrow

Gustin writes, “Does anyone have any escrow experience, legal and cost? I am dealing with a client that got burned bad and we are reducing their fear with escrow on the first two iterations.”

Follow the discussion…

Project Planning tools

Mike Pence writes, “So, I used to use MS Project for the composition of those dreaded Gantt charts, but it has been a few years since I had to be so formal. Anything new and exciting – and more robust than Basecamp – happening in the world of project planning software?”

Follow the discussion…

Not long after, Jim Mulholland started a new thread on the same topic and brought up the open source application, redMine. Follow this discussion…

Ruby on Rails versus .NET

Michael Breen asked a big question on the list, which has sparked an going discussion about the benefits of using Rails versus .NET (and other platforms).

“A couple of months ago I decided to stop actively pursuing .NET gigs to focus on Rails. Several of my existing .NET clients have learned of this through the grapevine and have contacted me to discuss.”

Follow the discussion…

Three things Tim’s learned from Freelancing Rails

Tim Case shared his experience of freelancing with Ruby on Rails and highlights three things that he’s learned.

• The non-code business aspect of Freelancing is demanding.
• It takes 10 hours to bill 6 to 8.
• Figuring out your rate is hard.

Read the rest of Tim’s observations and the discussion the followed.

Client issue tracking and documentation

Jeff Judge writes, “Hello all! I was curious to here how people are handling client issue tracking and documentation.”

Several applications were mentioned for handling issue tracking and the general consensus was that there was still a lot to be desired that current options didn’t provide. Be sure to follow the discussions…

Join the Community

These were just a small handfull of the discussions that have taken place over the past several weeks. If you’re an aspiring Rails freelancer or business owner, be sure to join the community and share your experiences and learn from other members of the community that are willing to share theirs.

Until next time, have fun!

While engaging in another one of our deep philosophical conversations in #caboose, the topic of remembering that great idea that we had before we fell asleep or at any point during the evening.

Manfred Stienstra writes, “I always think of stuff right before I fall asleep and can’t remember them when I wake up.”

This happens to me as well, just not as much as it used to. I keep a small moleskin notebook and a pen on my bed side table and try to get everything in there as it comes up. When I open it, I see notes that don’t make any sense, which were probably after waking up from some bizarre dream. There are many business and development ideas that come up, but it’s often hard to record everything.

I’m sure that there are others who’ve faced this problem. Have you come up with a working solution? If so, would you mind sharing it?

I meant to work on this post… oh about 7 months ago.

Way back in January (7 months ago), Jamis Buck posted an article titled, Testing your views, which gave a few tips on using Test::Unit to, as the title suggests, test your views.

While, I’m not going to rewrite everything that Jamis wrote, I’d like to show you how to test these views with RSpec. (you might take a moment to quickly read his post…)

In this example, I’m going to show you how we’re able to write specs for the following RHTML, which you’ll notice matches the code that he wrote tests for.

  <% if @user.administrator? %>
    Hi <%= @user.name %>! You appear to be an administrator.
    <%= link_to "Click here", admin_url, :id => "admin_link" %>
    to see the admin stuff!
  <% end %> 

Jamis writes, “The only really significant thing you ought to be testing here is that the admin link only shows up for administrators. “

So, let’s do just that, but with RSpec.

I’m not sure how Jamis is handling his view tests, but we’re going to approach our view specs, much like we approach our controller specs, with the use of mocks and stubs, because we really don’t need to spec any of our models at this level in the application.

Tip: Write specifications for your models… in your model specs not in your controller or view specs.

The first thing that we’re going to do is setup a custom spec helper, because for something like an mocked user, will probably get reused in other areas of the user interface. Spec helpers are essentially modules that you can include in your RSpec descriptions (the block that starts with describe) and reuse.

In this spec helper, I’m going to include two methods, to mock the User model and stub out any of the methods that are necessary for spec’n this view.

module MockUserHelper
  def mock_normal_user
    user = mock(User)
    user.stub!(:administrator?).and_return(false)   # <--- NOT an admin
    user.stub!(:name).and_return('David Chelimsky')
    return user
  end

  def mock_admin_user
    user = mock(User)
    user.stub!(:administrator?).and_return(true)    # <--- IS an admin
    user.stub!(:name).and_return('Aslak Hellesoy')
    return user
  end
end

In the mock_normal_user method, we’re constructing a mock object and stubbing out the methods that we see are being called in the RHTML code. In mock_admin_user, we’re basically doing the same thing, but just stubbing the administrator? method to return true for this mock user.

By stubbing these methods, we’ll be able to send a non-ActiveRecord object to the view and have it render without knowing the difference. For example, the if @user.administrator? condition will return true or false, depending on how we stubbed it.

For more information on mocks and stubs, read here.

Now that we have our spec helper, let’s go ahead and dive into a few specifications for the view.

describe "index page" do
  include MockUserHelper

  it "should render an admin link for an admin user" do
    assigns[:user] = mock_admin_user
    render 'index'
    response.should have_tag('a#admin_link')
  end

  it "should not render an admin link for a normal, non-admin user" do
    assigns[:user] = mock_normal_user
    render 'index'
    response.should_not have_tag('a#admin_link')
  end
end  

Please note: This code example is only longer than the one shown by Jamis because he didn’t include how he setup all his user sessions/objects. ;-)

When these specs are run, we can see the following results.

Pretty output courtesy of RSpec + TextMate bundle

Great, we’ve been able to write specifications for our Rails views without a lot of pain. Stay tuned for more posts on this topic as I continue writing about how Designers and Developers can work together, in harmony. (see my last post on this topic)

For more information on adopting RSpec, please visit the RSpec project homepage.

Our team is lucky enough to be in a position where we have both designers AND developers working on the same code base in parallel.

Since Ruby on Rails adopts the Model-View-Control pattern for separating business logic from the presentation layer, we’re able to give our designers a lot of breathing room to to design the interface, whether it’s for interaction or aesthetic reasons. However, sometimes this breathing room has resulted in small bugs slipping into the application interface. In general, nothing disastrous, but each bug that slips into the queue, slows down the project and we want to avoid as much of that as possible.

I’d like to share a few issues that we’ve seen occur on various occasions, and then show you what we’ve done to avoid them happening again.

Scenario #1: The case of the changed div id, (victim: designer)

• Designer adds a few HTML elements to the page, defines an id on a <div> tag and styles it with CSS.
• A few days later, a developer needs to make some changes, tests it in their favorite browser and commits.
• Later, the designer doesn’t understand why the styling is all messed up. “It was working fine.”
• ...minutes, hours… go by where the designer tries to track down the issue. “Oh! Someone renamed the id in this <div> tag. Sigh.”
• Developer apologies, but explains that he needed to do it because he needed to make it work with his new RJS code.

Scenario #2: The case of the changed div id, (victim: developer)

• Developer is implementing this cool new Ajax feature into the web application
  • The code relies on there being one or many HTML elements in the DOM with specific id values defined.

Example: <div id="notification_message">

• A few days later, a designer is making some changes to the layout and needs to restyle some of the view that this <div> tag is defined. Designer decides to change the id to a different value for any variety of reasons. (or perhaps they changed it to use a class instead of styling it by the id). Often times, we don’t know who set the id or class… and many times the developers aren’t savvy enough with HTML and designers end up cleaning things up a bit.
• Later, code is checked in and designer didn’t notice that the Ajax was now breaking as they weren’t focusing on just the layout.
• Day or two later, developer sees bug, “Feature X isn’t working, throwing JavaScript error…”
• Developer is confused, “Hey, that was working! What happened?”
• Developer tracks down the problem, discusses with designer, they figure out a solution. Problem solved.

I could outline a few other examples, but I really wanted to highlight these two types of situations, as our team has seen this happen on several occasions. Luckily, we’ve learned through these experiences and have taken some measures to try and avoid them in the future.

Moving forward (together)

Both of the examples above, were essentially the same problem, but resulted in problems for a different role in the design and development cycle. While, I’ve definitely been the victim of #2 several times myself, I know that I’ve also been the guilty of #1. So, what can we do as designers and developers to work with each other without causing these little problems from occurring? (remember: many little problems can add up to a lot of wasted time spent resolving them)

Several months ago, I had a meeting with Chris (User Interface Designer) and Graeme (Lead Architect/Developer) to discuss this very problem. At the time, we were implementing a lot of Ajax into an application and were occasionally running into Scenario #2. We discussed a few possible ways of communicating that, “yes, this div id should NOT be changed (without talking to a developer first)!”

Idea 1: Comment our “special” HTML elements

We discussed using ERb comments in our views to do something like the following.

  <% # no seriously, please don't change this id, it's needed for some Ajax stuff %>
  <div id="notification_message">
    ...

We all agreed that, while effective, it was going to clutter up our RHTML code more than any of us desired.

Team Response: Meh.

Idea 2: Reserve id’s for developers

Another idea that came up, was to ask that designers only use classes and ids wold be used by the developers when they needed it.

  <div id="developer_terriroty" class="designer_territory">
    ...

Chris pointed out that this wasn’t an ideal solution as there is a distinct case for when to use ids versus classes.. and he is very strict about adhering to the HTML/CSS standards.

Team Response: Not hot about it…

Idea 3: Naming convention for Ajax-dependent elements

The third idea that was discussed, was specifying a naming convention for any elements that were needed by our Ajax code. We played around on the whiteboard with some ideas and settled on the idea that we’d prefix our id’s with something easy to remember for both designers and developers.

We agreed on… x_ (x underscore), which would make an element id look something like this:

  <div id="x_notification_message">
    ...

x == ajax... get it?

While this adds the strain of typing two more characters to much of our RJS code, we don’t run into Scenario #2 very often anymore.

  render :update do |page|
    page[:x_notification_message] = 'Something exciting happened... and this is your notification!'
    page[:x_notification_message].visual_effect :highlight
  end

or in client-side JavaScript (where we also use this)...

  $('x_notification_message').do_something

I find that this helps our team keep a clear distinction between what can and shouldn’t be changed in the views by our designers. Sometimes they have a good reason to do so, but they know that if there is x_, then they should ask one of the developers on the team for assistance in renaming it without causing any problems in the application. It also allows our designers to add classes to these elements, or style the id that we’ve defined.

Team Response: Wow, was that all we needed to agree on? Hooray!

This leads me to some other problems that have/may come up, but I’ll discuss that in my next post on this topic, when I’ll show you how we can use RSpec to avoid these sorts of designer versus developer problems.

If you’re working in a similar environment, how are your designers and developers working, together, in perfect harmony?

Until next time, remember to hug your designer. ...and if you’re still having developer design your applications, consider hiring a designer. ;-)

UPDATE: changed examples after a few comments about using div_for as another solution. (see comments for details)