Recent Posts

What was that idea again?

August 02, 2007

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?

Spec Your Views

August 02, 2007

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.

Designers, Developers, and the x_ Factor

August 01, 2007

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.
```text
-   A few days later, a developer needs to make some changes, tests it
```text
in their favorite browser and commits.
```text
-   Later, the designer doesn't understand why the styling is all messed
```text
up. "It *was* working fine."
```text
-   ...minutes, hours... go by where the designer tries to track down
```html
the issue. "Oh! Someone renamed the `id` in this `<div>` tag. Sigh."
```text
-   Developer apologies, but explains that he needed to do it because he
```text
needed to make it work with his new RJS code.
```ruby
**Scenario #2:** The case of the changed `div` id, (victim: developer)

-   Developer is implementing this cool new Ajax feature into the web
```bash
application
-   The code relies on there being one or many HTML elements in the
    DOM with specific `id` values defined.
```ruby
Example: `<div id="notification_message">`

-   A few days later, a designer is making some changes to the layout
```html
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.
```text
-   Later, code is checked in and designer didn't notice that the Ajax
```text
was now breaking as they weren't focusing on just the layout.
```text
-   Day or two later, developer sees bug, "Feature X isn't working,
```text
throwing JavaScript error..."
```yaml
-   Developer is confused, "Hey, that was working! What happened?"
-   Developer tracks down the problem, discusses with designer, they
```text
figure out a solution. Problem solved.
```ruby
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](http://chriszgriffin.com/) (User Interface Designer) and
[Graeme](http://blog.imperialdune.com/) (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.
```html
```html
<% # 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.
```html
```html
<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:
```html
```html
<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.
````ruby
```ruby
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)...
```bash
```javascript
$('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)

YSlow and Rails performance: Getting UJS and AssetPackager to play nice

July 27, 2007

Yesterday, I started to dig deeper into YSlow and decided to pick an application that we recently launched for a client. The performance grade that I saw at first was an F, which wasn’t surprising to me because we knew that there was going to be some fine tuning in the near future.

There is a lot of JavaScript in this application and we have several files to break up stuff to make it more maintainable. However, in production, we really don’t need to send the client (browser) 19 different JS files. We’ve been using mod_deflate to compress these files, but it doesn’t solve the problem of having several connections opening to download all the necessary JavaScript. The same is true for our CSS files.

At RailsConf, DHH announced that an upcoming version of Rails would bundle all the stylesheet and javascript files into one file and compress it. We’re running on 1.2.x for this application and decided to look at the AssetPackager plugin as a good solution to this problem.

I installed the plugin via piston and ran the following task, which is provided by AssetPackager.

89 gmail invites available!

July 27, 2007

While everyone else is trading their pownce and skitch invites, I wanted to let everyone know that I still have 89 gmail invites available.

Post a comment on my blog and I’ll hook you up!

Happy Friday! ;-)

update: only 12 left!

RubyURL 2.0 on the horizon

July 16, 2007

RubyURL was a project that I built about 2 1/2 years ago as a late night attempt to see what I could build and deploy with Ruby on Rails in a night. It’s nearing 50,000 unique website links, has a Ruby gem that you can use with it, and rbot plugins.

I’ve rewritten it about three times in the past six months, to try out some new approaches, but haven’t deployed with a new version as I’ve been waiting for someone to help me with a new design. Chris has offered to help out and once we integrate his new design with it, we’ll be launching it.

Everything is not great in RubyURL land though. It appears that it’s become an easy target for comment spammers to abuse the site to generate rubyurls and paste those links in their spam comments. Several pissed off bloggers, forum administrators, and system administrators have emailed me to complain that I’m spamming their site. Sadly, even with a basic disclaimer on the site, they still like to blame me for their spam. It’s gotten common enough, that I’ve written a template email that I respond with that explains how the site works and that I’m not accountable for people posting links to my URL redirect tool.

You can see that it’s popping up around the net via a google search.

So, I’ve been trying to think of ways to make it easier for people to flag URLs as being abusive of the site. I’ve not come up with any elegant solution that doesn’t force the good users of the site to have more steps in their process to create a basic RubyURL.

The ideal (and current) workflow:

  • User navigates to http://rubyurl.com
  • User pastes in long url into text box/area
  • User submits form
  • User is provided with new (shortened) rubyurl
  • User copies the rubyurl and does what they want with it
(generally... pastes into IM, IRC, Email, etc.)
```yaml
Some people have suggested using a user system to do this, but I really
don't like that as a solution.

Another idea, which I built... and later removed from my new version,
involved having the original url load in a frame, and then provide a way
for users to flag it as 'spam', 'nsfw', or 'dead'. Then, we could
provide the user with a warning that the following URL was flagged
before, **are you sure you want to continue?** I didn't like this as a
solution in this way as it felt very obtrusive to have a rubyurl frame
at the top of the browser window.

One person suggested a captcha to try and verify that the user is human,
but there are problems with this.

-   I really dislike captchas. ;-)
-   This doesn't prevent spammers from using the ShortURL gem, which
```text
does everything via an API.

In regards to the API, this could be enhanced by requiring that everyone register an email address to get an API key, but only solves the API abusers.

