stop trying to show how smart you are

Sitting feeling bright and somewhat giddy with my own self confidence I decided to dust down my copy of “C++ Template Metaprogramming” by David Abrahams and Aleksey Gurtovoy. Thinking I really need to be the master of something and further thinking C++ template programming was that “thing”. I approached the task with some gusto for at least a few days hours minutes, however, as with most advanced study you really have to be willing to dedicate your life to it. It’s never long before the inevitable gloom of reality sets in and you realise that this is more than an afternoons work. Without much control your brain starts telling you that there are much more important things you could be doing. Thankfully for everyone else on your team you stop and decide that it’s just not worth it.

The fact is that writing code that only those who have decided to dedicate a fair chunk of their life to is never going to be the right choice. There is nothing worse than trying to understand code like this. There are times where it pays to be smart, like when you have a better (much) faster algorithm, or doing something saves you hundreds of lines of code. But most of the time you see this kind of code it’s people just trying to prove how smart they are.

Now C++ is not alone in this. Ruby has exactly the same problem – you can get stuff happening as if by magic. I could be wrong but I imagine most people read code from top to bottom, working line by line, they don’t expect code to be auto generated or happen as some elaborate method_missing technique. Sure I can maybe relax my vitriol for those building frameworks where things are being used in some generic unknown context. However the vast majority of applications out there don’t have to deal with these problems. The biggest problem these applications face is that the developers creating them want to architect some elaborate framework to fit a very specific use case – it almost makes me cry. I’m not sure why as a profession we don’t revel in an approach that oozes simplicity. This is certainly what the smartest developers I’ve working with have always managed to do.

is ruby killing your career?

I’m probably at the point with Ruby where I consider it my programming language of choice (I program in both Ruby and C++ in my day job).

Over the last few years I’ve kind of grown to love Ruby but I’m not really one to get passionate over someone else’s choice of programming language – apart from Java, which, I’m sorry, I hate. However, when it comes to employment, there is no doubt in my mind that being competent in a particular programming language can strongly influence A) getting an interview and B) getting the job.

This is why ruby developers, like me, are killing their career. Sure Ruby is cool and Rails is awesome but do a quick check on job boards and see how many people are looking for a ruby developer. Actually, let me save you the time I’ve done some of the work already.

I’m not claiming this to be scientific in anyway what-so-ever but it does warrant some thought. I only searched using the programming language as a keyword, which, I know, may not give the full story but should convince you there is some merit in the point that I’m trying to make. Additionally (and I suppose somewhat importantly) my search area was restricted to Scotland.

First up I carried out a search on s1jobs.com. The table below gives a summary of the results:

Language Number of jobs matching keyword
Ruby 3
Java 18
C# 26
C++ 9
PHP 7

I then tried a cwjobs.co.uk:

Language Number of jobs matching keyword
Ruby 2
Java 35
C# 45
C++ 45
PHP 4

As you can see, the job prospects for Ruby developers here in Scotland are somewhat dire. Sure, people don’t always look for a particular programming language when employing someone (which is a decent policy) but, as I said above, it helps a lot.

I decided to take my crude search a little further as I thought “Hell, there will be waaaaaaay more cool Ruby jobs in London”. Below we have the results, just cwjobs this time:

Language Number of jobs matching keyword
Ruby 57
Java 792
C# 838
C++ 611
PHP 196

That was kind of disappointing! Ruby still doesn’t do that great – even worse when you realise there were over 200 that mentioned Perl and 150 Python. By the looks of it if you want to maximise your chances of getting a job in the UK, and already doing Java or C# in your day job, you’d be better off learning C/C++ in your spare time.

Is all this going to stop me coding in Ruby? Probably not. Is it worth thinking about for a minute? Yes sure. If I was starting my own company and was hoping to get some developers in then I’m likely to be faced with a problem. Yes you can train people up, but that costs time and money. When they leave it may be worse, as the chances of finding replacements at the required skill level will be difficult. Finding a Java/C#/C++ programmer is bound to be far easier.

So is it all bad news for us Ruby developers? Well not if you plan to move to California – yeah yeah I know I’ve went on about it before. I’m not exactly sure of the popular job boards in the US so I went with the only one I knew off the top of my head, careers.stackoverflow.com. The results for the Bay Area are as follows:

Language Number of jobs matching keyword
Ruby 27
Java 33
C# 10
C++ 23
PHP 17

Maybe this was a skewed sample set but impressive all the same. So moral of the story is if you want to be a well paid Ruby hacker make sure you don’t stay in Scotland :-).

idiot’s guide to linux on amazon ec2 – part 2

In Part 1 I covered how to remove the root login, create a new user, and add this user to the list of sudoers on an linux ec2 instance. In this section I will cover how I got Ruby on Rails, MySQL, Nginx and Thin working together on the Ubuntu instance.

First up, I think it’s worth taking a moment to explain what Nginx and Thin actually are, as they are maybe not as well known as the others.

Nginx is a very fast web/proxy server developed by Igor Sysoev. According to wikipedia it currently runs, amongst others, the WordPress and Github websites.

