Archive for the 'WebDev' Category

Note: I've reorganized this site to use tags; the category archive remains to support old links. Only posts prior to April, 2006 are categorized. Tag Archive »

Friction, Tags, and Just Writing Something

In my last post, I talked about the forces that prevent me from writing blog posts- factors I collectively call friction. One of the things that I cited was a desire to get things done first- for example, to make some headway on a new project before discussing it. Another version of the same problem is the desire to work out an idea completely before trying to explain it. In this entry I’m going to try and throw caution to the wind, and write about some ideas which aren’t fully formed, but which have been rattling around in my skull for a while.

Another of my examples of friction was categorizing posts. When I first started this site, I wrote my posts in the browser, using the Blosxom plugin wikieditish. Due to the way wikieditish works, I had to come up with the URI of a post before writing a post. Because my URIs reflect my post category tree, that meant that I had to categorize my post and name it before the first word was written. This is a little extra friction at the beginning of the process, when I’m still trying to figure out how to an idea into words.

Today I use Blapp to write my posts, which lets me name and categorize my post after it is written. This has reduced the friction of starting a post, but I still encounter friction when I need to categroize my posts. My category system, which you can see in the “More” boxlet on the side of this page, is a hierarchical system that evolved mostly in the first few months of the site’s life. As time has gone on, I’ve regretted some of the decisions I’ve made, and I’ve been reluctant to add new categories, because they don’t fit into the existing structure as well as I’d like.

Blosxom supports both date-type URIs and category URIs; this post is available both ways:

(Edit: the date-style link seems to be busted at the moment, I’ll ty to track that down tommorow. But it should work). I decided to use the category model for all of my internal links, trackbacks, etc., because they are nicely hackable along the category axis. On the other hand, the date URIs are nicely hackable along the time axis.

The friction is really tied up in the category tree. Besides the issues with the hierarchy, sometimes a post seems to qualify for multiple categories. There are ways to hack this into Blosxom, but none of them are very elegant, and have the side effect of further polluting your URIspace with additional permalinks, one for each category a post is placed in.

A solution I’ve been mulling would address a couple of these points at once, and that is to move to a tag-based categorization scheme, a lá del.icio.us, flickr, et al. Using a tagging system, a post can be tagged with as many tags as needed. Category style URIs would give way to tag-based URIs, which are actually index URIs rather than permalinks. For example, to see all of the pages I’ve bookmarked via del.icio.us and tagged as webdev (web development), you can visit http://del.icio.us/jason/webdev. In this case, I think the best candidate for a permalink becomes the date-style URI.

Tagging has been a hot topic for a while, but I’m going to sidestep the entire debate over taxonomy vs. folksonomy and simply talk about ways such a system would be useful. The ability to cross-tag a post I’ve already mentioned. Another benefit is the ability to automatically provide links to related material in other places. For example, a post about web development could automatically include a list of recent articles from this site with the same tag, and a link to that tag’s index on del.icio.us.

For another example, look at Technorati tags. This system allows you to tag posts in a way that lets Technorati aggregate your post with others that share that tag. A blogging system using tags could generate the Technorati tagging markup automatically, and could even show links to Technorati’s page for that tag (See Tantek’s site for an example of this in action.)

But why stop there? Another form of blogging friction I suffer is the need to link. I find it slowing and distracting when I’m writing a post to go hunt down URIs to things I want to link to- even related posts on my own site. Tags could help here as well, by adding tag lookup to authoring tools. If you haven’t used it lately, go check out the standard del.icio.us posting bookmarklet. If you have a del.icio.us account, click here to trigger it now for this page; your back button will bring you back. It has some cool new features, like a list of tag suggestions based on the content of the page being bookmarked (sometimes- if you don’t see suggestions, try it on some other pages). Now picture a blogging tool that analyzes as you type, suggests tags, and then suggests links to like-tagged content via services such as Technorati tags and del.icio.us, as well as posts from your own site. Instead of hunting down links, your authoring tool hunts them down for you. And with the groovy new Ajax stuff all the cool kids are playing with lately, you could even do this in a browser-based authoring tool.

I’ll wrap up for now with a teaser/segue to a future post- I’ve been toying with this idea for a while; and I’m of the opinion that as much as I like Blosxom, it’s not the right tool for this job. So, like scores of other wheel-reinventing programmers before me, I’m considering writing my own blogging software. But that’s another post.

Friction

If you’re a regular reader, you haven’t really been reading me regularly for a while now. This is because I haven’t been writing here on the site regularly for some time. The home page displays 10 articles at a time; as I’m writing this (prior to posting this), the oldest article is from March 22. Today is June 12; I’ve only managed 10 articles in the past 3 months.

