Monthly Archives: February 2014

Hipchat APIv2 Example: Send Room Notification

This is an example using Hipchat APIv2 to send a message to a room.

#Python
import json
import urllib2

token = "YOUR TOKEN"
header = {'content-type':'application/json'}

def send_message(room_id_or_name, message):
    url = "https://api.hipchat.com/v2/room/" +
            str(room_id_or_name) + "/notification"
    data = json.dumps({"message":message})
    req = urllib2.Request(url+"?auth_token="+token, data, header)
    res = urllib2.urlopen(req)
    return res.read()

if __name__ == '__main__':
    send_message(123456, "Hello, World!")

Use Dictionary as Default Argument

So I am working on a python module, which is like a pipeline and contains lots of sub-modules. Each sub-module is a function which is flexible (like a plugin) and it needs some parameters. So the main-module receives every parameter from its arguments and pass it to each sub-module, and if it does not find a parameter in the argument, it passes a default value.

It looks like the following,

def main_module(pa1=1, pa2=2, pb1=3, pb2=4):
    sub_module_a(pa1, pa2)
    sub_module_b(pb1, pb2)

main_module(pa1=0, pb1=0)   # caller

But the problem is the sub-module may be changed at anytime and I do not want to change the interface for the main-module. And another problem is that after adding some modules the interface of the main-module will become very long and hard to maintain.

def main_module(pa1=1, pa2=2, pc1=5, pc2=6, pc3=7):
    sub_module_a(pa1, pa2)
    # I suddenly decide to use sub_module_c instead of sub_module_b
    # I will have to change the interface of main_module
    # and those who call it.
    sub_module_c(pc1, pc2, pc3)

main_module(pa1=0)    #Have to change caller

So finally I found a solution which looks like,

def main_module(parameter = {}):
    default_paramter = dict(
        pa1 = 1, 
        pa2 = 2,
        pb1 = 3,
        pb2 = 4,
    )
    default_parameter.update(parameter)
    sub_module_a(default_parameter['pa1'], default_parameter['pa2'])
    sub_module_b(default_parameter['pb1'], default_parameter['pb2'])

main_module({'pa1':0, 'pb1':0})

so that if I change the sub-module, the caller can still remain unchanged.

def main_module(parameter = {}):
    default_paramter = dict(
        pa1 = 1, 
        pa2 = 2,
        pc1 = 5,  # new parameters for sub_module_c
        pc2 = 6,
        pc3 = 7,
    )
    default_parameter.update(parameter)
    sub_module_a(default_parameter['pa1'], default_parameter['pa2'])
    sub_module_c(default_parameter['pc1'], default_parameter['pc2'])

main_module({'pa1':0, 'pb1':0})    # remain unchanged
# the caller doesn't even know
# that the implementation of main_module has changed

A even more fascinating way to support the plugin-style sub-modules is that

def main_module(module_list=[], parameter = {}):
    module_mapping = dict(
        use_module_a = sub_module_a,
        use_module_b = sub_module_b,
        use_module_c = sub_module_c,
    )
    default_paramter = dict(
        pa1 = 1, 
        pa2 = 2,
        pb1 = 3,
        pb2 = 4,
        pc1 = 5,  # new parameters for sub_module_c
        pc2 = 6,
        pc3 = 7,
    )
    default_parameter.update(parameter)
    
    for module in module_list:
        module_mapping[module](default_parameter)
        # but have to let the sub_modules pick 
        # the parameter they need in their implementation

# caller can decide which module it wants to use
main_module(['use_module_a', 'use_module_b'], {'pa1':0, 'pb1':0})

There are definitely many better ways to do it, and that’s why I think I am becoming to love Python – the flexibility.

cvCaptureFromCAM(CV_CAP_ANY) returns NULL

I had a weird problem when I was trying to use OpenGazer.

I used almost a whole day to make it successfully compiled, and when I ran it, it was terminated immediately by a segmentation fault.

After a few debugging I found it out that the reason was that cvCaptureFromCAM(CV_CAP_ANY) returned NULL.
I have to say it was extremely weird because I have been using Python+OpenCV on the same machine for a long while and it works completely perfect.

To demonstrate the problem, here are two pieces of code

//LANG: C++
#include <opencv/highgui.h>
#include <iostream>

int main()
{
    CvCapture* capture = cvCaptureFromCAM(CV_CAP_ANY);
    if(capture == NULL)
        std::cout<<"NULL"<<std::endl;

    return 0;
}
#LANG: Python
import cv2

cap = cv2.VideoCapture(0)
ret, frame = cap.read()
cv2.imshow('frame', frame) # it shows a correct image from the webcam
cv2.waitKey(0)

The point is that the C++ one does not work, but the python one does.

I tried to install pwc but I couldn’t get it done. Then I installed libv4l2, and upgrade OpenCV from 2.4.2 to 2.4.8, then rebooted the system.

Then the problem was magically solved. I don’t know what exactly I did that solved it, but anyway I managed to run this amazing webcam eye tracker.

OpenGazer is an amazing webcam eye tracker that can detect which pixel on the screen you’re looking at. It can handle slight head moving since it tracks a few feature points on the face to detect the orientation, but It is still not that stable. At least it shows a probability that we can use the webcam to detect where the user is looking at.