I’m starting to brainstorm some solutions that specifically help the requests made through the web. I haven’t checked the logs enough yet to verify it, but I have a strong suspicion that much of the abuse is happening through a web-based bot, not through ShortURL… because Ruby developers are nicer than that. (I hope…)

So, I am curious… dear readers of my blog. How might you solve this problem without disrupting the user experience? Or, should I just stick with what I’ve got going and find a better way to respond to pissed off bloggers who think I’m spamming them?

Discuss…

Rails Code Audit Tips - Filtered Parameter Logging

July 16, 2007

It’s been a month since I posted, Audit Your Rails Development Team and now I find myself sitting in a hotel room in Mankato, Minnesota with Graeme after a long day of walking through the documents that we delivered to our client after conducting a Rails Code Audit and Review. Our client felt that it would be a great idea to have us visit with six of their employees and walk through the various topics that we brought up in our process. We’ve been doing several of these audits recently and are thought that it would be a good idea to begin sharing some problems that we’ve discovered across projects.

As much as we like to find lots things that we’d recommend improving in Rails applications, we also want to make sure that as many projects as possible avoid some of these common oversights. So, expect to see more posts related to things that we find through our Code Audit and Review process.

Today, I’d like to point out a potential security problem that is often overlooked by developers and system administrators.

Log files.

Does your application request any of the following information from your users?

  • Social security number
  • Credit card date (number, expiration date, etc..)
  • Passwords

BY DEFAULT, all of this data is being written to your production log file. Even if you’re encrypting this data in your database, request parameters (get/post) are all written to your production logs without any encryption. Log files are also notorious for having insecure file permissions, so if you’re on a shared host, other accounts on the server might be able to view them. Regardless of how secure you think your server is, this isn’t data that you want sitting around.

Lucky for you, Ruby on Rails has an easy solution to this problem! All that you need to do is use the filter_parameter_logging method in your controller(s). We generally add something like the following to our application controller.

Airplane customers prefer bland food...?

July 02, 2007

Earlier today, I was booking flights for Graeme and myself as we’re heading to Minnesota soon to visit one of our clients. While purchasing the tickets on Travelocity, I was glad to know that they remember that I’m a vegetarian. However, I almost made the mistake of submitting the form with the following meal preference for Graeme.

I found it amusing that this was the default in the drop down.

One ID to rule them all

June 25, 2007

I finally decided to put my claimID to use today with the announcement that Basecamp now supports openID. This means that I can easily access all of my Basecamp project with a single login. Some of our clients have their own Basecamp projects and having everything spread around (different usernames, passwords…) made it difficult to manage. I just modified my accounts on a few Basecamp sites and now see them all listed for me to navigate between.

update: Minor annoyance. This caused all my RSS feeds to break because I subscribe to each project individually. I assumed that they’d allow me to now use my openid/password for all my RSS feeds/iCal subscriptions, but they provide you some unique hash for the password. Not sure why they decided to do that… instead of allowing me to use my openid/pass for the subscriptions.

Put Your Controllers on a Diet already!

June 19, 2007

If you’re working with Ruby on Rails and are looking for ways to improve your existing code base, I would encourage you all to read the following blog posts.

  • [Skinny Controller, Fat
Model](http://weblog.jamisbuck.org/2006/10/18/skinny-controller-fat-model),
Jamis Buck
```text
-   [Find methods in
```text
controllers](http://blog.imperialdune.com/2007/4/19/find-methods-in-controllers),
by Graeme Nelson
```ruby
-   [RailsConf Recap: Skinny
```text
Controllers](http://www.therailsway.com/2007/6/1/railsconf-recap-skinny-controllers),
The Rails Way
```text
-   [Rspec notes from the trenches
```text
2](http://blog.caboo.se/articles/2007/6/19/rspec-notes-from-the-trenches-2),
by Courtenay

Hopefully… you’ve already read each of them and as a result… put your controllers on a diet.

Installing Ruby on Rails and PostgreSQL on OS X, Second Edition

June 19, 2007

It’s been just over a year since I posted the article, Install Ruby, Rails, and PostgreSQL on OSX and it still gets quite a bit of traffic. Unfortunately, there have been a few changes in the install process that have caught people.

Today, I am leaving my PowerBook G4. It’s being replaced with a MacBook because the logic board is on the fritz. So, guess what that means? I get to install Ruby, Ruby on Rails, PostgreSQL on OS X again! I figured that I would post a revised version of my previous article for those who may go through this same process in the near future.

::: warning [WARNING]{.caps}: This post contains some outdated instructions. Please read Installing Ruby on Rails and PostgreSQL on [OS X]{.caps}, Third Edition, which is focused on Installing Ruby on Rails on Leopard. :::

Berkun introduces ADD

June 19, 2007

Author of The Art of Project Management, Scott Berkun, introduces Asshole Driven development.

“Asshole Driven development (ADD) - Any team where the biggest jerk makes all the big decisions is asshole driven development. All wisdom, logic or process goes out the window when Mr. Asshole is in the room, doing whatever idiotic, selfish thing he thinks is best. There may rules and processes, but Mr. A breaks them and people follow anyway.”

Read the rest…