As I've been working with open source technologies for a few years now I've noticed, comparatively recently, a gigantic leap in the quality of the 'products' themselves. At the same time, and not coincidentally, somewhere between many and damn nearly all of the latest and greatest rapidly growing companies are relying on OSS technologies for their growth. Some of these companies can be called startups and some are not. Another pattern has emerged, that of the long touted "code reuse" actually happening.

The question that comes to mind is: why?

I think to answer that question we need to look at where today's software industry has come from. When I started the GenX's ruled the roost. We (mostly) went to university, studied proper computer science - learning how hash tables work etc - and combined with the just extreme ego that goes with most geeks this led to a cousin of NIH ... I can do it better ... and consequently an industry that for most of the 90's was based on reinventing the wheel. I have a deathmarch story about that that can wait for another day. GenY are different. They want results. They want to look good. From an IT industry standpoint they've come up from HTML2 and the culture of exchanging chunks of Javascript to make menus pop up, and most have never even considered what actually goes on under the lid. They just want it to work - hence the rediscovery of code reuse.

But this is not the whole story. As these guys grew up some, understandably, got an interest in the industry in general and how one went about going from HTML to coding to coding-for-someone-good. 99% of the software industry is about making boring stuff for boring people (one of the reasons the GenX NIH thing kicked off). The HTML generation have approached the problem from a different angle: instead of being better they appreciate the need to look better, hence an appreciation for publicity, hence open source.

Seriously. It's the greatest ever platform for a coder to demonstrate their wares and has led to things like Guido van Rossum becoming a "household" name, DHH of rails fame making himself a PITA at every possible opportunity, and a big BIG desire within the up and coming coders to be seen. In a world where nobody wants to work for Microsoft anymore, career building has changed and open source is both the vehicle and the benefactor.

I've been battling with a few lightbox scripts, attempting to put an ajax window on top of an existing window. There's no shortage of these things in the Javascript universe and my path through them looked like this:

Original Lightbox won't work because it only hosts images.

Particletree Lightbox gone wild Seemed fine at first, but won't dynamically resize to the size of the content.

Greybox is fantastic but relies on an Iframe which prevents javascript (or, at least, prototype) from being able to script elements with $().

ModalBox does all the above and is therefore the winner. Note that when it says you need the files in an "includes/" directory they mean it, it has to be called "includes/"

Note also I have a little hack to resize the window, which can only be done relatively ... there is no call to "resize to fit the content again" unless you completely reload the content. In my case I had a div at the bottom so I passed the 'old' height of the div as part of the ajax call ($('messages').getHeight()) then passed this back again as part of a dynamically created script (Modalbox.resize(0,$('messages').getHeight()-{{divheight}});) that gets called by prototype when the update finishes.

Just one more :) I was wondering how I could debug an app that switches between http and https on django when 'python manage.py runserver' doesn't support it. As it has done in the past, stunnel came to my aid...

First download and build the latest stunnel. It's a ./configure; make; sudo make install thing. I needed to add the installed path (/usr/local/sbin) to my system path in /etc/profile too.

Second create a file that tells stunnel what to do - the examples showing things being passed on the command line are old. Unfortunately. I'm running with:

pid=

[https]
accept=8443
connect=8000

The empty pid line is important since otherwise it will attempt to write a pid file somewhere it doesn't have permission. I saved this file as "dev_https"

Finally start stunnel with stunnel dev_https, run your django project and attempt to connect to it with https://127.0.0.1:8443/
and you should be good to go. Any problems, change the dev_https file to have "foreground=yes" at the start and errors will be streamed to stderr.

Note: For OSX 10.5: It appears easier to run stunnel as root sudo stunnel dev_https and I added the path to my local profile (~/.profile) - PATH="${PATH}":/usr/local/sbin

Edit, again: You can do HTTPS=1 ./manage.py runserver to have calls to request.is_secure() return True.

I just spent longer than should be necessary on this. Again, for the sake of an as yet unknown traveller in these parts, a little advice.

First, don't try to build against MAMP. It seemed like a good idea to start with, but as soon as I didn't need xdebug for PHP any more the amusement started to wane quite quickly. Instead use (Apple's built in Apache 1.3 and) the official MySQL packages. I had to (shudder) reboot afterwards because various paths, caches and what have you still pointed to the MAMP one but once that was done, no problem.

Secondly, there have been some changes in the build script for mysql-python and the hacks you'll see all over the net for 1.2.1-p1 (or something) are no longer necessary. So step 2 is to get the 1.2.2 source package straight from Sourceforge. I followed the instructions, vaguely, and built with "python setup.py build" then "sudo python setup.py install". You probably can build in just one step, the second one, but then you get lots of temporary files owned by root and therefore a pain to clear up.

Finally, and the tricky bit, the plugin (or egg or whatever you're supposed to call it) still won't go because it can't find the client library on the path. No idea if you're supposed to go in and mash the system wide path in /etc/profile so I merely symlinked the library it was complaining about to the appropriate directory.

DaveMBP:/usr/local/lib davep$ sudo ln -s /usr/local/mysql-5.0.45-osx10.4-i686/lib/libmysqlclient_r.15.dylib

Except as one line (this theme is growing old). Obviously when version numbers change you'll have to change with them too, but no rocket science there. Oh, and you can find all the installed mysql libraries by going to /usr and asking:

DaveMBP:/usr davep$ find . -name "libmysql*"

Don't use spotlight because it doesn't index the unixy bits.

I will blog about something that is not to do with fixing bits of Python ... soon!

An entry in the hope that a search engine will make this useful for someone in the same situation...

I hosed my Python install (on debian 4.0), so I nuked it and rebuilt it. Unfortunately trac no longer worked, which is a problem. So a couple of nuke and rebuilds later (including building the entire envionment, even python, from a straight "apt-get install trac") and I'm getting this error:

file is encrypted or is not a database

After some hunting around I came to the conclusion that my problem is being caused by the database being written with an earlier version of sqlite. My first go at this was to replace the provided pysqlite2 with pysqlite1, but the magic word appears to actually be python-sqlite...

# apt-get install python-sqlite
# apt-get remove python-pysqlite2

Tadaa! We are back up. Hmmmm, speaking of backups...

Edit: Another debian upgrade broke it again. This time I was forced to do the upgrade properly.

I nearly missed it, but it appears that the latest performances on UpStage are tomorrow. It has to be said that I have seen exactly one UpStage performance, and it was ... not entirely to my taste. But the UpStage platform (FOSS) is now in version 2 and knowing Douglas (Bagnall, Wellington resident genius/nutcase) it has probably been rewritten from scratch, and is certainly a great improvement on the original.

Go Douglas!!

Another "this should be a lot simpler" thing, this time to find the site packages directory (the root directory for 'from x.y import z')

python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()"

Most python frameworks, including django, install themselves from a setup.py ... this is helpful when you want to start crawling around the sourcecode for the installed frameworks. In django's case you want to do this because the code is sufficiently clear to be almost self documenting.

It appears that John Gruber has managed to crash his iPhone already. The crash log, captured on the way through his Mac to Apple, contains what looks to my eye as something a little ominous:

Exception Codes: 0x8badf00d

Now that is not the sort of thing to happen by chance. Furthermore the crash log doesn't seem to want to actually allocate blame for the crash to any particular thread or cause. Repeat after me: never buy the first iteration of an Apple product.

Lots of other interesting stuff in there too - binary images for an OpenGL-ES implementation, sqlite3 and frameworks called "CoreSurface" and "CoreTelephony". Hmmmmm.