Close and Go BackBack to Viget

Hoptoad: in Brief

Tony Pitale
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:

image

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:

image

For new exceptions an email notification is sent:

image

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.

Drizzle and Ruby on Rails

Clinton R. Nixon
Clinton R. Nixon, Senior Developer, July 29, 2008 2

I recently went to the 2008 O’Reilly Open Source Conference to give a tutorial on plugins for Rails. I recorded it, and if you’re interested in understanding and building plugins, I think there’s some good stuff there.

What’s more exciting to me than that are the talks I attended. I saw Brian Aker, the director of architecture for MySQL and the maintainer of the C client library for memcached, talk about both memcached and his new project, Drizzle. In the FAQ for Drizzle, he says:

I’ve been wondering for a long time now about all of the changes post [MySQL] 4.1. I believe there is a large market of users who never wanted them, and never cared for them. I also wanted to question the foundations of what we built.

  • So what are the differences between this and MySQL?

No modes, views, triggers, prepared statements, stored procedures, query cache, data conversion inserts, ACL. Fewer data types. Less engines, less code.

In his interview with Tim O’Reilly, Aker said that Drizzle’s intended for a different market segment, specifically for web applications. Whether it’s intended specifically for Rails or not, I think we have a lot to look forward to with Drizzle and Ruby on Rails.

Currently, ActiveRecord doesn’t use foreign keys without a plugin, views without a plugin, or many data types. The creator of Rails has called databases “a necessary evil for the object-oriented domain model,” which is maybe overstating the case, but definitely reflects the view that business logic, including relational mapping, should stay in the application layer. Drizzle shares this view.

One might ask how this is really different from SQLite. Unlike SQLite, Drizzle is focused on multi-core architectures, and assumes you will have lots of RAM to use for the database. This focus on multi-core will allow Drizzle to handle concurrent connections well (they are keeping transactions).

MySQL isn’t slow, but MySQL without features you aren’t using will be even faster. The Drizzle project’s in C and C++, but if you’re proficient with those, I highly suggest participating in its development. Their coding standards show a definite commitment to quality over feature quantity, which should make working on it a very rewarding experience.

Talking about Drizzle has created some interesting discussions in our development lab. We’re split on whether database-enforced relational integrity is necessary, or if pushing that to the application layer is a good idea. We’d love to hear your thoughts in the comments.

Introducing: XHTML Dev

Ben Scofield
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.

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

Mark Cornick
Mark Cornick, Web Developer, July 18, 2008 0

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"

A Confusing Rubyism

Ben Scofield
Ben Scofield, Development Director, July 12, 2008 5

The following code has the potential to be terribly confusing:

if x = some_method
  monkify
else
  rhinofy
end

In Ruby, the return value of an assignment statement is the value assigned (run a = 1 in irb and you'll see it returns 1), so this code can be understood as:

  1. Evaluate some_method and assign the value to x
  2. If the new value of x evaluates to true, run monkify
  3. If the new value of x evaluates to false, run rhinofy

Unfortunately, however, most developers are much more accustomed to seeing the equality operator == in conditionals, which means that often we'll misinterpret that code as:

  1. Evaluate some_method and compare the result to x
  2. If they are the same, run monkify
  3. If they are different, run rhinofy

In the interest of clarity, then, it's probably better to avoid using an assignment statement in a conditional. Of course, other concerns may override the need for clarity - but it's something to keep in mind.

A Development Community for Viget Labs and Beyond

Every team member here at Viget Labs strives to be an innovator. We members of the development team are no different - that's why we're constantly engaging in community discussions and exploring the unknown that is the next generation of open-source web applications.

Viget Is Hiring!

Viget has job openings for Ruby Developers, Interns, and Front-End Developers. Learn More »

Recent Comments

I think that polymorphic_url(@commentable, :anchor => “comment_#{@comment.id}") should work. You can also refactor the “comment_#{@comment.id}” to a separated method, like dom_id, which returns the dom identifier of the comment.