What deployment tools can do for you

I restarted work on one of my older hobby projects. Though I’m not really sure what my end goal is yet I got a vague idea of what I want to build and it’s nice to have something of my own to code on.

While setting this project up I took some extra time to make sure I got deployments automated from the start. Proper configuration and use of tools saves a lot of time but it also takes several hours to a day or two to set up, depending on the project of course.

There is a ton of guides on the web on how to do this so I won’t reiterate too much here. The project is version controlled with git which allows me to set up a repository directly on the server. In the post-receive hook I am able to add any commands necessary to properly manage the project.

As an added bonus I have fully integrated dependency management with Composer, automated asset optimization with Assetic and database migrations (that write themselves!) with Doctrine. The result is that I write some code, run a command to generate migrations if the code touches the database, and commit before pushing to live.

And that’s it.

I don’t have to SSH into the server to manually do a pull. There’s no need to optimize and minify CSS and JavaScript on my dev machine. I don’t have to worry about out of date dependencies. Heck, I don’t even have to write any SQL. It just works.

How I set up Pelican for blogging pt. 2

So the whole point of running a static website (besides that it’s cool) is the performance aspect. And I personally think that if you’re doing something for performance you might as well go all the way. So here’s how I optimized my static website.

First downloading the plugins and themes I would require to the folder for my configuration files.
git clone https://github.com/getpelican/pelican-plugins ~/Projects/Pelican/plugins
git clone https://github.com/getpelican/pelican-themes ~/Projects/Pelican/themes

And then adding them to the main configuration file by adding these lines to the bottom.

# Plugins
PLUGIN_PATHS = ['/home/rasmus/Projects/Pelican/plugins']
PLUGINS = ['assets', 'gzip_cache']

# Theme
THEME = '/home/rasmus/Projects/Pelican/themes/monospace'

I picked “monospace” for the theme since it was fairly lightweight and only required one small CSS-file, normally I would write a theme myself but for now I just wanted everything up and running. The two plugins added in the configuration are for asset management (assets) and for generating a static compressed version of the website (gzip).

The assets plugin requires additional dependencies for Python which I had to install through pip sudo pip install webassets cssmin. To get the asset management working properly I had to do some modifications to the theme source code. By changing the CSS links to this (below) in the theme and also removing the @import in the CSS file I am able to minimize both CSS files into the same stylesheet and send both over the same request, minimizing requests to the server.

{% assets filters="cssmin", output="css/style.min.css", "css/main.css", "css/pygment.css" %}
{% endassets %}

My Apache-server automatically started serving the gzip compressed files, so I didn’t have to add anything else for the compression to work. Normally I would have to configure Apache to compress the files as they are being requested, but by having the files compressed beforehand allows for some additional milliseconds to be scaled of the wait time from the server.

And then to cheat a little bit I set up static caching with expires headers and disabled ETags. This means that the website will first be downloaded once in 10-20 milliseconds depending on network connection speeds, but after that all resources will be loaded from the local cache and I can reduce the rendering time to 3 milliseconds. I do this by first setting up modules with a2enmod headers expires and then adding this to the vhost directive (I have .htaccess disabled for even better performance).

Header unset ETag
FileETag None
ExpiresActive On
ExpiresDefault A300
ExpiresByType text/css A526000
ExpiresByType image/gif A526000
ExpiresByType image/png A526000
ExpiresByType image/jpeg A526000

All in all the site is rather fast now, I’ll keep this blog posted if I discover anything else to improve.

How I set up Pelican for blogging pt. 1

No, this blog still uses WordPress because of its convenvience and ease of use. But I needed a way to document my personal server that I use for Mumble, IRC and my small projects and I decided to test out static blog generators for that.

Normally people use Octopress (based on Jekyll) which labels itself as “A blogging framework for hackers” which is cool and all but I really don’t like Ruby and I had heard a lot of good stuff about Pelican so I went with that.

This post merely describes what’s different in my own approach and isn’t very detailed in itself, for a better tutorial in setting things up I recommend the documentation pages on how to get started. Continue reading How I set up Pelican for blogging pt. 1

The Heartbleed Bug or “Why you shouldn’t reuse passwords”

The Heartbleed Bug was discovered last week, which is a vulnerability in OpenSSL which powers the HTTPS services of most major websites today. The bug can be quite adequately explained by this XKCD comic.

This brings to light the importance of not reusing passwords. Even if your password is fairly impossible to guess and mathematically improbable to crack it’s still useless if you use it for multiple websites. Because it only takes one website to leak your password through a vulnerability like this to compromise all of your accounts where you reused the same password. So don’t, or at least enable two-factor authentication.


Facebook released Hack last week, which is a new language based on PHP that requires the use of their virtual machine,┬áHip-Hop (aka HHVM). But it’s important to remember that Hack is not PHP, while it understands PHP in much the same way that C++ understands C it isn’t always possible to migrate from the default interpreter to HHVM since they have chosen to not support all of PHP’s features, for better or worse.

There have been a lot of mixed sentiments on the internet over the new language, though the biggest concern appears to be that the naming choice will make it difficult to find anything actually related to the language. Imagine searching for “hack language” or “hack facebook” for example.

Personally I think the release of an independent version of PHP could be positive for the community, regardless of the name. PHP has always been quite careful about backwards compatibility and stability while leaving performance, consistency and, in a sense, security at the side. Hack have already introduced a lot of cool features (really just stuff that you would normally expect from a modern language) that PHP will probably never see the light of, type annotations and collections being my favourites so far. And HHVM have already made significant improvements to the performance of PHP.

I hope that Hack can become a platform for language features and changes that the core PHP language might not be ready for. Since Facebook uses PHP as a base for their new language they might be able to get a lot of traction from developers shifting their code bases to Hack, and maybe this shift can cause PHP to transform into something that not only gets the job done but also something that doesn’t allow “clever” code, inconsistent behaviour and other general headaches.

On the success of Flappy Bird

Apparently there’s a new mobile game called “Flappy Bird” which has taken over the mobile gaming market. I had honestly not heard of this game before I read that it’s being taken down by its creator for being too successful (what?).

IGN put up a review explaining the game concept which is so ridiculously basic it’s almost embarrassing. The fact that this game is so immensely successful only shows to prove what people like David Heinemeier Hansen have been talking about for a very long time which is to “underdo your competition“.

By removing as many features as possible you’re also making your product easier and more accessible to use by lessening the learning curve. This means that you can essentially expand your market by making your app smaller.

Flappy Bird might be an extreme example of “less is more” but it have also accomplished something that many app developers can only dream of.

Setting up two-factor authentication everywhere

I’m studying computer security this term and it has a way of making you very paranoid about security matters, and recent articles like this and this really doesn’t help either. Therefore I’ve decided to set up two-factor authentication everywhere possible to help protect myself to some degree for the uselessness of passwords.

Two-factor authentication essentially means that you use two authentication factors to log in instead of only one. An authentication factor is one of three things, something you know, something you have or something you are. A password is a good example of the first, while a card or cellphone is in the second category.

What this means is that for someone to hijack one of my accounts they will not only need to know my password but they also need my cellphone to generate a temporary one-time key to log in. While my phone can also be remotely tracked and locked down in case it’s stolen, and through backed up recovery keys I will still be able to access my accounts.

It might sound complex and difficult but it really isn’t, and the major security gain is a worthwhile tradeoff. To enable two-factor authentication you merely have to download an app (like Google Authenticator or Authy), use it to scan a QR code for the account you want secured and then you’re done. The next time you log in on a new computer you open your app, get a key to type in and you’re logged in as usual.

There’s a fairly comprehensive list of services which support two-factor here.