Best practices and the joy of programming


When I was about 16 years old (1996) I was programming object pascal (Delphi). In that language I wrote a calculator program to convert a number from decimal to binary. While implementing this functionality I found out that I could make this code generic, such that you could give it any base (2 for binary, 8 for octal, 10 for decimal and 16 for hexadecimal) and convert the numbers back and forth. This was an extremely satisfying experience and it felt like I created a thing of beauty, like I discover a secret or maybe as they call it “a programming gem”.

Since nobody uses Delphi anymore (you may want to try Lazarus though), I rewrote the code into Python for any beginner to understand.

def convert_base(s,b,nb):
	# character set
	# function to convert int to string
	def int2str(n,b):
		if n==0: return ''
		return int2str(n // b, b) + c[n % b]
	# function to convert string to int
	def str2int(s,b):
		if s=='': return 0
		return str2int(s[:-1],b) * b + c.index(s[-1:])
	# filter invalid characters
	s = ''.join([k for k in s if k in c[0:b]])
	# convert string and return
	if s=='': s = '0'
	s = int2str(str2int(s,b),nb)
	if s=='': s = '0'
	return s

I can’t imagine anyone will feel the same satisfaction reading this code as I did writing it in 1996. Let me explain why. In 1996 we did not have the Internet yet, or Stack Overflow, where all the programming questions you may dream of are already asked. You would typically learn everything from books, both the how and the why, and you could not cut corners by Googling the answer. So there was no guarantee, unlike now, that with proper research you find the most “Pythonic” implementation.

You could even turn this around. Nowadays we know so good how things “should” be done, that there is little room for innovation. If you come up with a different approach to a known problem it quickly dismissed as “wrong” and “not a best practice”. On one hand this may be a sign that the software industry is maturing. On the other hand it may be crippling, because we now have generation of programmers who have no clue why things are the way they are. They can’t argue the motives of their choices any further than it being a “best practice”.

I can think of plenty examples, but the most striking is when I was implementing “default routing” in Symfony2. It is considered a “bad practice” by the Symfony author, hence removed in the second version (and I implemented it again). Hardly any programmer I’ve met can properly argue why it makes sense that it was removed (but they all tend to have an opinion). I guess that proves the point.


How to win a senior programmer job interview

This post will give you 3 advices that will help you to win any job interview for a senior programmer position. It does not matter that you can’t program when asked during the interview, just follow these simple advices and you are one step closer to being a rockstar software developer earning big bucks!

Advice 1: Learn the Fizzbuzz answer

Most interviewers ask the same question to measure programming skills: program Fizzbuzz. It is a very popular, but extremely tricky assignment that even the most skilled programmers fail at. Just learn the code in the required language by hearth and you will fool any interviewer. Note that you really don’t have to understand the code as the explanation of what the code does is given in the assignment.

Java implementation (Fizzbuzz)

public class FizzBuzz {
	public static void main(String[] args) {
		for (int i = 1; i <= 100; i++) {
			if (i % 15 == 0) {
			} else if (i % 3 == 0) {
			} else if (i % 5 == 0) {
			} else {

PHP implementation (Fizzbuzz)

for ($i = 1; $i <= 100; $i++)
    if (!($i % 15))
        echo "FizzBuzz\n";
    elseif (!($i % 3))
        echo "Fizz\n";
    elseif (!($i % 5))
        echo "Buzz\n";
        echo "$i\n";

Python implementation (Fizzbuzz)

for i in xrange(1, 101):
    if i % 15 == 0:
        print "FizzBuzz"
    elif i % 3 == 0:
        print "Fizz"
    elif i % 5 == 0:
        print "Buzz"
        print i

C implementation (Fizzbuzz)

#include <stdio.h>

int main (void)
    int i;
    for (i = 1; i <= 100; i++)
        if (!(i % 15))
            printf ("FizzBuzz");
        else if (!(i % 3))
            printf ("Fizz");
        else if (!(i % 5))
            printf ("Buzz");
            printf ("%d", i);

    return 0;

Advice 2: Learn the “100 to 1” answer

A very smart interviewer has come up with an alternative to the popular FizzBuzz assignment called “100 to 1“. Probably because the FizzBuzz answers got really easy to Google. The assignment is to print a count down from 100 to 1 using a “for” loop that has a loop variable “i” that starts at 0. This blog has gotten exclusive access to the secret answers to this very hard and brand new assignment. Use them in your benefit!

Java implementation (100 to 1)

public class HundredToOne {
	public static void main(String[] args) {
		for (int i = 0; i < 100; i++) {

PHP implementation (100 to 1)

for ($i = 0; $i < 100; $i++)
    echo (100-$i)."\n";

Python implementation (100 to 1)

for i in xrange(0, 100):
    print 100-i

C implementation (100 to 1)

#include <stdio.h>

int main (void)
    int i;
    for (i = 0; i < 100; i++)
        printf ("%d\n", 100-i);
    return 0;

Advice 3: Failure defense and contract extension

If you make a mistake, then don’t worry. Claim it is due to test anxiety. Another great defense is that you could not solve it, because you rely heavily on your favorite IDE. If that does not work, then you can say that the assignment seemed so trivial to you that you could not believe it was the actual assignment and you were looking for the hidden “difficulty”. One of these will work every time, guaranteed!

Some people have commented that they are worried about being outed as an impostor as soon as they won the job. Don’t be! By the time you are “up to speed” you are already earning big bucks for a few months and you have passed your trial period. Also, by posing humble, showing your effort and indicating that you are having trouble “adapting to the working environment” or “finding your spot in the team” you can probably achieve to win a contract extension.


It is important to realize that you can become good at winning a senior programmer job and also that being a great programmer is not always the easiest way to win it. Be aware that there may be some luck involved as not every interviewer asks the right questions (the ones above) or is sensible enough to buy your defenses (if you even need these). Don’t be discouraged if you do not succeed at once. There are enough companies eager to hire senior programmers, so you can have many chances as they interview anyone who sends them an impressive CV.

Let me know if it worked for you! Or maybe don’t… as I would become really depressed if it did (as this is a satirical post). ūüėČ


10 reasons why PHP is better than Python

“There are only two kinds of languages: the ones people complain about and the ones nobody uses” – Bjarne Stroustrup,

People wonder: Did he really say that? Yes, he did. If you wonder who Bjarne Stroustrup is: He created the C++ programming language. Many people believe that Python is “pretty cool” and PHP is “really bad”. But as we all know, there is truth in the saying:

It’s a poor carpenter who blames his tools.

I believe both good and bad software can be written in any language. And I should probably also quote Joel Spolsky who calls “language wars” a “fruitless debate”. But nevertheless, if you program in PHP and run into one of these Python “evangelists”, then the following list may come in handy.

10 reasons why PHP is better than Python

  1. Python hosting, hard to find and expensive, while cheap PHP hosting is everywhere.
  2. Python cannot be mixed with HTML (needs a template library), while PHP can.
  3. Python has no proper encapsulation (private keyword), while PHP has.
  4. Python is hardly used in the real world, while something as big as Facebook is built on PHP.
  5. Python has a great community, but it is not comparable to PHP’s.
  6. Python has some books and tutorials, but PHP has way more of them.
  7. Python does not have the live docs (famous forum-like reference manual) like PHP has.
  8. Python does not have a steep learning curve, but PHP is still easier to learn.
  9. Python indentation for code blocks is prone to errors, while PHP uses curly braces.
  10. Python¬†lexical scoping is a mess (‘global’ and ‘nonlocal’ keywords fix this), while PHP behaves as expected.

To wrap up

PHP has come a long way. Today it is a mature language that executes fairly speedy. Agreed that it has some quirky naming of it’s built-in functions, but hey.. that’s the price you pay for backwards compatibility.

Hint: Make sure to also check out this page on that is a good reference when comparing Python to PHP.



PHP 5.3 is now officially end-of-life (EOL)

PHP 5.3 last regular release (5.3.27) was done in July 2013, back then we read the following statement on the release notes:

Please Note: This will be the last regular release of the PHP 5.3 series. All users of PHP are encouraged to upgrade to PHP 5.4 or PHP 5.5. The PHP 5.3 series will receive only security fixes for the next year. –

So, back then it was not a big deal, since security fixes would be released for one more year (and a year seems very long). But last week PHP 5.3.29 was released and since that year has passed PHP 5.3 is now officially end-of-life (EOL). This means there are no further updates, not even security fixes, as you can read in the release notes:

This release marks the end of life of the PHP 5.3 series. Future releases of this series are not planned. All PHP 5.3 users are encouraged to upgrade to the current stable version of PHP 5.5 or previous stable version of PHP 5.4, which are supported till at least 2016 and 2015 respectively. –

Ubuntu Linux users that run the still supported (and popular) 12.04 LTS release on their web server should not be worried too much: Ubuntu maintainers will backport security fixes until 2017. But running PHP 5.3 might be cumbersome, especially if you want to develop using the latest PHP frameworks or libraries. These often contain “array short syntax” and thus require PHP version 5.4 or higher . The simplest option is to upgrade your Ubuntu 12.04 LTS to 14.04 LTS, since that comes with PHP 5.5. If you decide to stay at 12.04 for a while, you will be stuck with 5.3.10 from the¬†repo, unless you…

Upgrade PHP from 5.3 to 5.4 in Ubuntu 12.04 LTS

This is more or less the only option you have. Since it is not officially supported you have to install a PPA. I normally do not recommend this, since you could mess up your system badly and/or severely endanger the security of your machine. But I must admit that OndŇôej Sur√Ĺ’s PPA is a very famous and widely¬†used one, which would make it a bit more trusted. So, I will include the instructions, but you have been¬†warned:

sudo apt-get install python-software-properties
sudo add-apt-repository ppa:ondrej/php5-oldstable
sudo apt-get update
sudo apt-get dist-upgrade

Why you should not upgrade PHP to 5.5 in Ubuntu 12.04 LTS

PHP 5.5 and it’s dependencies are provided by the “ppa:ondrej/php5” repo. And even though PHP 5.5 is longer supported and more powerful than PHP 5.4, you should probably stick to PHP 5.4. The reason for this is that PHP 5.5 requires Apache 2.4, where Ubuntu 12.04 comes bundled with Apache 2.2 by default. This means that when you upgrade PHP 5.3 to PHP 5.5 you also have to upgrade Apache 2.2 to Apache 2.4 (as a dependency). This could¬†break many things, but it will (most certainly) break your virtual host configuration. So this is something I can’t¬†recommend unless you are really sure what you are doing. Do not upgrade PHP to version 5.5 without having a tested upgrade plan. I’m serious… be very very careful!


PyCon Australia 2014: conference videos online


PyCon Australia 2014 was held last week (1st Р5th August) at the Brisbane Convention & Exhibition Center.

PyCon Australia is the national conference for the Python Programming Community, bringing together professional, student and enthusiast developers with a love for developing with Python.

For all of you that did not go, most of the conference is available on YouTube (39 videos):

  1. Graphs, Networks and Python: The Power of Interconnection by Lachlan Blackhall
  2. PyBots! or how to learn to stop worrying and love coding by Anna Gerber
  3. Deploy to Android: Adventures of a Hobbyist by Brendan Scott
  4. How (not) to upgrade a platform by Edward Schofield
  5. Caching: A trip down the rabbit hole by Tom Eastman
  6. Verification: Truth in Statistics by Tennessee Leeuwenburg
  7. Record linkage: Join for real life by Rhydwyn Mcguire
  8. Command line programs for busy developers by Aaron Iles
  9. What is OpenStack? by Michael Still
  10. Software Component Architectures and circuits? by James Mills
  11. IPython parallel for distributed computing by Nathan Faggian
  12. A Fireside Chat with Simon Willison
  13. Accessibility: Myths and Delusions by Katie Cunningham
  14. Python For Every Child In Australia by Dr James R. Curran
  15. Lightning talks
  16. How to Read the Logs by Anita Kuno (HP)
  17. Serialization formats aren’t toys by Tom Eastman
  18. Django MiniConf: Lightning talks
  19. What in the World is Asyncio? by Josh Bartlett
  20. Try A Little Randomness by Larry Hastings
  21. Building Better Web APIs by HawkOwl
  22. devpi: Your One Stop Cheese Shop by Richard Jones
  23. Learning to program is hard, and how to fix that by Jackson Gatenby
  24. Lesser known data structures by Tim McNamara
  25. The Quest for the Pocket-Sized Python by Christopher Neugebauer
  26. Sounds good! by Sebastian Beswick
  27. Running Django on Docker: a workflow and code by Danielle Madeley
  28. Software Carpentry in Australia: current activity and future directions by Damien Irving
  29. The Curse of the Django Podcast by Elena Williams
  30. Grug make fire! Grug make wheel! by Russell Keith-Magee
  31. (Benford’s) Law and Order (Fraud) by Rhys Elsmore
  32. The Curse of the Django Podcast by Elena Williams
  33. Lightning talks
  34. The Curse of the Django Podcast by Elena Williams
  35. Seeing with Python by Mark Rees
  36. Descriptors: attribute access redefined by Fraser Tweedale
  37. How do debug tool bars for web applications work? by Graham Dumpleton
  38. Continuous Integration Testing for Your Database Migrations by Joshua Hesketh
  39. Closing

Have fun watching!