Development Blog: Viget Labs

Tony Pitale, Web Developer, July 30, 2008 4

I was notified on Monday (or thereabouts) that Hoptoad had launched. Hoptoad is a service which stands to act as an intermediary between your Rails application exceptions and your email inbox. Any notification of exceptions raised will be delivered to Hoptoad and any repeat exceptions will be combined and counted. An email notification is still sent, but more intelligently (instead of hundreds of emails flooding your inbox).

Having completed registration, I added a number of separate projects. Instructions for setting up a Rails application follows. WIth a simple plugin, and a new initializer, my Rails application was all set to go.  I was able to configure and run the Hoptoad rake test in less than a minute. I did have to update an older project to Rails 2.1 and I’m not sure which versions specifically are compatible. All other projects worked without so much as a hiccup. As would be expected, a handy feed is provided.

After receiving an exception, Hoptoad will list it on the project’s page with a handy count of duplicate exceptions:

Exceptions appear to be compiled by an interesting combination of exception type, controller/action, and the exception message raised. The summary page details the time for the latest of each of the exceptions. Exceptions that have been reviewed on the site are marked as “resolved” and can be hidden. I was able to cull this information using the included rake test task, modified to raise a variety of exceptions, from different actions. I ran the modified task many times over to see how the errors would be combined. Any further insight into this process would be interesting to hear, so please leave comments.

Clicking on the exception will bring up all the wonderful details including details about the environment and the backtrace:

For new exceptions an email notification is sent:

I can’t vouch for the other members of the team here at Viget Labs but, for me, Hoptoad seems like a great fit. I always felt that email, while relatively immediate, was far too difficult to wade through with a large volume (my inbox doesn’t scale). I can understand the reason for reporting every single exception though the process always seemed inelegant. Hoptoad has successfully solved this problem, given my domain. I’ll report again after using Hoptoad in production for longer than a week.

Ben Scofield, Development Director, July 28, 2008 4

We’ve recently started reviewing our markup and CSS standards at Viget (we do this periodically to make sure that we stay up to date with recent developments and changes in the landscape). As part of that, we’re looking into the whole XHTML/HTML MIME type issue (brief summary: sending XHTML with the text/html MIME type is technically wrong, but sending it with the correct application/xhtml+xml MIME type is broken on some browsers).

After a fair amount of discussion, we’ve settled on releasing production sites written in XHTML and served as text/html (there are several reasons for this, but they’re mainly outside the scope of this post). We very much wanted to get some of the benefits of serving these pages as application/xhtml+xml in development, though, so I took a little time last week and whipped up the XHTML Dev plugin.

Basically, installing this plugin forces your Rails application to serve pages as application/xhtml+xml—but only in development. That means that our designers and developers can build out pages and easily check them for well-formedness in standards-compliant browsers (which show error pages when given malformed application/xhtml+xml markup) without having to hit an external validation service. The plugin is inactive in production, which means that third-party and user-generated content won’t break the site unexpectedly.

Of course, there’s still the issue of testing with older browsers in development, and for that the plugin provides a before_filter (handle_with_ie). With that filter in place, any requests from IE6 or earlier browsers will receive text/html responses.

It’s a simple plugin, but it’ll make things a little easier for us down the road. If you’re interested, grab it from GitHub.

Mark Cornick, Web Developer, July 18, 2008 2

Here at Viget, we’ve done a variety of Rails deployments for our many clients. Nearly all of these have been to dedicated Linux systems, and between those we’ve seen a number of different Linux distributions. Which distribution has what it takes to successfully run your application? This post compares four popular distributions’ support for the basic building blocks of a standard Rails stack, and provides some of our own advice and experience.

Continue reading "Linux Distributions For Rails Hosting: Viget’s First Annual(?) Shakedown"

Brian Landau, Web Developer, July 07, 2008 0

Testing helpers is a topic we’ve covered a couple times already here on the Viget Extend blog. I’ve additionally submitted a patch to Rails for adding some helper assertions to ActionView and other helper related testing goodness. But until that gets accepted and committed, I thought I’d hold everyone over with a helper testing plugin.

