aronpilhofer.com :

Vikings, I Could Quit You

Tue, 29 Dec 2009 13:21:00 +0000

It's mornings like this when I wonder whether it's even worth it. Why do I bother with this -- or any -- football team? Because clearly my beloved Vikings are going to squander the best shot they have had in a decade for a Super Bowl. At this point, they will be lucky not to end up playing a Wild Card game, when just a few weeks ago we were looking at cruising to 14 or 15 wins and a first-round bye.

How many times can I keep hitting myself with a 2x4?

Winfield, Favre, Williams aren't getting younger, and neither am I. The probability of no salary cap next season -- and maybe beyond -- is scary. And based on the vibe I got when I was home for Thanksgiving, there is zero change of getting a new stadium there. With no cap, and no stadium, you can bet your bottom dollar this team becomes the Twins of the NFL -- just good enough to break your heart year after year after year. Or, worse, they move to Los Angeles, and that is just ... wrong.

Any of those scenarios happen, I'm done. Just done.

Football has always been my first love, but I can quit it because I've done it before. Not with football exactly, but other sports. The North Stars moved to Texas in my youth, and that was easy: I quit them. The Twins won two World Series, and then started paying minimum wage. Easy: I quit them. The Timberwolves were one series away from going to the championship, then they traded Kevin Garnett for next to nothing. A little harder, but I quit them too.

Vikings? I can quit them. In fact, I have a plan.

Some Saturday in the next couple weeks, I'm going to an undisclosed location in North Jersey to join a friend of mine who is a brit and a massive soccer fan. There's some bar there that secretly opens at like 8 a.m. and all these expats gather to eat Brit foot, drink Irish beer and watch Premier League football.

It's like a speakeasy for soccer fans, and based on that alone I agreed to go. But now the stakes are higher. I'm wondering if I shouldn't look at this as possibly the first day of the rest of my sporting life? Soccer could be my methadone program.

It's possible. I was riveted by the World Cup last time, and have to say I'm really looking forward to it this summer. And there is something mighty appealing about spending hours eating, drinking and going bonkers for a 0-0 tie. Mighty appealing indeed.

Another perk? I might actually get to see some decent soccer on T.V. here in New York, which, due to NFL rules, blacks out almost every halfway decent game on Sunday because either the moribund Jets or mediocre (and painfully dull) Giants are playing a home game.

And if next year we're looking at the Wild Card-losing Vikings playing a capless season with a 41-year-old quarterback (or, worse, another season of Tarvaris Jackson) and a likely move to freakin' L.A. on the horizon.... bring on the bangers and mash. I'm done.

The most appealing part of this plan is that I can make a fully conscious decision about my rooting interests.

Growing up in Minnesota, I bled purple before I knew any better. As an adult, I can make a conscious decision to root for the biggest, baddest, wealthiest football club on the planet. I might have grown up cheering for the West Ham of American football teams, but as an adult I can choose to cheer for the Yankees of soccer. Life's too goddamn short. Chelsea? Real Madrid? Manchester United? Go baby go.

It could happen.

How Not to Choose a Web Framework (And Django Sucks!)

Mon, 21 Dec 2009 14:32:00 +0000

A journalism professor friend of mine wanted to start teaching her students to program using a web framework, and quickly narrowed her options to the two obvious choices: Rails and Django. Faced with two fairly similar, can't-go-wrong options, she turned to her technical friends, and asked a simple question: Which should she choose?

Anyone who's spent any time at all in the company of nerds (present company included) knows what happened. For those who have not, let's put it this way: she might have gotten less vitriolic, less doctrinaire, less jingoistic responses had she asked about Middle East peace or global warming.

It's a phenomenon deeply ingrained in the technology world -- the open source community especially. And one that comes as a surprise to journalists as they edge closer to this realm themselves. People who are otherwise rational, sane and logical about most everything become frothing-at-the-mouth lunatics when someone disses their technology of choice.

