Behind the Curtain at TCG

TCG Executive Team Wins 2012 SmartCXO Award

TCG's executive management team has been named one of the best senior leadership teams in Washington, DC, by the 2012 SmartCXO Awards. The awards are sponsored by SmartCEO magazine. Hats off to our team—they truly deserve this recognition! To read the full press release, click here.

Telework Exchange Announces Spring 2012 Town Hall Meeting

The Telework Exchange--a public-private partnership focused on eliminating telework gridlock--has announced that its Spring 2012 Town Hall Meeting will be held Wednesday, May 2, 2012 at the D.C. Convention Center.

The spring program will focus on the fundamentals that empower a successful workforce—regardless of where they are located, and will consist of two tracks addressing telework technology and management methods that support a mobile workforce. GSA Administrator Martha Johnson will deliver the morning keynote address.

The Fall 2011 Town Hall Meeting was the largest Town Hall Meeting to date, with more than 900 attendees and 115 Federal agencies represented.

Registration is complimentary to government employees (industry rates apply) and Town Hall Meeting attendees are eligible to receive continuing professional education credits.

For more information and to register, click here.

Firefox 4 Saved My Android

As a side project I have been working on an HTML5 app designed to permit real-time playing of board and card games on multiple devices (PC, iPhone, Android, etc.).  This led to some interesting research about touch events and getting click events to work quickly on mobile devices.  So I was really excited to get an Archos 80 G9 to do some testing.

The Archos is speedy and responsive, so I was looking forward to lightening-fast piece manipulation, especially since my wife's iPad 1 worked rather well.  I was shocked, however, to find that the brower's animations and touch response was painfully sluggish.  As it turns out, the iPad's touchmove polling (46 moves/sec in the test) is significantly faster than the Android default browser's polling (14 moves/sec). My app and sites like Google Maps just seemed intollerable.  The Dolphin browser suffered similar issues.

I was furious!  Why would some software architect out there choose to cause a whole class of applications to languish in sluggish stuppor due to an inane choice of polling frequency?  Fortunately I found this comparison of Android browsers that portrayed Firefox as a clear winner in performance. At least on the Archos, Firefox polls touchmove events much more frequently, resulting in a nice touch-based HTML5 app experience.

Since I had actually started researching how to return the device, I can say without exhageration that Firefox 4 saved my Android.

Faster Random Numbers in JavaScript

There is a non-deterministic cellular automaton simulation that I have coded in a few in different languages on everything from a Commodore Vic-20 to an Android phone.  It's basically a grid populated by various colors that change states based on some random probabilities.  Ok, that explanation didn't sound as simple as I hoped, let's try again:  It's basically a screen full of squares that shift colors in a random fashion. I like to code it because it is pretty to look at. 

The important thing is that for each frame in the simulation I need to generate a random number between 0 and 3 for each colored block.  The more colored blocks you can pack on the screen, the better the light show looks.  With too many blocks the computer slows down and that doesn't look good at all.  My latest implementation was in HTML5 and JavaScript.  Since the program needs a lot of random input, I was curious about how quickly JavaScript could pump out a series of random numbers.  It turned out to be more than fast enough and my program is actually limited by the display code.

Even though the random number generation wasn't my bottleneck, I was interested in seeing if I could generated the randomness I needed more quickly.  You see, I have a special case.  I only need 2 bits of randomness to get my number between 0 and 3.   The typical JavaScript example for this would look like:

r = Math.floor(Math.random() * 4);

My first thought was that I'm generating a lot of random bits, packing them into a floating point number, then doing a floating point multiplication, then throwing most of the result away.  There has to be a better way.  First I needed a benchmark to compare my experiments against:

    var iterations = 1000000;
    function basicRand() {
        var r = 0;
        for (var i = iterations; i > 0; i--) {
            r = Math.floor(Math.random() * 4);
        }
    }

I used Firefox to profile the script and found that it ran in 85 ms.  As I said, more than fast enough for my real purpose, but I was curious.

