Category Archives: Web Development

Testing Rails Exception Notification in Production

Every Ruby on Rails project I have been involved in has used the Exception Notification gem. It sends you an email with very helpful debugging information whenever your application breaks in the real world. However, I’ve seen people fail to ensure that it actually works in their production environments–not when they first launch their site, but weeks and months afterward when it really matters. If your production environment changes, your application may fail, but you might not get an email about it because that which broke might have affected email sending. And you’ll think everything is honky-dory. Make sure you have something like this in your application and that you test it periodically to ensure you’re getting exception notification emails.

In config/routes.rb:

  map.connect 'test_exception_notifier', :controller => 'application', :action => 'test_exception_notifier'

In app/controllers/application_controller.rb:

  def test_exception_notifier
    raise 'This is a test. This is only a test.'

I also recommend adding this to a periodic test script and your deploy script so you don’t have to remember to test it.


The Unplugged by Ruven Meulenberg

While researching user experience design techniques, I stumbled upon some nifty whiteboard magnets for prototyping called GuiMags as well as a complementing book called The Unplugged.

GuiMags look like the nicest way to prototype something before going to HTML and CSS. Labor intensive forms of prototyping don’t seem to add much value, and paper and traditional whiteboard prototyping only works until you’ve changed your mind about something and have to throw your work in the trash or erase half the board.

Although I decided to postpone a magnet purchase until I am doing design again, I was able to get my hands on the book. Its premise: we limit ourselves by the technologies we use. Instead of thinking outside the box, we’re often thinking and functioning in it. A large part of this thinking inside the box is how we develop software.

Although, everyone interested in the topic should pick up the book, here are a few of my takeaways:

  • Every major form of art that involves technology (music, film, video games, graphic design) starts outside technology. Artists do not limit themselves by their technology but by the limits of their own minds. As a software engineer, you often limit yourself by the technology you use day-to-day.
  • Spend as much time as you can iterating on concept and design before going to implementation.
  • Design the software front-end not the back-end first.
  • Just like there are code freezes, freeze the product when it has passed the design phase.
  • It is often wise to outsource the implementation.
    • This serves as a peer review of the design before it goes to implementation. Software developers traditionally think about the back-end first.
    • Different cultures have different strengths: “England and Western Europe are great at design, Ukraine and Macedonia have amazing and prompt developers who can think for themselves, the Netherlands always emails back the same day, India is extremely polite, etc.”
    • Work can be done while you are sleeping. “This can cut the development time in half.”
    • Because you already know what you want and won’t be constantly changing the design, contractors will want to work with you even if you pay less.
    • Only be satisfied with five-star developers.
    • Pay more than you agree to pay.
    • Do one-week sprints. Longer sprints end up getting delayed, with excuses.

With the last (sub)point in mind, I think this methodology is well-suited for an agile development process.

There is a lot to gain from reading the book, so make sure to grab a copy for yourself.

Catching Up to Video Games

A little over a month ago, Yahoo’s Douglas Crawford gave a great presentation on “The State of Ajax.” His opening was brilliant. He started with a brief history of computing ending with some of the incredible things being done in the video game industry, including current real-time 3D rendering of hair, light, reflections, and the like. Then he pokes fun at the web development community because of their excitement over rounded div corners. Clearly, we have some catching up to do.

Although I have been opposed to the use of Flash for regular web sites for years, Office Max came out with a nifty Flash application last Christmas called “Elf Yourself,” which they’ve upgraded this year. Not only can you skin the dancing elf with your own face, you can call a 888 number to record your own message to viewers. Very clever and very funny. Take a look at what my little brother, Nate, pieced together and then elf yourself.

CSS Selectors: Use Classes

I have refactored a lot of web pages the past thirteen years. When CSS came out, I was ecstatic; my mark-up was much cleaner; style changes were simpler; life was more enjoyable. However, I have also refactored a lot of CSS. Changes to styles are a given and are simple to make–that’s the beauty behind it. The pain comes in when mark-up changes. Mark-up changes often lead to changes in selectors.

Pain is at its worst when selectors are anonymous, whether as inline styles or ones that are dependent on element ordering and hierarchy, such as:

div > p > a > span
div > p img

The mark-up they style is highly susceptible to change as a site evolves. It is prudent to construct base element selectors (body, p, img, etc.) after starting from a clean CSS slate, but anonymous ones should be avoided.

The second is the use of id selectors over classes. Although not anonymous, they lock you into styling just one thing on the page or complicate styles by prefacing them with numerous selectors:

#warning, #attention, #exception { color: red; }

The minute you decide to add an #error element to your page, you’re refactoring your CSS again. Even though you may just want to style just one element on the page when you first define it, it doesn’t have to be selected by id; you can select it by a CSS class:

.attention { color: red; }

If you add a #warning or #error element later on, which you want to style the same, you can simply use the class you’ve already defined and not have to add yet another selector to the list.

I am now at a place where I have largely abandoned anonymous and id selectors and have stuck to just base element and class selectors. Styling is easier and simplicity, readability, and consistency come as added benefits. Of course there are exceptions to this way of thinking–that’s why id and anonymous selectors exist. They just shouldn’t be the default way of thinking.