Don't believe me? Drop in to a BSD users' group some night and start talking about how awesome Ubuntu is. The next programmer you see hacking in vi, just walk over and casually ask what they think of emacs. See that dude over there futzing with The Gimp? Go tell him how much better Photoshop is and see what happens.

Or just go to Google and type in any technology followed by "sucks" and see what comes back. Some suggestions to get you started: "javascript sucks", ".net sucks", "emacs sucks", "php sucks" and especially "java sucks". You'd think these people had better things to do -- like, work. But it's a truism in the tech community: the lower the stakes, the higher the heat.

The same is true of Rails and Django, though I have to say I think the Django folks are way more obsessed with Rails than vice-versa. The real Rails-driven vitriol seems to be directed more at Java or .Net than Django.

And, of course, there in that last paragraph is all the proof you need of my larger point. Did you catch it? First, I casually implied that the Rails users are more mature than those who use Django (which, they are). And then I contrasted Rails with Java and .Net, thereby subtly suggested that Rails is ready to rumble with the big boys and Django is not (duh!).

That's why I'll offer this suggestion to anyone facing the same dilemma as my friend: Go ahead and ask your techy friends what they think, but take everything they say with a massive grain of salt. Listen, absorb, take it all in. But treat them like a prosecutor treats a hostile witness: take nothing at face value.

When they say "Rails is hype" or "Django is more difficult to teach," ask them why? And keep asking until you get an answer that makes sense. And then go confirm it yourself, like any good journalist.

To borrow a phrase, if your mom tells you "I love you. Oh, and Django sucks!", confirm it.

Some ill-considered thoughts about The Texas Tribune

Thu, 05 Nov 2009 17:55:00 +0000

The much-anticipated launch of The Texas Tribune took place Tuesday, and I thought I'd scribble down a few thoughts about the site. I know it's hardly fair to critique an enterprise that is merely hours old. And as of yesterday morning, they were clearly still working out some bugs... doh!

But this is the internet era, after all. And if the web is tailor made for anything it's precisely this sort of half-baked, half-thought-through, ill-considered commentary written by someone who has no real expertise per se, but plenty opinions. Welcome to the web Texas Tribune!

I'll come back to the content in another post, after spending more time with the site. But today I wanted to focus on the first impressions: The concept, and the design.

* Concept: The Big Idea is great. A nonprofit site doing serious journalism "to promote civic engagement and discourse on public policy, politics, government, and other matters of statewide concern." It's a big Big Idea, but in Evan Smith, who was editor of Texas Monthly, they have someone who has the juice and experience to make that happen. They also have an impressive lineup of reporters, technologists and multimedia folks to translate the vision into something tangible.

Like many of the journo nonprofits cropping up these days, the Tribune will distribute its work through its own website and via "distribution partners." That's not only smart, it's necessary. Building a brand and destination website from scratch is tricky business (just ask Geoff Dougherty) so getting your name out there in as many outlets as possible is a very good idea. Where the Tribune goes that others have not is the idea that the organization can provide a platform for civic engagement through its "on-the-record, open-to-the-public events."

Interesting idea, and somewhat reminiscent of the civic journalism movement that captured the imagination of so many academics (and so few journalists) during the 1990s. I wasn't a fan then, but for an organization like the Tribune this might make some sense. The notion that public-interest journalism should be about solving problems -- or at least acting as a conduit for dialog between the public and The Man -- isn't such a bad idea, particularly now that the web offers so many cheap and easy tools to facilitate such a dialog.

The problem the Tribune faces is the same problem all of these journalism startups face: They are new, small and, at least initially, won't have the cache of other, more established media organizations. That means they will be easier for the afflicted and the comfortable to ignore. But, perhaps, this is where the partnerships come into play. It'll be interesting to see what they come up with.

* Design: Real designers I know (read: people who actually know what they are talking about) may disagree, but I'll be blunt: I. Love. This. Site.

Love it!

