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:
Cached page: /tag.html (0.00044)
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.
Zdot-MBP:~ tim$ sudo port install erlang
Error: Unable to execute port: invalid command name "configure.cppflags"
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:
configure.cppflags \
-no-cpp-precomp
with this:
configure.env CPPFLAGS="-no-cpp-precomp"
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.
Now it’s time to try out some Amazon API stuff.
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.
As I read through the Wikipedia entry she sent, I was amazed at the story of Liviu Librescu. He was a survivor of the violence of the Holocaust.
He was killed in the Norris Hall Engineering Building. He was 77 years old.[5] 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[6][7], 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.
Virginia Tech and Blacksburg, our hearts and prayers are with you.
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.
InfoQ: DHH Responds to Stateful Web Applications Row
[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.
A number of months ago we held an internal debate over XUL, and its place in our development. For the most part, we debated many sides of the issue and came out with “let’s wait and see.” Basically the core of the debate was whether a desktop-like UI is better for our apps or if a web model was more appropriate. Some of us leaned toward the web app side, some just thought the timing was too soon to tell for XUL. Personally, I prefer to keep all the MVC issues on the controller side, and limit JavaScript on the client to handle issues of rapid user feedback (check out the code behind Google’s “star” in GMail), and leave the control flow and rendering decisions to the server-side.
But that’s just me.
Grand Canyon Skywalk :: Hicks-Wright.net
This was not because the package was that complex, but because each person in the line thought they were going to be paying $25 per person. In reality, the tribe was charging another $50 on top of the $25 for each person. You read that right, 75 bucks a pop. The “Question Answerer” explained it to us:
“The investor wants to get his, that’s the $25. But it’s our land, and we don’t get any of that $25, so we have to get ours too, you know?”
When I heard about the glass skywalk it sounded like a really cool idea in principle. Now that I read this, I’m definitely passing on the trip for a LONG time. No cameras on the skywalk (what!!??!), long lines, and hidden fees. $75 per person is not even thinkable. No way. Too bad they launched in the day where one guy’s blog post can touch a few thousand potential customers.
I’ve been silent again. I know, it’s not what I intended at the beginning of the year. It’s just that it’s so much fun to go off and build stuff. I get sucked into all sorts of side projects outside work that are interesting and time consuming (not to mention time spent with the fam — two under the age of 2 is both a joy and a handful!).
So here’s one glimpse into my recent projects. I’ve been hacking away at another WordPress site. It’s a volunteer project I do mainly on the weekends. It’s been interesting to fiddle with PHP more in depth while still doing heavy Rails stuff in the evenings. I forget how functional style programming tends to work. Shared variables abound, and one file melds into another. PHP seems really good about working with files, though. It’s really amazing how easy it is to say, “now go use that file”. I’ve done stuff like that in JSP and other languages, but it’s pretty darn simple in PHP. The mental concepts of assembling a web page seem to be all about choosing the file that renders a certain part of the page. That’s different from JSF where you think mainly about assembling components, and different from Struts where you often think of Actions or logical forwards, and different from Rails where you think of the method in your Action and the responds_to block.
So it’s not likely that I’ll hang out in PHP land for long. Nor is there any danger of me evangelizing it, but I look at this as simply one of many recent experiences I’ve had while building something that confirms another of the Pragmatic Programmer’s axioms: learn a new language every year. I’d add, Do it while hacking something together.
