Migrating from Posterous to Blogger

At the news that Twitter was buying Posterous, it was only a matter of time before the end would be announced, so I started reevaluating another solution for blogging.  I had written off Blogger for years since it was pretty primitive and lacked features that mattered to me.  With the further integration of Google + and clients on most mobile devices, I decided to go Google and give it a try.

In order to move from Posterout to Blogger you need to use Wordpress as a middle man first and then use an open source app called Wordpress2Blogger conversion utility.  Here are the steps:

Posterous Export:

1. Visit http://posterous.com/#backup
2. Click on the "Request Backup" button next to the space you want to backup.  Depending on the size of the blog this could take minutes or hours.  My 200 post blog took about 10 min or so.  When it is ready you will receive an email.
3. Go back to http://posterous.com/#backup and click the download button to receive the zip file of your space.  Although this appears to be in a format for Wordpress to import, the WordPress2Blogger tool will not work directly on this file.

Wordpress.org Import/Export:

1. Login to Wordpress.org 
2. Create a new blog with the same name
3. Go to Tools -> Import and select Posterous
4. Select the Wordpress_export_1.xml file in the unzipped package download from Posterous
5. Follow the instructions to import.
6. Once complete, go to Tools -> Export and export the xml file.

Convert Wordpress Export:

1. Visit http://wordpress2blogger.appspot.com/
2. Click "Choose file" and select the xml file download from Wordpress
3. Click Convert.  This will convert the file to a blogger import file
4. Once complete, a file will download in the blogger format.

Blogger Import:

1. Create your new blog with your blog's name
2. Go to Settings -> Other and click on the "Import blog" link under "Blog tools".
3. Select the xml file from Wordpress2blogger
4. Start blogging on Blogger.

The process sounds elaborate but the process is pretty fast and I was able to move 4 blogs in about 30 minutes so after the first one it is somewhat routine.  There are some differences with Blogger but overall there seems to be ways to do most of what I did before without too much hassel.  I do miss the simplicity of Posterous but as you know it had it's frustrations as well.  ~Lou

Prep Ruby on Rails Apps for GitHub Publishing

When I started to publish code on GitHub I began searching for the best way to share my code without accidentially giving away my keys, passcodes or usernames. I tried to fork a version for publishing but branch history will still allow the public to see what was in previous versions. After trying a few methods, I opted to store all my passcodes in a *.yml file in config folder and just add it to the .gitignore. This required a few notes to let cloners know what to do with the code in the case they were to use their own keys directly.

Create a file under the ‘/config’ folder ‘ app_passwords.yml’

defaults: &defaults 
    app_key: my_app_key
    app_secret: my_app_secret 

development:
     <<: *defaults

test:
     <<: *defaults 

production:
     <<: *defaults

In order to load ‘app_passwords.yml’ it needs to reside at the top of the ‘/config/initializers’ folder. I placed a file called ‘01_app_passwords.rb’ (I added the 01 to put it at the top of the file list since initializers are processed in order).

In ‘config/initializers/01_app_passwords.rb’

MY_PASSWORDS = YAML.load_file("#{Rails.root}/config/app_passwords.yml")[Rails.env]

Now that the passwords are loaded into the Rails envionment, they can be called from the controller.

In ‘my_controller.rb’

APP_KEY = MY_PASSWORDS['app_key']
APP_SECRET = MY_PASSWORDS['app_secret']

Now that the app’s sensitive data is located in a single place, the ‘app_passwords.yml’ can be added to your ‘.gitignore’ file and it will not be committed to GitHub (as long as you don’t have other commits to your code history). There are now two options for your README for letting users who download your code to change in order to use it with their own passwords.

1. Change ‘MY_PASSWORDS['app_key’]‘ and 'MY_PASSWORDS['app_secret’] with their own keys and passwords. or….
2. Add their own ‘app_passwords.yml’ to the ‘/config’ folder.

This seems to get the worry out of the way and let you code and commit without worry (well at least after the first commit and check!). ~Lou