I really like the Juice Analytics blog. These guys know their stuff when it comes to business analytics and data information display. They know all the big names, all the new tools, and they’ve got their own tips on top of that which makes it a great read. I really like their new site layout, and find it interesting they went with Python and Django. Most of my new stuff these days is Rails, but I have respect for anyone that makes a conscious decision about what they’ll use. And today, there’s a lot of power in light languages combined with flexible frameworks. Rock on, Juice.
So you’ve got a great Rails app. You’re setting up page caching for those publicly accessible pages shared by everyone. One of your pages is the :index. It seems like the caching isn’t working when you’re testing it, but the output constantly says:
What gives? Try seeing if “/tag” seems to use the cache, but “/tag/” doesn’t.
The mechanism behind the Rails page caching takes your action output and stuffs it all into an HTML file that can easily be found by the web server. Ah! So there’s no voodoo in Rails itself that tries to check for that page. In fact, it’s banking on not being called by pushing that burden off to the web server. In our case, this is Mongrel.
So how does Mongrel decide? Well, the mongrel_rails fires up a RailsHandler which uses the PATH_INFO to check for the existence of a cached file. When you’re requesting “/tag/” it’s looking for tag/.html, but not finding it.
I put together a patch here to address it. Seems to work in my limited testing, but I don’t know what I may have broken. Yeah, usually I make sure to write a test for my patches. This time I didn’t. Perhaps it won’t make it in until I do, but at least I’ve got it written down here to remind me when my cache doesn’t seem to work quite right.
So I ran into a funny error today while trying to install erlang on my Mac.
It turns out (after running port using the -d option), that macports was trying to upgrade my gettext version. The Portfile seemed to be trying to set the CPPFLAGS option for the configure tool. I opened up /opt/local/var/db/dports/sources/ rsync.rsync.darwinports.org_dpupdate_dports/devel/gettext/Portfile and replaced:
That seemed to have fixed things. I was able to continue my install and fire up erl. Since I couldn’t find the answer on the big Google-Net I cast, I figured I’d write it up here in case some poor soul had the same bad luck I did.
My youngest cousin was in a building next to Norris Hall. She’s an engineering major at VT. Her mother works on campus. Her father has worked for the campus for years, and works for the campus from home. She wrote yesterday with a brief update that said, in part:
One guy I know was in a classroom in Norris (the building that the gunman barricaded) but they put a table up against the door and all pushed on the door when the gunman tried to enter. Two bullets came through the door at chest level but everyone was down low to the ground and later escaped safely.
He was killed in the Norris Hall Engineering Building. He was 77 years old. Librescu held the door of his classroom shut while the gunman, Cho Seung-hui, was attempting to enter it, and was shot through the door, but was able to prevent the shooter from entering the classroom until his students had escaped through the windows, sacrificing his life to save several students from being harmed and is regarded as a hero during the aftermath of the Blacksburg massacre.
As a student of self-defense, I have great respect for those willing to put their lives at risk to help others. My uncle suggested that in addition to classes in self-defense, we should have classes on group defense. The heros of United 93 forever changed the way airplane passengers respond to threats. Tragedies like the Virginia Tech massacre and others may produce the same resolve for group defense in our collective culture when we’re faced with such situations.
In last year’s JSF Burrito podcasts, I argued that I didn’t see the point of using a strong component model for JSF and that throwing away nice HTTP RESTful URIs is a Bad Thing. In an interview with InfoQ, DHH takes up a similar (though probably more polite) stance.
[There is an] assumption that all web developers really want to be desktop developers and that all web applications would be better if only they were more like their desktop counterparts. I don’t accept that assumption. I love working with the web as it is. I love the architectural patterns offered by HTTP and REST.
So in many ways, I see chasing a desktop-like view of the web as chasing the past, not the future.
I’ve written about my reactions to JSF one year after the burrito entries. I find myself clearly in the camp that DHH is in: making desktop-like web apps is chasing the past, using RESTful style development is an approach I prefer.