Apache redirect SSL

I want to force all connections to one virtual host to always use HTTPS.

<VirtualHost *:80> ServerName name.server.com RewriteEngine On RewriteCond %(HTTPS) off RewriteRule ^/(.*)$ https://%{HTTP_HOST}/$1 [L,R=301] </VirtualHost>

That supposed to work but not. The Rewrite rule seem to be discarded or simply don’t match and apache just give 404 response. If I put some handler inside the virtual host config, that handler would be called to return a response.

<VirtualHost *:80> ServerName name.server.com RewriteEngine On RewriteCond %{SERVER_PORT} !^443$ RewriteRule ^/(.*)$ https://%{HTTP_HOST}/$1 [L,R=301] </VirtualHost>

and that work !

Update:
Look like the problem was with using %(HTTPS) instead of %{HTTPS}.

Mercurial: cannot partially commit a merge

Did some changes on live, commited and then trying to push some local changes. Hg complained that would create multiple heads and refused. Fair enough, so I just hg pull at local to get the changes from live. Hg then reminded me to merge that. Run hg merge and then I need to commit that merge.

$ hg commit -m 'merge from live' files1.txt files2.txt
abort: cannot partially commit a merge (do not specify files or patterns)

At first I didn’t really understand what it mean and what I found on google look complex than it supposed to be for such a simple case. Until I read again the part … “(do not specify files or patterns)”. Yup, it really mean it.

$ hg commit -m 'merge from live'

I’m not supposed to specify any files when commiting a merge.

Convert UTC time to local

UTC to local:-

>>> import datetime, pytz
>>> local_tz = pytz.timezone('Asia/Tokyo')
>>> datetime.datetime.now().replace(tzinfo=pytz.utc).astimezone(local_tz)
datetime.datetime(2011, 3, 4, 16, 2, 3, 311670, tzinfo=<DstTzInfo 'Asia/Tokyo' JST+9:00:00 STD>)

local to UTC:-

>>> import datetime, pytz
>>> datetime.datetime.now()
datetime.datetime(2011, 3, 4, 15, 6, 6, 446583)
>>> datetime.datetime.now(pytz.utc)
datetime.datetime(2011, 3, 4, 7, 6, 22, 198472, tzinfo=<UTC>)

Controlling output using grep

There’s a number of options available to control the output of grep. Today I’m ‘grep’ing some string from our log files, which named as local0, local0.1, local0.2 and so on. When ‘grep’ing multiple files, by default it prefixed the line output with the filename that the result come from. Since I’m piping the result to another python script for further processing, the prefix interfere with my script. To surpress the filename prefix from the output line, we can use ‘-h’ option to grep command. So something like:-

$ grep -h "some string to search" local0* | cut -d' ' -f1,2,3 | python myscript.py

Unrelated noted, reading the piped output from python we can use sys.stdin.readlines():-

for line in sys.stdin.readlines():
    print line

Test code

Test entering source code:-

with open('file.txt', 'w') as f:
    f.write('hello world')

Test end.

class Debugger:

    def __init__(self, object):
        self.__object = object

    def __call__(self, *args, **kwargs):
        import pdb, sys
        debugger = pdb.Pdb()
        debugger.use_rawinput = 0
        debugger.reset()
        sys.settrace(debugger.trace_dispatch)

        try:
            return self.__object(*args, **kwargs)
        finally:
            debugger.quitting = 1
            sys.settrace(None)

End test.

Django folder organization

Since Django is just Python, theoretically it just a matter of putting your Django’s project and apps module under PYTHONPATH. Easy as it sound. But Python packaging currently in a state of mess, at least that’s the way I see it.

First we have the standard (which come in std lib) distutils module to help developers package their modules for easy distribution. Basically you put your modules inside a zip or tarball with one file named setup.py that contain the installation routines. So to install a Python modules package with distutils you would:

$ wget http://some.site.com/tarball/mypython-modules-1.2.tar.gz
$ tar xzf mypython-modules-1.2.tar.gz
$ ls
mypython setup.py README
$ python setup.py install

The module would then be installed under your standard site-packages directory and should be ready to import.

Then some people realize that this has some shortcoming. What happen when you want to install the new mypython-modules-1.3 when it comes out but still keeping the old one ? Running setup.py install would just override the old one because no versioning information is being kept by the packaging system once you install it into your site-packages. So people come with setuptools package as an extension to distutils. Basically the idea is to keep some meta information about the packages being installed alongside the modules in site-packages directory so that different version can installed without overwriting each other. Sound’s great but the end result is a really weird site-packages directory you would have.

Consider the site-packages installed with just the plain disutils:-

$ ls /home/kamal/python/lib/python2.5/site-packages
beaker docutils glasshammer jinja mako pygments sphinx sqlalchemy werkzeug

and with setuptools:-

$ ls /home/kamal/python/lib/python2.5/site-packages
Beaker-1.3.1-py2.5.egg                  Pygments-1.0-py2.5.egg
docutils-0.5-py2.5.egg                  setuptools-0.6c8-py2.5.egg
easy-install.pth                        setuptools.pth
Glashammer-0.2.1dev_20090706-py2.5.egg  Sphinx-0.6.2-py2.5.egg
Jinja2-2.1.1-py2.5-linux-i686.egg       SQLAlchemy-0.5.4p2-py2.5.egg
Mako-0.2.4-py2.5.egg                    Werkzeug-0.5-py2.5.egg

setuptools make use of Python ability to read from zip files and put all the modules inside single zip archive, known as egg. To be able to install multiple versions together, it need to store some information (path actually) inside .pth files.

I get started into Python when there’s already tools called virtualenv from Ian Bicking that let you create a local isolated Python environment specifically for your project without the need to interfere with the global system Python. So in practice, I never had the requirements to install multiple version of the same module inside my site-packages. I would just create another isolated environment if I really need to do that (which most of the time never happened).

There’s still part of setuptools that I found useful, and I’m using it in my daily Python development. The easy_install script. What it does is, given a package name, it would go to PyPI (Python Package Index) or it’s mirror hunting for the specified package and if exists, download and install it to the appropriate place in your system. The only problem, it would install that package as a Python egg, creating the mess I described before.

The problem I have with this eggs is, when deploying through mod_wsgi, I have to add all the eggs directory (mean all the installed module) into PYTHONPATH since mod_wsgi unable to find the module inside an egg.

Sed: Delete next n lines after match

ALTER TABLE some_table ......
CREATE VIEW user_log_view AS
  SELECT some_column .....
SELECT * FROM some_table ...

cat dump.sql | sed "/CREATE VIEW user_log_view/,+2d"

Would delete CREATE VIEW statement definition.

Adding jquery.js to Drupal page

Drupal conditionally load jquery.js so to make sure it would be loaded in our module, add some js into our module hook_menu:-

function cvt_menu($may_cache) {
  //This would load jquery.js
  drupal_add_js('$(document).ready(function(){ $("div.messages").fadeOut(5000); });', 'inline', 'footer'); }

test

test oss.

Hello world!

Assalammualaikum,

Catatan yang pertama.

quote