Updating the Python Job Board

Have you ever looked at the Python.org Job Board? It lists in chronological order postings sent by recruiters and employers looking for developers with skills and interests in Python.

The Job Board has been around since at least 1997 (I checked using the WayBack Machine just to see what it looked like) and not too much has changed since then. New postings are sent by email and a volunteer cuts and pastes them into the head of a text file, fixes the formatting and checks it into Subversion. Instead of the original HTML template, now an ReStructuredText template is used which causes all sorts of problems because few people know what ReST is or have any idea how to format their posting. Eventually, the posting (if accepted) turns up on the web page and later in the RSS feed and on Twitter.

Here are some stats: Currently, there are approximately 40 jobs posted per month. The web page is in the top 10 entry pages for the site month after month gathering around 80k hits per month. The RSS feed gets around twice that and some third party sites re-brand the content and redistribute it which we have no stats for. The Twitter page has around 230+ followers.

Everything on the page is static and the Python infrastructure team has been against dynamic content for good reason but in a time when Google's appengine allows the the easy construction of a dynamic website with additional server capacity on demand, maybe it is time to update the Jobs Board. Two things to change are the process by which jobs are added and the lack of useful search or visualization ("where are the jobs?", "where are the job-seekers?").

The largest part of the work is converting the incoming posting into valid ReST and checking the page after pasting the new posting in. That's it. Emails are answered with a templated response (for both additions and removals) and checking into Subversion takes seconds.

There is good progress being made on a web front-end that will allow employers to directly submit postings and see how they look in their final HTML form. These will be held pending approval. The use of the browser will allow postings to be added and updated from anywhere instead of only from a machine that has the development environment currently required. There is also some intent to support submission by email but that has details yet to be worked out.

All this will be ready for some friendly testing soon (mid-November) and hopefully will reduce the response time and the amount of work needed to add postings as well as adding feedback to employers about how their ad is performing.

If you have comments or suggestions or would like to help, please let me know!

one of those days..

I have not written anything in here for a while because:

1) I'm too busy
2) I don't have anything interesting to say
3) No-one reads this, right?

A funny thing happened today.. I found this post from Steve Yegge that brushed aside my dejected writer's block and reminded me why I started blogging in the first place - partly to help me remember interesting things and partly to improve my writing skills. Or lack of.

If you do read this, leave me a comment.

Moving House

Not literally moving house but I decided it was time to upgrade my python.org local build machine from Redhat ES4 to something more recent so I fired up a Fedora Core 11 VM that I haven't been using so far, copied over my SSH keys and started checking out the website svn repository.

There was nothing wrong particularly with ES4 but Xemacs is a little long in the tooth now and didn't want to mess the machine config around to install Komodo or Eclipse when that VM was really for testing releases at work.

The checkout finished without a hitch (can't get PEPs but that was expected). Now to install docutils, yaml and pyramid.

I am using an RPM-based system so I have a choice of installing the packages from source, installing from easy_install or RPM. My preference is RPM if only to make sure that I have a single place cataloging all software installed on system paths. If I wanted to get into virtualenv or some other sandbox arrangement (not today) then I could go hog-wild and install all sorts of crazy stuff.

I install docutils and run make again and it fails looking for yaml. There's only one YAML available from Yum that is Python related but is it the one that pydotorg is using? A quick search of the wiki and a broken link or two later and I decide to give it a go.

The README in the checkout root directory tells me I need mako (a templating library) as well. Yum adds in python-beaker (a caching library or WSGI middleware layer) and libyaml and away we go.

The next make command succeeds so start the server and presto! Everything is working, time to shut down the ES4 image.

Start to finish.. around 15 minutes. Lots faster than the first time or two when the site went to using Pyramid.

Python Job Board Tag Cloud

Using TagCrowd (http://www.tagcrowd.com), I created this visualisation of the most common words on the Python Job Board (after removing meaningless, high-frequency words like contact, description, e-mail etc).

ability (90) able (47) agency (43) analysis (40) applications (214) apply (41) architecture (40) automation (39) based (71) build (101) business (48) ca (39) candidate (98) client (66) code (90) com (308) communication (56) company (80) computer (87) create (42) css (56) currently (38) data (98) database (55) degree (43) design (143) django (111) email (56) engineer (106) environment (110) equivalent (38) etc (45) excellent (48) following (37) frameworks (73) highly (44) html (59) http (159) ideal (43) implement (45) including (96) information (44) interest (62) java (46) javascript (84) job (261) join (39) knowledge (140) language (69) lead (49) linux (106) looking (130) maintain (45) management (108) mysql (65) network (39) open (58) opportunity (51) performance (57) php (50) platform (40) please (71) plus (76) position (77) posted (186) problems (49) product (46) programming (127) project (80) python (488) related (38) requirements (85) responsibilities (72) role (42) science (75) security (42) senior (42) services (76) site (47) skills (207) software (266) source (57) sql (41) strong (123) support (58) systems (105) team (185) technical (83) technologies (111) telecommuting (87) testing (117) tools (60) uk (57) understanding (53) unix (42) usa (87) used (85) web (362) www (99) years (115)

created at TagCrowd.com

Using Git Behind a Firewall

I am doing a lot of work involving the Samba code base right now and it has frustrated me that I cannot check out the trunk using git because I am behind a firewall.. then again the tarballs for the stable releases have been adequate until I realised that my tinker toy modifications needed to be made into patches and that was tricky..

Long story short:
if you try 'git clone git://git.samba.org/samba.git samba' and it fails because of a firewall issue then change the scheme from git:// to http:// and presto!

I think this only works if the repository you are checking out has a gitweb installation.