Contribute, look dumb, fear not, repeat.

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.

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?

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.

Well as it turns out brute strength can work, but it breaks a lot of things along the way.  With your objective in hand you can stand triumphantly over the ruins of your development team.  Now, will those now hardened veterans be willing to fight the same way for the next release?

I've been doing software development for close to ten years now and have seen several development, management, and operating styles.  They all met with some measure of success and some measure of failure.  Agile is the new guy in town and he's winning a lot of friends.  Last week I spent three days at Jeffery Palermo's Agile Boot Camp offered by Headspring Systems.  I've actually been part of three teams that made the transition from waterfall to SCRUM (another agile management method).  So I wasn't sure if I was going to learn anything new.  However after talking with Jeffery about the class and hearing how it was run, I thought it would be worth the expense.  Seeing as how I currently do not have a day job, it beats playing WoW all day.

I'm glad I took the class.  A recurring theme began to emerge that I've also noticed in discussions at the Agile Austin and ADNUG (Agile Developers Network Users Group) meetings.  It's all about scale.  My previous experiences with agile development have all been with Enterprise level software.  I can already feel my nose rising as I type the word 'Enterprise.'  Oh it just makes me feel so superior.  What it really means is that Enterprise software probably tends to have a lot more process wrapped around it than something built for a smaller client.  Many of the tools and techniques you will learn in Jerry's class will apply to your projects regardless of scale, but they really shine in an environment where you have a focused customer with a direct need and a small user base (<1000 users).  Jeff's class is about efficiency.  Do exactly what the customer wants with the least amount of effort in a way that is highly sustainable, portable, and automated.  This is what I came to learn!

Being an ex-Microsoft man, I know Microsoft tools and process really well.  And as far as corporations go, Microsoft does a good job of using enough process to reduce chaos, but not so much to prevent work from getting done.  Your mileage may very if you are a Microsoftie.  The company has tens of thousands of employees and many hundred groups, of which I have been a part of about three.  This was my experience there.

That aside, Jeff's agile methodology offered a lot of new approaches that didn't fit in my previous world view which is what I want out of training.  The class isn't workbook based either.  You will develop a dynamic project, have design meetings, argue over how to build it, how to test it, and how to deploy it.  You will learn a cool set of tools that he uses to accomplish these goals.  They're not *the* set to use, but they are a good set that works.   $2350 is a mortgage payment, a new laptop, or a pretty nice vacation.  That being said I will certainly earn more than that out of applying the lessons learned in his class. 

ROI > 1 .. Do