A couple months ago I made a bet with a friend. He felt developers don’t blog as much because they don’t have the time to. But I felt differently. I told him the issue was much deeper than time.
I said, “We would blog more if writing was fun!” That realization was the beginning of Blogcast. Simple as that.
Blogcast 1.0.5 is the start of my vision to make writing fun for a lot more people. Initially, I focused on new writers because many needed encouragement to start. But, what about seasoned writers with years of blog posts under their belt?
Should they be condemned to a blogging platform that no longer caters to their needs as a writer? I don’t believe that. I won’t believe that!
Blogcast 1.0.5 features four enhancements:
Blogcast WordPress migrator
Why WordPress? Simple. Many of us in the Ruby and Rails community use WordPress as our blogging engine. But more importantly, fans of Blogcast have reached out to me and asked for a migration tool.
Jason Fried once said, “No is easier to do. Yes is easier to say.” I wholeheartedly believe this because you can’t be everything to everybody.
Yet, a migration tool aligned with my vision to make writing accessible and fun. So, a migration tool is something I support with a resounding and unequivocal Yes!
Go to your Blogcast installation and run rake –tasks to see your available options. One of those options will be rebirth:wordpress:
This is Blogcast’s WordPress migrator tool. The scroll parameter is the location and name of your WordPress export file.
Use the migrator tool like so:
A successful run will look similar to this:
There should be no spaces between rebirth:wordpress and […]. The correct syntax is rebirth:wordpress[…].
I use the excellent Nokogiri for wordpress.xml parsing. So, if you need to use the migration tool, go there to find out how to install Nokogiri properly on your specific system.
Also, make sure your Gemfile is up-to-date with the Nokogiri gem. If you don’t need to use the migrator tool, then you don’t need to have a dependency on Nokogiri.
The wordpress.xml export file doesn’t maintain formatting details. That’s good news and bad news. The good news is you don’t have the extraneous formatting associated with WYSIWYG editors.
The bad news is semantic tags like those used in WYSIWYM editors aren’t preserved either. What you’re left with is pure unformatted data. You’ll have to edit your old posts and add the line breaks (new paragraphs) and Markdown headers that you need.
Finally, if you inserted any manual tags for code highlighting, then you can remove those tags. Highlight.js is smart enough to figure out what programming language you’re using automatically.
Removed all db/migrate Migrations
I removed all migrations from this release because they added more confusion than benefit. Migrations are a development tool.
A lot of people were using the migrations for deployment and then proclaiming it was a bug when it didn’t work. Keep in mind, you are not supposed to use migrations to deploy your Rails database.
Most of you already know schema.rb is the canonical definition of your Rails app database structure. The Rails Core Team has already spoken on the issue (copied directly from the Rails generators):
Note that this schema.rb definition is the authoritative source for your database schema. If you need to create the application database on another system, you should be using db:schema:load, not running all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations you’ll amass, the slower it’ll run and the greater likelihood for issues).
For Pete’s sake run rake db:schema:load so you’re not pulling your hair out. If you need to make specific changes for yourself or a client, then implement and execute your additional migrations. But, you should not run migrations to load the database from scratch.
A successful run will look like this:
Admin user seed instance now available
By default, the admin user is available in the development database that comes with Blogcast. To help with deployment and automated tasks, I added the default instance of the user model to db/seeds.rb.
This should add some value to your deployment and setup tasks. The user model instance in db/seeds.rb now looks like this:
Use the following Rails rake task to load the default admin user seed:
A successful run will look like:
Cleaned up generic error pages
Depending on your setup, some of you may have had some issues getting your 404 and 500 error pages to render properly.
I looked into the issue. The problem was a generic error page didn’t have access to an asset deeper than its current directory. The solution was to move any required assets to the same directory level.
In Blogcast 1.0.5, I moved the error.css and cute koala.png to the same directory level as the 404.html and 500.html generic error pages.
It gets the job done. Plus with this change I still get to maintain separation of concerns. So, overall I’m happy with the results.
Special thanks to everyone that made this release possible. A very special thanks to the WordPress Veterans who graciously donated their blog exports to the cause. Thank you!
Happy New Year folks!