Posts Categorized “programming”

Simplify your Jekyll publishing process with wercker

With many bloggers moving to static site generators and success stories like Obama's $250 million fundraising platform people are accepting static site generators as a serious alternative. Especially when security and performance is important.

Regardless of all the goodness that static site generators offer, they come with a price. You need to regenerate the site every time the content changes. This must be done by a machine that has the static site generator software installed. Although this may not be a problem when you are at the office, it will withhold you from finishing an article on your tablet or fixing a typo from your cell phone.

Wercker to the rescue!

Wercker is a collaborative continuous delivery platform in the cloud. You can leverage its power to do the content generation and deployment process for you. In this post we will focus on how you set up such a process for a Jekyll site that is hosted on Amazon S3.

Prerequisites

Add your application to wercker

First you need to add an application to wercker. Sign in at wercker and click the big blue add an application button.

image

Follow the steps given and make sure you give the werckerbot user, read rights on your repository at Github or Bitbucket.

At the end of the process the following screen appears.

image

Creating the wercker.yml

Now it is time to define your build process. This is the pipeline that will get executed everytime changes are pushed to the git repository.

Create a new file called wercker.yml in the root of your repository with the following content:

# our build should run within a Ruby box
box: wercker/ruby
build:
  steps:
    # Run a smart version of bundle install
    # which improves build execution time of
    # future builds
    - bundle-install

    # A custom script step
    # that actually builds the jekyll site
    - script:
        name: generate site
        code: bundle exec jekyll build --trace

Lets briefly go through the wercher.yml file. The first line contains box: wercker/ruby which defines that you want to run the build in a Ruby box (by default this is Ruby version 1.9.3p429). The second line describes the build section that consists of steps, in this case there are two steps. These steps are performed during the execution of the build process. The first step bundle-install is a smart version of the bundle install command that leverages caching so future builds will run faster. The second step script executes the script that is defined the code clause that consists of a single command bundler exec jekyll build --trace. This step actually builds your Jekyll site.

Add wercker.yml to your repository

After you created the wercker.yml add it to your repository by executing the following commands.

git add wercker.yml
git commit -m 'Add wercker.yml'
git push origin master

Because you have created an application for this repository at wercker it should now start building. Open the application page at wercker to see the following result.

image

Congratulations, you first green build on wercker! If you tweet me or e-mail pj@wercker.com a screenshot I will make sure you receive a wercker sticker to celebrate.

Add deployment target information

Now you have automated your content generation process that will get executed every time you push your code to git. This is helpful to catch jekyll errors early, but without deployment it doesn't help your actual live website. Let's add a deploy target to your application on wercker so we can close the loop!

Go to your application at app.wercker.com and click on the settings tab.

image

A new form opens that you can use to enter information that is passed to the deployment context. Here you enter the details of your Amazon S3 bucket. The key and secret key can be found in the AWS security credentials page.

image

We leverage environment variables, in faith with the 12 factor design principles.

note: these aren't my real keys… duh!

If you host your website somewhere else you can leverage the custom deploy target for any type of deployment (for instance FTP or rsync)

Add deployment steps

The current wercker.yml file contains the steps that are executed when the application is built. Now you want to add steps that are run when the application is actually deployed. These steps are performed in a context that hold the information you have entered in the previous section; key, secret and s3 url.

Add the following to the end of your current wercker.yml file:

deploy:
  steps:
    - s3sync:
        key_id: $KEY
        key_secret: $SECRET
        bucket_url: $URL
        source_dir: _site/

The s3sync step synchronises a source directory with an Amazon S3 bucket. The key_id, key_secret and bucket_url options are set to the information from the deploy target, previously created. Only the source_dir option is hard coded (or should I say hard configured) to _site/. This is the directory where Jekyll stores the output.

We could also hard code the key and key secret in here, but that is not something you want to put in your git repository. Especially not when you repository is public like mine.

Commit the changes of the wercker.yml file and push them to your repository.

git add wercker.yml
git commit -m 'Add deployment section'
git push origin master

Deploy it!

You have pushed changes to your repository, thus wercker created another build. Now the deployment information that you have added in the previous steps can be used to deploy the website. This can be done for every successful build in your application by clicking the blue deploy button.

image

Did anything go wrong?

Let me help you! Just tweet me or sent me an e-mail pj@wercker.com.

Learn more

Open Mou from terminal

I'm a big fan of Mou. However I find that I almost always want to use it while at the terminal. Especially since I started using autojump. We have two options here, creating an alias or writing a script. I prefer the first because I already have a huge number of aliases in my ~/.zshrc file and don't have to chmod anything.

Using an alias

Add the following line to your .zshrc, .bashrc or .profile file.

alias mou="open -a Mou.app"

Using a script file

Create a file names mou in your /usr/local/bin (or any other path that is exported in $PATH) with the following content:

#! /bin/sh
open -a Mou.app "$@"

After the file is created add execution rights via:

chmod +x /usr/local/bin/mou

Open it

Now you can just do:

mou [file.md]

Jump fast with autojump

Once in a while you discover a tool that makes you wonder how you ever lived without it. Autojump is such a tool. It allows blazing fast file system navigation from the terminal by letting you to jump to any path you previously visited. The command j born2code changes directory to /Users/pjvds/dev/born2code.net. Autojump doesn't need the full directory name, a small piece is enough. It will match your input with a list of weighted paths and picks the one on top.

How does autojump work

Autojump stores the paths you visit in a simple textfile called autojump.txt. Picture the following cd command.

cd ~/dev/getting-started-python/src

That command will update your autojump.txt file to look like this:

10  /Users/pjvds/dev/getting-started-python/src

When you cd to another directory with the following.

cd ~/dev/getting-started-ruby/src

Autojump.txt file will contain both directories.

10  /Users/pjvds/dev/getting-started-ruby/src
10  /Users/pjvds/dev/getting-started-python/src

The 10 in front of both lines is the weight of the directories. They both have the same weight because they are both visited once. Now when one of the directories is visited again the weight will get updated.

cd ~/dev/getting-started-python/src

Will update the weight of /Users/pjvds/dev/getting-started-python/src:

14   /Users/pjvds/dev/getting-started-python/src
10   /Users/pjvds/dev/getting-started-ruby/src

So /Users/pjvds/dev/getting-started-python/src is now the heaviest weighted path in the list. If you want to change directory to it - in other words jumping - you simply execute the following.

j src

A pwd command would output /Users/pjvds/dev/getting-started-python/src. The j jump command will also update the weight of a directory. So the autojump.txt now looks like the following:

17   /Users/pjvds/dev/getting-started-python/src
10   /Users/pjvds/dev/getting-started-ruby/src

You can give extra hints to autojump. If I want to jump to the ruby src instead of the heavier weighted python one I simply do the following:

j ruby src

More

Installation information and more examples can be found at the Github page. Happy jumping!