Experiment #1 was to see if I could speed things up by forgoing the floating point math and converting the random number to a string and extracting the random digits.  Sure that's a lot of work, but I could get a lot of significant random digits out of a single random number....and doing this is easy in JavaScript so it was worth a try:

    var digitString = "";
    function fasterRand() {
        var r = 0;
        var digit = 0;
        for (var i = iterations; i > 0; i--) {
            digit = 9;
            // throw out any 8s and 9s because they will skew the distribution
            while (digit > 7) { 
                if (digitString == "") {  
                  // we were out of digits, create a new random number and convert to a string
                  digitString = Math.random().toString().substr(2,12);
                 }
                 digit = parseInt(digitString.substr(0, 1)); // grab the first digit
                 digitString = digitString.substr(1);        // shift the first digit out of the string
             }
             r = digit % 4; // do a mod 4 so the result is in the 0-3 range
         }
     }

This function was clearly misnamed because it took 258ms to generate the 1 million random numbers.  That is about 3 times slower than the standard approach! In retrospect, I think I should have known that all the string manipulation would suck up a lot of cycles.

I did have another idea that involved shifting the random bits around and using bitwise & to get the bits unpacked.  Reading some documentation I found that JavaScript is a little funny about giving you access to the underlying bits of your variables.  No matter the original type of a variable, the bitwise operators will be converted to 32 bit signed integers.  Even still, that means that a randomly generated integer should have 32 accessible bits of randomness.  My next try was this:

    function shiftRand() {
        var r = 0;
        var raw = 0;
        var maxint = Math.pow(2, 32);
        for (var i = iterations; i > 0; i--) {
            raw = parseInt(Math.random() * maxint);
            for (var j = 0; j < 15; j++) {
                r = raw & 3;
                raw = raw >> 2;
                i--;
            }
        }
    }

Much better!  This generated the million random numbers in just 12 ms!  That is about 7 times faster than the standard implementation.  If I was using this for scientific research I would want to do some analysis of the code to make sure that my results are just as random as the standard implementation.  Since this is really just a toy application, I also don't mind if I loose a little of the randomness. 

Your mileage may vary:  the more random bits you actually need the less the speedup will be.  I did some quick tests and found that if if you need 16 bits of randomness it is still faster to break down the 32 bit random integer than to create two unique randoms, but it's something close to 1.25 times faster.  Still better, but not nearly so dramatic.

A real JavaScript ninja can probably wring out a faster implementation, but I am quite happy with my 7 fold improvement.  If you have any suggestions for faster generation of random numbers, let me know in the comments!

Three Ways to Handle Orientation Change on Your Mobile Web Site

Most of the projects that I have worked on used a desktop web browser for a front end.  The nice thing about desktop computers is that people don't go around flipping monitors onto their sides.  Another nice thing is that users either keep their browser windows full screen or they are smart enough to know how to re-size it to fit your web site nicely.  Developing for mobile platforms is a bit more complicated.

The first problem is that a user can rotate their device.  The second is that users can't exactly re-size your browser window in the traditional sense.  Sure, they can zoom in and out, but that doesn't change the aspect ratio of your site.  To make things worse, a mobile site needs to be viewable on a wide range of device sizes.  Everything from a 240x320 Blackberry to a 1024x768 iPad is fair game for your test team.

After a bit of research and experimentation I've found three ways that you can handle rotation and content layout.  Surely there are more systems to deal with the problem, but these have covered all my needs so far.

#1 Fluid Layout

This is probably the simplest and most familiar to traditional web developers.  It does require some advanced planning though.  When you are starting on your design, arrange your content into blocks and set them all floating left.  As your screen size and shape changes, the mobile browser will display your content as best it can.  If you planned well and your content is amenable to this technique, this can look good.

#2 Provide Alternate CSS for Portrate and Landscape

Similar to #1, this requires some planning.  Keep your design modular and use CSS to lay everything out, but design two (or more) sets of css layouts.  You can wrap your css layout in @meda selectors like this:

One layout for portrait and one for landscape.  You then wrap each CSS layout in media selectors like this:

@media screen and (orientation:portrait) { … }
@media screen and (orientation:landscape) { … }

