Pluto is no longer a planet but a dwarf planet along with two others, Ceres and 2003 UB313. And that means it's time to renew the campaign to rename UB313 as Daes. Why? Because U+B313 is the Unicode character for that symbol in Korean.
Mac OS X 10.5 Leopard is going to have Ruby on Rails pre-installed. It's also going to have Python and Ruby bindings to Cocoa built in (I've been writing full-blown Mac apps recently using PyObjC, giving me the development speed of Python (including the console interface) plus the ability to dive into Objective-C when I need to, for example, muck around with USB). And I also read that tixe, the framework that gives your application programmatic access to what's happening on a webpage, has been rolled into the official Apple browser.
With the right helper libraries, this adds up to Mac apps that are as easy to create and iterate as web apps.
Okay, so it goes like this: You prototype your application by making a Ruby on Rails app, running it on the built-in webserver (Mongrel comes with 10.5 too). After you get it running in a regular browser, you create a shell Mac application: this is just a minimal web browser instance in a window, pre-configured to visit your local Rails app. With a couple of lines of code you set it up to start and quit the webserver when you open and close the app.
Using Interface Builder, you create new elements in the Mac app (buttons, drop-downs, menus and so on). There's a special Rails controller class for dealing with these, so you make that and wire the native UI elements up to existing actions. You don't even need to do http requests because tixe lets you treat the UI elements on the webpage just like the native UI ones. And now the native app is working, you ditch the equivalent actions inside the web view and just use that for displaying data. If you need to tap into system level services on the Mac (like IM, scripting other apps, or whatever), you can.
Ta-da, you've got a Mac app. Sure it's a bit kludgy and not the fastest thing in the world--but it's network native, it's easily deployed, and it's very fast to build. If somebody writes the correct tutorials - and knowing the Rails crowd, somebody will - this substantially lowers to bar to prototyping applications on the Mac.
Dirk is back.
Dirk is the first web toy I ever wrote, an association game for everyone to add to, way back in 1998 (it's linked from the bottom of NTK 1998-09-18), and also how I learned Perl. It disappeared eventually--the interconnectedness means that things in Dirk used to rank really high at Google, and when Google was made the default search engine at AOL... well, it filled up with some pretty nasty connections, faster than I could remove them. I took Dirk down when somebody asked me whether I wanted to be responsible for republishing those words.
I've rewritten Dirk for my own learning a few times, in Perl again, PHP and Python. It's my Hello World app, hitting web apps, databases, general syntax, algorithms and performance. I try to write it as idiomatically as possible each time, and squeezing every drop of performance out of the pathfinding algorithm (which I know pretty well by now) lets me learn what's fast and slow in each language. I had a Haskell implementation going on for a while too, though not a very good one (I want to have another shot at that).
This time it's Ruby on Rails which hits Python's "there's only one way to do it" philosophy better than any Python framework I've used (which is what I've been using recently). And since deployment is as much part of Rails as anything else, I figured it was time to go public again, almost 8 years after the first time.
So: Dirk is one of those six-degrees games, exploring the fundamental interconnectedness of all things. Dirk only learns from connections you make. Take a minute to add a new one. Enjoy.