Of course now that it’s Friday and I’m feeling the urge to start writing more code having to do with dongs.  What the fuck is wrong with me?  Don’t answer that.

I figured that by explaining some of what I’m struggling with, some magic will happen.  I need to blog more and work on my “explaining complex shit in a meaningful way” skills, so if this in any way interests you please read on.

WARNING: TECHNICAL SHIT BELOW!

The application I am rewriting is a MySQL database-driven app that has two interfaces:

1. A command-line interface (CLI) utility written in Perl for direct manipulation (addition/removal of records) and querying (searching) of the database. Only engineers have access to this tool.
2. A web application written in PHP for searching the database for non-engineers.  Mostly support and operations staff use this. This also provides a hacked up “API” that returns a list of comma-separated values (CSV) of matching records.

There are a shit-ton of logical pitfalls in that code that have really thrown me off.  Being that we have a Perl CLI tool and a PHP web app, the much of the code is duplicated for each language. The tool was originally written in Perl with the web app piece tacked on as an afterthought.  At the time I was really into PHP’s native support for MySQL but was pretty much a novice so ended up making some downright lazy and bad choices.

With PHP and it’s bloated cousin Perl, there are so many ways to do the same thing that there really isn’t one right way to do things.  Typically that means there are that many more wrong ways to do them.  For example, horrible crap like this where we have PHP making a system() call to execute a Perl script from within index.php:

<table>
  <tbody>
    <tr valign="top">
      <td>
        <?
          system('perl body.pl column="' . $POST['column'] . '" value="' . $POST['value'] . '" netmask="' . $_POST['method'] . '"');
        ?>
      </td>
    </tr>
  </tbody>
</table>

“Why is that?”, you ask?  Well let me tell you!

First things first, the primary users of the app (aka the stakeholders) have been requesting some new features for a long time and with everything else going on it hasn’t really been a high priority for me.  Especially because it was written in Perl, which I have grown to hate passionately since I started using Python.

Next, the systems from which the CLI tool runs are being replaced, which means the app has to be moved to the new systems. We run a Red Hat offshoot distribution of Linux, so we use RPMs to manage what gets installed on machines.  What this means is that any Perl module dependencies need to be installed via RPM. With RPM and Perl there are always dependencies of your dependencies, and you can bet that some of those won’t be available in the repository. This opens a massive can of worms of having to download the module source and convert it to RPM.  For those of you who are familiar with Perl’s CPAN and RPM, you’re probably thinking “Just use cpan2prm!”. Right, if only it were that simple…

You see, the new hosts are running a 64-bit kernel, which means that the subset of available packages is even smaller because packages have to be specifically built (or rebuilt) for 64-bit installation. Even if it’s the same files inside of the package, it still has to be re-packaged for 64-bit.

So, I was left with the choice of either uprooting the tool from its current location, wrangling package dependencies, rebuilding packages, modifying the Perl code to shoehorn it into the new systems all the while overlooking the implementation of the requested features; or rewriting it using Python & Django.

Naturally, I chose to rewrite it because the thought of having to trudge through antiquated Perl hackery gave me diarrhea and I really don’t want to ever touch Perl or PHP again if I can help it. By rewriting the app in Python, I can implement the new features and bring the code into the present at the same time without having to go through bouts contemplating suicide. Annnddd… That leads us back to the nightmare that is Perl and PHP.

As I mentioned above, with Perl & PHP there are so many ways to do things that most of them are convoluted, confusing, hard-to-read, and just plain fucking wrong. With Python–and Django for that matter–there is usually only one right way to do things, and that way is pretty much always elegant.  Plus, one of the most beautiful things about Django is that it wholly and completely abstracts the database interaction from the source code.  That means not having to write complex SQL statements manually, and the less SQL I have to write, the better.

In meeting with the stakeholders on rewriting the application, we decided that all of the energy should be invested in replacing the web app with a real API with a RESTful interface. If you don’t know the basic premise of REST (which is a methodology, not a protocol), it’s that URLs should be easy-to-read, self-describing and beautiful. Beautiful URLs? WTF? How can a URL be beautiful?  I’m glad you asked!

The old PHP version of the API is very heavy on the query string, requiring GET variables to be passed in the URL itself which is not only cumbersome, but can get confusing and hard to read very quickly:

http://server.whatever.com/api.php?show=all&user=jathan

Compare that to a RESTful version of the same:

http://server.whatever.com/api/show/all/jathan/

