Advanced Magic

In trying to cross compile Qt 5.5.1 for the Beaglebone Black Simon Stürz’ blog post was extremely helpful (Thank you Simon).

I made a few modifications to Simon’s cross compile script:

Obviously I replaced all occurrences of 5.2.1 by 5.5.1.

Then I replaced all occurrences of ${CC} by ${CC_PRE}.

Then I replaced the initial

export CC="${CC_DIR}/bin/arm-linux-gnueabihf-"

export CC_PRE="${CC_DIR}/bin/arm-linux-gnueabihf-"

Finally, right after

# configure qtbase
if [ ! -d ${PREFIX} ]; then
 ./configure \
 -prefix ${PREFIX} \

I added

-extprefix ${PREFIX} \

as another option to have Qt installed in directory Qt-5.5.1.

Since I’m new to Qt, it took me a while to find out, I had to manually install the Qt-5.5.1 directory populated by the script on the Beaglebone under /opt and add the path to LD_LIBRARY_PATH or /etc/ld.so.conf.

Python is a great language to build commercial applications using databases. Often times an object relational mapper is used to isolate the Python code from the database (like in Django or SQLAlchemy).

Using the database API directly however has the benefit of SQL. SQL is taylormade for database access and is therefore much easier to understand and easier to build in the first place. Using SQL lets you use vendor specific features effortlessly.

I try to use SQL for database access wherever possible. To ease the transition between the two languages I use these patterns frequently:

class ObjectFromRow(object):
    """
    Base class for query results.
    """
    def __init__(self, row):
        """
        Stores all fields from a single DB row in this object as attributes
        """
        for k, v in row.items():
            setattr(self, k, v)

    def __getitem__(self, name):
        """
        Container method to allow x[y] like access which is needed for string
        formatting as in "%(bla)s" % obj
        """
        value = self
        for n in name.split(','):
            value = getattr(value, n)
        return value

class Address(ObjectFromRow):
    """
    create table person(
        firstname varchar(30),
        lastname varchar(30),
        birthdate date,
        zipcode varchar(5),
        city varchar(30));
    """
    pass

class AddressListPerZIP(object):
    @classmethod
    def listFactory(self, cursor, day):
        """
        print a birthday list for day
        """
        criteria = { 'birthday': day.strftime("%%-%m-%d") } # ignore year of birth
        query = "select firstname"\
                "      ,lastname"\
                "      ,birthdate"\
                "from person "\
                "where birthdate like %(birthday)s"
        cursor.execute(query, criteria)
        for row in cursor.fetchall():
            address = Address(row)
            print "%(lastname)s, %(firstname)s, %(birtdate)s" % address

ObjectFromRow defines a generic class to build python objects from query rows. The objects instances variables are automatically initialized from the db row. The __getitem__ method defines the method to access instance variable like a[‘b’].

The last tow lines of the code show this pattern in action: an address object is created from the row retrieved, formatted using “%(name)s” while accessing instance variables through __getitem__(name).

These development patterns allow for a streamlined and uncomplicated cooperation of procedural Python code and SQL.

This pattern is sure to work with psycopg2 (the Python PostgreSQL API) and does not work with MySQL unfortunately.

Efficient Python means lower cost in development and maintenance of
Software. Python programs written in a good style are easier to
develop, easier to read and cheaper to maintain.
Because they are easier to maintain, they are easier and cheaper
to extend and are therefore more up to date and more useful.

I will describe what I mean with a good style and explain basic command line parsing.

The basic structure of a Python program consists of the ‘hash bang’ notation
in the first line and the encoding string in the second line.
Next will be the actual code.

#!/usr/bin/env python
# -*- coding: utf8 -*-

print "Hello Beautiful World"

For a simple program as this, where is really no need for something else.
Running

$ ./demo1.py
"Hello Beautiful World"
$

does just what you expect.

To make our little example more useful, we start to add some procedural structure:

#!/usr/bin/env python
# -*- coding: utf8 -*-
def hello ():
    print "Hello Beautiful World"

if __name__ == '__main__':
    hello ()

We encapsulate the actual program logic in a function called ‘hello’.
This function is called only when the program file called demo2.py is executed by the Python interpreter directly, like this

$ ./demo2.py
"Hello Beautiful World"
$

Let’s see what really happens inside. Change the code like this:

#!/usr/bin/env python
# -*- coding: utf8 -*-

def hello ():
    print "Hello Beautiful World"

print "__name__:", __name__

if __name__ == '__main__':
    print "this is __main__"
    hello ()

and run it from the command line:

$ ./demo2.py
__name__: __main__
this is __main__
$

So the variable __name__ somehow automatically received the value ‘__main__’ by the Python interpreter.

The purpose of this behavior is easy to see, when we run our sample program in a different context:

$ python
>>> from demo2 import *
>>> __name__: demo2
>>>

Now the magic variable __name__ has the name of the module ‘demo2’ and the next to last line is starting to make sense: the program itself can distinguish between being run as a program by itself or being imported as a module.

To use the functionality of the program in the module context, we need to call the function named ‘hello’.

>>> hello()
Hello Beautiful World
>>>

To sum up, we’ve learned, that we can use a single program file both as a self contained program and as an importable module.

Now, let’s give our program some more structure:

#!/usr/bin/env python
# -*- coding: utf8 -*-

class App (object):
    def __init__ (self):
        self.text = "Hello Beautiful World"

    def run (self):
        print self.text

if __name__ == '__main__':
    app = App ()
    app.run ()

We’ve created an application class called ‘App’ to serve as a container. The class ‘App’ defines two methods, one called ‘__init__’ and ‘run’.

In ‘__init__’ initialization of the object takes place. In ‘run’ the actual work of printing the message is done.

When the program is run as a stand alone application, the object ‘app’ is created from the class, with the ‘__init__’-method called by Python. In the next line, the ‘run’ method is executed to serve the actual purpose of this program.

Running the program:

$ ./demo3.py
Hello Beautiful World
$

does exactly what we expected.

Using this sample in a module context allows us to use object creation and and execution separately:

python
>>> from demo3 import *
>>> app = App()
>>> app.run()
Hello Beautiful World
>>>

We can create multiple App-Objects and use them independently:

>>> app2 = App()
>>> app2.run()
Hello Beautiful World
>>> app
<demo3.App object at 0x7f62817b0550>
>>> app2
<demo3.App object at 0x7f62817b0610>
>>>

To show, the two app instances are really distinct objects we just need to look at where respective object addresses above.

Advantages of the this object oriented encapsulation will show up in larger programs. We laid the foundation for further extension.

Hi all,

it took a while, but here it is (unfortunately only in german yet), my first video blog on programming in Python:

Thanks for watching.

Monibot is a new tool to graphically monitor Oracle database servers.

Monibot uses a monitoring daemon to monitor any number of database servers. Data is stored long term in a separate database. Performance and reliability data can be viewed interactively using a browser based interface.

This approach allows for easy detection and resoltion of imminent problems, long term observing of trends and planning of growth.

Monibot was developed in cooperation with a very large user of Oracle database software and profits from their long term experience of running mission critical appliactions with minium downtimes.