Contribute, look dumb, fear not, repeat.

Got this off the Drudge Report this morning.  It's more writing on the wall, but it sets the context very well for what is coming.  There's no need to fight it, so we'd better get used to embracing China as the world's next super power.  Let's just hope it's a peaceful transition.  Their rise is affecting manufacturing job markets the most right now.  Software and IT services still hold an edge in experience because kids getting out of Chinese universities just haven't shipped software yet.  This will change though.  Right now most companies have a hard time getting the value out of overseas development houses that cost less.  I suspect the US and Silicon Valley have maybe 15 to 20 years before anyone working in those markets can be easily outsourced to very reliable, highly experienced developers in China or India.  So save up now, and start looking for property in less expensive regions where your VISA is valid, and the money you save now will go further, as income pressure for American IT workers will force real wages lower.

Today I had the opportunity to practice some more test driven development with a resident expert in the field, Scott Bellware.  Scott is a really excited and engaging guy to be around.  He's really taken on Domain Driven Design, he believes in it, and he can teach it like you would teach someone to tie their shoes.  It's simply second nature for him.  I consider myself a relatively accomplish IT professional.  I know my way around all flavors of C code, object oriented design, and implementation.  Typically I come from the school of thought that you plan what you are going to build before building it.  Write it all down, figure out the hard problems, chop them into smaller, more manageable ones.  Show your solution to someone else, let them tear it up, and before you start writing any code you have a pretty good idea of how version 1.0 of what you are creating will look like.  Now this is an abbreviated summary of development, but that being said you can push it into waterfall with milestones, or agile with a backlog and sprints. 

Milestones and sprints are both organizational process.  They have very little to do with actual development.  Domain Driven Design is the bible for this style of development, and we got to experience a little piece of it implementing just a few straightforward rules in part of a hypothetical system.  I have not read the book, although it is now on the top of my list. 

The paradigm as experienced in an afternoon is code to the test, and isolate your functionality into 'domains.'  Coding to the test is essentially writing your tests first, simple ones.  Write a test, then write the code to get just that test to work.  As you make more tests work, you add more functionality without adding anything extra.  It goes against my grain because you see extensibilities and optimizations you want to make for future expansion or features you 'know' are coming simply because you've seen them done that way so many times before.  This is a lot like taking your past out of your coding future, and only writing what is necessary even if it feels incomplete.  If you come to a new feature, write it down, present it to the client, or whoever is writing the check before writing something no one may want.

The domain side of the coin revolves around setting rules for what to and not to write for given domains.  At the core of this is interoperability.  Make no piece of code dependent upon another.  If you add an include or a using, that is all it should take.  Everyone who has written software has gone through a project where they tried to get one little API or feature to work which required just one include.  That one begat another, which begat another, and another until you've written a state machine for Judges in the Old Testament.  Adhering to strict domains eliminates this.

Now I am not about to call myself an expert on DDD, but I did like what I saw.  For the purposes of our example, it worked very well and I can envision it to work well for large projects.  One thing is for sure, I will definitely be giving this new approach a few more cycles.  I'll just need the discipline to stick to it and not jump into coding before testing which is oh so tempting.

Last week I was in Seattle and Portland to visit friends, family, and business associates. The weekend turned out to be a marathon of meetings and traveling which produced a lot of results. Part of the trip was talking to potential employers in the area where I could work remotely from Texas.

My good friend Jason Herre has recently come under the employment of Microsoft working on a new team at Microsoft called 'Velocity.' He's been there for just a few months, and extols the virtues of the group and what they do regularly. Like many groups in Microsoft, they are expanding and therefore hiring. Jason felt I may be a fit for one of their heads, so I spent some time with their group on Friday finding out what they do.

Essentially they encourage and inspire OEM partners to make their machines faster and reduce the impact of their native software. When you first buy a new computer, that is as fast as it will ever be. Past day one, your machine gets slower and slower until you reformat and reinstall it. It's a terrible solution to hear from your tech savvy relative or support person, "Oh, you should just reinstall." The Velocity team tackles this with a very cool tool called Xperf. It's a diagnostic tool that hooks up to Microsoft's remote symbol server and analyzes everything that is using up system resources on your computer over a given period of time.

This might sound mundane, but there are key periods of computer use which infuriate consumers and myself alike. They are,