If your design needs to be tweaked for different resolutions, you can even do that with a media tag like:

@media (min-width:500px) and (max-width:900px) { … }

#3 onorientationchange JavaScript

Finally, if you want to modify your layout, or do anything else, using JavaScript when the orientation changes you can bind to the onorientationchange hook:

window.onorientationchange = function() {
  switch (window.orientation) {
    case 0:
	// run your JavaScript for portrait mode here
        break; 
       
    case 90:
	// run your JavaScript for landscape mode with the screen turned left
        break;
   
    case -90: 
	// run your JavaScript for landscape mode with the screen turned left
        break;
  }
}

 

Audio Effects for HTML5 Based Mobile Apps

I've been experimenting a bit with HTML5 mobile applications.  One of the funny little corners I've found is how to reliably use audio effects across platforms.  The HTML5 spec includes an <audio> tag.  Unfortunately I found it to be a little quirky, especially on some Android 2.x devices that I tested.

If you aren't concerned with every mobile device and you know that it is well supported on your target platforms, the <audio> tag might be the easiest way to create sounds.  Here is an example:

<audio id="sound_click" src="audio/click.wav" preload="auto"></audio>
<script>
    //do this when you want to play the click.wav sound:
    document.getElementById('sound_click').play();
</script>

For me, this worked out perfectly for the iOS devices I tested with and also in the Chrome browser I use during development.  On my Android 2.3 device, it was very laggy and I couldn't get it to work the way I wanted.

There are some open source libraries that can help you in your cross-platform quest.  I looked at jPlayer for a bit.  It works on the devices I tested on.  Under the hood jPlayer uses the HTML5 audio tag with a Flash player fallback.   It is a great solution if you are doing a pure web app and don't have any access to the native layer.

I am using PhoneGap Build to package my HTML5 code as a native app on Android.  That gives me another option.  I can use PhoneGap's audio API for the cross platform audio goodness that I want.  It did take a little research to get all the pieces in just right.  The trick I was missing in my first go round was specifying the path to the audio resource properly.  It turns out that you need to prepend "/android_asset/www/" to the relative path for your audio file.  In the end my audio code looked like this:

var my_media = null;
function playClick() {
    if (onAndroid && onPhoneGap) {
        if (my_media == null) {
            my_media = new Media("/android_asset/www/audio/click.wav",
                                                function () { console.log("playAudio():Audio Success"); },
                                                function (err) { console.log("playAudio():Audio Error: " + err); console.log(err); console.log(err.toString()); });
        }
    my_media.play();
    } else {
        document.getElementById('sound_click').play();
    }
}

This lets me use the regular HTML5 audio tag when my application isn't running as a native app and the PhoneGap media API when I'm on android. 

PHP Code Review Checklist

I recently created a code review checklist for a PHP based project I was working on.  If you want to be pedantic, it's actually a list of questions that the reviewers should ask themselves as they look through the code.

This isn't an exhaustive list and it's not meant to be.  The only thing you will get from making an all-encompasing code review checklist is a list the your reviewers will ignore.  I'm depending on my team to be smart, autonomous, rational, and wise.  Perhaps I am idealistic, or maybe I'm just lucky to work with a great group of engineers.  The final version is still under development, but I wanted to share what I think is important when doing a "formal" code review.

Questions to consider while reviewing code:

1. Is the code readable as written?  Does it require additional comments, better naming, or general refactoring to be easily understandable?  Does the code generally conform to the style of coding for the project?
2. Does each function contain a (very) brief comment describing functionality, inputs, and outputs?
3. Does new code keep business logic away from presentation code?
4. Is identical functionality repeated multiple places in the code base?
5. Are there any code blocks that should be abstracted into functions or classes for maintainability?
6. Are there any hard coded constants that could possible change in the future?
7. Are all reasonable error conditions handled?

