Blue Sky On Mars

Probably the #1 reason that I’ve been using Firefox instead of Safari has been the lack of “type ahead find” aka “find as you type” aka “that thing where you start typing and it searches the page without having to pop up a window, so it’s like really convenient and you can just press enter to follow a link so it’s good for navigation too”. Acid Search brings that feature to Safari and adds the ability to really expand Safari’s search box. It’s worth noting that Saft, the uber-Safari plugin, adds type ahead find as well.

Another Safari tip that I just learned that will make life so much nicer is that pressing the option/alt key while tabbing through form fields allows you to get to every control, including buttons and combo boxes. It’s always been really annoying to have to reach for the mouse when I hit the “State” field on a form.

Ian Bicking has posted more thoughts on Ruby on Rails. For those of you not familiar with Ian, he’s had his hands in object-relational mapping, web frameworks and even template tools.

Ian’s perspective in this latest article is from short experimentation with Rails, but I agree with the things that he has said that he likes and dislikes. Ian has described Paste in terms that make it sound like a piece of middleware for web framework developers to use in sharing code. While that’s all fine and dandy, I do hope that we’ll start to see some fully-fleshed out packages that provide a good quick start for apps.

If nothing else, Rails has brought to light the fact that starting each new project with a completely blank slate is a real drag.

Being an XP type, I don’t go in for specs for everything. Where interoperability counts, specs are key… and Mark Pilgrim nails the personalities in Why specs matter.

“Angels” read specs closely, write code, and then thoroughly test it against the accompanying test suite before shipping their product. Angels do not actually exist, but they are a useful fiction to make spec writers to feel better about themselves.

Ryan Tomayko had commented on my post from yesterday regarding using HTTP correctly (not abusing HTTP GET, etc.). My posting was following the pragmatic perspective of getting things done without worrying about absolute correctness. I agree with Ryan’s new posting “On HTTP Abuse”. Favoring “getting things done” doesn’t also mean that I don’t want to do things correctly. His post is correct that the frameworks that we use to get real work done just don’t lend themselves to using HTTP fully and correctly.

My guess is that many of the frameworks were created in the process of trying to get some job done. Especially given the nature of what’s easily testable with the browsers we have today, I can imagine how the frameworks we use came to be the way they are. It’s a non-trivial task to make a framework that encourages proper use of HTTP and exposes its full power while still being as easy as what we have today.

But, we do today have browsers that do a reasonable job of HTML/CSS/DOM, so it’s not inconceivable that we could have server side frameworks and browsers that let us really exploit all that HTTP can offer.

A couple weeks ago, one of the Detroit pop stations mysteriously switched formats and started calling itself “Doug FM”. They described their new format, if I recall correctly, as being like you “dropped your iPod in a can of paint”. What it boils down to is that they don’t have a 25 song playlist of current music in some format. They play a variety of things from the 70s, 80s and early 90s (I haven’t heard more recent than that on there).

It turns out that Doug is part of a new breed that also includes Bob, Jack, Dave and other radio stations.

No, I’m not yelling in the title. I’m just following up on Dare Obasanjo’s post about misunderstanding REST: A look at the Bloglines, del.icio.us and Flickr APIs. Dare’s complaint is that these services all have URLs that have side effects via HTTP GET. This is an interesting distinction to make.

I just set up a new Drupal installation, and I’m reminded of Drupal’s cron.php. cron.php runs whatever periodic maintenance tasks are needed. In other words, it changes data. But, you really want to use GET in that case, because it makes it trivial to add a wget crontab entry to ping it periodically.

My own app keeps does housekeeping as links are clicked, which is far easier via a GET than to rig up a POST via JavaScript. Maybe the difference here is whether or not one is making a claim of a RESTful interface. Or maybe the difference is how caught up in the semantics of it one is. Josh Alen has a good comment on this:

people chose between GET and POST based on other critera than suggested in the Fielding paper

I think this is on target. If you’re conciously providing an API for the public to use, following the RESTful standards that Dare mentions is worthwhile, because it helps with the principle of least surprise. But, you also need to look at the overall convenience of what you’re doing… if you have a good reason to bend the rules, do so and make sure you document it. If it’s truly a good reason for rule-bending, it shouldn’t really take people by surprise or throw them off.

This makes me think of the general notion that APIs are a user interface for developers. In Swing programming, to add a widget to a window you had to do this:

frame.getContentPane().add(somewidget)

This is the “correct” thing to do, because the JFrame object itself is not actually a container for UI widgets. But, it has a container: the content pane. Correct or not, it was annoying. Java 1.5 now allows you to do this:

frame.add(somewidget)

Though it is less “correct” for the architecture, I think this is more inline with what programmers expect and want to do with the API.

I don’t know if this is the case with the Bloglines, Flickr and De.licio.us APIs, but my main point is that there are times when user experience is worth more than “following the spec”.

F-Script is a Smalltalk dialect for Mac OS X. Clearly, many in the Mac community are already aware of F-Script, since it won an Innovators Award in 2003. I’d imagine many are always aware of F-Script Anywhere, which allows you to attach F-Script to any Mac OS X program. I wasn’t aware of this until yesterday, so I just had to say “wow! that’s cool!”.

Using F-Script Anywhere, you’ve got an object browser that you can use to poke around at the various objects in a running program, sending messages and getting responses back. Within a couple minutes of download F-Script Anywhere, I was able to send JavaScript commands to my running Safari window. Mac OS X has the coolest software architecture around.

Speaking of the Mac OS X software architecture, Apple has an open source package called Core Foundation Lite, which provides a number of the base classes used in Cocoa development. I knew that Mac OS X’s kernel was open source, but I didn’t realize that some of the framework code was also open source. CFLite is still quite low-level, but it is a way to move some code between platforms.

I’m not exactly sure how it is that I’ve never heard of this before. Maybe I have, but it didn’t make enough impression on me back then. MusicBrainz provides audio file metadata (somewhat like the CDDB), but it does it based on an acoustic fingerprint. The artist/song name/album name tags on my music tend to be of good quality already, but it wouldn’t hurt to do a run-through and cleanup. For the Mac, there’s IEatBrainz to clean up your iTunes library.

All this talk of brains is making me hungry.

Adobe Acquires Macromedia hopefully won’t mean that you need Adobe Reader to view Flash in the future.

This has got to exist already. Today, I was battling trackback spammers. I have MT-Blacklist installed, so they’re mostly just a nuisance, because I have to delete and rebuild all of those entries that they hit.

Then it occurred to me: all of the trackback spam that I have seen has been repeated multiple times on the blog. They never hit just one post, and they’ll often hit dozens or maybe even hundreds.

So, at least for now, a simple solution would be to compare the received trackback with the last N trackbacks to see if there are URLs in common. If so, consider them spam and waste them. I don’t think there’s any legitimate reason to receive the same trackback repeatedly.

Of course, this won’t last forever, because if everyone does this the trackback spammers will just make every URL unique. You can’t work stricly off of the domain provided because of sites like blogspot and typepad. It is conceivable that a popular blog will get more than one trackback from one of these sites within a short period of time.

I would consider implementing this myself, but I’m going to change blog software soon. I’m leaning toward Wordpress right now, because it looks pretty slick.