Startup; "I'm going to go get a cup of coffee or waste some time for a few minutes because I know that even though I can see the desktop, it's not going to respond to my inputs until the disk IO light goes off who knows how many minutes later."

Shutdown: "I swear I'm headed out the door as soon as this computer turns off. Get your keys. Where's my wallet? Do I have my phone? Do you have the directions to where we're going? Why hasn't this thing turned off yet?"

Sleep/Hibernate: "Why do you carry your laptop around open? Oh, it never really shuts off when I close the lid. It just heats up my bag and wastes battery. If I closed it, by the time I got to the meeting room, it would take longer to come out of sleep than if I just hard cycled the power."

Anyone who has used a laptop in a business environment has likely run into one or all of the above. Xperf shows the exact process, the exact driver responsible for taking up CPU, Disk IO, network, and a myriad of other resources. The tools is not discriminatory either. It points the finger at OEM software as well as Microsoft processes. It's the UV light at the crime scene that is your start up experience.

Looking at just one example OEM machine, I could easily tell symptoms like waiting for a network response, or waiting to detect a piece of hardware that isn't connected, or a piece of start up software that uses a lot of disk. In many cases there are layers of offenses that if addressed can shave 15-30 seconds from each of the above scenarios.  The best part is you can download the tools for free to find out where your machine is slow.

Eureka!  Well it's not that much of a victory, but on a new platform, and one with a super shiny screen it's fun to see your code work.  So far developing for the iPhone is remarkably easy.  There are lots of framework objects and samples to get you started with simple applications.  The first thing I wanted to do was use the screen to interpret finger swipes.  You would think this would be built in, and according to the documentation, it is.  However I couldn't get it to work in the emulator.  Here is the sample code Apple provided to intercept swipes.

// Handles the continuation of a touch.

- (void)touchesMoved:(NSSet *)touches withEvent:(UIEvent *)event

{  

    // Enumerates through all touch objects

    for (UITouch *touch in touches){

        if (touch.info & UITouchInfoSwipedDown) {

            touchInfoText.text = @"Swipe down";

        } else if (touch.info & UITouchInfoSwipedUp) {

            touchInfoText.text = @"Swipe up";

        } else if (touch.info & UITouchInfoSwipedRight) {

            touchInfoText.text = @"Swipe right";

        } else if (touch.info & UITouchInfoSwipedLeft) {

            touchInfoText.text = @"Swipe left";

        } 

        // Send to the dispatch method, which will make sure the appropriate subview is acted upon

        [self dispatchTouchEvent:[touch view] toPosition:[touch locationInView:self]];

    }

}

touchesMoved is a call back that gets executed while your finger is still moving across the screen.  Checking the .info member variable against an enumerated bit mask should do the trick.  In my simulator I could never get these events to fire while dragging across the screen, so I rolled my own.  It's pretty straight forward, but it works and I get all of the expected outputs on my cool little app.

#pragma mark -

#pragma mark === Touch handling  ===

#pragma mark

