The CrunchyFrog Blog

A week or so after upgrading Firefox to 3.0.7 on my Linux system, I began running across an occasional web page that wouldn’t render correctly. At first I attributed it to poor page coding — perhaps one of those old-timers that still hasn’t learned that there’s more to web browsers than IE, or someone who mucked up their CSS and wound up with white text on a white background — but since I wasn’t necessarily in need of the information at the site, considering the Google search that took me to the site provided many more possible links, I just moved on to the next site without bothering to figure out why the page didn’t render.

Unfortunately, the frequency of pages not rendering properly began to increase to the point that I began experiencing the problem with web sites that I did need to access. Opera could render them fine, and Firefox on my Mac OS X system had no problem, but Firefox on Linux was a basket case. Even worse, Galeon and Seamonkey crashed when I tried to visit those same sites.

My previous post contained multiple code fragments contained in macro:code blocks, but they were not formatted correctly. There was an excessive amount of space at the beginning of each code block and a smaller amount of excess space at the end, as well as extra lines between each line of code.

Looking at the source code revealed that every line of the code block was terminated with a BR tag. The XHTML code for the line number columns looked like this:

1
2
3
4
5
6
7

<pre>1<tt><br />
</tt>2<tt><br />
</tt>3<tt><br />
</tt>4<tt><br />
</tt><strong>5</strong><tt><br />
</tt>6<tt><br />
</tt></pre>

Clearly, not what is expected.

I tried the same post in a mephisto development environment but could not replicate the problem. After ruling out browser and OS differences, it was clear that the problem was confined to the production server.

Another curiosity was that the problem only happened when there were multiple code snippets or text followed a code snippet. If only one code snippet appeared in a post and nothing followed it, the BR tags were not inserted.

The differences between the development and production systems are the web server (mongrel in development and Apache + Phusion Passenger in production) and the Ruby interpreter (plain ruby in development and Ruby Enterprise Edition in production).

I quickly narrowed the problem down to Passenger. Passenger 2.1.2 was recently released but the production server was still running version 2.0.6. A quick sudo gem update passenger, an edit of the Apache config, and a restart of Apache, and the extra BR tags have been eliminated.

I can’t tell from the Passenger release notes what might have caused the problem in the first place but, whatever it was, it affected the CodeRay parsing and is no longer an issue.

Now if I can only sort out the CSS issues that are causing some minor formatting glitches with the code snippets in Opera and Firefox 2.

So I have an controller method that responds to multiple formats, like so.

1
2
3
4
5
6

def index
  respond_to do |format|
    format.html
    format.pdf
  end
end

Simple enough. So what do the tests look like?

1
2
3
4
5
6
7
8
9

def test_default_index
  get :index
  assert_response :success
end

def test_pdf_index
  get :index, :format => :pdf
  assert_response :success
end

Again, nothing fancy. Let’s run the test and …

  1) Failure:
test_pdf_index(FoosControllerTest)

    [stacktrace omitted for brevity]

Expected response to be a <:success>, but was <406>

2 tests, 2 assertions, 1 failures, 0 errors

Ruh-roh. How could such a simple test fail, and what’s a 406 response? Well, it’s the numeric code for a Not Acceptable HTTP response, so it looks like the HTTP request is borked. Perhaps the log file will reveal something, and indeed it does.

Processing FoosController#index to pdf (for 0.0.0.0 at 2009-03-21 22:57:10) [GET]
  Parameters: {"format"=>:pdf, "action"=>"index", "controller"=>"foos"}

Looks like we can’t use a symbol for the format in the test. Sure enough, a quick change to the failing test,

1
2
3
4

def test_pdf_index
  get :index, :format => 'pdf'
  assert_response :success
end

and the results are as expected.

2 tests, 2 assertions, 0 failures, 0 errors

Update: Looks like the code formatting is fubar.

Update II: The code formatting is now fixed. See the explanation if you’re interested in the details.

Today finds me celebrating (in a rather low-key manner) two milestones. The first milestone is finally getting this blog off the ground, and the second is the second anniversary of the first commit of my first serious Rails project. The initial site went live two weeks later, replacing a crufty old PHP-based codebase that I had grown weary of maintaining. Naturally, several new features have been added since the original launch and both Ruby and Rails have made developing the site more enjoyable than any of the languages that had been used previously.

For much of the year the site doesn’t look like anything that anyone would bother using Rails, or any other application framework, to create. Why not just throw up a bunch of static HTML pages?

Well, the site exists to support the Dixie Cup homebrew competition that’s held every year in October. The public side of the site handles the online registration process while an administrative backend handles the running of the competition. For about 10 months of the year the site sits quietly with infrequent updates and then springs to life for a couple of months of serious activity.

Since I’ve had several inquiries about the code from other clubs who want to use it for their own competitions, I’ve begun working to extract the guts into a separate project. I found myself needing to look at the revision history of some files and, at one point, decided to look all the way back to the beginning of the revision history for the entire project and noticed the date of the first commit was March 20, 2007.