Articles on About This Blog

When I started this blog almost a year ago, I really wasn’t sure what I’d be writing about. As it happened, it ended up being much more technical than I had envisioned, and focusing a great deal on building and deploying Ruby on Rails applications.

I haven’t written nearly as much as I would like about Rails, in part because this blog felt like not quite the right place for it—I want something with a richer information architecture.

In the past year, I’ve collected a huge list of links to useful blogs, valuable references, ebooks, mailing lists, conferences, and other resources. There’s a tremendous amount of information available on the web, and it’s hard to imagine learning all this technology without the web as a resource. But this information is widely scattered, and while a google search will sometimes lead you quickly to the best resource to answer a given question, often it takes quite a bit of sleuthing. Rails itself makes it relatively easy to build an application to organize and present all this information—a curious sort of virtuous circle.

In the past few months, I’ve been working with my colleague Chris Haupt on just such an application: BuildingWebApps.com. The BuildingWebApps.com main site is currently in a limited private beta, but you can visit the site now and sign up to receive an invitation when we’re ready to accept more beta users.

We’ve begun a BuildingWebApps Blog, which explains a little more about what we’re doing, and will chronicle the development of the site. If you’re interested in Ruby on Rails or web applications in general, please visit the new blog and sign up for its feed.

In my transition to the multisite version of Mephisto, the feed for this site was messed up for a bit. I think I have this sorted out now, but please let me know if you see any problems.

The cause of the problem was, as far as I’ve been able to figure, that I directly edited some entries in the site table in the database, and didn’t anticipate some of the effects. Moral of the story: use script/console to perform your actions through the model, rather than hacking directly on the database.

I’ve just moved this blog to a new server, running a multi-site version of Mephisto. This enables the single Mephisto installation, and one group of Mongrel servers, to service more than one blog.

You shouldn’t notice anything different—but please let me know if you do! This was a somewhat tricky move, and while I think everything is working fine, it is possible there are some obscure issues.

Along the way, I had to learn a bit more about Mephisto’s internals than I had previously, and also had several hours of fun (not!) with Apache’s mod_rewrite. I’ll post the details in a day or two for those of you who are interested in such arcana.

We are (we hope) finally beyond the worst downtime in this site’s short history. Alas, my customers’ sites were down as well, for two periods on Friday and for most of the day Saturday.

What went wrong? There is a chain of helplessness that appeared to end at AtlantaNAP. The company that provides my hosting, Rails Machine, was as helpless as I was to fix the problem. Rails Machine operates about 20 servers in a hosting facility called SiteSouth. SiteSouth, as it turns out, operates a cage full of server racks in a large facility called AtlantaNAP.

Update: In the original version of this article, I laid the blame squarely upon AtlantaNAP. I got a call from one of their representatives on Monday morning stating that the problem was, in fact, SiteSouth’s, and that AtlantaNAP had done what they could to help them out. From my vantage point, I can’t tell who was really at fault here. I’ve updated the article to reflect this ambiguity.

Either AtlantaNAP or SiteSouth had some sort of router problem that apparently caused some or all of the servers in SiteSouth’s cage, including all those operated by Rails Machine, to lose connectivity. AtlantaNAP has many connections to the Internet to provide redundancy, since reliable connectivity is one of the core attributes for a hosting provider. But if a router between those multiple connections and your site fails or is misconfigured, then it doesn’t matter how many connections to the Internet there are on the other side of the router.

That this kind of failure can happen is understandable. For a cohosting facility to take an hour and 45 minutes to correct it is bad, but tolerable if it’s an extremely rare event. But for the failure to repeat twice again that same day, and then for many hours the next day, is really unforgivable.

I suspect some finger-pointing may continue between SiteSouth and AtlantaNAP. Whoever was to blame, both companies are likely to lose some business over this. Within a hour of the first outage, Bradley Taylor at Rails Machine was looking for a new hosting facility, at least as a supplement, and surely the intensity of that effort accelerated as the outages repeated almost unbelievably.

Here’s the log from the site24×7 monitoring service, showing the start time and total downtime for each outage:

• April 6, 7:51 AM: 1 Hrs 46 Mins
• April 6, 9:55 AM: 1 Hrs 17 Mins
• April 6, 2:14 PM: 13 Mins 30 Secs
• April 7, 9:52 AM : 4 Hrs 21 Mins
• April 7, 3:47 PM: 13 Mins 51 Secs
• April 7, 5:33 PM: 1 Hrs 29 Mins