Thin is a ruby web server that “glues together 3 of the best Ruby libraries in web history”[1]:

  1. the Mongrel parser, the root of Mongrel speed and security
  2. Event Machine, a network I/O library with extremely high scalability, performance and stability
  3. Rack, a minimal interface between webservers and Ruby frameworks

Right on to the job at hand and first up was getting apt-get working!

To my surprise (but probably widely known) the Ubuntu ec2 instance did not come with apt pre-configured – unlike yum on a Fedora instance I had previously used. Instead you first have to run apt-get update to download the list of package locations. Now that we’ve done this we can get to work installing the other bit of software required.

MySQL
The first thing we need to install are the MySQL client and server. To do this run the commands:

sudo apt-get install mysql-server
sudo apt-get install mysql-client

Then you need to make sure that the root password for MySQL is set to something secure. This can be done using:

sudo mysqladmin -u root a_good_secure_password

Ruby
Now it’s time to install Ruby on Rails. First we need to install ruby, rake, rubygems, and a couple of other useful packages. The following commands should add the required binaries to your path:

sudo apt-get install rubygems
sudo apt-get install build-essential
sudo apt-get install rake
sudo apt-get install ruby-full

We can now use gem to install rails:

sudo gem install rails

As we will be using MySQL you probably also want to install the MySQL client development library in order to get the ruby gem to build/install correctly. This can be done by running:

sudo apt-get install libmysqlclient15-dev

Obviously the version of the libmysqlclient will depend on the MySQL version that you are using. Finally we can install the mysql gem by running:

sudo gem install mysql

Nginx and Thin
To install the nginx package we run the command:

sudo apt-get install nginx

Nginx then needs to be started so we run:

sudo /etc/init.d/nginx start

By default the package should also add the entries required to restart nginx if the instance is rebooted – you can always check by looking in the /etc/rcX.d directory (where X is the run-level number).

Now it’s time to install thin:

sudo apt-get install thin

Creating application config files for Thin and Nginx
It is a good idea to create config files that can be used to restart your thin clusters. To do this we use the thin config command. Now, let’s assume the app is called myapp and so we run the following command:

sudo thin config -C /etc/thin/myapp.yaml -c ~user/www/myapp --servers 3 -e production

This creates a thin config file /etc/thin/myapp.yaml that starts 3 instances of the rails application found in ~user/www/myapp using the production environment. By default it will start the first server on port 3000 and the next on 3001, and so on. Should you wish to specify the port you can supply it with the -p option, i.e. -p 6666.

You can now start your thin clients using:

sudo /etc/init.d/thin start -C myapp.yaml

It’s worth noting that if you don’t specify the -C option thin will use the config files found in /etc/thin and start the thin clients for each config file found in this directory.

As we want to use nginx as a proxy to our thin client instances we must create a nginx config file for our application. An example of such a config file is shown below:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
upstream myapp {
    server 127.0.0.1:3000;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
}
 
server {
    listen   80 default;
    server_name example.co.uk;
 
    access_log /home/user/www/myapp/log/access.log;
    error_log /home/user/www/myapp/log/error.log;
 
    root   /home/user/www/myapp/public/;
    index  index.html;
 
    location / {
        #auth_basic "Please supply login details";
        #auth_basic_user_file /home/user/www/myapp/public/protect.passwd;
        proxy_set_header  X-Real-IP  $remote_addr;
        proxy_set_header  X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header Host $http_host;
        proxy_redirect off;
 
        if (-f $request_filename/index.html) {
            rewrite (.*) $1/index.html;
            break;
        }
 
        if (-f $request_filename.html) {
            rewrite (.*) $1.html;
            break;
        }
 
        if (!-f $request_filename) {
            proxy_pass http://myapp;
            break;
        }
    }
}

Lines 1-5 set up the proxy for our thin clients that we started on ports 3000-3002. The values that you include here obviously depend on the number of clients that you started and the ports they are running on. The rest of the file is dedicated to setting up the web server with the majority of settings being pretty self explanatory, so I’ll only highlight the important bits.

First, we see that the server waits for requests on port 80 and the domain used for this site is example.co.uk (lines 8-9). It’s worth noting that hosting a subdomain, say subdomain.example.co.uk, is as easy as replacing example.co.uk in line 9 with subdomain.example.co.uk. Lines 20-23 take care of things like forwarding the real IP address to rails as well as some other set up required for https. Finally the remaining lines in the file check to see if an index.html file is available at the url specified and if so displays displays it (lines 25-28), serve static files straight up (lines 30-33), and finally if the file specified by the url does not exit on the file system it sets headers and proxies for our thin clients and passes it on.

As a side note, lines 18 and 19 that are commented out enable basic http authentication in nginx. You can uncomment out these lines if you require this feature. The password file for http auth can be generated using the apache util htpasswd – you will need to install the package that contains the htpasswd utility.

The config file (let’s call it myapp) is placed in /etc/nginx/sites-available, and finally a sim link is set up between the sites-available directory to the sites-enabled directory to enable the website:

sudo ln -s sites-available/myapp sites-enabled/myapp