These questions are shaped by my personal experiences and the kinds of projects that I work on.  Some of them won't be applicable to another project, or even if they are applicable, they might not be necessary. They are also very subjective.  Decisions made while writing software are rarely black and white.  What is readable code for one person might be opaque for another coder who has a different skill set.  "Reasonable" error conditions may differ based on how critical this application is.  Consequently, I think code reviews are best when they are discussions and opportunity for learning.

There was another group of questions that I thought were important, but aren't really code related.  They probalby won't become part of our checklist, but I think they are interesting none the less.

1. Are the requirements formalized in writing and tracked/managed properly?
2. Are the requirements clear and unambiguous?
3. Is there a testable scenario that can exercise the new/changed requirements?
4. Was the code tested by someone other than the author? 
5. Did the modified code satisfy all the current system requirements?
6. Did the test scenarios exercise all the changed code paths?  If not, is there a good reason for that?

For me these questions are more like project wide diagnostic tests.  If you are running over schedule or you are getting a lot of bug reports back from the downstream users, asking these questions may help explain why the code creation process isn't performing as well as expected.

Effective Image Buttons for HTML5 Mobile Apps

Mobile application development doesn't always mean native apps for iPhone and Android.  If you are an experienced web developer you can use HTML5 to make great apps that have a great look and feel.

I'm working on a small HTML5 mobile app that uses toggle buttons to set the application state.  For my app, I have a bank of buttons that have two states "in" and "out".  Here is what they look like:

I used Gimp to create the buttons as PNG formatted images with transparent background.  On my first iteration, I setup the buttons using simple HTML img tags:

<img src="Images/blue_in.png" state='in' colorname='blue' onclick="toggleButton('blue');"/>
<img src="Images/reg_in.png" state='in' colorname='red' onclick="toggleButton('red');"/>
<img src="Images/green_in.png" state='in' colorname='green' onclick="toggleButton('green');"/>

As you can see, I am storing the state of each button in the img tag itself. The toggle function looks at the current state and swaps the image around, like so:

            function toggleButton(color) {
                var button = $('.button_img[colorname=' + color + ']');
                var colorname = button.attr('colorname');
                if (button.attr('state') == 'in) {
                    button.attr('state', 'out');
                    button.attr('src', 'Images/' + colorname + '_out.png');
                } else {
                    button.attr('state', 'in');
                    button.attr('src', 'Images/' + colorname + '_in.png');
                }
            }

The first thing I noticed in testing was that on my Android device I was getting a very annoying green box highlighting the images when I clicked them.  You can disable this with a bit of CSS that sets the highlight color to transparent.  So I added this to my CSS:

.button_img { width: 100px; height: 100px; -webkit-tap-highlight-color:rgba(0, 0, 0, 0); }

So now things are looking better, but the performance isn't really up to the standards of a native app.  When you click on a button it takes about half a second for the state to change.  My goal is to make this HTML5 app every bit as good as it's native cousins, so this delay will never do.  The problem is that I'm binding my toggle code to the onclick event.  Due to the nature of a touch screen device, the onclick event has something close to a half second delay between the time you touch the screen and when our javascript is triggered.  A better choice is to bind to the touchstart event.  That is called immediately when our button is pressed without any undo delay.  This code is a little trickier because you can't define it right in the img tag.  You can do all this with standard JavaScript using the addEventListener function, but I love jQuery, so my new code looks like this:

          $(document).ready(function () {
                $('.button_img').each(function () {
                    $(this).bind('touchstart', toggleColorTouch);
                });
            });

            function toggleColorTouch(e) {
                toggleButton($(e.target).attr('selectcolor'));
            }

Ahh, now this is looking really good.  One final thing is missing though...there is no auditory or tactile feedback.  That's not everyone's cup of tea, but if you want it is easy enough to add.  You can trigger audio feedback using HTML5's audio tag and API.  Just put this audio tag in in your HTML:

    <audio id="sound_click" src="click.wav" preload="auto"></audio>

Then when you toggle the button, trigger the sound:

            function toggleColorTouch(e) {
                document.getElementById('sound_click').play();
                toggleButton($(e.target).attr('selectcolor'));
            }

Older Android devices have some lag problems with the audio tag.  So if you are targeting Android, either use an alternate method or make sure you test this out on the devices you want to support. 