What Happened?

I don’t know yet, and may never know, what really happened. Here’s what I could see from the outside.

Here’s the tracert output for the path from my provider (Comcast) to AtlantaNAP, where the trace bounced back and forth repeatedly between two IP addresses (it repeated more times than I’ve shown here) but never reached my server:

  6    11 ms     9 ms    21 ms  te-8-1-ar01.sfsutro.ca.sfba.comcast.net [68.87.192.137]
  7    10 ms     9 ms     9 ms  68.86.143.9
  8     *        *       14 ms  68.86.90.165
  9    11 ms    11 ms    11 ms  64.215.30.201
 10    71 ms    68 ms    70 ms  NLAYER-COMMUNICATIONS-INC.ge-4-1-0.410.ar4.ATL1.gblx.net [206.41.25.
230]
 11    69 ms    71 ms    69 ms  atl-core-a-tgi2-1.gnax.net [209.51.149.105]
 12    70 ms    69 ms    69 ms  63.247.69.182
 13    69 ms    69 ms    70 ms  209.51.156.5
 14    69 ms    69 ms    71 ms  209.51.156.6
 15    69 ms    69 ms    69 ms  209.51.156.5
 16    71 ms    69 ms    69 ms  209.51.156.6

When the problem was finally (I hope!) fixed Saturday evening, the route changed, getting quickly to my server. All the changes occur in AtlantaNAP’s (or SiteSouth’s) routing. Here’s the current route:

  6    15 ms     9 ms     *     te-8-1-ar01.sfsutro.ca.sfba.comcast.net [68.87.192.137]
  7    11 ms    11 ms     9 ms  68.86.143.9
  8     *       12 ms     *     68.86.90.165
  9    11 ms    12 ms    11 ms  64.215.30.201
 10    69 ms    69 ms    69 ms  NLAYER-COMMUNICATIONS-INC.ge-4-1-0.410.ar4.ATL1.gblx.net [206.41.25.
230]
 11    84 ms    72 ms    71 ms  atl-core-a-tgi2-1.gnax.net [209.51.149.105]
 12    70 ms    69 ms    69 ms  63.247.69.182
 13    70 ms    71 ms    68 ms  207.210.123.118

I hope to have some news in the next few days, in part about what went wrong, but more important at this point, what the plan is for the future for Rails Machine to move beyond SiteSouth and AtlantaNAP.

Tagging has become one of the themes of so-called Web 2.0 sites. Really nothing more than free-form keywording, tagging has proven useful in many contexts. Eschewing hierarchies and controlled vocabularies, tagging reduces keywording to its essence. For many of my uses, though, I’ve been finding it it just a bit too simple.

Tag clouds

Seven years ago, the startup I led (Fotiva) built one of the first photo organizers to use tags, which Adobe brought to market as Photoshop Album. Since then, tags have become a popular organizing method on the web, not only for photos (most notably at Flickr) but also for web bookmarks (such as at del.icio.us) and for blog posts (encouraged in large part by Technorati). Rather than offering any tag hierarchy, typical usage on the web is for all tags on a site (or within a user’s account, for private tags) to simply exist in one big namespace, sorted for display either alphabetically or by popularity. A hybrid listing, sorted alphabetically with type size denoting popularity, has become known as a “tag cloud”.

Hierarchical tags

For me, this approach doesn’t scale well. With more than a few dozen tags, the organization cries out for some further structure. This is true for tags describing web pages as well as tags describing photos or blog posts, but the sheer number of photos I take, and the diversity of their tags, first made the problem acute in that context. I have tags for a dozen different types of boats, for example, and for several dozen places, and for more than 30 people; mixing those together in an alphabetical sequence is counterproductive, yet that is what sites such as Flickr force you to do. In the Photoshop Elements organizer (which is where the Fotiva/Photoshop Album code base ended up), you can have hierarchical tag categories, so I have Places > USA > California > San Francisco Bay > Angel Island, and Boats > Sailboats > Schooners. I have hundreds of tags, and without these categories they would be much harder to use.

A proposal for tag clusters

To use the tag hierarchy in this way, you have to create tags within the hierarchy. Once tags are created, you can apply them in Photoshop Elements using drag-and-drop from the tree-structured tag list.

