Draconis Software Blog

One of the things I had been meaning to do for some time was to switch all of my email over to my Gmail account. The idea is simple: I have a lot of different email accounts, and it’d be great to keep them all in one place, backed up, and always accessible. So, setting up Gmail to access each of my different email accounts (well, five of the most important, and the rest just forward to my gmail address) was trivial. The hard part, however, was getting all my previous messages into Gmail.

Here’s a quick overview of how to get all of your old emails into Gmail as painlessly as possible (and one way that preserves dates!).

(Read the article)

Comments (12)

I just came across an article from the Wall Street Journal about Google’s plan to offer consumers a service to store their personal data files.  I’m pretty excited about this, and so should you, for several reasons.

First, mass data storage is getting cheaper and cheaper, but to really push prices down, it takes the economies of scale a company like Google or Amazon can get by combining thousands of users’ storage needs into a single service.  Providing a service like this will decrease the total cost per gigabyte to even lower levels, which theoretically could make it cheaper to sign up and pay for a service like this than to go out and buy a hard drive.

Second, Google usually does services right (not always, but usually).  It looks like they have an eye towards consumers, rather than businesses (like Amazon’s S3 service), which will, hopefully, mean good integration with your desktop.  I sincerely hope to see a tightly integrated OS setup where users can treat their Google storage service as “just another hard drive” on their computer.  I’d really rather not see some cumbersome client software you have to download, but rather a network share on your computer.

Third, and most important (to me at least), is the freedom from worrying about backups, redundancy, and scaling.  More and more, I’m watching movies and TV shows on my computer or home entertainment system via iTunes and similar services, and my storage requirements are expanding rapidly.  There will be a time in the very near future where I’ll need a terabyte or multiple terabytes to store my movies and TV shows for access, rather than as DVDs.  And I’m not alone: many people are doing just this, as everything becomes digitized and always available.

Anyway, it’s all still very early to get too excited about this service, but I really hope Google does this one right.  Keep it simple, no client software, cross-platform, and as cheap as possible is the way to win consumers here; and I know that now - and in the future - people’s storage requirements are just going to increase.

After updating my Mac to Leopard (MacOS X 10.5), I noticed I had a couple issues when updating Rubygems. For instance, when running “gem update mongrel_cluster”, I would constantly get build errors. After doing some digging, I found that you need to set ARCHFLAGS to your system type. Here’s how you would update all your rubygems on Leopard:

sudo su
[Enter your password]
bash
export ARCHFLAGS="-arch i386"
gem update

Note that you’ll want to change the i386 to the actual architecture you have (my MacBook, for instance, is an Intel processor, while you would want to use “ppc” for non-Intel Macs).

Once I had updated my gems, things started working fine again. For instance, mongrel_cluster was having issues configuring a new project, but after updating the gem using this method, it seemed to be working fine. Hope you find this useful!

Comments (2)

I’ve had my iPhone for a few weeks now (and yes, I got my $100 rebate), and I have to say that my biggest gripe is the lack of a good to-do list application. Of course, this is a fairly small gripe in the grand scheme of things (Apple got a lot right with this device), but it’s still important to me. One of the major ways I work on a day-to-day basis is to set lots of small, achievable tasks using my to-do list, then check them off as I get things done.

There are several to-do list iPhone web apps out there (notably, 37signal’s Ta-Da Lists), though it’s just not quite what I’m looking for. I really like the built-in to-do list in iCal, so having an actual iPhone application (not just an app via Safari) that can sync to my pre-existing iCal to-do items would be ideal. Hopefully Apple will be forthcoming with one (especially since it seems to-do items will play a bigger role with the Mail client in Leopard).

Comments (1)

There’s an interesting opinion up by Joel Spolsky, a software developer and founder of FogCreek Software, about where the direction AJAX-based web applications are headed. He makes an interesting, and I feel very apt, comparison with the olden days of mainframes and Lotus 1-2-3, and the current state of the interactive web. For instance, he likens the idea of sites like Google’s Gmail with Lotus 1-2-3, where the development team spent all of their time writing code and optimizing it for the current day’s limitations, rather than looking ahead and adding new wiz-bang features that would give them their “long-term competitive advantage.”

And I think Joel is completely right. Gmail, for one, has been stagnant for the last three years or so, and haven’t been preparing for the future. Check out this blog article from Lifehacker about a comparison between Gmail and Yahoo Mail. Their conclusion? Yahoo Mail has spent the last two years innovating and adding all sorts of new features, while Gmail has very little improvements (except, perhaps, incrementally increased storage levels).

(Read the article)

Yesterday, Apple dropped the price on the 8gig iPhone (that killer, must-have gadget that’s apparently been selling like crazy since being introduced), along with new product announcements in their iPod lineup. Unfortunately, it looks like this price break puts a lot of us early adopters in a tight spot: those of us who shelled out the full $600 for the 8gig models are now realizing the price of purchasing early: about $200.

