Google PageRank still matters for SEO


On Monday, September 21st we moved this blog to another domain. This has made the traffic on the blog go up from 2000 to 2800 unique visitors per day. You can see the effect in the graph above (source: count-per-day plugin).

Google PageRank


At LeaseWeb we run several websites with different Google PageRank scores as you can see in the picture above (source: In order to let the sites benefit from the highest valued domain we could move the sites from subdomains to paths. We did that for this site (LeaseWeb labs). =>

This higher Google PageRank led to an expected increase of Google search traffic. It went from 1250 to 2000 (+60%) clicks per day. It is incredible what better Google PageRank can do for the traffic of a site.

Moving domains? 301 everything!

Moving content from one domain to another (or from http to https) is not without risk. If you do not proper 301 redirect your content, you may lose traffic/rank due to penalties for having 302 redirects or no redirects at all.

I suggest that you create a second property on the Google’s Search Console so that you can see the search traffic move from one site to the other. You can also tell Google in the search console that the site has moved.


On the above graph (from Google’s Search Console) I have drawn a red line to show the 6 day transition from the old to the new domain.


Docky makes Xubuntu look pretty

Xubuntu is my favorite Linux distribution. It is fast, pretty and minimal. Right now I am running version 15.04 and 14.04 (LTS). Previous versions used to have a sort of a dock on the bottom, but current versions do not have that. In the current version the top panel holds the “Application Menu”, “Window Buttons” and the “Notification Area”. When you move that panel down it will be familiar to Windows XP users. In order to make the transition for Mac OSX users easier you may some more adjustments. Apple desktop users need features like: a dock, expose and a quick launcher.

1) Docky is a good looking icon dock


Docky is a dock that looks great and indicates open programs, so it can be a replacement for your “Window buttons” in the taskbar. Removing these from the panel is easy (right-click). I recommend installing docky with the following command:

sudo apt-get install docky

There are two tricks you may want to execute after installation, read about them below.

Docky: Remove the anchor icon

Docky has by default an anchor icon in the dock. It allows you to configure the dock. This can also be done by right-clicking a border or a separator, so you don’t really need the anchor icon. You can simple remove the anchor icon using the following command (source):

gconftool-2 --type Boolean --set /apps/docky-2/Docky/Items/DockyItem/ShowDockyItem False

You may replace “False” at the end of the line with “True” to revert the change.

Docky: Wrong Thunar and Terminal icons

The “Thunar” and “Terminal” icons may look bad/weird and the applications may have double entries in the dock. This problem is less serious than it looks. It is caused by Docky not being able find the corresponding application shortcuts (that contain the icon path). This can easily be fixed with the following commands (source):

sudo cp /usr/share/applications/xfce4-terminal.desktop ~/.local/share/applications
sudo cp /usr/share/applications/Thunar.desktop ~/.local/share/applications

NB: You may encounter other applications with this problem, but this easily fixed in a similar fashion.

2) Skippy-XD adds expose functionality

The “expose” functionality is in which a click-able miniature version of all windows are shown in a non-overlapping layout to enable quick and pretty switching of applications. For Ubuntu there is “Skippy-XD” an application that does exactly that. It has a daemon mode and a run once mode. The daemon mode is very usable. Here is how to install skippy-xd (source):

sudo add-apt-repository ppa:landronimirc/skippy-xd-daily
sudo apt-get update
sudo apt-get install skippy-xd

To make start during login navigate in the main menu to “Settings” > “Session and Startup” > “Application Autostart” and add the following command:

skippy-xd --start-daemon

To make F3 act as the expose hot-key navigate in the main menu to “Settings” > “Keyboard” > “Application Shortcuts” and add the following command:

skippy-xd --activate-window-picker

Now logout and login to see whether the application indeed works as intended.

3) Launchy is a great quick launcher

You know how convenient you can search on OSX with a Ctrl-Space? This can easily and beautifully be configured using the “Launchy” application. This can easily be installed using the following command:

sudo apt-get install launchy launchy-plugins

After installation you may have to edit the settings to make launchy properly index you “Documents” and “Downloads” folders. Also make sure you check out the plugin configurations.


After installing and configuring these applications your Xubuntu is feeling a bit more like OSX. For people that are switching operating systems this may be a good thing (they could also try Elementary OS). I personally dislike having a dock and prefer the gnome 2 layout with 2 panels: one on top with the main menu and one on the bottom with the window buttons. This is exactly why power users like Linux: you can customize it to fit your needs.


When (not why) “Agile” and especially Scrum are terrible

This article is a response to “Why ‘Agile’ and especially Scrum are terrible” as posted on Michael O. Church’s blog. He is not so much attacking the agile manifesto, as he he is attacking the reality of “agile”, the way it portraits itself and the excesses.