- (void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event

{

    _labelDirection.text = @"";

    // Save the position

    for (UITouch *touch in touches) {

        // Send to the dispatch method, which will make sure the appropriate subview is acted upon

        [self dispatchFirstTouchAtPoint:[touch locationInView:self] forEvent:nil];

    }

}

// Saves the first position for reference when the user lets go.

-(void) dispatchFirstTouchAtPoint:(CGPoint)touchPoint forEvent:(UIEvent *)event

{

    _myTouchPoint = touchPoint;

}

// Handles the continuation of a touch.

- (void)touchesEnded:(NSSet *)touches withEvent:(UIEvent *)event

{  

    for (UITouch *touch in touches) {

        // Send to the dispatch method, which will make sure the appropriate subview is acted upon

        [self dispatchTouchEndEvent:[touch view] toPosition:[touch locationInView:self]];

    }

}

#define MIN_SWIPE_DISTANCE 10

// Diffs the start and end points of the swipe to determine direction

-(void) dispatchTouchEndEvent:(UIView *)theView toPosition:(CGPoint)position

{   

    CGFloat xDelta = position.x - _myTouchPoint.x;

    CGFloat yDelta = position.y - _myTouchPoint.y;

    // We only want to see large strokes

    if(abs(xDelta) > MIN_SWIPE_DISTANCE || abs(yDelta) > MIN_SWIPE_DISTANCE)

    {

        // See which way the stroke went

        if(abs(xDelta) > abs(yDelta)) {

            if(xDelta > 0) {

                _labelDirection.text = @"Right";

            }

            else {

                _labelDirection.text = @"Left";        

            }

        }

        else

        {

            if(yDelta > 0) {

                _labelDirection.text = @"Down";

            }

            else {

                _labelDirection.text = @"Up";

            }

        }

    }

    // Short distances are considered clicks

    else

    {

        _labelDirection.text = @"Click";    

    }

}

touchesBegan and touchesEnded are also call backs that get executed when you think they would, when your finger touches and then leaves the screen.  I use a little subtraction and the magic of absolute value to determine the drag direction.  Small drags are considered clicks.  Now I'm ready to plug any code into my directions.  This doesn't use the delta or the accelerometer that are available, but for my purposes I just need a direction at this point.

• What do you expect to be the user’s motivation for using the application?
• What do you intend to be the user’s experience while using the application?
• What is the goal or focus of your application?
• How does your application organize and display the information people care about? Is there a natural organization associated with the main task of the application?

I am an avid reader of Foreign Policy, and there is an awakening article in the March|April issue titled Iraq's 100 - Year Mortgage.  Healthcare is the leading category on our checks in the United States for a lot of reasons which I won't go into here.  It's no surprise that heath care costs for Veterans are a contributing portion of that pie.  Currently the US spends approximately $280 Billion per year funding the Iraq war.  I'm not here to judge whether that expense is justified or not.  There are good reasons on both sides of the argument for that expense.  The long term cost however goes unnoticed by most I believe.

According to Linda J. Bilmes research, medical technology has allowed the wounded to killed (US troops only) in Iraq to achieve a 7:1 ratio, up from 2:1 in WWII, and 2.6 in Vietnam.  More surviving troops is a great thing.  The cost associated with their long term medical care is something that is not often considered.  The medical costs for the 1991 invasion in terms of all the care that veterans of that war will expend is sighted as five times more than the cost of moving the gear, pulling the triggers, and moving it back.  Iraq, like most American military actions after WWII will end for lack of money.  Congress will run out of patience and money eventually.  As soon as there is a politician giving America a choice between war and lower healthcare costs, and those affected by such healthcare outnumber those that don't, that candidate will win.  It may already be happening now.  November will tell.

Regan era economists after the cold war came to the conclusion that 'deficits don't matter.'  As a means to an end of the Cold War, maybe they didn't.  However we are going to be in for a deficit that's even worse than the one Regan created.  So maybe they don't matter up to a point that we haven't reached yet.  I do not know what that point is.  Ultimately the US will get the rest of the world, well actually nations that lend money to the US, to pay for the Iraq war for us.  This is some consolation for the credit bill that is due to our future.  Seeing has how the Federal Reserve has been lowering rates to ease panic on Wall Street, it has chosen one of two poor routes to travel.  In this case it has chosen inflation over slowing economic growth, even though we may end up with both.  Inflation will continue to weaken the dollar and the US will pay back it's debts over the coming decades, but at a nice discount since the dollars it will pay them back in are up to 50% weaker than the ones it borrowed;  thank you China!  I used to argue that the Fed should suck it up and stick or even raise rates to save the dollar and hold inflation at bay as an amateur economist.  If this were one big game of Civilization IV, I'd do what they are doing now.  It's national self interest, everyone is doing it.

You may be asking yourself, why would anyone be going from a Mac back to a PC.  I mean that's going back into the big market share.  Maybe it's for the artists who gave up, but not many are doing it.  I could not find a tool that would import an Entourage .rge file into Microsoft Outlook 2007.  I found some tools to read .rge files on a mac.  Oh and you can transfer your contacts via a tab delimited text file.  What about e-mail?  Oh you can copy it to the file system and loose all you formatting.  I guess this just goes to show that the market for users converting their e-mail from Entourage to Outlook is small which means Macs must be catching up.  Or it means that no one uses Entourage, which seems more likely since Macs are so yahoo and gmail friendly.

Why am I moving machines around anyway?  Well I'm going to embark on some XCode programming.  I've never written anything for the Mac before, but it's shiny brushed aluminum surface calls to me.  And in actuality, I really just want to make an iPhone app.  The AppStore Mr. Jobs is talking about launching just sounds so simple, so elegant, so mac.  It opens in June which is plenty of time to put together a workable app.