This Photo is Struggling to Contain all of the Awesome.

So much awesome in one picture.

I was going through some of my high school pictures, and found this gem.  I’m pretty sure that one would have trouble putting MORE awesome into a single picture.

• Guitars.
• Darth Vader.
• Cheesehead.

I challege you to find a picture with more awesome in your photo collection.  Rules are that it must not be a ’staged’ picture intended to be full of ‘awesome’.  And it must be your picture – no Google image searching.  You lose points if beer was involved.

Guitarists: I have found our goal!

I may have, in fact, found the loudest, most ridiculous guitar solo ever in the history of guitar-dom.

Only the monster hair bands of the 80’s could have fostered such an awesome, over-the-top guitar performance.

Your mission, as a guitarist, is to:

1. Build up some AWESOME chops.
2. Grow long, greasy hair that you can tease into a massive hair-helmet.
3. Acquire some TIGHT black pleather pants.  Extra points for shiny. Extra EXTRA points for added bulginess.
4. Acquire some sort of long, open-chested coat that you can wear.  Must have some sort of reflective pattern, or at least be a really LOUD color (yellow or pink come to mind).  You are encouraged to show off your ‘man-muff’ of thick chest hair, which is a major contrast to your pasty-whiteness.
5. Lastly, purchase an absolutely WICKED tri-necked, heart-shaped guitar.  WOW.

Java Frustration : Parsing Integers

Recently, when I was working with jhammer, I discovered a frustrating ‘feature’ of some of the default Java Integer and Long methods.  I hope to save some other coders the same trouble.  The problem comes down to this:

Integer.parseInt(Integer.toHexString(i),16) != i;

When the integer i has the most significant bit set (i.e. 0×80000000) , parseInt will throw a NumberFormatException.  I don’t think this is a problem with the methods or their implementation, but rather is a result of Java’s lack of support for ‘unsigned’ integers.  i.e. – a 32 bit integer is ranged from -0×40000000 to 0×40000000, with the upper-most bit being the ’sign’ bit.  This would be okay, except for the Integer.toHexString method returns a (hexidecimal) string that represents an unsigned 32-bit integer: The string form of 0xa0000000 (decimal -1610612736, in 2’s compliment) is represented as “0xa0000000″, which is unparsable by Integer.parseInt as it is not (really) a ‘valid’ signed 32-bit integer.

There are two solutions that I came up with:

1. Roll your own solution (which is what I did, as it looks better to the user, in my opinion).
2. Test the upper-most bit and flip the ’signs’ of the outputted hexadecimal string.  It looks something like this:

String prefix = ((value & 1<<31) != 0) ? "-" : "";
String value_str = prefix + Integer.toHexString(-value);

This will create out parsable hexadecimal numbers that will be ‘correct’ 31-bit integers.  The same process can be followed to create parsable hexadecimal Longs.

Watchmen Movie

A group of friends were going to see a movie called ‘Watchmen’ on Monday evening.  Since I don’t have cable and hardly ever watch TV, I had not seen any previews for this movie.  I only had a title to go by.  I have since decided that this is by far the best way to see a movie – I had absolutely no expectations of what the movie was supposed to portray.

Maybe it was just fun for me because as the opening credits rolled (which are extensive), I saw the big ‘DC Comics’ logo flash on the screen.  My first thoughts were something along the lines of “oh, great – another comic book movie that everybody will rave about for 6 months until Watchmen: The Beginning comes out.  I expect tight spandex, drawn out fight scenes, gruff voices, and lasers.  Plenty of lasers.”  I wasn’t even sure what the movie was rated, as I literally just bought my ticket (no lines on Monday night) and sat down in the theater.  At this point I was expecting a PG-13ish adaption for the big screen. As it turns out, I may have been wrong with that assumption. 

Watchmen features plenty of over-the-top gore that rivals the chainsaw scene in Scarface.  The violence is layered on top of the many ‘Blue-penis’ scenes, which sent the row of high-schoolers behind me into a chorus of laughter and giggles each time Dr. Manhatten waltzed onto the Big Screen in all his renaissance glory.  I thought we were all supposed to be adults?

I must say that I was mentally unprepared for this mature assault on my senses, but I think that this made the movie a better overall experience.   Going into the story with nothing, expecting nothing, I was surprised and captivated by every twist and turn.  I think that this is the way that movies are meant to be watched – the audience has no preconceptions of what the film should be, and instead just allows the director to show them an imaginary world through their lens.  Hollywood promos and reviews should run as follows:

Movie Title.  Rating.

as I feel that this makes for a more enjoyable experience for the consumer.  Especially with all the garbage that is coming out of Hollywood, right now (every single movie advertised in the theater was a sequel or prequel for a film I had already seen – no new IP?!?! come on! clearly they’re just trolling for $$), I feel that even bad films could benefit since the audience is really not expecting anything special.

As far as Watchmen goes, I felt that it was a good movie – not great, but good. The plot was a little bit haphazard and felt like it was a little ‘rushed’ (even though it took almost 3 hours) – as if the storyteller wanted to say more.  Or maybe they just want you to buy the comics to flesh out the sketchy parts…

I’m not sure if I would go and see the movie, again, but it was worth the $7 I paid for it.

JHammer: Psuedorandom Unit Testing

I started a new open source project, yesterday, called JHammer.  From the JHammer website:

jhammer is a simple extension to JUnit that provides a framework for writing repeatable random unit tests. The framework aspires to help developers uncover difficult “show-stopping” bugs earlier in the development process through the use of automated psuedorandom unit tests.

The basic idea behind the framework is to provide an easy way for software testers to generate interesting stimuli for their unit tests, and do as much as possible to guarantee that those tests are repeatable.

The main advantage to pseudorandom testing is that the test writer writes one test and one set of checks/assertions to ensure correctness).  Every time the test is run it generates new (typically unique) random stimulus to exercises the unit under test (UUT).   The important part is that the psuedorandom test generation is able to create test cases that a human test writer would have a hard time designing.

For example, I had a simple open-addressed hash table (see Wikipedia for a good explanation) implementation written in C.  Like any decent programmer, I wrote  simple unit tests and they all passed.  Just for kicks I wrote a (quick and primitive) random test generator and started running test iterations.  The random tests immediately (within 100 iterations) found a bug in my code! Basically I had a copy-paste error that calculated the wrong array offsets when resizing the array).

So I fixed that bug (I probably would have stumbled upon it, eventually) and happily completed 500 or so random test iterations, multiple times.   I then “upped the anti” and started running hundreds of thousands of test iterations (and randomized the hash table size).  The random tests hit a non-trivial bug that required the following sequence of events to hit:

1. Element A added to hash table
2. Element B added to hash table ‘close’ to element A
3. Element B removed from hash table.
4. Hash table resized.
5. Element A added back into hash table.

What happened was that due to an errant bit flip in the implementation, the table now had two element ‘A’s. Because elements in the table must be unique, my program was no longer correct!  Here was where I realized the true power of psuedorandom testing – I would not have thought to test that particular sequence of events, yet that bug would have had catastrophic results if it washit in the field.

As sort of a pet project I decided to make a similar test framework for Java, and called it JHammer.  Writing unit tests is with JHammer is almost identical to writing JUnit tests , so there isn’t much of a learning curve.  Even so, there are a few things to keep in mind to ensure a repeatable test.  I wrote up a (rather lengthy) article at http://jhammer.tigris.org/wiki/GettingStartedWithJHammer that outlines how to use the tool.

There is a very preliminary preview build available in the Documents and Files section – click on previews and get the most recent preview build (Preview 6 as of this writing).  I would greatly appreciate more feedback on the project before I start adding more features.

Hiking Grey Rock, CO

Last weekend (2008-06-14) Heather and I took a trip out hiking to Greyrock Mountain (just NW of Fort Collins). I just spent ~2 hrs figuring out how to upload the pictures (sorry, WordPress won’t let me do thumbnails!) and getting the GPS data into Google Maps. As a result, I don’t really feel like typing up a huge post to go with the pictures…

Heather and I woke up at ~6:00 AM so start the hike at 8:00AM. Finished the hike around 1:30PM. We took the ‘Meadow trail’ both times (by accident). If you look closely (Google Earth is better for this), you’ll notice that we didn’t quite make it to the summit. At the top of Greyrock there are 3 ‘peaks’ – or rather, 3 higher points of interest surrounding a lake. We didn’t go all the way to the very summit of Greyrock, as we wanted to get back at a decent time, although the hike was still very fun.

Greyrock Mountain ‘Meadow Trail’

Here’s some other links to people who have hiked this trail:
Sam Cox (Landscape Imagry)