If you read the comments on Reddit then you find that there are two camps: scrum advocates and scrum haters. The haters complain how scrum leads to bad behavior and the advocates argue that this behavior is caused by doing scrum wrong. In this post I will focus on this behavior that, both parties agree, should be avoided.

1) Being judged personally

You should not be judged on hour by hour productivity as a software developer, because constant daily competition is not healthy. What particular tasks, technical debt or research tasks each developer worked on in a sprint is irrelevant. Peer pressure is the most effective way to keep people productive and looking at individual performance kills peer pressure. If there is micro-management going on, then that has nothing to do with being “Agile”.

Although there may be a high level of transparency, that does not mean that management should be evaluating people’s performance at the end of each sprint. The story points are designed to prevent management from doing this. The retrospective allows for criticizing the performance and effectiveness of people in the team by the team.

Especially web-based “Agile” registration tools must be used with care (or avoided). They are not part of “scrum” as white-boards and stickies are preferred. Also they may add lots of bureaucracy and may be misused to draw conclusions. Conclusion that may destroy the valuable trust relationship between employer and employee as they are more likely to be wrong than right.

If you see “agile” and “scrum” as tools to achieve “accountability” or “predictability” you are missing the point. It is merely a method to talk about work done instead of work to be done.

2) Developers being considered the lowest rank

The “product owners” and “scrum masters” do NOT outrank “team members”. Although they prioritize the user stories, they should not not choose which ones get executed. Also they should not assign tickets. If they feel superior or they are treated (or paid) as such, then something is wrong and not in the last place because good team members are all-round technical experts and these are extremely hard to find.

Team members are stakeholders as well. They can not only choose which tickets to work on (from the top of the stack), but also add stories (often technical debt) and argue why they are important.

One of the goals of agile is to eliminate blame and fear in the workplace. In a good team people do not fear to say “I was stuck with my code all day and got nothing done” during a stand-up. People should understand their pain and instead of blaming them offer some help.

3) Short term focus

Under Agile, technical debt can pile up not being addressed, because non-technical business people decide on priorities. They will not see a problem until it’s far too late or, at least, too expensive to fix it.

This pileup may be the result of  a straightforward application of “scrum/agile” principles. The focus may easily shift to only things that bring business value or “visible features” as I like to call them. These principles might work when imposed/implemented by an engineering team onto itself, but they break apart instantly the moment the management tries to impose them from outside.

There’s no reason why major refactoring can’t be tackled as a story. And having metrics to measure this (e.g. steadily increasing time to deliver features) should make it easier, not harder, to make the business case.


Short term work under high scrutiny is not fun nor agile, avoid it.


Heka monolog decoder

This post is about how to use heka to give your symfony 2 application logs the care they deserve.

Application logs are very important for the quality of the product or service you are offering.

They help you find out what went wrong so you can explain and fix a bug that was reported recently. Or maybe to gather statistics to see how often a certain feature is used. For example how many bare metal reinstallation requests were issued last month and how many of those failed. Valuable information that you could use to decide what feature you are going to work on next.

At LeaseWeb we use quite a lot of php and Seldaek’s monolog is our logging library of choice. Recently we open sourced a heka decoder on github here. For you who do not know heka yet, check out their documentation.

Heka is an open source stream processing software system developed by Mozilla. Heka is a “Swiss Army Knife” type tool for data processing, useful for a wide variety of different tasks, such as …

Heka runs as a system daemon just like logstash or fluentd. Heka is written in go and comes with an easy to use plugin system based on lua. It has almost no dependencies and is lightweight. James Turnbull has written a nice article on how to get started with heka.

send symfony 2 application logs to elastic search

How better to explain with an example.

Lets say you have a symfony 2 application and you want the application logs to be sent to an Elastic Search platform.

On a debian based os you can download one of the heka debian packages from github.

    $ wget
    $ sudo dpkg -i heka_0.9.2_i386.deb

To configure heka you are required to edit the configuration file located at /etc/hekad.toml.

    $ vim /etc/hekad.toml

Take your time to read the excellent documentation on heka. There are many ways of using heka but we will use it as a forwarder:

  1. Define an input, where messages come from.
  2. Tell heka how it should decode the monolog log line into a heka message
  3. Tell heka how to encode the message so Elastic Search will understand it
  4. Define an output, where should the messages be sent to.

First we define the input:

    type = "LogstreamerInput"
    log_directory = "/var/www/app/logs"
    file_match = 'prod\.log'
    decoder = "Symfony2MonologDecoder"

Adjust `log_directory` and `file_match` according to your setup. As you can see we alread told heka to use the `Symfony2MonologDecoder` to we will define that one next:

    type = "SandboxDecoder"
    filename = "/etc/symfony2_decoder.lua"

Change the `filename` with the path where you placed the lua script on your system.