If you’re not already aware, if you bought your iPhone within 10 days of an announced price break, you’re entitled to receive the difference from Apple (provided you claim this within another 14 days of the announcement).

Should Apple reduce its price on any shipped product within 10 calendar days of shipment, you may contact Apple Sales Support at 1-800-676-2775 to request a refund or credit of the difference between the price you were charged and the current selling price. To receive the refund or credit you must contact Apple within 14 business days of shipment.

Sadly, we at Draconis bought out iPhones 16 days before the announcement: 2 days later and we would have qualified for that rebate. But I’m not bitter over it: I love my iPhone, was willing to part with the full price without expecting any kind of rebate, and anyway, these things are out of our control. Anyone else in the same boat as us?

Comments (2)

Just like every other techie in the world, we recently got our hands on some iPhones.  And, as software developers, our first thoughts were: what can we write for this thing?  Well, as everyone else has already pointed out, you’re pretty much limited to writing web apps for the iPhone only, but this doesn’t impact us as much: we’re doing web apps exclusively at the moment anyway!  I’ve been looking into creating an invotrak app for the iPhone recently, and believe I should have something available in the near future.

Craig Hunter has a good article up on his site that discusses some of the limitations of creating applications for the iPhone, though his standpoint is coming as a traditional Mac developer (and he makes great points: it doesn’t make any sense for a user to connect to a web app to input to-do list items):

Business aspects aside, the main issue I see as a traditional developer is that iPhone web app development is still very limited. Outside of some viewport settings, a couple special link types (really only the "tel:" link is new), and some new "-webkit" style attributes, there is little about making iPhone-specific web apps that differs from generic web apps. And that's possibly the most disappointing aspect of all from my standpoint. Apple's announcement states that "developers can create Web 2.0 applications which look and behave just like the applications built into iPhone", but that's not the case.

I believe there’s a lot that can still be done with the tools we’re given, and I look forward to Apple creating more tools in the future.

Comments (1)

Ruby's version of make, Rake, is an indispensable tool that all Rubyists should learn and use regularly. It's the perfect way to run all of those project-specific tasks like clearing the cache or removing stale session data.

Once you start using Rake, you'll probably find that you duplicate many of your tasks in all of your projects. It's not too much to copy often-used .rake files, but there is a better way. Sake (short for System-wide Rake) solves this. Once you install a Rake task into Sake's repository, it becomes available system-wide via the sake command.

Say you have a file named dbversion.rake, which finds the migration version of your database, as follows:

To install this system-wide, first install Sake by running gem install sake. Rubygems will download and install everything for you. Now you can install the Rake task into Sake by typing sake -i dbversion.rake. You can now run the db:version task inside any Rails app by typing sake db:version. Pretty neat, eh?

Sake has a few more tricks up its sleeve. You can view the rake tasks that are currently installed into Sake by running sake -T. It can also install tasks hosted on a remote web server by replacing the filename that appears after sake -i with the url. Check out the original blog post to read more.

Some other sites with info on Rake that I found interesting:

• Some useful Rake tasks from ERR THE BLOG
• A tutorial on Rake from Rails Envy
• A more in-depth view on Rake from Martin Fowler

Comments (1)

There's a good overview of antispam practices at Howto Forge today, detailing the various methods either currently in use (black/gray/white lists, applications, etc), and proposed (DKIM, etc).

In a world where spam is bound to hold such an important position,
methods of preventing it should also be given an increasing importance.
Some of the easiest and most widely used prevention methods are host
control solutions, Antispam applications and user education.

I'm particularly excited about Domain Keys Identified Mail (DKIM), which I wrote about recently. Such a method would be very useful in tracking down spammers and controlling the flood of junk they put out, though, as this article points out, it's not without it's limitations. "The main disadvantage of DKIM is that email messages can be significantly modified in certain situations (e.g. when being forwarded by list severs), causing the signature to be invalidated and the message to be rejected. A solution to this issue would be combining DomainKeys with SPF, because SPF is immune to modifications of the email data."

Check the article out - it's a good overview of what's currently going on, and perhaps may inspire you to try a different approach to your current antispam efforts.

I recently saw an article about the DomainKeys Identified Mail (DKIM) draft being accepted by the IETF as an official proposed standard (even though it happened back in February). I really hope the acceptance of this takes off, though the article seemed to show many large companies (who could probably benefit from it) non-committal.

DKIM is a simple means for verifying the origination of an email in an attempt to better track (and fight) spam and phishing messages. The method is simple: the sender encrypts the message body using it's private key and stores this in the message header (non DKIM receivers, then, can safely ignore it and still deliver the message). A DKIM-enabled receiver looks up the originating domain's record and extracts the public key. From Wikipedia: "The receiver can then decrypt the hash value in the header field and at the same time recalculate the hash value for the mail body that was received, from the point immediately following the "DomainKey-Signature:" header. If the two values match, this cryptographically proves that the mail did in fact originate at the purported domain, and has not been tampered with in transit."

(Read the article)