Saturday, July 13, 2013

Using Python decorators for registering callbacks

In my previous post we talked about Python decorators and an intuitive way of remembering how decorators with arguments work.

The following code snippet had triggered the whole chain of thought:

Now that we know what decorators with arguments do, which is essentially - calling the decorator factory with the argument, using the argument to make logical branching in the decorator wrapper and returning the wrapper, we can now try to understand the above code. We first move on to the decorator route's source code found here to see it's implementation. Keep the source code opened in a different tab, as we will refer to it in the later sections.

This code deviates a bit from what we think about how decorators are used - decorators wrap the functionality of a target function with certain pre and post actions, like so:

 Decorator calling func
 In the function
 Decorator called func

But there isn't any call to the target function index in the route function definition. Instead, this code snippet throws light on another functionality of decorators - registering callbacks.

Callbacks are registered functions which are stored in some container data structure (mostly hashes with key as function name and value as function references). For example,

  calling func1 with arg 1
  calling func2 with arg 2

They are useful in building a map of functions and depending on specific user input, the hashes are looked up and the corresponding key's value - which is a function reference is called.

Monday, June 10, 2013

Thinking out aloud: Python decorators

This is not yet another explanation of decorators. There are a lot of people who have done a great job of explaining it. What this post is about is the way I understood it and how I wrap my head around decorators (pun intended).

Pre-requisite: this awesome stackoverflow answer on decorators.

I had been trying to learn Flask and came across this nice post. It contains a good introduction to flask in the form of a mini project. While going through the post, I came across this snippet:

@app.route('/') is a decorator which registers the index function to be called when a user makes GET requests to the root page.

I always get the part where we say that a decorator is a function which modifies another function - wraps it with a sort of pre and post functionality. The part of where decorators are passed arguments is what used to confuse me and led me to revisit the afforementioned stackoverflow post

For example, it is easy to understand this:


Decorator calling func
In the function
Decorator called func

which means that when Python encountered the @ symbol it did an internal equivalent of
func = decorator(func)

which in turn means that a decorator is a function which takes in a function and returns a wrapper over that function and reassigns that wrapper to the original function variable.

This has the side effect of redefining the function name also (func.__name__), to be that of the wrapper function, but as the stackoverflow answer mentions functools.wraps comes to the rescue.

What used to stall me were these kind of examples:


func1 args - [this, that]
func2 called_from_line:31 args - [who, what]

For func1 our logging is not as verobse as func2 which has 'debug' log level. This is possible because the decorator creating function takes an argument which decides logging behavior (whether to print line no. of caller or not).

The magic of closures is also involved because the decorator and the wrapped function remember the original environment that they were bound with (for func1 the variable loglevel is set to 'info' in wrapped_around_func and for func2, it is set to 'debug')

But what is the deal with the nesting of functions?

Saturday, October 13, 2012

googlecl = blog in vim

This post was uploaded from my Ubuntu box by running the command:
$ google blogger --blog "Curiosity heals the cat" post --title "googlecl = blog in vim" --src googlecl.txt

where googlecl.txt contains the content you are reading. Talk about making it easier to post! :)

Now I can type out on vim snuggled in the dark, warm comfort of the terminal without resorting to browser plugins supporting vim.

A small note on the setup - googlecl works with gdata library. Using the latest versions of googlecl and gdata caused problems for me.

But googlecl worked like a charm when I used the following packages:

googlecl-0.9.13.tar.gz + gdata-2.0.14.tar.gz= vimvana!

Be sure to set/unset http_proxy and https_proxy environment variables before starting to use googlecl. I had moved to a different network without proxy and googlecl gave me a stack trace, instead of a meaningful error message to disable my proxy.

When you run blogger operations for the first time, googlecl will check if you have obtained an access token to perform this action. If you haven't, it will try to obtain one (by opening a browser window and asking you to sign in)

Once you are signed in googlecl will put the authentication token in /home/your_user/.local/share/googlecl with the name as

I find it useful to delete this file once I am done with my work so that my acccess is revoked once I am done with my work. You can also invalidate the access token by going to Google settings => Security => Connected application and sites  and removing the access token manually.

googlecl supports editing of google-docs but not of blog posts. So you have to do a:

$ google blogger --blog "Curiosity heals the cat" delete --title "googlecl = blog in vim"
$ google blogger --blog "Curiosity heals the cat" post --title "googlecl = blog in vim" --src googlecl.txt

May be a deal breaker for some people.

More info about googlecl at googlecl manual

Sunday, March 4, 2012

Using mdadm to learn RAID concepts

I've been using mdadm to learn about software RAID configurations on Linux and I find it to be a great resource to play around with and do some hands on work. How I wish we were taught using these tools in college, rather than just being bombarded by all possible combinations of RAID.

Having the ability to setup and tear down VMs at the snap of a finger makes me think how fortunate CS students are nowadays. We had it tough. At the risk of digression, I sound like one of the Yorkshiremen from the classic Monty Python sketch - The Four Yorkshiremen

Statistics have shown that 85% of the audience, after clicking the above link have spent at least 45 minutes visiting the various sketches of Monty Python, including, but not limited to - Woody and tinny words, Argument Clinic and others.

And.... we are back. :)

This tutorial gives a gentle introduction to RAID and then builds up on the concepts and walks the reader through the mdadm tool. As that HOWTO is already delivering, I will not go into the details of it. The aim of this post is to inform about the pre-requisite setup for building RAIDs.