I'm super glad they didn't overthink this, and they so easily could have. Having done this web thing now for a couple of years, I have an ever-growing appreciation for simple, clean design. Simple is hard -- harder than hard. Hard to do well, and the Tribune does it very, very well. Kudos to the technology and design team for not trying to "innovate" where tried-and-true design patterns will do nicely, thank you very much.

The Tribune has a very traditional, very newsy look and feel: Three columns, feature position upper left, three promo slots along the top of the page, three smaller feature slots adjacent to the center well, a sea of headlines/links below that. Good! The headlines are big, bold and black. They contrast nicely with the sans-serif body text. Also good! (Are you listening L.A. Times?) I especially like the limited color palette, which makes the right things pop.

The Texas Tribune is the latest site to embrace the big, black horizontal navigation bar, and I think it may be the best of the bunch. Sub-navigation, for example, is very tricky business, but by adding just a hint a color to the navigation bar, it clearly indicates to the reader that there's more to see.

The best design on the web is one that doesn't surprise or confuse your readers. When attention spans are measured in nanoseconds, all other considerations are secondary. Predictable is good, and the design staff obviously kept that firmly in mind. Nicely done.

A few quibbles:

One suggestion would be to keep the story synopses to a single sentence, or two at most if it's in the feature position. Headlines need to be descriptive and punchy. "A brief history of fratricide," for example, is clever. But the way-too-long synopsis gives readers (at least this one) no clue really what the story was about until the last sentence.

All you really need, actually, is that last sentence: "Party faithful want to stay above the fray: Primary challenges to longstanding incumbents tend to get rough quick." I would read that story.

The organization and order of the entire center position and secondary feature positions confuses me. I get the idea: rotate those four stories through the center well randomly, and give people something fresh to see each time they come back.

The trouble is, not all four of those stories (at least as I am looking at the site today) are worthy of the center well. One is a day old, and presented completely out of context from the story that it, presumably, is following. There's no "related" link. No graphical treatment to indicate to readers that this is a series of stories. Not even a link in the follow story back to the initial piece. Odd, and not very webby.

Other stories don't have this problem. A story about a recent statewide poll does link to previous stories, which is good. There's also a list of related stories in the c column, which is even better. I think this kind of treatment should be standard fare: more organic links to related stories in the body text (and please just link to them in context; don't use "here" or, worse, "click here"). Also, I kind of think related links should go on the homepage under the synopsis, and in the in-line promo on the story page, not buried in the c column where few will notice it. God invented the c column for ads anyway.

One tiny content-related nit: The story mentions on the bottom that the margin of error was "+/- 3.46 percent." I'm willing to wager my right arm that should be "3.46 percentage points."

Getting back to the homepage, I think the idea of rotating feature stories randomly is interesting, but probably not necessary. Maybe I'm old school, but I say pick something to feature and go with it.

A bigger issue is the relationship of stories in the center position to the rest of the page. As I said earlier, one of the stories in the center rotation is a day old. To my mind, the only reason to keep a story in a feature position so long is because it's of major importance, which, apparently, the piece on dropout rates is. But if that's so, I shouldn't have to land on it by chance. A day old story should be in the center, or migrated gracefully down the page. But where?

The relationship between the feature well and the sections just below it ("More Top Stories" and "The Rest") is unclear. I'm not even sure I understand what these lists are: "More Top Stories" is fine, and makes sense. But what is "The Rest"? It sounds like a place stories go to die, but looking at what actually is in there, that's not the case at all. It looks, at least right now, that "The Rest" is where multimedia goes -- so why not just call it "Multimedia"?

Oops, wait. As I was writing this, something called "The Brief" showed up in that list. It appears to be a daily roundup of news from around the site, and the web at large. OK, now I'm really confused.

Anyway, this needs some looking into, because some of the multimedia is pretty interesting -- especially Evan Smith's interview with Dan Bartlett. And all of it is more recent than one of the stories in the feature positions. Why aren't these worthy of a feature position? Odd.

Further down the page, things break down a little bit. The modules in the c-column I'm not in love with, and make what's in them feel like third-party content, and not a part of the rest of the site. If it were up to me, I'd pull TribWire off completely, and integrate it with stories as related links where appropriate, perhaps with some kind of icon to indicate that this is a related link off the site.

Regardless, this is far, far too much prime real estate to devote to this feature. Meanwhile, other content that is kind of important is getting buried. I'd shift the blogs up to the top of the column (they really shouldn't be below the fold), and pull them out of that chunky module so they feel like part of the site.

