imapsync from Godaddy email to gmail (Google Apps for Business)

Yesterday was my last day using the klunky Godaddy webmail client. I spent an average of 30 seconds for each page to load and to read each email, which can cause certain madness. Since Google pretty much knows everything about me anyway, I made the switch to Google Apps for Business since I have my own domain. All good, I gave Google my credit card number, changed my MX records (another easy task made horribly painful with Godaddy's abysmal domain admin webapp) and am now enjoying sub-second response times and all the features of gmail. Except one minor thing, I need all my email from the Godaddy account - time to migrate all those messages. I didn't find much to go on from Google's own support page on the matter but if you have the wherewith-all to run a perl script from the command line, imapsync is a great tool to accomplish just this. Here's the command that worked for me, note the --regexflag argument is important because gmail seems to be true to the IMAP RFC's and doesn't recognize the \Forwarded flag, so any messages you've forwarded will otherwise not be migrated and you'll get errors like this:

Error message:

- msg Folder/1 {1891} couldn't append  (Subject:[Message Subject]) to folder Folder: 44 BAD Invalid Arguments: Unable to parse flag \Forwarded

Command:

$ imapsync --ssl1 --ssl2 --host1 imap.secureserver.net --host2 imap.gmail.com --user1 your@email.address --user2 your@email.address --password1 'your-godaddy-password' --password2 'your-google-password' --regexflag 's/\\Forwarded//g'

Django vs Ruby on Rails - the (un)final smackdown

Having worked with both Django and Ruby on Rails on recent projects, I was able to form some opinions on a question I spent a fair amount of time researching: "What should I use for my next webapp, Django/Python or Ruby on Rails?"

First of all, both are amazing MVC web development frameworks. I've never been so productive doing web development and it's hard to go wrong using either one. I owe an enormous debt to the creators and contributors of/to these open source angels. Also keep in mind that I'm not in any way entering the debate of Python vs Ruby - I consider them equal for the purposes of this exposition. Moreover, performance considerations are equal, any marginal performance advantages you can argue one over the other is vastly out-weighed by the talent of the developers building your web application. Within the foregoing context, here are some pros/cons of each:

Ruby on Rails

• Pros
• In general, I found more forum and community support (stack overflow, etc) and found more contributors to common add-ons (gems).
  
  
• Asset pipeline - Rails has a built-in asset packaging tool that compresses/minifies js, css and helps partition these resources among pages for page-load optimization. Note that Django has similar options via contributed packages - example.
  
  
• Though Rails doesn't have much in the way of a built-in admin app (think basic CRUD directly to your tables). There is a great selection of contributed gems (check out rails_admin).
  
  
• Though Rails doesn't have much in the way of a built-in authentication, the de-facto standard gem - devise (using warden) is much more flexible and forward-thinking than django's built-in auth with the ability to authenticate independently for different domains and realms.
  
  
• Model validations with Rails seemed more usable and flexible out-of-the-box. These rules are also easier to apply to form input, whereas with Django, I found myself having to duplicate validation code for persistent data.
  
  
• Rails is more faithful to the MVC design pattern with clear delineation of models, views and controllers. Django's borders seem less defined with four main constructs: view, form, model and templates where the MVC view is somewhere between Django views and templates, and the MVC controller is somewhere between Django views and forms (closer to views), with some unnecessary overlap between Django models and forms.
  
  
• Rails has built-in database migrations (though check out South for Django).
  
  
• Rails has better support for RESTful API's and interfaces out-of-the-box with its resourceful routes.
  
  
• Route/url mapping is clearer and more concise with Rails' resourceful routes.
  
  
• Rails logging for a development environment is deeper and more verbose out-of-the-box giving developers better insight into bugs and/or bottlenecks with profiling info (though check out the django debug toolbar).
  
  
• Rails template system can readily adapt to different implementations - HAML, etc. Though Django seems to be catching up on this.
  
  
• ORM - rails' built-in activerecord is more functional than Django's ORM. For example, I couldn't find a reliable way to accomplish a simple left outer join with Django (without writing SQL). Also Rails' ORM is modular allowing you to choose a particular ORM engine.
  
  
• Rails' console, though slower to start is much more usable because it automatically imports everything you need.
  
  
• More built-in CSRF magic.
  
  
• In general, Rails has more magic built-in (e.g. mapping URL to controller/template name). This can be good or bad depending on your taste but I found the Rails magic overall to be very useful, intuitive and in good taste.
  
  
• Cons
• Rails is evolving quickly. This is a pro as well, but when it comes to upgrading Rails and included gems, there are some backward-compatibility issues to deal with, compared with the less accelerated (dare I say, more stable?) Django.
  
  
• Somewhat brittle dependencies with gems - I found myself having to deal with gem version conflict issues on rare occasions, though Bundler and RVM made dealing with different versions of Ruby and gems quite enjoyable overall.
  

Django

• Pros
• With Django, I was less concerned with rails' mass-assignment issues since any field not defined/declared in a form will not be considered for persistence. Note that rails behavior can be made compatible to Django in this respect with a special option for the paranoid - config.active_record.whitelist_attributes = true.
  
  
• Faster startup time in the development environment. Rails' models are much more tightly bound to the database schema and there is significant communication/validation with the db before Rails is able to start handling requests.
  
  
• Built-in admin interface - sophisticated and highly extensible/customizable CRUD interface, right out of the box.
  
  
• Good separation of application code and template code. Django forces you to do the heavy lifting outside of templates with minimal procedural capabilities in the template language. This is of course at the expense of flexibility.
  
  
• Cons
• Django built-in template system is less rich with limited ability to use the programming language within a template. This is reportedly by design to protect against bad coding practices - I get that, but would rather rely on discipline of my team and have the additional flexibility.
  
  
• In general, with Django I found myself asking where is the equivalent of such and such that I used in rails?
  
  

Another interesting discussion on this topic.