Cykod Web Development and Consulting Blog

These definitions are definitely not universal, but here are my definitions of two different ways of fixing programming problems:

Debug (v) - To trace a program's path of execution to a known state and then forward to find a divergence from expected behavior.
Flail (v) - To keep trying different sh*t until something works.

Both Debugging and Flailing can use the same tools. You can debug with print statements and you can flail with Visual Studio's line-debugger. The difference is more a question of how you approach the problem rather than the tools you use to do it.

A classic example of flailing is getting an off-by-one error in a loop and to just keep changing your conditions until it seems like the solution is right. It's a lot easier to just make a couple of code changes and let the computer do the thinking than to stop and actually understand exactly what's going on.

In general debugging is involves a much larger context switch as you have to wrap your mind around a much larger piece of code and step back and understand the bigger picture of what you are doing. If you a fixing a smaller self-contained problem you just introduced, a full-stop debugging effort may not be worth the effort. That said, for the other 96%** of the problems you come across, Flailing isn't the answer.

In particular, If you are fixing a problem that does not relate to code you wrote recently, going the flailing route will invariably introduce bugs that weren't there before, as you will miss boundary conditions or get something to work for only a subset of you possible inputs (barring 100% bullet-proof test coverage)

The other major problem with flailing (and remnants of this are apparent in a lot of CSS file that I look at), is that even if you solve the problem, you end up with additional cruft that may not have been needed to reach a solution and you'll never know what it was that you did exactly to make things work.

If you are really up a creek as to where the problem lies and know you are going to have to try a multitude of different attacks, one solution is to try one thing and reset your VCS back to a known state before you go and try something else. That way you won't end up with attempted fix piled on top of attempted fix.

** - Made up Number 

60 Percent more than a captcha apparently.

When we officially launched Webiva last month I decided that in lieu of the standard CMS demo where you log in to a system where lots of other random Web visitors had left there dirty imprint we wanted to give users their own private Webiva backend and let them select from some premade site-templates to play around with.

To this end I threw together a site demo module over an afternoon that simply restored a backed-up site to an available demoXX.webiva.org domain, added a user to that site and then sent the user an email with login instructions. Because restoring a backup could take a little while and had to be done in the background, asking a user for their email was the easiest way to handle this process from a lazy-programmer perspective.

I added a disclaimer "your email will only be used to send you a demo, and will not yadadada..." and put the demo launcher live.

Taking a look at the logs after a couple of weeks, I noticed a lot of bounces - people visiting the site but just leaving without launching a demo. From a quick calculation it looked like 80% of visitors were leaving without launching a demo.

The obvious explanation for this was that people just didn't want to give up their email address for something as trivial as a 20-minute demo. It was just too valuable. When I put the launcher up I knew some people would feel this way, but given that Webiva is open-source I figured people would be more willing to trust that we aren't going to abuse their emails than if we were, say, a mortgage company. That apparently wasn't the case.

So the beginning of this week I tasked myself with re-writing the launcher to replace the launcher to require a captcha instead of an email. Now, from a user perspective a captcha is actually more work than entering their email - they already know their email but have to decipher the captcha - but I figured that it would lower the bounce rate some.

The results surprised me though - 80% of unique sessions skipping launch dropped to 20% - a 60% swing, and a little deeper look at the logs seem to indicate that most of the remaining 20% are just bots/etc we're not filtering out. Users were more than happy to put in a couple of seconds of work on the (admittedly not that difficult) captcha.

I always knew email address were heavy but had no idea how much they weighed down a form. Now (for a small sample size) I know - and won't make that mistake again.

We just bought a couple new servers on which we were going to run a number of XEN virtual machines. After checking out Eucalyptus and Ubuntu's UEC (Ubuntu Enterprise Cloud), I decided to give that a shot instead - after all being able to automatically launch instances from a EC2-like command interface as well as being able to take snapshots and have my own personal S3 store seemed pretty darn nice.

Getting the UEC CloudController and NodeController's up and running turned out to be pretty easy - The UEC docs , while they're aren't that many of them - are pretty good. I ended up doing an install from both the CD and from packages and both went fine.

Where I ran into some problems was in actually deploying and running the provided Debian Lenny image (I'm guessing straight Debian is less popular than running Ubuntu, but I like the slow pace of updates Debian) that I thought I'd document here in case they are of use to other people getting started. I'm sure some of these are already fixed upstream or in the latest update, but here are my notes from deploying early last month:

Root image size

 Root eucalyptus image too small for what you're doing? Debian lenny image wasn't big enough for all the packages I need to install. Make a bigger image (run this on your box and upload the bundle to your CC):

# create a new file 5 GB large
$ dd if=/dev/zero of=debian-large.5-0.x86.img bs=1k count=5000000
5000000+0 records in
5000000+0 records out
5120000000 bytes (5.1 GB) copied, 92.4922 s, 55.4 MB/s

# copy the current image to the new file
$ dd if=debian.5-0.x86.img of=debian-large.5-0.x86.img conv=notrunc
2050048+0 records in
2050048+0 records out
1049624576 bytes (1.0 GB) copied, 86.6303 s, 12.1 MB/s

# setup loopback device
$ sudo losetup /dev/loop1 debian-large.5-0.x86.img
$ sudo e2fsck -f /dev/loop1

e2fsck 1.41.9 (22-Aug-2009)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop1: 20021/128256 files (0.6% non-contiguous), 127180/256256 blocks

# resize the file system to the new size
$ sudo resize2fs /dev/loop1
resize2fs 1.41.9 (22-Aug-2009)
Resizing the filesystem on /dev/loop1 to 1250000 (4k) blocks.
The filesystem on /dev/loop1 is now 1250000 blocks long.

# Now rebundle and uploaded (linking to existing kernel images):
$ euca-bundle-image -i debian-large.5-0.x86.img  --kernel eki-CF9C1839 --ramdisk eri-1BBF191F

Debian lenny image problems

(All these fixes need to be done from inside of the image after the image is run for the first time)

 /tmp isn't writable (not a eucalpytus problem - but this causes a bunch of problems esp. w/ mysql install)

 chmod a+w /tmp

DNS server is messed up on the VM's - add your DNS manually to   /etc/dhcp3/dhclient.conf by adding the line (near the top)

 prepend domain-name-servers DNS-SERVER-IP;

(Don't forget the semicolon) Where DNS-SERVER-IP is your nameserver, then run  /etc/init.d/networking restart to restart networking

Mounted file system problems - no swap or transient storage, run the following:

swapon /dev/sda3
fdisk -l
mke2fs -t ext3 /dev/sda2
mount /dev/sda2 /mnt

I added the following to /etc/fstab to make the mounts survive a reboot:

/dev/sda2        /mnt          ext3     defaults                   0 0
/dev/sda3        none          swap     sw                         0 0

nosegneg issue - receive an error message from apt upgrade like:

 ldconfig: /etc/ld.so.conf.d/libc6-xen.conf:6: hwcap index 0 already defined as nosegneg
dpkg: error processing libc6 (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 libc6

edit  /etc/ld.so.conf.d/libc6-xen.conf and change 1 to 0