This weekend I’ve been reading Joel On Software. While I’ve read a number of Joel’s more frequently linked articles on his site (from which the book is culled), I’ve not read alot of his material, so picking up the book seemed like a good choice. I always prefer hardcopy for extended reading. One of the topics he expounds on at great length in the book is the need for writing good functional specs. I found this interesting, as I’ve recently been battling my inability to write at work- not on specs, but on documentation. Joel gives this advice:

Writing is a muscle. The more you write, the more you’ll be able to write. If you need to write specs and you can’t, start a journal, create a weblog, take a creative writing class, or just write a nice letter to every relative and college roommate you’ve blown off for the last 4 years. Anything that involves putting words down on paper will improve your spec writing skills.

(from Painless Functional Specifications – Part 1: Why Bother?)

And of course, he’s right. That’s one of the reasons I started this weblog. And yet I don’t write enough. I attribute this largely to friction – things that make the act of writing a blog entry more effort then necessary.

One example of friction is the posting interface- when I first started the site, I posted everything via a simple web form, which was functional but it required me to pick a category before writing the entry. This doesn’t sound like much friction, but friction is cumulative, and every little bit hurts. Also, editing large amounts of text in a browser edit box isn’t really alot of fun. Worst of all, I couldn’t begin a draft and leave it till later to finish – I could only post completed works.

Last December, I started using Michael McCraken’s Blapp, a dedicated OS X editor for Blosxom weblog posts. It lets me write locally, see a preview of my post using my own templates, I can write the entire post before assigning a category, and I can save my work without posting it. This all amounts to lower friction, and it has made it easier for me to write for this site.

Another source of friction is inertia- the less often I post, the harder it is to get around to posting. To that end, I’m going to challenge myself to post here more often. After the November Blogging Challenge, I’m not going to try and hold my self to a post a day. Instead, I’ll shoot for a post every other day.

Another source of friction has been concern over content; I’ve often tried to keep my posts to a certain technical scope (which at other times I’ve ignored wholesale), to this end I’ll try and loosen up what I post about. A special case of this problem is a certain aversion I have to the release early, release often mindset- when I have a project in mind that I might want to tackle, I have a need to get a certain amount of progress under my belt before talking about it. In my defense, this site contains a number of examples to the contrary- things I’ve posted with “more info to come later” which never came. Nonetheless, I’m going to try and follow Les Orchard‘s example, and post about whatever I’m currently tinkering with, even if it won’t come to fruition.

Ultimate Blogger

I hate reality television. I continue to be amazed that the fad hasn’t followed disco and parachute pants into our collective Gallery of Things That Seemed Like a Good Idea at the Time. But this post isn’t about reality TV.

This post is about a blogging contest, set up in a Challenge/Win Immunity/Vote Someone Off format popularized by the aforementioned “genre” [As you read, make air quotes. -Ed.] Ten bloggers will be chosen from among the applicants to compete for six weeks in The Ultimate Blogger. Having participated in a number of blogging challenges in the past, I’ve seen firsthand how they can energize a flagging blogger (that would be me… 3 posts so far this month). This one certainly looks like fun, but I don’t think I’ve got the time to play. Besides, I doubt I’d make it past the application… only 10 contestants will be chosen.

But don’t let that stop you from applying. There are several of my favorite bloggers I’d like to see participate in something like this. If you don’t know who you are, check the blogroll. There are even prizes (circa $500 worth). And who knows, maybe I’ll give it a shot anyway. Deadline for applications is Friday, April 29, 2005 at 8:00 pm PT*.

* Footnote: The application states 8:00pm PST. PST is, of course, Pacific Standard Time. To the best of my knowledge, there are no areas in the U.S. Pacific Time Zone that do not use Daylight Saving Time*, so I think they meant 8:00 pm PDT. If so, your deadline is an hour ealier than you think. Yes, I know I’m being pedantic, but I’m a programmer- what do you expect? Also, I spent the first fer years of my professional life designing call-center scheduling software, so I tend to get picky about date and time math.

* Footnote to the Footnote: Yes, it’s Daylight Saving Time, not Daylight Savings Time. Yes, really. Want to learn lots, lots more about Daylight Saving Time? Check out the Webexhibits.org Daylight Saving Time Exhibit, one of my favorite sights on the web.

On Support

Simon Willison points to a Forrester Reasearch publication (being offered for $49) that cites Greasemonkey as a reason for corporate IT departments to delay or avoid Firefox deployments. For those unfamiliar with Greasemonkey, it’s a plugin for Firefox that allows users to create custom JavaScript to be attached to invidual web pages, changing their functionality in much the same way that user style sheets can change the appearance of a web page.

Simon calls the report FUD, which it may be, and defends the right of corporate web users to employ such means:

