These days it seems like everyone is on the free web storage bandwagon, offering somewhere between tens of MB up to 2GB file storage and all kinds of options on how to share that with other people.  But remember back in the day when GMail was first lauched, and it was a hit because it offered 2 gigabytes of storage space where its closet competitors had only 10 megabytes free?

Well those inbox sizes have continued to grow, up to 7.5gb as of this writing.  GMail isn’t the only one with a big mailbox any more, but it’s certainly the most well-known.  What if you could convert that space into a web-based drive and store files into it?  Even at a 3-to-4 ratio (base64 encoding) you can still cram over 5gb into it, which is enough for many people to store a complete photo library, a document backup, etc.  Free offsite backup for just a bit of legwork.

This is a script called “mail-drive.pl” which does exactly that: it provides an interface to an IMAP mailbox and allows users to put, get, list or delete files from the store.  Individual files are broken down to smaller attachment sizes to fit into the mailbox on storage, and retrieved in the proper order when pulling to disk.  Using this, with a wrapper script in a cron job, will allow me to keep backups in a special gmail inbox which I can then get back later if I ever need it.  Free offsite backup!

• mail-drive.pl, Version 0.1, 1.5kb

Introduction / History

Here’s a guilty pleasure: http://dragcave.net, a “click to grow” adoptables site.  It’s a somewhat pointless and spammy website where users click on colorful pictures of eggs to collect them, then repost those images on other websites to gather unique views from anyone else who sees them.  After enough views, the egg hatches and grows up into a full-sized dragon.  So it’s got kind of a viral effect – the eggs get reposted to forum signatures etc. where other people click the eggs to find out just what the heck is the point, and then some of those people stick around to collect eggs and spread them even further.  It grows itself.  There are a ton of adoptables sites out there – Dragon Cave is just the one my wife found first, and by extension it’s the one I joined.

Somewhere in the history of adoptables sites, a user figured out that there was an easier way than spamming message boards to gather a large number of views: simply set up a huge “egg dump” area on a dedicated fan site, and ask users to come view the eggs and post their own.  For Dragon Cave three or four popular fansites had cropped up by mid-2009, designed by budding webmasters with varying degrees of aesthetic and coding skills.  That’s about the time that I decided to set up my own, just to see what was involved and how successful it would be.  So: Egg Drop Soup was born.

http://greg-kennedy.com/dragcave

The entire site is coded in PHP, and the earliest version screen-scraped everything from the bare HTML code to do the work.  It all felt like a hack, with the site design geared fully towards functionality and a minimum of flashy web content.  For whatever reason the site caught on .  A few whiz-bang features, plus the fact that several big-name fansites folded when an unannounced API change came through, boosted the site to about 5000 users at its peak.

Recent Progress

I’ve spent the past few days on a mild resurgence in EDS development.  Dragon Cave has an officially supported API which makes screenscraping obsolete, but I hadn’t ever ported over the pages to use the new features.  Since the HTML had changed in the meantime, this meant a lot of annoying bugs had crept in.  So step 1: port the code to use the API.  Once that was complete, I added a long-missing “Emergency Room” feature: this prioritizes the eggs in danger of expiring at the front of the rotation, so they gain a massive infusion of views and hopefully promote to adulthood (and immortality).  There are a couple of other features in the works, but I feel I’m nearing the end of what I set out to do with this project, and it’s going into maintenance mode unless some inspiration strikes me.

Okay, so this is a pretty boring post, but I wanted to make it for a couple of reasons.  First, it helps me to keep track of what I’ve been working on – this blog exists to categorize my projects, and since I’ve sunk a good number of hours into this one, it warrants a mention.

Second, I’m seriously considering open-sourcing the code to the site (BSD 2-clause license).  I don’t feel there is much danger in userbase loss to clone sites, because being an established name in the DC community is as much (if not more) a driver as features.  People simply gather where everyone else gathers, because that’s where the views are.  So if someone throws out “EDS 2” on stock code it’s no real threat to me.

Instead, I think this would help out a lot of struggling devs on the site by dropping a full-featured codebase on them.  I’ve seen at least one forum post where people are discussing the technical details of setting up a hatchery.  I think EDS is a perfect “skeleton code” example, because it really focuses tightly on making things work, and leaves the web design to the imagination… or the future adopters of the code.

Purpose

iPhoto Modified Importer is a tool to import digital photos to your iPhoto library as “modified” versions of original photos.  By default iPhoto only lets you import Originals.  This is a workaround to keep some existing linkage between Original and Modified versions on your disk, and bring that relationship into iPhoto.  It tricks iPhoto into thinking it is an external editor, then allows you to replace one photo with another from disk.

Background

Before I used a Mac, I organized and edited all my digital photos with Digikam on Linux.  My workflow looked something like this:

• Create a folder for the Album (e.g. “4th of July 2010”)
• Create a sub-folder beneath that called “Originals”
• Import all photos from the card to the Originals folder
• After editing an Original, save it to the top-level folder with the same filename.

By doing this, my release-ready photos were at the top level of every album, while Originals contained digital negatives and unedited photos for safekeeping.

Now that I am using a Mac I’d like to switch to iPhoto and get used to its workflow.  I have no problems letting iPhoto manage my library by itself, copying my photos into a consolidated location, etc.  But the first stumbling block I run into is: how can I preserve that linkage between digital originals, and the modified versions?

Most advice boils down to: “import them separately”.  But that leaves duplicates in the library, and worse it splits my workflow into “pre-iPhoto” and “post-iPhoto”, because any newly edited photos _will_ be linked.  Also, I can’t easily track which edited version goes with which original.  Since iPhoto uses its own database to keep relationships and photo info, there’s another problem: getting modified versions into iPhoto is hard.  You can’t just copy the files to the right location and expect them to be there.

Solution

Here is a solution that relies on iPhoto’s “Edit in External Editor” option.  Place the app somewhere on disk and then under iPhoto Preferences, change the Edit drop-down box to point to the app.  Now, when you double-click on a photo, it will start up iPhoto Modified Importer.

Use the Browse button to locate your target edited photo on disk, then hit OK.  The tool will “save” the image to the correct location, and exit.  iPhoto should then recognize that the file has changed and update the thumbnail, etc.

Warning

This tool is HIGHLY UNTESTED.  It doesn’t ask before saving over anything you’ve done, and it probably has potential to destroy already edited photos in your library.  BACK UP BEFORE YOU TRY TO USE IT.

Future Goals

There are a couple of additional items on the screen that I hope to one day turn into a useful feature.  Ideally you could set up a source directory first, and then iPhoto would report when a filename match is found, defaulting to that location.  This would speed up the import process.

Download

iPhoto Modified Importer 1.0 – zip file 2.6MB

This ZIP file contains the application, and the source code.  It requires XCode to build and… well, I really don’t even know what version of OS X it’s for.  10.6 at least.  Cocoa is a language designed by moon men for the sole purpose of being impossible to understand by Earthlings, but maybe it will make more sense to someone else than it does to me.