Now we have defined the input we can tell heka where to output messages to:

    index = "%{Hostname}"
    es_index_from_timestamp = true
    type_name = "%{Type}"

    message_matcher = "TRUE"
    server = ""
    flush_interval = 5000
    flush_count = 10
    encoder = "ESJsonEncoder"

In the above example we assume that your Elastic Search server is running at

And thats it.

A simple log line in app/logs/prod.log:

    [2015-06-03 22:08:02] app.INFO: Dit is een test {"bareMetalId":123,"os":"centos"} {"token":"556f5ea25f6af"}

Is now sent to Elastic Search. You should now be able to query your Elastic Search for log messages, assuming the hostname of your server running symfony 2 is myapi:

    $ curl | python -mjson.tool
        "_shards": {
            "failed": 0,
            "successful": 5,
            "total": 5
        "hits": {
            "hits": [
                    "_id": "ZIV7ryZrQRmXDiB6thY_yQ",
                    "_index": "myapi",
                    "_score": 1.0,
                    "_source": {
                        "EnvVersion": "",
                        "Hostname": "myapi",
                        "Logger": "Symfony2MonologFileInput",
                        "Payload": "Dit is een test",
                        "Pid": 0,
                        "Severity": 7,
                        "Timestamp": "2015-06-03T20:08:02.000Z",
                        "Type": "logfile",
                        "Uuid": "344e7cae-6ab7-4fb2-a770-d2cbad6653c3",
                        "channel": "app",
                        "levelname": "INFO",
                        "bareMetalId": 123,
                        "os": "centos",
                        "token": "556f5ea25f6af"
                    "_type": "logfile"
        // ...

What is important to notice is that the keys token, bareMetalId and os in the monolog log line end up in Elastic Search as an indexable fields. From your php code you can add this extra information to your monolog messages by supplying an associative array as a second argument to the default monolog log functions:


    $logger = $this->logger;
    $logger->info('The server was reinstalled', array('bareMetalId' => 123, 'os' => 'centos'));

Happy logging!


What’s up with FizzBuzz post commenters?

Somehow FizzBuzz is still a topic today and that’s why I recently wrote a (satirical) post about it. Today I’ll describe the history of FizzBuzz and provide you with the links to the original articles. For anyone who does not know what FizzBuzz is, let me explain this first. Fizzbuzz is a programming test of a trivial algorithm that is supposed to be written with pen and paper (without using a computer). Many programmers fail this test during interviews. What that means? No idea… really… I don’t.

What’s wrong with FizzBuzz?

I believe in programming tests in the interview process, but not in the “trivial algorithm with pen and paper” type. In my opinion the following is wrong with the FizzBuzz test:

  1. No Google or other tools
  2. Being overlooked while writing
  3. No way to run the code (or check the syntax)
  4. No text editing (insertion/modification)
  5. Algorithm is trivial

To me, these differences with programming in the office make FizzBuzz a test that has nothing to do with the actual creation of software. Although I have no data to back it up, my feeling says that FizzBuzz success DOES correlate with programming experience. But programmers that are good at memorizing syntax are far less valuable than those solving non-trivial algorithms. Since FizzBuzz rewards only the first, I think it is flawed. So it is a bad test, so what?

Those comments… why?

Well, before we skip to the history of FizzBuzz I have one question about these posts that I want you to help me answer:

“Why do people post answers (code) to FizzBuzz articles in the comments?”.

Aren’t you disqualifying yourself by posting the answer to FizzBuzz? I feel you are saying “the answer is interesting” or “look, I can solve it!”. What’s up with that? Some people post answers in obscure languages, which I also do not understand. What is that supposed to mean? Does it mean “this obscure language can be used to solve this trivial problem” or “I know this obscure language good enough to solve a trivial problem”? Or, more understandable I guess, are all these reactions trolls to invoke a reaction? If that is the case, then what is the desired reaction?

One commenter (EdwardM) writes:

And, just because I’m a geek, and can’t help myself, here’s what I whipped up in a couple of minutes. I’m sure it could be better, but that’s when you start up an interesting conversation about refactoring in the interview, right? 😉

He knows it is wrong to post the answer, but still he does it. Is it the urge to share? The urge for recognition? Maybe that is all not true. Maybe I am too negative and is it a positive thing. Maybe it is fueled by the “joy of programming”, can that be it?

History of FizzBuzz

Okay, now as promised the first three posts from 2007 that started the whole FizzBuzz discussion in the first place:

  1. Imran Ghory: Using FizzBuzz to Find Developers who Grok Coding
  2. Reginald Braithwaite – Don’t Overthink FizzBuzz
  3. Jeff Atwood – Why Can’t Programmers.. Program?

Other interesting links on the topic:

Read them, but remember: beware of the comments! 😉