Test post

Mobile blogging test.

How to unpack rpm

I rarely use this one but it's handy sometimes:

rpm2cpio rpmname.rpm | cpio -idv

(taken from this blog)

edit:

sometimes it doesn't work because of this:

cpio: Malformed number

but it seems that cpio is broken and it can be fixed with:

rpm2cpio rpmnamerpm | lzma -d | cpio -id

(taken from another blog)

GPU-GEMS

GPU GEMS has arrived! It contains chapter of mine (as a co-author) about fact Smith-Waterman algorithm implementation on NVIDIA GPUs. I host code of it on http://code.google.com/p/sw-gpu/.

How I Learned To Stop Worrying And Love The Setuptools

This is mainly note for myself if I ever forgot how to use it.

For most of the time my projects lived each in it's own directory and I resolved importing issues with sys.path manipulation. That works for low number of simple programs/libraries. Using distribute (setuptools) seems to be a natural step forward.

I'd like to stay with this approach (no setuptools) for a little bit longer because I'm easily distracted and I need to get used to setuptools boilerplate ;)

Steps to make life less painful (use setuptools) and to preserve old ways:

Step 1. install virtualenv
Step 2. virtualenv $SOME_PATH_TO_NEW_ENVIRONMENT
Step 3. source $SOME_PATH_TO_NEW_ENVIRONMENT/bin/activate

Then we've got cloned python installation that will work with python setup.py install or whatever. But we're only halfway done and need to setup our package.

Step 1. mkdir $PACKAGE_INSTALLER
Step 2. cd $PACKAGE_INSTALLER
Step 3. ln -s $REAL_PACKAGE_DIR .
Step 4. write setup.py as advertised in documentation

Thats all. I can hide package installers so I don't get distracted but still I get all power of setuptools.

edit:
Main benefit is that when using setup.py develop I can edit my package as always in $REAL_PACKAGE_DIR.

More django!

Ahh, finally... me and my co-worker convinced our boss to ditch our's lab www site based on Liferay. Among other problems, the big one was that there were three big unmaintanable catalogs each with separate Liferay instance.

I don't want to criticize Liferay yet it's too big for our needs. It also does not fit in well into me and my co-worker skillsets (well it fit is a bit worse after I converted him from Java to Python ;).

So we're looking for something that is:

* possibly written in Python (easily extendable for us)
* possibly Django compatibile (we have one service based on django and it would be nice if it could be easily put together, there'll be more django-based services in the future)

I'm going to hunt something down on Monday.

django-registration

This will be about (bad?) documentation.

Im in process of making small database inferface in django with few additional functions. I need to register people. This is the place where django-registration kicks in, I choose it to cut development time and to not reinvent the wheel.

Basic setup of django-registration is a breeze, but when it gets to template creation it gets worse. Information about context variables passed to the templates is hid among the rest of documentation. I found easier to dig it out from the code rather than from documentation. It could be so beautiful if it was included in overview.txt (in "Templates used by django-registration" section specifically).

I know that it is not much but it could be easy 5 minutes of setting up django-registration instead of 15 minutes poking with code and other documentation.

Fortunately I wont moan more but do something productive instead and produce better documentation ;) I know that in a week I will not remember which template takes which parameter and first place I'll be looking in is documentation. So here we go:

The views included in django-registration make use of five templates:

* ``registration/registration_form.html`` displays the registration
form for users to sign up. Gets ``form`` in template context. Default urlconf ``^register/``.

* ``registration/registration_complete.html`` is displayed after the
activation email has been sent, to tell the new user to check
his/her email. Does not get any context variables.

* ``registration/activation_email_subject.txt`` is used for the
subject of the activation email. Gets ``site`` which is site address as in Django sites. This template should render to only one line of text.

* ``registration/activation_email.txt`` is used for the body of the
activation email. Gets ``site``, ``expiration_days`` and ``activation_keys`` as context, ``expiration_days`` is ACCOUNT_ACTIVATION_DAYS value and ``activation_keys`` is activation key. Default urlconf for activation is: ``^activate/(?P\w+)/``.

* ``registration/activate.html`` is displayed when a user attempts to
activate his/her account. Gets ``account`` and ``expiration_days`` as context, ``account`` is False if activation failed and corresponding User object otherwise.

If I got everything right there is no need for more reading if one intends to get only basic registration. Hope this helps.

I reported it at http://www.bitbucket.org/ubernostrum/django-registration/issue/12/documentation-improvement