Broadband monitoring tools

A few weeks back I was faced with 30, 60 and sometimes even 95% packet loss every 3-4 days, so I wanted to setup some simple network monitoring to keep track of my broadband connection. I started off using ad-hoc tools whenever the internet mis-behaved, and then I would call up my ISP and wait for them to fix it. This resulted in quite a few refunds! Next, it was time to gather some data on just how bad the situation was – who knows, maybe the information will help my ISP troubleshoot the problem (I can tell them how long the problem has been there, even if I’ve been asleep or at work), or perhaps get past the first line support people.. Continue reading “Broadband monitoring tools”

Using chef to provision a Django webapp

Wouldn’t it be nice to be able to deploy a Django webapp on your own server just based on a git repo URL? I set out to try this using the neat-looking family of “application” chef cookbooks. These can be used to setup nginx, gunicorn and a Django webapp. With a few more chef recipe extensions we can add the necessary MySQL (or other) database bits, and we’ll have a pretty comprehensive deployment.

The main aim of this post is to describe how go as quickly as possible from zero to a fully chef-deployed Django app. This is not a substitute for learning chef of course.

Continue reading “Using chef to provision a Django webapp”

The experience of participating in a MOOC

I just finished taking a Coursera course on Software Defined Networking (SDN), taught by Dr. Nick Feamster from Georgia Tech. Since I was initially undecided on whether or not I should take it, I thought to blog about the experience, in case it will help anyone else make such decisions in the future. I won’t re-iterate content from the course or post answers here. 😉 Continue reading “The experience of participating in a MOOC”

IPv6 – doing your part

I sometimes find it annoying that IPv6 still isn’t readily available. This raises the following question in my head: what can we, as tech-savvy individuals, do about it, now? I think the main thing we can do is ask for it, and use IPv6. The aim of this blogpost is to give you ideas where and when you can ask for it, how you can use it in the mean time even if you don’t get what you ask for, and tell you about my personal experience in practising this.

There probably won’t be anything revolutionary in this blog post for people who have been following the IPv6 deployment and who have IPv6 addresses assigned to their computer and any servers they may use… But I think that if we don’t ask for it, we won’t get it any quicker, so I’m writing this ask anyway 🙂 Continue reading “IPv6 – doing your part”

Using Flex and a Bison GLR parser in the Facebook Hackercup

I thought the following problem statement sounded like an interesting parsing problem. What makes it interesting is that you need to generate a parser of a perhaps less-well known type, namely a GLR-parser (“generalized left-to-right parser”). Of course this isn’t as efficient as the intended solution, but maybe it will come in handy some day, in a situation that can’t be solved with a simple algorithm.

I’ll assume that you’re familiar with the basics of lex/flex and yacc/bison, as well as the general concepts around lexical analysis, grammars and parsers.

Here’s an excerpt of the problem statement: Continue reading “Using Flex and a Bison GLR parser in the Facebook Hackercup”

Back after mod_wsgi & Python 3

The Python-powered bits of this website (my portfolio as well as the redirection to the blog that’s active for ‘/’ unfortunately) threw up HTTP error 500’s since Nov 18. Unfortunately I only now noticed this, though I’m not sure if Django’s email reporting system would’ve alerted me about this.

I got the following errors:

[usual headers] mod_wsgi (pid=14552): Target WSGI script '/<path to django project>/' cannot be loaded as Python module.
[usual headers] mod_wsgi (pid=14552): Exception occurred processing WSGI script '/<path to django project>/'.
[usual headers] Traceback (most recent call last):
[usual headers]   File "/<path to django>/django/django/core/handlers/", line 4, in <module>
[usual headers]     from cStringIO import StringIO
[usual headers] ImportError: No module named 'cStringIO'
[usual headers] 
[usual headers] During handling of the above exception, another exception occurred:
[usual headers] 
[usual headers] Traceback (most recent call last):
[usual headers]   File "/<path to django project>/", line 25, in <module>
[usual headers]     from django.core.handlers.wsgi import WSGIHandler
[usual headers]   File "/<path to django>/django/core/handlers/", line 6, in <module>
[usual headers]     from StringIO import StringIO
[usual headers] ImportError: No module named 'StringIO'

I guess what happened is that an upgrade switched mod_wsgi to use Python 3 rather than Python 2, and for some reason Arch Linux didn’t replace the mod_wsgi package with the new mod_wsgi2 package, which uses Python 2. I must admit, the above is a rather peculiar way of beign notified that your WSGI process is using the wrong Python version.

Lesson learned: monitor your server automatically.