HPEL - A fast binary logging for WebSphere v8

Troubleshooting Java EE apps running on WebSphere just got a bit easier with WebSphere v8's new binary logging and tracing mechanism: HPEL (High Performance Extensible Logging).
HPEL provides logging/tracing run-time performance boost (x3.5-x5 claimed) increasing the chances that you'll be able to turn on tracing on a production system.
HPEL comes with two offline viewing tools: A crafty command-line tool for log analysis, and a web based traces viewer on the Web admin console (handy for remote servers).

The command line utility has a tail function and can filter by: Logger/Thread ID/Time/Server startup instance/etc. Which is a good enough reason for me to get rid of my (slow performing) custom Python based filtering scripts.

Good old legacy text based logs are still supported but are recommended for development mode only.

10 things I like about Android development

1. Java - Write in Java on both the Client and Server sides. Simplifies development and presents a low learning curve for newcomers.


2. Paid apps culture - Unlike when using web apps, mobile app users we're tamed to pay for the apps they like (Thank you Apple for cracking the ice). Developing for Android might be the first time that you'll sell a piece of software directly to your users (it is my first time, and I've been programming since 1996).


3. TTD - When creating a new Android Eclipse project it auto suggest to create matching test project. Proves to show that the Eclipse perspective designer had TTD in mind.


4. API Demos - Good samples project to copy code segments from. Bundled with the SDK.


5. No single point of entry - No single main() function. Your application can have multiple entry points (Activities), which can be used to service the user's Intents. Different from what I'm used to.


6. Construct UI using XML - specifying UI elements using a markup language makes more sense than doing it programmatically (attention Swing).


7. Multiple App markets - More choices for us developers.


8. Coping with multiple device resolutions - using density independent pixels worked well for my modest needs.


9. App Inventor - Ridiculously easy to build your first app. Go try it.


10. What's your 10th? Comment if you have one.

My first App:

My first app is the Weight Watchers Points Tracker (diet related), that I've initially created for my own usage, then later posted to the Android Market. Surprisingly it has been doing pretty good (>10K installations). I'll need to see what comes next...

Spice up your tests - execute in (repeatable) random order

We have a series of SIPp tests that periodically runs against a SIP server we develop. The tests repository keeps on growing and we've gathered up a nice pile of tests.

As good tests should be isolated from one another, their order of execution is arbitrary by definition. The tests should produce the same results consistently regardless of where they are located in the execution chain. I thought I might take this to the test, and perhaps find a bug or two along the way.
Working in Python, I now simply shuffle the list of tests prior to execution:

random.shuffle(testList)
executor.exec(testList)


Nice. Now what happens if a certain execution order fails? I would find the issue and fix it, what else?! Right, but how will I reproduce the same exact execution order that failed before, in order to validate the fix?
One naive option is saving the entire execution order as a list of indices, this is not very comfortable. A simpler option is to simply seed your random object with the same seed int value used during the execution to reproduce. Here's the code:

import random
seedValue = options.get('shuffleSeed', random.randint(0, 10000)) # Seed is provided by the user in an attempt to reproduce, otherwise it's set to some random value.
random.seed(seedValue)
random.shuffle(testList)
print 'Shuffled with seed=' + str(seedValue)
executor.exec(testList)