That’s it. All we need to do now is restart nginx (/etc/init.d/nginx restart) and assuming your config is ok the site should now be up and running. (If nginx is already running and you want to parse the config without restarting you can always get the pid of the nginx process, ps aux | egrep '(PID|nginx)', and run sudo kill -HUP PID – in fact this is all you actually need to do to get your site up and running)

[1] The Thin homepage – http://code.macournoyer.com/thin/

sticking with what you know

There comes a time in every programmers life when they have to learn new things and step out the box. Yeah it’s difficult, for sure. It’s all too easy to create the latest application in your software empire, using a language you’ve been developing in for the last 10 years. However, the real problem is thinking this is the only choice. When is it time to abandon this certitude?

First, we cover the forced abandonment. This is when you are pushed kicking and screaming into pastures new, whether you like it or not, i.e. the new job. Here, not only is the new language curve ball thrown (viciously), but you also get whole new set of business rules into the bargain. So what do you do? You program the new language like the old one, only translating the syntax in your head. This is not the best way to learn a language though. Why? Well consider those C programmers trying to program imperatively in Java, Java programmers in JavaScript, C++ programmers in Ruby, and so on. When there is a change in paradigm this mapping strategy just doesn’t work – a similar situation exists with languages that contain a more powerful expression set. It also encourages the behaviour where people learning enough to get the job done, without understanding what is really happening, or that there may have been a better way using “unmappable” language’s features. A better approach would be to write something small, and new, that allows you to explore the language’s features. I’m sure most people can think of something they could write. Furthermore, if you can make it useful to other people, or even your new employer, then everyone’s a winner! This is something I touched on before.

For many people though, this is the only time they will ever consider abandoning. This is sad, and a poor characteristic in a programmer. And to be honest, I just don’t understand it. That’s not to say that I don’t accept that people just do programming as a job, then go home and don’t think about it. However, it’s like most things in life, it’s nice to progress?

As a programmer there will also be other signs that the tide is turning, and you don’t have to be too alert to spot these. Previously I wrote “Perl is Dead, Long Live…Perl?” and being a big Perl fan it was sad to see the language apparently dying, so I know what it’s like. Some signs to look out for may be:

  • the language features are not moving on (Java watch your back) – the people who created it no longer care,
  • the community surrounding the language is dwindling – the people who use it no longer care,
  • there is little in the way of choice when selecting libraries/frameworks – the experts have fled,
  • other programmers have never heard of it – there is no buzz,
  • jobs using it are few and far between – businesses have given up on it, the death kneel.

However, this is all not to say that you give up on your language just because it’s no longer cool – popularity is by no means a great indicator that something will suit your needs. It need not be the case that you give up on your language of choice, instead it could be that you contribute and drag the language forward. But be careful with this one.

Finally, any decent employer will want to see that you are continually developing your skill set – their business needs are continually evolving, so why aren’t you? You are much more likely to land a better job if you contribute to your own education in some way. It looks good and it’s also something to talk about.

So go out and learn something new today, and stop sticking with what you know.

programming language obsession makes you look stupid

It appears that many people seem to have too much of their life wrapped up in a particular programming language.  You only need to look over at dZone, Reddit or Digg to see this fandom in all its glory.  All too often we find articles about why such and such a programming language sucks.  However, just because a language sucks for one (or a couple) of particular reasons, it doesn’t mean it is not useful in general.  It’s like me saying computers suck because they crash.  However, just because my computer crashes from time to time doesn’t mean it’s not useful.

I just find the whole religious aspect to a language rather pathetic.  The result often leads to the inappropriate choice of language for development of an application, simply because the individual’s voice that is heard the loudest makes the decision.  Ok, if any language will do then just go with whatever you are comfortable with, but stop yourself bitching about other people’s choice of language.

For example, the number of times you hear people saying dynamic languages are no use, for a plethora of reasons, is stunning.  You would think that no one had ever developed anything of reasonable size and scale in these languages.  It’s not as if most of the largest websites on this planet have not been written in PHP/Python/Ruby, yet you still read articles where people are saying where such a feat is likely to lead to catastrophe.  Stop doing this it makes you look stupid.

The same can be said for those that diss Java.  OK, I think it’s possibly a poor choice for those considering a startup web business (basically if you are going to be considering shared hosting Java as an option on this platform is nonexistent), but there are many places where the use of existing libraries written in Java make it the ideal choice for an application.  An example of this can be seen in what I’m currently working on, which is an application that uses constraint programming techniques.  There are a few such libraries in other languages but the most mature and feature rich (and free) are in Java so sense dictates you use Java.

Essentially my bug bear boils down to people choosing a language for the wrong reasons, more often than not due to blind faith rather than education.  Don’t just use a language because it is popular, use it because it best fits the job needing done.  Popularity can come into it though, because at the end of the day you might wish to tap into a large set of existing programmers, or you may want to attract the brightest young talent who want to work in what’s popular/new.  Just don’t let it be the only thing that dictates your choice.

Unfortunately, regardless of however many blog post or articles people read and write, I feel that we are never going to remove this inherent language evangelism.  Maybe the industry would be in a far better position if we were all language agnostic.  Can you imagine how much more work would get done if people spent the first two months of a project actually doing work rather than arguing about what language it should all be written in.