Blog

First off, jQuery UI is great. It makes creating a responsive UI simple, and the tabs capability is great. However, I recently came across a use case where I wanted to dynamically alter the url of a tab (specifically, the query string) dynamically, something it seemed the library didn’t allow. The load-time href of the tab was wrapped and inaccessible at run-time. The fix would be simple, but the source file I was working with was the minified output of their customizable web-based build system, making modification impossible. Downloading fresh, unminified source was equally impractical. So I looked into building it myself. It turned out surprisingly easy.

Obtaining the source

First, I downloaded the latest stable source (1.8.16 at this time), and took a look through it. All the modules had their individual files. In the build directory, I noticed “build.xml”. This is an Ant build configuration file, so I then proceeded to setup Ant.

Setting up Ant

It took reading some documentation, but this was equally simple. I already had Java, so I jumped right to getting application:

1. Download the Ant binaries from here
2. After unzipping it, I configured the following environment variables:

• %ANT_HOME% = Installation path for Ant
• %JAVA_HOME% = Path to current Java install on my system (not technically necessary, since this was already in my %PATH%)
• Add %ANT_HOME% to %PATH% so I needed fully-qualify the exe when I execute it

Building the Source

Again, this was simple.

1. Open up a command prompt
2. cd to the build folder inside the jquery.ui source directory (where build.xml is)
3. “ant build deploy-release” to build it to build/dist

There were a few other build options I could’ve chosen. “Minify” will just output the minified source, without license info, documentation, or zipping it.

I also experimented with building jQuery UI 1.9 beta, but ran into some issues. Getting the source from github was simple, but they’ve replaced their minification engine from the Google Closure compiler to uglify.js, since it “saves 4 minutes per build, and actually produces slightly smaller files“. This posed an issue, since the current version of the code executes uglify.js from a shell script. I converted the Linux shell script to a Windows batch file, with a little help to get the directory name. This all went fine, until it came to actually executing the js from the command line. There is no console js engine by default in Windows, and using the js.exe output when I built Firefox seemed to error when it ran the script (issue with referencing “global”). Since using 1.8.16 was alright for my immediate purposes I didn’t look into further solutions.

I could’ve tried installing Rhino to get around this, but it’s something to try in the future. Another solution is obviously to try running it on Linux. I spent a bit of time updating my Ubuntu VM install after getting everything working. Until I try and venture into building 1.9, I’m just fine developing off of 1.8.16. After all, it works great.

More often than not, solving problems through software is simple. The issue/requirements are there in front of you, clear and needing to be solved. Every once in a while though, something stands up and teaches me a lesson.

Every system relies on external components. Whether it’s a third-party library to help with a specific purpose (jQuery, ComponentOne), a runtime to compile applications against (.NET, Java), or a compiler library for simple operations (iostream, math.h), all systems have dependencies. They’re everywhere.

99 times out of 100, when something goes wrong with the code, it’s my fault. These are the cases I mentioned earlier: clear issues, simple solutions. It’s the tricky ones that exist outside my program’s black box, where creative coding and problem solving comes into the picture. These are the ones I like. They teach me to think outside the box, to not take anything for granted, and that above all, we’re all human.

It’s what makes software fun to write.

Today I learned a valuable lesson in debugging. Today I learned what it can be like to chase your own tail. I had accomplished the rare feat of introducing a bug through the very act of debugging.

A common feature for software is to behave differently depending on the rights of the user. Super users should see an entire list, while normal users should have less power, only seeing list items pertaining to them. Simple to code, tricky to test. All it takes in an “if” statement, like this:

if(superuser) {
   // Run special code
} else {
   // Run not-so special code
}

And then you write the code. Of course, with my default rights, I can only check one half of this conditional (I am a superuser). Rather than modifying the code and recompiling, or modifying my rights, I thought it would be great to use a debugging tool to bypass this check entirely, and hop right into the non-privileged. Big mistake. First time I tried this, I got a null reference error while calling a function. Not out of the ordinary, the function called a web service, maybe I wasn’t disposing of something properly. 20 fruitless minutes later, I’d rewritten that function several ways trying every way of calling, disposing, and scoping I knew. When that didn’t work, I looked higher up.

The erroring function was called in one other place, in a non-static context. No luck when I tried changing that. Using an intermediary variable for the result? Still it crashed. After a lot of simplification, I managed to make the null error happen one line further up in the code:

MyClass c = new MyClass();

Now this didn’t make sense. MyClass had a default, empty constructor, and no class-level fields. Yet running this line gave me a Null Reference Exception. Getting tired of stepping the debugger forward each time, I decided to just comment out the check, recompile, and continue debugging. Then, the error stopped. After a lot of hunting through Disassemblies, I found the rub: using the debugger to bypass a line of code changed (or rather, didn’t change) some values in memory that the instructions below expected. Eventually, when it tried to issue a “call” to a memory address, there would be random garbage data there. A seg fault may’ve been happening under the scenes, which .NET happened to present as a… Null Reference Exception.

My attempt to observe program state altered the very state I was trying to observe. Schrödinger’s bug.

I’m readying for graduation, and I’ve taken a looks back at how my coding style and structure has evolved (and am I ever glad it has). At first, there was a mess of convoluted logic, not-so-poly morphism, and generally bad code. The best example for this has been an ongoing project of mine for the last 3-4 years. I’ve been working on a chess engine, which has undergone massive rewrites as I’ve learned more. Without any knowledge of design patterns and limited knowledge of exactly what a compiler does, it was an unreadable mess of code. The only thing saving it from being spaghetti was structure.

private bool canPiecesMove()
{
  char colToMove = whiteTurn ? 'w' : 'b';
  short[][] moves;
  short[] discoveryCheckOrig = discoverCheckPiece;

    for (short x = 0; x < 8; x++)
    {
      for (short y = 0; y < 8; y++)
      {
        if (board[y, x] != null && board[y, x].Colour == colToMove && board[y, x].Value != (ushort)Game.PieceValues.king) // Come to own non-king piece
        {
          moves = board[y,x].getMoveableSquares(x,y);
          if (board[y, x].Value == (ushort)Game.PieceValues.pawn)
          {
            if (board[moves[0][1], moves[0][0]] == null && !isPinned(x, y, moves[0][0], moves[0][1])) // Pawn can move forward                             {                                 discoverCheckPiece = discoveryCheckOrig;                                 return true;                             }                             if (moves[1][1] >= 0 && moves[1][1] < 8 && moves[1][0] >= 0 && moves[1][0] < 8)
            {
              if (board[moves[1][1], moves[1][0]] != null && board[moves[1][1], moves[1][0]].Colour != colToMove && !isPinned(x, y, moves[1][0], moves[1][1]))
              {
                 .....
              }
            }
          }
        }
      }
    }
  }
}

While it worked, it was a mess. 3 rewrites later it now takes advantage of 3 further years of knowledge and education. I’m currently working on move generation in preparation for eventual AI, but not much real feature progress has been made on the engine since. Refactoring has been the main draw of effort.

Have I been bikeshedding in my development? Many friends say yes, but I disagree. Sure, additional features are few and far between, but isn’t one of the rules to develop one to throw away? Doesn’t the release early, release often mantra allow for ingenuity and inspiration to be unhindered by what “must be perfect?” I’ve learned a great deal since my first pass at this chess engine, and about the only unchanged code is UI-based. Without the willingness to go back and fix what wasn’t broken, I feel something would’ve been lost.

So I say this: Never be afraid to reinvent your own wheel.