Independently Testing Helpers

The main tenet here is that helper functionality should be tested outside of another context (i.e. the controller). To achieve that, we need to create helper tests that live independent of our other tests. As Justin pointed out, Rails actually provides a class to assist in this, ActionView::TestCase.

The plugin I’ve created has two generators that help in creating these tests. The first, helper_tests, can be used to generate tests for your existing helpers. It creates a test file for each helper in the test/helpers directory and a test method for each public helper method. You can also pass it a list of helpers you wish to generate tests for and it will skip those that you don’t name.

Usage:

> script/generate helper_tests [SampleHelper Admin::AnotherHelper ...]

The other generator, helper, creates a helper -- and a helper test for the name provided. It will also accept a list of methods for the helper and generate them, as well as tests for each one.

Usage:

> script/generate helper HelperName [methods ...]

All generated helper tests will be run with rake test now along with all the other tests. Also a rake test:helpers task is provided to run just the helper tests.

Bonus Assertions!

That’s right ... I’ve also rolled in assert_tag_in, assert_tag_not_in, assert_select_in, assert_hpricot_in, and assert_hpricot_not_in assertions to the ActionView::TestCase class. These work exactly like their ActionController counterparts, except for the Hpricot ones, of course. These work by simply passing them the HTML string, and either a CSS selector or a XPath selector. The method then looks for an element matching the selector.

In the future, I’d like to spiffy assert_hpricot_in up by making it more like assert_select but it’s still useful to all Hpricot lovers out there as-is.

The Helper Me Test plugin:

The plugin is up on GitHub: http://github.com/vigetlabs/helper_me_test/tree/master

The clone URL to install with: git://github.com/vigetlabs/helper_me_test.git

As always comments, suggestions, or whatever are welcome, as well as forking it and adding your own twist.

Brian Landau, Web Developer, June 19, 2008 1

When creating web application there’s often a need for single links that have a destructive or “unsafe” effect. In accordance with HTTP specs, GET’s (e.g. links) should not be used for this. The issues that 37signals had with unsafe links prove the importance of this.

This is also important if your application is RESTful. Rails offers a few good solutions, but none of them are ideal. There’s link_to_remote, but this requires the user to have JavaScript enabled and doesn’t allow for progressive enhancement. Then there’s submit_to_remote, which requires you to wrap it in a form tag yourself and also doesn’t allow for progressive enhancement. Last, you have button_to, which is almost ideal, but it uses a submit button that offers less options for styling than a button tag.

And this is where the idea for a button tag helper came in. (See this blog post for a good description of why the button element rocks). Thus, ActionButton was born.

With it, you can create a form with a single button element. The form can be set to point to any url just as you would with a normal form. The button and the form can have different id and class attributes, making them easy to target via JavaScript. But you don’t need to set these; by default it will create classes and ids that are sensible. Of course, all the normal HTML options are available, too.

The plugin will also install a modified version of the lowpro library. The ujs_remote_form helper provided creates a snippet of lowpro JavaScript that can be used to make a form (or set of forms) submit via an AJAX call.

So how would I use this?

Well, if you have a list of blog posts in an admin section and you want to add delete buttons next to each of them and you want them to look the same in every browser, this is how you would do it.

<%= action_button 'delete_post', "#{image_tag('icons/delete.jpg', :alt => 'delete')} Delete", 
                   post_url(post), {:method => :delete, :number => post.id} %>

Then when you’re ready for some AJAXy goodness, you can either use the Rails built-in helper of the plugin’s lowpro one:

Built-in:

Add this for each post:

<%= observe_form "delete_post#{post.id}-form", :on => 'submit', 
                 :confim => 'Are you sure you wish to delete this post?' %>

Lowpro:

Add this for the whole page of posts:

<%= ujs_remote_form 'button.delete_post', :confirm => 'Are you sure you wish to delete this post' %>

So where do I get this plugin of button joy?

It’s up on github right now!

If you have any questions, comments or suggestions, send them my way. It’s great to get feedback, but if you really feel I messed something up, just fork it and make the changes you feel it needs.