Tweetwire is an interesting idea, but I'd rather see it further down the page, or just promoed. And unless you have seen such features before, it's a little hard to figure out at first glance what it is -- even if you are a Twitter user. It's also not helpful that readers see only one tweet at a time, which may or may not be interesting or helpful in figuring out what it is. (I just learned that Michael Williams, who serves on the Texas Railroad Commission, is going to use an electric razor for the first time this today. Good luck Michael!)

A little lighter touch on these modules would help, and rearranging them on the page would be a big improvement. I would promote the blogs and most emailed/viewed/blogged/searched modules up the page, and move TweetWire and TribWire down. Or even off.

Finally, the site is a bit light on social media tools and, especially, RSS. There's no autodiscovery anywhere to be found (at least that I was able to find), and although features that scream for an RSS feed (TribWire, Our Blogs) have them clearly marked in the homepage modules, there's no autodiscovery or even a link to the feed inside the site. As for social media, that's a little trickier to implement well, and I'm willing to bet it's tops on the list of coming features.

Having said all that, nothing I've mentioned here is fatal, and most of it is fairly nitpicky (and in some cases, I'll grant you, a matter of preference). All in all, the site is outstanding -- an amazing piece of work, given the insane time constraints the development team was working under. I'm really looking forward to reading more.

UPDATE: Brian Hamman is insisiting I disclose that Matt Waite and Chase Davis, who I believe worked on the backend and CMS for the Tribune, are friends of mine -- even though I'm sure neither had a lot to do (if anything) with the design. But, Brian was threatening to out me on Twitter, so there you go. (Happy now?)

Snow Leopard Ugrade Nightmare

Wed, 28 Oct 2009 13:01:00 +0000

I dumped my last Windows box well over two years ago, which means the pain and suffering of OS upgrades were, unfortunately, a distant memory when I pulled Snow Leopard out of its plastic sheath last Friday. If I had flashed back to those horrible days of endless backups, clean reinstalls and upgrade utilities that did nothing like what they were supposed to, maybe I would have thought twice.

But every upgrade of OSX to this point had been painless, or nearly so. Stuff broke, certainly. But fixes were easy. And I thought that's where things were headed when I tweeted the following Friday night:

Went to Snow Leopard, and so far so good. New VPN support is killer (goodbye flaky Cisco client). Also, +30 GB of space. Nice work Apple.

What I didn't know at the time was how badly my dev environment was hosed. MySQL was working, but wouldn't talk to Ruby. My Ruby gems were completely messed up. Rails was throwing completely bizarre errors, and lots of things that should have gotten upgraded seemingly didn't.

I did do my homework ahead of time: I knew Ruby gems would have to be reinstalled. I knew MySQL was going to go south. I also expected to be able to fix these problems (both fairly minor) pretty easily. Turned out there was way more cruft on my system than I realized, and suddenly this upgrade went from an outpatient procedure to major surgery.

I'm far from a Linux/UNIX guru, and based on that alone I should have thought twice in retrospect about diving into an upgrade willy nilly. But I figured enough people had done it by now that it would be merely a matter of Googling around a bit when things went wrong. Unfortunately, it turned into a bit more of an epic than that.

Thirty-six hours (and two installs) later, my home desktop is finally up and running just like I like it, with my dev environment (Ruby + Rails + Perl + MySQL) fully restored and functional. And now that I'm done, I'm seeing some of the nice bits of Snow Leopard: increased stability, smaller footprint, 64-bit everything, great VPN support, great support for Exchange, which The Times is moving everyone to over the next few months.

