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.

Boxologic’s Cross Platformability

Last night we pushed code changes that makes Boxologic sanely buildable on OSX, Linux, and Windows. We also knocked out the way it used to require a specifically named input file (ending in .txt and following the ancient Windows 8.3 naming format), and added command line options for a help screen and version info.

Making it cross-platform was a unique experience for me. Making it compile on a modern unix machine was straightforward enough. Removing the windows-specific libraries and functions and migrating a few outdated functions were pretty much all it took.

Reworking command line options was a bit different though. In order to have mostly automatic option parsing, I was going to use the POSIX compliant getopt(). In fact I already had it working and commited at one point. But that required the use of a header unavailable on Windows systems unless you’re using something like MinGW as a compatibility layer. So then it became a question of examining what the long term goals of the project really are, if we’ll ever really have more than a handful of cli options that are easily managed manually without the use of getopt() and it’s GNU cousin getopt_long().

The answer turns out to be “Yes”. It’s more desirable to mange things manually and have simple cross-platform building than to strictly build for POSIX systems. So I reworked and committed code changes that compile out-of-the-box on OSX, Linux, and Windows. This project is turning out to be quite fun!

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.