I am using Virtualbox with a VM running Ubuntu 10.10. For mdadm I have installed the mdadm tool (installation steps mentioned in the tutorial page).

As you are going to play with different RAID configurations, you will need to add multiple disks. For VirtualBox, go to the main menu, right click on the VM, go to settings and then to storage. Out there add 2 more SATA disks each of 1 GB - I used this value because I am going to partition each disk into 2 partitions of 512 MB each. If there are no new disks added to your system, then these disks will show up as /dev/sdb and /dev/sdc on your Linux box.

Boot up your VM. Become root. Execute the following command:
# fdisk -l
You will see a partition table for /dev/sda - containing - /dev/sda1, /dev/sda2, etc. - this is the first disk in which your OS is installed. We are not going to touch this disk.

We are going to work with /dev/sdb and /dev/sdc - the 2 new disks that have been added. If you already had added other disks the device names may be different in your case - but one thing is for sure - for the new disks, the partition table will not exist. Hence for the new ones fdisk output will be something like this:

Wednesday, November 30, 2011

putty + screen = meant to be

I am getting used to the screen command for my Linux development environment and I find it to be a great tool for detaching and reattaching sessions - but that's just scratching the surface from what I see on the net. As there are many useful posts out there explaining why screen is something that you've been missing if you are working via putty, I will let them do the talking.


A redhat magazine post

I am a newbie to screen and this is all that I have been doing:
  1. Open multiple putty sessions via Putty connection manager
  2. Foreach tabbed session I do a: $ screen -S session_name
  3. Code
  4. While leaving for the day, disconnect all sessions - I don't "exit"
  5. When I want to come back again - I open the tabs once again and reattach to previous session - I normally name my sessions "tab1", "tab2", etc. so reattaching is equivalent to: $screen -d -r tab1
All this is good enough. I had just one rant while using screen - I did not know how to scroll back. Say I run a find command and the output spews out to more than 80 lines - the size of my terminal window. If I am running in screen mode - by default I can scroll back only upto 100 lines. And then, this post came to my rescue:

Saturday, June 4, 2011

Stray thought

The difference between an average programmer and a good one is the same as the difference between an optometrist and an ophthalmologist.

Friday, June 3, 2011

The easiest way to recover admin password of BSNL ZTE DSL modem

In my previous post, I had described how to recover the admin password of your BSNL ZTE DSL modem, provided you have the modem configuration backed up.

But if you don't have the config file backed up - recovering the admin password is all the more easier. Read on to know more.

Model: BSNL Dataone ATE ZXDSL 531B modem.

This post shows how you can get the admin password of the modem without any backed up configuration. You just need to know the modem IP. Let me know if the link is broken - I will write a new post describing those steps.

If your modem/router's basic security is flawed to this extent, then deploying its in-built security measures is like trusting a visually impaired lame duck, one suffering from suicidal tendencies, arming it with banana skins, and telling yourself: "That ought to keep me safe from fire-breathing dragons and the 15 feet tall goblins who ride them!" (a justified exaggeration the "sitting duck" analogy).

Sunday, May 29, 2011

Recovering admin password of your modem from backed up configuration file

Model: BSNL Dataone ATE ZXDSL 531B modem. (Below points worth a shot for any other modem also)

Assumption: You have saved your modem settings locally on your machine. If not, don't be disheartened (Do slap yourself thrice though), this post will help you out.

If you don't know how to upload/save your modem/router's configuration file, read this.

I had forgotten the admin password and I didn't want to reset my modem. Just wanted to see if I could get any info from the configuration that I backed up.

I opened up the file and searched for the keyword "admin" and I came across this block:
<sysusername value="admin">
<syspassword value="YWRtaW5fcGFzc3dk">
Took a blind shot to see if it is a base64 encoding and <insert your jumping-with-surprise word here> it was base64 encoded!

Securing my DSL modem

I had a BSNL modem installed at my home quite some time ago. The guy who installed it did the minimal configuration - just enough to connect to the internet. He did nothing on the front of basic security - hiding the wireless network, changing the default password, etc.

As with all standard modems, this one had a web interface at The interface was easy to navigate and through it I hardened a few of the settings. I am going to share them in this post.

The security measures that I describe will be available on any standard DSL/ADSL modem. The UI navigation will vary across different models. But the ideas - like changing your modem's IP from to some non-standard value e.g. will stay the same.

The changes are limited by my own experience and I'd appreciate if you could share any other security measures that you took. If you are happy with the way things are going on - your wireless network is not hidden, your modem's IP is, default password is "admin" - stay happy and go back to watching that skating cat video on youtube, while I download the entire LOTR trilogy on your connection :). If you want to get your hands dirty and learn a few things in the process, read on.

The author is not responsible for temporary/permanent loss of internet connectivity or inadvertent establishment of communication with alien life forms resulting from the changes described in this post.

Modem: BSNL Dataone - ZTE - ZXDSL 531B

Before moving on to the changes, I'd recommend that if you are going to do them as you read this post, please read the whole post first. And the changes don't come into effect until you save them or in some other cases restart the modem (changing the modem IP for instance). So if you want to experiment with the changes, do them one at a time - change the config, save it, check it and move on. Doing multiple changes and not knowing what went wrong is not worth the debugging time. You can also keep on saving changes as you move through the post, creating snapshots of the configuration file.

The first thing to do before messing around with any settings is to insure yourself against the destructive streak of the geek in you - the one which prods you with the "Go on, try it out, let's see if it blows anything up" thought. Hence I backed up the minimal configuration that was done by the BSNL guy.