Weblog
Try Ruby!
I'm intrigued, perhaps even impressed by Why's Try Ruby!, an interactive, in-browser Ruby tutorial. It really is quite a fascinating collision of technologies.
It's almost painfully Web 2.0 - I'm pretty sure most of the buzzwords are there - Ruby, Ajax, that sort of thing. All sat on top of the ubiquitous Json and Prototype libraries.
It's a neat idea, and a useful tool in learning what is a very interesting programming language, but it displays something which is has become alarmingly common in the Web 2.0 landgrab - a complete disregard for the usability conventions and metaphors that have made the web such a success in the first place. Want to bookmark a particularly useful page of the tutorial? Oops, no, sorry - you can't do that, best start again. Want to hit your 'back' button and run over that tricky last section again? No such luck.
I don't want to sound like a miserable old bugger (well, maybe just a little), but I'm starting to fear for the future of HTTP. I'm nostalgic for TBL's original design.
Still, everyone has the sense that we're in a fascinating and exciting phase in the Web's development - even I can't deny that. It will be interesting to see how this pans out.
URL File Extensions Considered Harmful
A recent conversation with a colleague reminded me of just how much I hate seeing programming language file extensions in URLs. You know - .php, .asp, .cfm and the like. There are several reasons why we avoid them like the plague.
First off, what happens when we change platform from PHP to ASP/Ruby/some other language? You have the choice of scrapping your existing URL schema (considered harmful), setting up a whole lot of redirects or rewrites, or maintaining a naming convention that no longer represents your platform.
It sounds unlikely to happen - how often does a non-trivial site or app migrate to a whole new development platform? Well, anyone who has worked in the industry for more than a few months knows the answer to that. PropertyMall (just an example) has moved from static HTML to Perl to PHP3, 4 and 5 in its lifetime. As a result, we're stuck with lot of rewrite rules supporting legacy URLs, but next time it happens, there will be one less thing to worry about.
There's a more academic objection, based on the very essence of HTTP and the web. Now, if I request a resource ending in .xls, I want to receive a spreadsheet, right? So, if I request a file ending in .php, I want to be served some PHP code! But what I get is HTML. Well, OK...so should the URL end in .html? Maybe - but that breaks down too, say, if we were to dynamically send HTML/WML/XML/etc depending on whether the agent is a web browser, or a phone, or an internet-ready washing machine. HTTP is designed to take care of that stuff for us, so we should never be relying on file extensions.
Aside from that, I can't help but feel that it just looks clumsy and amateurish: it certainly betrays the fact that the author simply doesn't know how to decouple the URL schema from the filesystem - a WTF in itself. There's also some debate about whether Google (etc) really 'likes' pages that it believes to be dynamic, and therefore likely to change. That said, one thing I won't be discussing in detail here is SEO: there's enough blogs about that sort of thing already.
'lo world
'lo world