But given everything, I'm not sure it was worth it, and I'm going to think long and hard before attempting to update my laptop or work machine. I think I'll stick with 10.5 for a while on those boxes. I'm writing this up hoping it helps someone out there in the same boat I was late Friday night: confused, annoyed, frustrated, defeated.

The Upgrade

The first signs of problems was Ruby itself. Snow Leopard comes with Ruby 1.8.7, but after the upgrade my Ruby was still 1.8.6. I realized why when I did a which Ruby. Apparently, I had recompiled a new version at some point, because it was pointing to the binary in /usr/local/bin, instead of /usr/bin.

OK, no problem. I got rid of the old version of Ruby, and suddenly we were in business again. It was pointing to the new 1.8.7 version of Ruby.

I decided to check out other parts of the system. For some reason, the upgrade blew away the symlink to the MySQL binary. I knew something like this would happen based on my pre-upgrade reading, and since I was using an older version of MySQL anyway, why not update it? I downloaded the .dmg from mysql, and installed version 5.1.

I then tried connecting from Ruby, and that, of course, exploded. But here too I knew that there would be problems with certain ruby gems because of incompatibility between the 32-bit and 64-bit environments of 10.5 and 10.6. No worries: I simply needed to reinstall, recompile all my gems.

I found this nifty little one-liner to reinstall all your gems in one go, and it seemed to work well. I tried to connect to MySQL again. Boom! Reinstalled the mysql gem, and tried again. Boom!

I tried recompiling Ruby, and that exploded mysteriously on me. I tried compiling MySQL from source, and that failed. I tried uninstalling everything, and reinstalling from scratch. Same problem.

I Googled around for a while trying to find an answer, and never was quite able to figure out what was going on. A few people reported the same error, but none of the solutions helped.

Time for a clean reinstall.

The Clean Reinstall

OK, this was more than I bargained for going in, but heck, I hadn't done a complete systemwide reinstall since I bought this machine, so why not start with a clean slate? Time to dive in.

After a bit more research, I came upon this HOWTO, and decided it made the most sense. I would first make a complete bit-for-bit copy of my entire system on a bootable external hard drive, and then after confirming that everything worked, I would do a clean install on my desktop, and use Apple's really outstanding migration utility to move my user info, applications and data back.

