Tag: rake

Moving from Tumblr to WordPress

Recently I moved this blog from Tumblr to WordPress, as I wanted more control over the environment. My setup now is a hosted WordPress instance on heroku, with really nothing special, using the current PHP stack with Apache2 as my server, and ClearDB to provide me a MySQL instance to store data in. Since this basic setup will provide rather dreadful performance, especially on a single free Dyno, I use Amazons CloudFront as my CDN. All this gets me to a quite fast experience. The setup was quick and painless, but migration of the content proved harder than expected. All there is to do to make this work on heroku is using environment variables to get the database setup in PHP.

https://gist.github.com/sideshowcoder/251bfe82128958901c20.js

Importing Tumblr into WordPress

WordPress offers an importer for Tumblr, sadly this importer seems to strip HTML from Tumblr posts which meant that all my carefully embedded content was not imported. Looking around there are multiple ways to solve this, the quickest being Tumblr2Wordpress which allows to create a WordPress compatible XML file from all the Tumblr posts, with the content being HTML. Importing is as simple as hitting import on the new WordPress blog.  

One thing which constantly annoys me on the more “casual” web is that people break links all the time, and since I didn’t want to be one of those people I wanted to make sure that all links to my content still work after the migration. Also since I use Disqus for my commenting, and Disqus uses the URL to determine the correct comment stream (afaik) I wanted to make sure this works correctly. Tumblr uses a somewhat weird way to reference posts its URL format is something like: http://tumblr.com/posts/SOME_ID/THE_SLUGIFIED_POST_TITLE what is funny about this is that the last part of the URL does not matter at all, it is just the ID Tumblr cares about, and this ID is also carried over by the import and stored in the post_name attribute for the post. So to faking the first part of the Tumblr URL in WordPress is easy, just make the permalink structure: /post/%postname%. Now if everybody would just link to the ID this would work great, but sadly most of the time the title is going to be included, even though nobody cares about it. The solution to this is simple, just don’t make WordPress care about it either, but display it if needed.https://gist.github.com/sideshowcoder/6c57a8fa85c28e9a837b.js

Added to function.php of the theme that is in use, this little snippet will provide a new tag for the permalinks to attach and strip of the slugified title to the to the permalinks, depending on if the imported post used the Tumblr way of URL or if it is a new WordPress post, just don’t name your posts 1234… /post/%postname%/%tumblrslug% will now give you the structure you need.

Easy management with Rake

For the longest time I have been a ruby guy and I just like to use rake to automate almost everything and do the needed command remembering for me. So to make sure I can keep managing my blog I ended up creating a Rakefile with some function to manage my remote instance, and I use dotenv to manage my local variables in the same way as heroku does remotely, through environment variables. For anybody interested, this is what this looks like

And that’s it, the blog is migrated, all the links should still work and I can easily manage the needed tasks, like backup, getting into the database, running a local server all through Rake.

Setting up Couchbase views with Rake

If you are like me, you like your code and at best everything else about your
app to be versioned. This makes setting up a new development environment quick,
and even more important reproducible. So one thing which always bothered me was
setting up external code outside of the application to generate Couchbase views,
since those views are build using JavaScript, and by default live in the
web interface, far away from my application code. If you want to know more about
them watch the Couchbase 103 – Views and
Map-Reduce by the way.

Since those JavaScript functions are code which is closely related to my app, I
like to keep it inside as well, and provide a task to actually set them up for
the given environments. The following quick gist provides a rake task to do
this, adding all views in config/couchbase_views to Couchbase.

https://gist.github.com/sideshowcoder/10465780.js

This works great together with dotenv to provide the connection details via
environment variables, but can also depend on any other way to
set up the database connection easily.

README Driven Development: Testing libraries from a user perspective

What really is outside in testing when writing a library? I have seen different
approaches to this problem like cucumber, rspec or bacon, but one step that
seems to be missing in a lot of cases is testing what the user sees first, the
README. On Github the README file has really become the first thing any
developer coming in touch with a library looks at, so it should be the getting
started guide, and something that can make or break the experience a developer
has. But many developers including myself seem to face a problem so keeping the
documentation working and updated. This got me thinking what I really want in
there are code samples, and those code samples should work copy and paste.

To achieve this the README has to be part of my build process, so I started
experimenting with including a runner for code inside as a Rake task

https://gist.github.com/sideshowcoder/8358021.js

The Idea really is nothing new, but I have been struggling to find a well
integrated solution. This is probably the simplest solution I could come up
with. I’m currently driving the development of a library idea for my talk at
takeoffconf, and it allows me to really focus on
the concept of the code from a user perspective writing the README first and
building the working code from there on.

Currently the solution is not robust so any help is greatly appreciated, even
though for now it works.

Make sure your rails migrations work, thank you.

Rails migrations are the ugly stepchild of most projects, even though
actually making them work correctly saves so much time. Even though they seem
like one-off scripts, and also are most of the time when you do need to run them
more than once you are already in a bad place, so be sure that the migration you
wrote, when there was time is not making it worse.

At least doing a quick testing of the rollback is worth your time, in all cases!
So just run

$ rake db:migrate && rake db:rollback && rake db:migrate

When creating a new migration, thank you, you are awesome :).

Testing rake tasks

Relying on rake task to do some repetitive work is a really common way in most
rails apps. Testing those tasks seems to not be as common so.

Why?

Personally I think this is mainly due to just not being present in the default
tests stack, so as a developer I assume they are not worth testing because nobody
else is. But actually I think a task which is essential to your application
should be tested never the less, so to ease my journey towards better test
coverage for rake tasks in my own apps I decided to create a little helper to
setup just the basic environment and about as important, be there as a reminder
that I should test those tasks.

Personally I come to like minitest to test rails apps, so the
gist is based on
minitest, but can easily be adapted for any other framework. Looking through the
code you’ll find some conventions I personally like to be enforced in my rake
tasks

  • namespace the task under the app name if it directly interacts with the app
  • put the tasks in sub directories under lib/tasks so it does not become a
    junk drawer of code
  • put each task in its own file
  • name the file after the task (common sense I guess but not always true)

so here we go, enjoy!

https://gist.github.com/sideshowcoder/5891019.js