Up and Running in Drupal
Welcome to the Drupal version of my blog. It looks only slightly different from the Rails version, and I’m proud of that, because it signifies my emergence from the Drupal theming learning curve. It also looks like itself in Internet Explorer 5 and 6, which is an even larger accomplishment.
It takes more than a day to learn how to theme Drupal
As I mentioned below, I’ve been learning Drupal. My practice exercise is to build a blog! Surprise, surprise.
So, I’ve been porting this blog to Drupal. Getting Drupal to emit “hello, world” took less than an hour. Getting all the initial modules tweaked and exploring the nooks and crannies of the admin interface took another few hours, after which I had a blog just like this one, except with comments and an RSS feed and a working full-text search. I may even have tagging, if I decide that I want to turn it on. All that I’m missing is the content and the visual design.
Which turns out to be the hard part. It’s not immediately obvious how to move your old site’s content into Drupal, and even after I found the Node Import module and made it almost work… I found that some of my posts had been cut off during the transfer, for mysterious reasons. I’m still not sure if the bug is in the 5-minute Ruby script that I whipped up to convert my blog posts into a CSV file, or in the module itself. Meanwhile, woe betide you if you accidentally click the button which “cleans up” after your inserts: you will end up doing the insert twice.
And then there’s the visual design. I started on it this morning, and it turns out there’s a reason why Drupal themers are in such high demand: Drupal theming is hard! Even after I took the Lullabot team’s advice and started with the elegant Zen theme as my model, I found that HTML and CSS was arriving in the final document from mysterious locations deep in the source tree. Just getting the search box and the “Search” button to change places was an hour’s work, involving reading the (wrong) HTML and noting the CSS classes, getting a refresher course on the Drupal Form API from Pro Drupal Development (do not attempt Drupal coding without this book), grepping the Devel module’s list of Every Drupal Method Ever for the relevant page, grepping my entire Drupal source tree once or twice, and finally overriding theme_search_theme_form, which sounds like something Porky Pig might have written but which actually makes a strange kind of sense, now.
So don’t look for the new version of the blog before next week. :)
I change blog software more often than some people change socks
I’ve become a cliche: the person who updates his blogging platform more often than he updates the actual blog.
Various charming, intelligent, and overworked Drupal developers have convinced me to give their favorite system a try, and so I’ve been happily studying Drupal for several weeks now. I built a very ugly and silly Drupal test site for practice, but unfortunately all the best parts are behind the scenes, in the admin interface. The front end looks dreadful, because I’m still getting the hang of that whole “theming” aspect of Drupal. “Theming” is a technical term for “making your site look different from the drupal.org homepage, while not looking like a traffic accident.”
Meanwhile, I’ll reveal my secret shame: instead of writing posts for my own blog I’ve been commenting at Hacker News.
Learning to live with the closed iPhone
The iPhone story continues to unfold at breakneck speed. Since I last thought about buying one, we’ve gone through the initial-rush-to-buy era, the third-party-applications era, the SIM-unlocking era, the drop-the-price-by-$200 era, the iPod Touch era, and (most recently) the enrage-the-hackers-by-disabling-third-party-apps era. Elapsed time: less than four months.
(No, I haven’t got one yet. Waiting this long has already saved me $200 and increased my options!)
Mark Pilgrim claims not to understand why so many techies are obsessed with hacking the iPhone:
I thought the big draw for Apple hardware was that “It Just Works.” By breaking it, you must know you’re giving up the “Just Works” factor, so what’s left? Rounded corners?
It’s easy to claim that the iPhone “just works” if you live in the United States. For anyone else in the world, the iPhone is broken. It’s not mere hyperbole when European hackers claim that they are trying to “fix” the iPhone.
And the hackers don’t want to give up the “Just Works” factor —- they want to tweak it, by adding a couple of extra apps here and there. It’s precisely because Apple’s platform works so well that so many people prefer cracked Apple hardware over other companies’ open platforms.
What are the alternatives? Reviews suggest that you can get much of the iPod Touch functionality from a Nokia n800, which runs an open Linux-based OS. But the Nokia costs more, has dubious video-playback speed, lacks the scrolling or pinching interface of the iPod, has a much less elegant design, and doesn’t work with iTunes. And, of course, it’s not a phone. The OpenMoko is a phone, but at its current rate of progress it might not ship before the Apple/AT&T contract expires four years from now. (The latest news: it is finally possible for one OpenMoko to call another. This is impressive work for a distributed open-source team, but it won’t be competing with the iPhone in this decade.)
The other reason to want third-party iPhone apps is greed. There are millions of iPhone users, so a successful iPhone app has a huge potential market. A successful OpenMoko app is worth exactly nothing at the moment.
Having said all that, I agree with Pilgrim’s main point: if Apple wants to run a closed platform, it’s their choice. It’s hard to argue with the success of the iPod, which (apart from an energetic minority of RockBox users and a slightly larger minority of Linux users) runs in a closed software ecosystem. The iPod works so well because its designers refuse to offer too many confusing choices. It really isn’t intended for hackers. It really is intended for everyone else. Those of us who don’t like that will either have to relax or devote our energies to a more hacker-friendly hardware platform.
I’m leaning toward the “relax” option in this case.
Private photo galleries: a bad choice for one's first Drupal project?
I’ve spent the last day or two trying to pick up the Drupal content management system. So far, I can confirm that Drupal is fairly easy to set up, and that the Lullabot Drupal podcasts are really nice. In particular, I liked the one on obsolete Drupal modules, because it gives you a fairly good sense of what to study first. (Not surprisingly, the answer seems to be “CCK and Views”, which is what I’d already heard.)
I decided to try to build a little photo-sharing system, analogous to Flickr. This is, of course, almost as big a waste of time as (ahem) building one’s own blog software, but I figured it would encourage me to figure out how things worked, and would allow me to incorporate my personal killer feature: the ability to have a private photo blog as well as a public one, and to invite certain friends and family members to look at the private photos.
The good news is that there’s a Lullabot page called “How to build Flickr with Drupal” . Awesome! Except, um, the article is a year old and uses techniques (like the Image module) that the very same Lullabot folks now decry as “deprecated”. Not so awesome?
Not to worry. Other helpful users have provided hints on how to use the more modern Imagefield and Imagecache modules to build an image gallery. But my private gallery idea quickly hit a snag: the Imagecache module refuses to work with an access-controlled directory of image files, and the patch isn’t quite ready yet.
The rest of the image upload process isn ‘t very clear, either. Indeed, it turns out that the presence of multiple, incompatible, half-built image modules is a well-known unsolved problem in Drupal, which I just happen to have stepped directly into.
Perhaps I need a different starter project. After all, it turns out that Flickr has already implemented the private photo blog.
Font selection is harder than I thought
I just got finished looking at the old design for this site in IE7 and Firefox for Windows. Yikes. I hereby apologize to all my Windows-using readers for the Courier New. I had no idea what I was inflicting upon you. So now you get Georgia, which is a lot less offensive.
What is up with Firefox for Windows and its font rendering? All my characters look anemic and thin, and the small caps in the tagline have the jaggeds. Things are much better in IE7. I guess I had better go look at things in IE6, but not before bed, lest I provoke nightmares.
I also recommend that Windows users switch to the Mac immediately just so that they can see my titles in the American Typewriter font that (in my amateur’s view) suits them so nicely.
Test your Rails app as it deploys to production
This blog uses the handy BlueCloth gem to provide Markdown syntax for writing posts. (And, eventually, for writing comments, but we’ll get to that.)
The problem is that I got everything working on my development server, but when I deployed the code to production using Capistrano and Deprec… boom! No BlueCloth gem, no functional app, lots of ugly black smoke.
(Okay, it was Rails, so it was nicely formatted black smoke with a fairly clear error message. But, still.)
The good news is that I had several unit tests that checked for Markdown support. The bad news is that none of those tests got run on the production server as the app was being deployed, so they were kind of useless. Fortunately, Peter Marklund has come to my rescue:
desc "Run the full tests on the deployed app"
task :run_tests do
run "cd #{release_path} && RAILS_ENV=production rake db:test:prepare"
# note how the cat /dev/null writes emptiness to the test log unless the tests
# generate an error condition - I learn some UNIX every day.
run "cd #{release_path} && RAILS_ENV=production rake && cat /dev/null > log/test.log"
end
desc "Run pre-symlink tasks"
task :before_symlink, :roles => :web do
run_tests
end
Still a few bugs in the system
Proud as I am to have deployed my first Rails app, I need to get busy building the bug database, because the posts are coming out in the wrong order.
I could actually fix this in two minutes, maybe less, but I think I’ll leave it this way for a day to inspire myself to set up that bug database. In the meantime, since I’m pretty sure Dave Winer once defined a blog as a bunch of posts in reverse chronological order, I’m not sure I’ve really built a new blog.
Use Rails To Write A Blog With Your Bare Hands
I’ve gone and done it: I have written my own blog software in Rails. It’s been a fun way to practice.
It took an embarrassingly long time —- over two calendar weeks from initial conception to initial deployment. Only three or four days of actual work, of course, thanks to this and that and the day job, but that hardly makes it less embarrassing, since everyone knows that a blog takes only fifteen minutes to build with Rails.
I have wondered about the pros and cons of this marketing strategy. On the one hand, I don’t doubt that working in Rails is incredibly efficient once you get the hang of it. (In fact, well over half of my time building this blog has been spent working out the CSS, learning how to write firewall rules, migrating my deployment recipes from older to newer versions of Deprec, practicing with the stock Rails testing facilities… you know, the learning curve. I can definitely imagine building apps like this one inside of a day once I know what I’m doing —- especially if I outsource the design to someone with actual training. :)
But people have a terrible tendency to equate efficiency with simplicity. They think that, because DHH can use Rails to build a blog in fifteen minutes, their cat should be able to build a blog with Rails.
When I watch DHH and other Rails wizards at work, I’m reminded of poets —- who write fewer words than journalists, but sweat more, because every word counts for so much. But when I watch the marketing campaign, I think of the theremin, the first musical instrument that could be played without being touched. When it was introduced by RCA in America in the late 1920s, the marketing copy emphasized its ease of use:
Having made the enjoyment of music universally possible, RCA takes another tremendous step —- making possible not merely the enjoiment of other people’s music, but the actual creation and performance of one’s own music! Now, for the first time in the history of music, anyone, without musical knowledge or training of any sort; anyone, without even the ability to read notes; without tiresome or extended “practice”; without keys, or bow, or reed, or string, or wind, —- without material media of any kind —- anyone can make exquisitely beautiful music with nothing but his own two hands!
Um, yeah. It turns out that the theremin is astoundingly difficult to play:
Still, the strangest irony of the RCA Theremin was its purported ease of operation. To the average consumer, the freedom of space was really a disorienting weightlessness. Even a fretless fingerboard or a slide trombone had something to hang on to —- a point of reference. The theremin called for the acute, inner ear of a singer to sense the location of each note before sounding it, but without any advantage of a physical sensation in the vocal cords or breath. [A] survey revealed that untrained performers preferred a keyboard orientation, with fixed pitch increments. Adding to the list of hindrances, the theremin was capable of playing only slow music, and it required an accompanying instrument or recording. For a device intended to replace the parlor piano, these were serious defects.
Rails allows you to build a website with a minimum of typing (“nothing but your own two hands”). Yet you must have a deep understanding of the Rails design philosophy, and of the underlying technologies, and of the problem domain. I know that the process of learning Rails would be a lot more daunting if I hadn’t cut my teeth on earlier Web programming frameworks.