I had just cleaned up my hard drive, so I dove right in to the backup. I downloaded carbon copy cloner, and after several hours (they aren't kidding) I had a fully bootable version of my system loaded onto the external drive. I unplugged my external drive (to avoid any confusion/disaster), erased my desktop hard drive, and installed Snow Leopard, which, again, went without a hitch.

After a reboot, I used the migration utility to copy over my settings, apps and data. That also took some time, but eventually everything was back where it belonged -- what a relief!

Immediately I could see things were better: The OS was picking up the correct version of Ruby. Updating my Ruby gems was no problem, so it was time to get MySQL working.

I first tried installing via the official dmg. That worked, but I was having problems installing the new MySQL gem. I tried the top-ranked answer here but it didn't work, so I decided to delete everything (this worked) and compile from source, which is what Mac guru Dan Benjamin suggests anyway.

Using Dan's excellent upgrade guide I was able to get Ruby updated. The only problem I ran into was that same dang readline error I had before while compiling Ruby from source. I compiled an updated version of readline, but the error was still there. After some googling I found this.

Making that change in the configs worked perfectly, and Ruby compiled and installed like a champ. After tweaking my PATH, I saw this.

$ which ruby /usr/local/bin/ruby $ ruby -v ruby 1.8.7 (2009-06-12 patchlevel 174) [i686-darwin10.0.0]

Perfect.

Everything else went seamlessly, and in the end I had updated Rubygems, Rails and Ruby. I deleted MySQL (again) and followed Dan's guide for compiling it from source. That worked perfectly and after I migrated my data over to the new version of MySQL, I tried logging in from the command line client to check that everything was working correctly. It was.

And now for the real test: Could Ruby and Rails connect to MySQL? They could! The long national nightmare was over.

UPDATE: Against my better judgement, I just upgraded the laptop, which for whatever reason went much, much better than the desktop. I did an upgrade of Snow Leopard, deleted my old copy of MySQL, compiled the new version from source per Dan Benjamin's tutorial above, which worked great. Then I recompiled Ruby from source, reinstalled Rubygems and used that nifty one-liner to update all my gems. Again, went perfectly.

I had one remaining issue: Rake wasn't working right. I couldn't run tests, nor could I get any of the Rails MySQL rake commands to work. When I tried to create a database, I was seeing the exact same error mentioned here. I tried the solution suggested.

sudo env ARCHFLAGS="-arch x86_64" gem install mysql — –with-mysql-config=/usr/local/mysql/bin/mysql_config

And all was well with the world. Hope this helps someone else out there.

UPDATE: Another smallish, but annoying, problem. After I recompiled Ruby, I noticed my buffer wasn't working in an irb session. Arrow up/down would give me "[[A" and "[[B" instead of my previous commands. Ugh. Googled around again, and found this. For whatever reason, when you recompile Ruby from source, this extension doesn't automatically get included. Odd. Anyway, it's a quick fix:

cd ext/readline ruby extconf.rb make $ sudo make install

UPDATE: Another small issue. I use the Komodo IDE periodically when writing Ruby scripts (go ahead... mock me if you must). Komodo comes packaged with 32-bit versions of the debug bundle (ruby-debug-base.rb and ruby_debug.bundle). When I tried to run a script, it threw an error, saying it was the wrong architecture. Simple fix: I installed the ruby-debug-base gem, and then opened the preferences tab and added /usr/local/lib/ruby/gems/1.8/gems/ruby-debug-base-0.10.3/lib to the "Additional Ruby Import Directories" section. Fixed.

Nginx gotcha

Tue, 11 Aug 2009 11:53:00 +0000

Yesterday morning I noticed some odd behavior: Nginx was serving pages with the wrong mime type. All of a sudden, links to cached pages were interpreted as octet-stream, when instead they were just straight-up html.

I suspected immediately that it had something to do with Rails page caching with Passenger plus Nginx, but what? Rails caches pages with the correct file extension, so shouldn't Nginx pick up on that and serve the page correctly? Turns out it's more complicated than that.

Part of the problem is the way Rails requests are structured. Rails requests don't contain file extensions, for obvious reasons. A request for my "About" page would look like this:

http://aronpilhofer.com/about-aron-pilhofer

In a dynamic application, that's no problem. The request gets passed to Rails through Passenger and Rails responds by rendering the correct action. But if you are using page caching (as I am), Rails never gets the request by design. Nginx should get the request, and then serve the cached page without ever hitting Rails.

But how does Nginx know that about-aron-pilhofer actually means about-aron-pilhofer.html? I am not entirely sure, but I suspect this is part of the magic of Passenger. On Apache, caching just works without any additional configuration. Not on Nginx, though.

I tried changing defaults, playing around with the mime types file, all to no avail. No matter what I did, cached pages were being served as binary data.

Thanks to Ezra Zygmuntowicz for proving me a clue to solving the problem in a sample config file he posted on his website. Turns out, putting in a rewrite to handle this problem solves it.

if (-f $request_filename.html) { rewrite (.*) $1.html break; }

Very simple. All this does is check to see if the incoming request continues the extension .html. If not, it appends it to the request. If that page exists (meaning it's cached), it gets served. If not, the request is passed to Rails, and all is well with the world.

Trying something new

Sun, 09 Aug 2009 16:48:00 +0000

Yep, trying out the new version of Typo, which seems to a big improvement, actually. Seems to have fixed all the things that annoyed me about it before.