Development Blog: Viget Labs

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.

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"

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.

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.