Standardized Grants Forms: It's Hard to Make It Easy

Victoria Collin from the Office of Management and Budget spoke at the National Grants Management Association’s November training session about the new Council on Financial Assistance Reform. The Council was created by the White House in October to make sure that the money others spend for the government is spent correctly and produces results. In return, the government is going to look at how to make it easier for people and organizations to apply for that financial assistance.

One of their aims is to better standardize grant applications across the Federal government to relieve some of the burden on applicants. This is difficult, as Federal grant programs cover so many different areas. Just as a challenge, I tried to come up with a standard application for three grant programs, Amtrak, WIC (Women, Infants, and Children), and cancer research. All have applicants, all represent social needs that deserve Federal support, all transfer resources from one entity (the Federal government) to another (the grant recipient).

So here is my form that would cover all three equally:

1. Name of the program to which you are applying:
2. Your name:
3. Your address:
4. Amount requested:
5. What you will do with the grant:
6. When you need it, and how long it will meet your need:
7. Why we should give it to you and not someone else:

I thought about a lot of other fields, like “How we will know that you are using the grant for what you say,” or “Name the Congressional district that will benefit,” or “List the deliverables you will produce,” or even “Give the number and names of unemployed veterans you will hire, how long each has been out of work, and the highest education level for each,” but the first question doesn’t make sense for the poor pregnant woman who gets two gallons of milk through WIC; the second doesn’t work for Amtrak; the third doesn’t easily apply to cancer research, and the fourth, as worthy as its goal might be, is just annoying.

I understand that it’s complicated to apply for grants, but if you want to spend someone else’s money, you are going to have to go along with someone else’s rules.

Nevertheless, the Council on Financial Assistance Reform will try to make the rules simpler in four aspects of the Federal grants enterprise:

• Fair and transparent award-selection procedures
• Government-wide reporting requirements, to emphasize results and allow government to blend funds and programs
• Consistent treatment of direct and indirect costs
• Risk-focused audits, looking for waste, fraud, and abuse

I wish them luck.

I’ve got to give a shout-out to Victoria Collins. She exhibited my favorite three best presentation practices:

1. Her slides were bullet points, charts, and pictures, not paragraphs, making them easier and more interesting to read.
2. She did not read her slides, she spoke to them, so we in the audience could follow along but were not distracted by reading ahead of her. We could listen.
3. Most difficult, she repeated questions before she answered them. Her audience was knowledgeable, so the questions were complicated, with a lot of explanation. She pulled the essence out of each question, and repeated it before she answered it. That is really tough to do, because the temptation is always to start formulating your answer as you listen to the question; she had to pay close attention to what the questioner was saying, and figure out how to rephrase it gracefully and accurately -- and then answer it.

Well done, Victoria.

Identifying Grants Fraud an Updated Old-fashioned Way

Recovery.gov has been touting its ability to identify waste and fraud in Recovery Act grants, and other grantmaking efforts are taking note. But the most successful methods are also the old-fashioned ones (albeit updated with technology).

The outgoing head of the Recovery Board, Earl Devaney, says his analysts have searched "massive amounts of data for criminal convictions, lawsuits, tax liens, bankruptcies, risky financial deals and other telltale signs of problems," in their oversight of their grants programs. Yet witnesses and gumshoeing are still the best ways to find ne-er-do-wells.

According to the Recovery.gov website, there were 8,032 reports of waste and abuse in Fiscal 2011, of which almost 1,800 resulted in investigations, and three-quarters of those resulted in actions. Another large group of miscreants and would-be miscreants was found by visiting them electronically at their locations -- and finding parking lots, warehouses, and storefronts standing in for community, retraining, and health centers.

These two discovery techniques are not new. They have been a part of crime fighting since the first detective found the first thief. But they were abeted by technology: many of the reports came in electronically through the website;  mapping software allowed electronic "visits" to applicants' addresses, and cross-database searching let Recovery Board analysts link addresses to multiple applicants and to business names and descriptions.

It's getting harder and harder to be a crook these days.