Simply entering tags as free-text, whether they are new tags or ones you’ve used before, is widely used on the web, and it is the ultimate in simplicity. But it doesn’t provide any clear way to support a tag hierarchy. With a few dozen tags, it’s fine, but as time progresses and you have more tagged material, it becomes less effective.

For blog authors, the problem is similar but has some different twists. For this blog, I have sections and tags, but they have no relationship to one another; they are two orthogonal organizing schemes. Sections are more static than tags; they must be created independently of creating a post. Tags, on the other hand, can be freely created just by entering them when creating a post. Since blog search engines such as Technorati, as well as some photo sites like Flickr, search on the tags, it is important to have reasonably specific tags, especially if you want to associate blog posts or photos with a particular event.

So what I end up with is tags that are very specific, and sections that are very general, but no connection between them. If tags knew what sections they belonged in, then I could dispense with assigning posts to sections as well as giving them tags. I could also list the appropriate tags as an index for a given section, to provide an easier way to navigate it.

Ideally, sections should be created by clusters of tags. For example, posts tagged as ruby-on-rails or php or css should all appear in the Web Development category. The question then becomes how tags get associated with sections. Any time a new tag is used, the blog engine could prompt the user for the section to which it belongs. Potentially, sections could be inferred automatically, using an existing lexicon for reference.

I think a similar approach could work for tagging photos. It could make sites like Flickr more capable organizers, or make programs like Photoshop Elements easier to use for tagging.

I’m planning to explore a Mephisto extension along these lines. I’d love to hear about any experiences you’ve had with organizing tags into clusters or hierarchies to make them more useful.

Those of you who may have started reading my blog for its relatively non-technical articles may have been mildly horrified, or at least repulsed, by my last few posts, which went rather deep into specific technical issues. I’ll continue posting both on business/marketing issues and on technical topics. The chronological nature of blogs mixes all these posts together, so the home page of this blog is schizophrenic.

You may find the blog categories, listed on the left, to be more useful than this home page, since it will sort out the posts by topic.

I have to admit I’m not yet entirely comfortable with the blog’s organization. I’m more accustomed to buildling sites where I have more explicit control over the information architecture. Some things I’ve wondered about include:

• Should articles be in only one section? Many seem to belong in two or more sections, and I’ve been putting them everywhere they seem to fit. But this provides a lot of overlapping content among sections and makes it harder for someone to know if they’ve read what they want without wading through some things multiple times.

• Should all the articles appear on the home page, or only ones of broad interest?

• Should I offer feeds on a per-section basis? Currently the only feed is for the entire blog.

• How useful are tags in addition to sections? I’m currently tagging articles primarily so they are more easily found in Technorati. You can also find other articles with the same tag by clicking the tag at the bottom of the article. Should there be tags in the left navigation bar as well?

• I’m showing full articles everywhere, rather than excerpts, so you don’t have to click through to another page to read the whole thing. But this makes it harder to get a quick look at what all the articles are when there are long ones.

• Reverse chronological order is odd when I write a series of articles that are like mini-chapters; they’re designed to follow one another. But they appear in reverse order in the blog.

• Comments show up only on single-article pages, which are shown after you click on an article’s title, or click the comments link at the end of an article. Will this mean that most people will never see the comments? Would it be better to always show the comments?

I welcome any comments on these issues and expect to evolve the design of the blog as time goes on.

In the past, I’ve always built full custom web sites. I found the design of blogs too constraining; they seem to emphasize ease of entering simple text over all else. The previous mslater.com was a custom, though simple, site.

As I began to want to do more writing, however, the appeal of a blog increased. I wanted to enable comments and RSS feeds, and it seemed like a waste of time to build those features myself.

At the same time, I began moving my web development work from PHP to Ruby on Rails. So this seemed like a perfect opportunity to try out one of the blog engines for Ruby on Rails. And that’s what you’re seeing now: Mephisto.

With Mephisto, I’ve been able to heavily customize the design of the site using simple templates written in liquid. Since the entire blog engine is open source, I can go in and modify the engine itself if I want (but so far, I haven’t found a need to do so). Since it is in Ruby on the Rails framework, the code is clean, elegant, and reasonably easy to understand (once you grasp the Rails conceptual model). It also has a nice, simple asset manager, so I can easily upload PDF files and images and so forth and use them in my postings.

As time goes on, I expect to experiment with the structure and layout more, and I’ll chronicle these efforts here. I have mixed feelings about the simple reverse chronological layout of blogs and hope to add some refinements that improve its usability. Let me know what you think.