Rui CarmoAfter partially clearing my head from both stress and allergy, I've been thinking hard about what to do in my spare time (which includes a big, triple underlined "GET MORE SPARE TIME" at the top of the list).
Besides my omnipresent stack of books to read, I recently added Foreign Affairs to my meatspace magazine list. So far it was limited to Economist (which, incidentally, mentions today's Time Traveler Convention in print), Wired and the occasional local business magazine, but photography and coding are still important distractions.
Despite mounting work stress, I've been working on and off on my NewWikiMigration, already changed the DNS records for this site in preparation for this wiki's migration to the new hosted server, and (yes, I'm finally getting around to this post's main topic) have been mulling what to do in order to learn Rails over the next six months (if it's anything like my half-an-hour-a-week transition to Python, it may well take a year before I spend enough time coding in Ruby to feel comfortable).
So I've been collecting some ideas on what I'd like to do with Rails - besides a decent collaborative Wiki. As usual, the simpler, more intriguing ones pop up in my head unannounced as I'm still trying to wake up...
Mail on Rails
So, let's say you have a gigantic e-mail archive you'd like to search, but you don't want to cart it around with you on your Mac (which, of course, rules out Spotlight). And that you'd like to have a nice, simple and effective web front-end to search for messages on that archive.
(People who are likely to point out Zöe or Lurker should know at this point that I tried both of them and that they have prohibitive server-side overhead, or are not really that useful for me, or both.)
Enter mairix, which is pretty damn fast and can be integrated locally with Quicksilver. But that is only useful if you want to have all your e-mail with you (which isn't my case).
Now picture a Rails web front-end for mairix running on your mail server, with the following features:
- Live Search (of course).
- Dynamic selection of mailboxes to be searched (recursively).
- Preview of query results (a message list would do, but a message preview would be nicer).
- Saving results to a specified IMAP folder or forwarding them to a specified e-mail address.
- For extra brownie points, retrieval of individual attachments.
This would run with access to a separate archive mail account, which I use to avoid having Mail.app's brain-dead IMAP layer try to index 4GB of e-mail over UMTS (another annoyance I have with it is that it doesn't let you choose which IMAP folders to sync).
Search results would be dropped in my inbox or (preferably) on a separate search mail account (which could be another IMAP account I'd access remotely or SMTP forwarding to another server).
And, of course, if this is done properly, you can replace mairix with Spotlight bindings (in case your mail server is a Mac) or any other indexer that tickles your fancy.
Flick the Rail
We've all seen fancy search fields like this image search. But what if it searched based on EXIF metadata?
Better still, what if you had something that let you easily tag all those photos you have on your site? This is a bit more than a photo album with tagging support (and yes, the name's a bad pun on Flickr, but this way everyone knows what I'm talking about), and this is what I'd like in such an application:
- Let you annotate photos with a description (Exif.Image.ImageDescription, tag 0x010e)
- Let you tag photos by adding a space-separated word list to them (Exif.Photo.UserComment, tag 0x9286)
- Let you browse your photos by tags (obvious)
- Provide a side bar listing tags to apply (live-searchable, with sticky entries on top)
- Let you apply tags by:
- Clicking on the tag
- Shift-clicking on the thumbnails you want to tag
- ...and not having to press any button to apply these
- Suggest tags based on date/time proximity to other photos
Of course file uploads, thumbnail generation, slideshows, comments, etc. can be added for extra brownie points, but the main focus of this would be to let you publish photos and keep the metadata in the JPEG files (which is where it belongs) instead of setting up databases and XML files for it.
I expect a SQLite database would be in order to keep the web interface running smoothly and fast, but part of my vision for this is that it would require zero setup - you just drop the code on your site and it works.
Incidentally, the current focus on using mySQL for Rails is fine and dandy, but if hosting providers are ever to start supporting Ruby, SQLite is a much better database to focus on, since it's easier to manage thousands of low-traffic sites in one box and doesn't force people to run (and maintain) a separate daemon.
And that's it, really. I have in mind a third small application, but haven't researched the Ruby libraries enough to figure out whether it's feasible.
More as I mull over it.