…tools like Greasemonkey are a fantastic way of fixing issues with the atrocious interfaces found in many “enterprise” web applications.Workers who use Greasemonkey to improve their productivity by fixing problems with internal applications should be applauded.

While I have nothing against Greasemonkey, this statement gave me pause. It reminded me of a parallel situation I have seen often as a corporate developer- Excel VBA Macros. Working for a financial institution, many of my non-IT co-workers are advanced power users of applications such as Excel- but they are not programmers. Many is the time that I (or my department) have been called because some business process is broken- only to learn that the process is one we’ve never hear of. Most often it is an Excel solution that uses VBA macros, which usually begin as a recorded macro and grow over time, and that was developed by an end user. When we are called in, often the original author is no longer with the company (interns are notorious for building these things). The end user only knows how to push a button, and has no idea what to do when they see a VBA error dialog.

Why do these grassroots solutions break? Ignoring for a moment the questionable nature of Excel in general and VBA macros in particular, there are still many factors. Foremost is the fact that these users aren’t developers. These solutions generally have no error checking (or worse, on error resume next, VBA’s way of saying, “Don’t stop just because it’s broken”). These solutions are often built from a recorded macro, and so they have all of the implicit assumptions the user made when recording the macro. Just because your query returned data in column K doesn’t mean it always will. Another major factor is lack of awareness- the users don’t know when things external to the app will change- DB schema, filesystem paths, etc- and the IT department doesn’t know that some guy in accounting has a macro that will break when the upgrade the file server next weekend and change the server name. In addition to these problems, there’s no Q/A, no source code control, and no documentation.

So when the inevitable day comes, when Joey Intern is long gone back to college, when the third or fourth person to inherit this spreadsheet gets and unexpected error or incorrect results, what do they do? They call the helpdesk, of course. The helpdesk has no record of such an app and no documentation on how to support it. Yes, they can support Excel, but they have no clue what the macro send_daily_faxes does or how it works. So they send the problem to the developers- whoever has VB and/or Excel experience. Now we (development) have to support something we’ve never seen, not written to corporate standards, with no documentation.

The developers will calmly tell the user that this is not supported, that we have no idea where it came from or what it does. Sometimes they have to accept that, and if the need is sufficient, make a request for the development staff to build a tool which does the same thing (as they should have dome from the beginning). Sometimes, the developer has to bite the bullet and kill the better part of a day figuring what to fix so he can fix it. After all, if this thing has been used for the past three years to send faxes to clients each day with important financial info, we can’t just call the client and say, “Sorry, your daily fax was sent with an unsupported tool. We’ll build a new tool in month or two.” Even then, we try to schedule work to replace that macro with a supported solution.

I hope the parallels are obvious. While writing custom JavaScript for use with Greasemonkey is more complex than recording (and extending) an Excel macro, there are those who will try it. Every such modification that becomes critical to daily operations will eventually be shared and/or handed down, and one day they will break. Who will fix them?

Goodbye, Yahoo

For someone who has been in the business as long as Yahoo, they sure have a stupid bot. The Yahoo (neé Inktomi) Slurp bot often requests completely strange URIs constructed from various things on my pages. Take this access log entry, for example (split onto multiple lines for clarity):

68.142.249.168 - - [27/Jan/2005:19:29:58 -0800] 
  "GET /weblog/Miscellany/About/xxx@xxxxxxxx/CoolStuff/Potpourri/Spanish/
        Hardware/Toys/Miscellany/WebDev/Browsers/Programming/Rants/Apple/
        Music/XML/XSLT/XML/XSLT/Spanish/WebDev/Blogging/Hardware/Apple/
        Programming/Microsoftish/ HTTP/1.0"
  200 5798 "-" "Mozilla/5.0 (compatible; Yahoo! Slurp; 
        http://help.yahoo.com/help/us/ysearch/slurp)"  

Yes, the URI contained an email address in that rediculous chain of categories (which wasn’t mine, so I elided it). In the bot’s defense, Blosxom will take the URI in stride, and return a page with no entries. There are plugins to modify this, which I may look into. Also, my comment system has a bug that can result in bad links when a bad URI (or no URI) is supplied. However, I don’t think that URI is naturally occuring on my blog. Even if it is, I don’t see any other bots asking for things like this.

Speaking of other bots, so far this month Yahoo Slurp has sucked down over 4 times the bandwidth that Googlebot has used. During this period, Google has delivered over 2600 hits, while Yahoo has delivered 107 (for those keeping score at home, MSN has delivered 23 hits).

So, 400% of the overhead, 4% of the return. Fortunately, I’ve found a way to tweak these figures, by adding a new entry to my robots.txt:

    User-agent: Slurp
    Disallow: /

Toodle-oo, Yahoo.