Testing Code Changes With Diff

Most people use the tool called “diff” to track code changes or build patches to apply to various pieces of code. A buddy of mine introduced me to a technique of using a diff almost like a unit test, where you create a set of “green bar” (known good output) files, then make changes to your code, then run diff against the newly generated output vs your green bar files.  I implemented this technique to make sure I don’t break something as I work my way through all the refactoring I want to do on boxologic’s code.  Curious about how it’s done?  Check out the test target in the make file and the bash script it runs.

Finding Bugs in the Most Arduous Fashion Possible

We had a fairly nasty bug in Boxologic, where some test files would run, others would segfault, and yet others would get stuck in an infinite loop.  I thought that it had to be a transcription error from when I originally moved the code from PDF format into a real buildable file.  Turns out I was right, but I had to print off the appendix of the PDF that held the original source code and go through it line by line until I found it, ticking off each line of code as I went. And just my luck, it was one of the middle line in the last function of the program.  Oh well.  At least things are working the way they should now, and this opens up the way for more refactoring.

Introducing Boxologic

Some time ago I began looking for an algorithm that could perform bin-packing in a 3D space. This search came up pretty nil. There was some dude in the UK doing a private beta of a service, but that was it as far a current implementations were concerned.  Though I did come across a single other solution with supposedly working code, it was all wrapped up in a PDF document that was the master’s thesis document for a gentleman in the Air Force.  Not really wanting to delve into something that would require transcription just to see if it was feasible, I put that project aside for the time being and moved on.

Recently, the problem came up again. Again I looked to see if anyone had published working code. Again, I found nothing really except this PDF that was a scan of the original document.  This time I decided that the world needed a good 3D bin packing solution, and decided to begin the transcription project.  In the interest of posterity, I released the original code – though cleaned up a bit – along with working binaries to Github. In the ‘readme’ for that project, I documented the history and intended future of that code base, and now I think I intend to make good on my threat and begin work towards a more cross-platform and feature rich version of that original code, and christening it Boxologic.

This is gonna be fun!

Is PHP Nothing More Than Web-Legos?

I guess the jury’s still out as far as I’m concerned. Let me be up front – PHP is no longer my language of choice, and I have a slight bias against it. Years ago, when PHP was still relatively nascent and beginning to take over from Perl as the web-programmers choice, I was all over it. I’d learned enough Perl to do most anything I wanted, but PHP was sexier because it had a lot of the stuff you had to work hard for in Perl just built right in. So I jumped the Perl ship and learned PHP. But I wasn’t a seasoned programmer. Though I was convinced I could build whatever I wanted (web wise) in PHP, I began to learn other languages as they either came into vogue or were needed for projects: C, Java, Ruby, etc.

Over time, as I matured as a programmer, I realized that PHP felt toy-like to me, as though it never really matured. It’s object orientation that began to see a little life in PHP4 and have a semblance of maturity in PHP5 always felt bolted on, like it wasn’t really terribly important for the language maintainers, but was added anyway to placate the users.

Recently I took on a project that required me to dust off the old PHP skills as I began to tweak some extant code bases to fit specialized needs. As I worked I joked to a friend “PHP is like web-legos. You can build some cool stuff but it’s blocky and fragile”. But later as I was opening up a a new set of files that would have to be tweaked, I immediately noticed a huge change in the style of code…  these files had real structure, used OO idioms correctly, were formatted coherently, and were easily digestible – all hallmarks of good code that I’d learned to appreciate as I became a better programmer myself. This code was written by a programmer that understood the craft of programming, not just basic hackish problem solving.

So I guess this became a bit of an object lesson that reminded me that it’s not necessarily the tool that is the problem, but the wielder. So my judgement on PHP will have to wait until I’ve spent more serious time with it. But don’t ask me about Perl. Sorry, Larry.