This is where Django excels because it encourages pretty URLs by making it easier to use pretty URLs than not to.

So, cutting this post off at the knees, I’ve been pounding on this for the past few weeks, learning a lot about how NOT to do things from my old code and how TO do things using Django as my guide.  I made a lot of progress, got the API working, and a basic search interface that returns stuff all using the same code.

But this week, I’ve been stuck.  I haven’t made any progress, have been getting really confused, and just generally bashing my skull into the keyboard.  I think I’m just fried from trudging through all of Perl’s curly braces, semicolons, ampersands, dollar signs… OMG THE SYNTAX!  KILL ME NOW!!

Besides, it’s Fried-day anyways, so I hope that just by spelling this all out here that I’ll be able to dig back into the code after the weekend with a renewed perspective.

p.s. Fuck Perl.

p.p.s. Fuck PHP too, but wrap that rascal. She gets around!

Enjoy:

#!/usr/bin/env python

''' MKdong turned into a module. I think I was smoking crack and/or high on Red Bull this day.

Dong goes into underpants Dong goes into boxers Dong goes into vagina Sperm comes out of dong Sperm goes into vagina Sperm goes into egg Dong goes into mouth Pee comes out of dong Pee goes into toilet Why am I iterating this crap? '''

import os, sys

blue = '\\e[0;34m' # blue

class Dong:

def __init__(self, maxlen=40, color=blue):
    self.maxlen = maxlen
    self.color  = color
    self.dong   = None

def mkdong(self):
    self.dong = '(_)/(_)'
    for i in range(self.maxlen): self.dong += '/'
    self.dong += 'D'
    os.system('echo -e "%s%s"' % (self.color, self.dong))

class Sperm(Dong): def init(self, count=500): self.count = count self.spermcount() Dong.init(self)

def __repr__(self):
    return '' % self.count

def tighty_whities(self):
    print 'Tighty Whities lowered your sperm count!'
    self.count -= 50

def boxers(self):
    print 'Boxers raised your sperm count!'
    self.count += 50

def spermcount(self):
    print 'Sperm count is %d' % self.count

def bike_seat(self):
    print 'asdjfoisadjs'
    pass

def radiation(self):
    print ':-x'
    pass

def castration(self):
    print ':('
    pass

def smoke(self):
    print 'awwww yeahhhhh.'
    pass

class Egg(Sperm): pass

if name == 'main':

try:
    donglen = int(sys.argv[1])
except:
    print "usage: mkdong "
    sys.exit()

if donglen > maxlen:
    print 'warning: a %s" dong is too big! cannot be longer than %s"!' % (donglen, maxlen)
    sys.exit()
else:
    d = dong(donglen)
    d.mkdong()</pre>

There’s really no excuse. I should be ashamed of myself but I’m not.

% ./mkdong
usage: mkdong <length>
% ./mkdong 5
()/()/////D
% ./mkdong 25
()/()/////////////////////////D

% ./mkdong 60
warning: a 60" dong is too big! cannot be longer than 40"!

It all started harmlessly enough with a silly AIM conversation with my coding buddy at work. We were talking about a bug, and well, read on and you’ll see. It regressed quickly.

The initial dongs were a little primitive and sickly looking. So I took his suggestion and improved their visual style. Here is how it turned out:

#!/usr/bin/env python

import sys

maxlen = 40

try: donglen = int(sys.argv[1]) except: print "usage: mkdong <length>" sys.exit()

if donglen > maxlen: print 'warning: a %s" dong is too big! cannot be longer than %s"!' % (donglen, maxlen) sys.exit() else: dong = '()/()' for i in range(1, donglen): dong += "\" dong += 'D'

print dong We laughed. We joked. We Tweeted. And then it regressed even further:

And then I released it to the public. So there you have it. Here is the final release of mkdong 2.0 for your pleasure:

#!/usr/bin/env python

import os, sys

maxlen = 40 color = '\\e[0;34m' # blue

try: donglen = int(sys.argv[1]) except: print "usage: mkdong <length>" sys.exit()

if donglen > maxlen: print 'warning: a %s" dong is too big! cannot be longer than %s"!' % (donglen, maxlen) sys.exit() else: dong = '()/()' for i in range(donglen): dong += '/' dong += 'D'

os.system('echo -e "%s%s"' % (color, dong)) Use it well. And remember they aren’t bugs, they’re dongs! Squish? Gross.