So, it’s official… the COHAA Ghosting Tweetup is on! Come join us in Columbus Ohio Thursday night October 1st. What is the COHAA Ghosting Tweetup you ask?

First, COHAA is the Central Ohio Agile Alliance. (And let me say right now… don’t blame this event on COHAA.) COHAA is a group of IT pros dedicated to promoting agile software development best practices. It’s a great group, and Pillar will be presenting an Agile2009 retrospective on Thursday the 1st at the Grange Insurance Auditorium in German Village at 650 S. Front St. in Columbus. If you are a software developer, application manager or IT exec, and didn’t get to attend Agile2009 in Chicago, join us from 6:15-8:00 for a look back.

Maybe by now you have seen the new “personal space invading” sport called Ghosting. If not, take a look at this video. It’s great fun, and we are going to put the sport to good use after the COHAA Agile2009 retrospective.

A Tweetup is a gathering of Twitter users. So spread the word on Twitter and use reference #ghostingtweetup.

So, at the first annual (and maybe last) COHAA Ghosting Tweetup, the agenda will be:
6:-15-8:00 COHAA Agile2009 Event
8:15-whenever: The 2009 COHAA Ghosting Tweetup!

How can you help:
- First we need to select a location. Somewhere in or near German Village seems logical. Any good bars with ample outdoor seating? Post a comment here and/or on Twitter (with the #ghostingtweetup tag) and make your suggestions for a location.
- Second, spread the word! Pass the word on Twitter by re-tweeting the following:
RT @agilesoftware Time for a little Pillar fun! Ghosting Tweetup:Columbus OH 10/1 http://pillartechnology.com/blog/?p=56 #ghostingtweetup

Looking forward to a little Pillar fun on the 1st! Hope to see you there.

We had a little bit of fun at the Pillar booth at Agile2009 this year. Here is a great video of Declan Whelan demonstrating Paired Juggling for us as well as a practice session with Kent Warman.

http://www.youtube.com/watch?v=3HLrcOl5Z48

http://www.youtube.com/watch?v=x8GhbAHFI5A

I would be surprised if the answer is yes except you are working for Google. For our new project we had a dream. A dream to create a complete testable web based business application for our customer. Now don’t get me wrong, it is possible to test drive standard web apps but it’s hard. We have to have some unit testing tool for JavaScript and then something like Selenium or Watir for the actual integration test. It’s a mess. Now when you take a first look at GWT, it’s like a promise land. You get an integrated development environment to build web application. An environment where your Java code compiles to JavaScript, you get all IDE goodness and above all write unit tests for your GUI code. And it’s been out for few years now. What could go wrong if we try it out for our new project? At least that’s what we thought…

Installation

Most of our developers use Mac book pro as their development environment. Now GWT has some issues running with Java 6 because of 64-bit mode, we had to use Java 5. Now after Snow Leopard update we had to re-install Java 5 just for GWT. This is entirely Apple’s fault but we had this initial hiccup to make up and running for our developers.

Creating Project

This one was really annoying for us. Now in GWT, project could be created in 2 ways, using the command line webappCreator or using eclipse plug-in. We kind of needed both. We needed eclipse because we like to use as our development environment and command line scripts for hooking into our CI builds. If you create project-using eclipse, you cannot use it from command line. Now if you create your project using webappCreator (command line) then it will work from command line but eclipse will not recognize it as GWT project. Come on, this is something really basic. How would a tool like GWT miss something simple like this? But webappCreator does create a .classpath and .project file so that you could import the project to eclipse but that is not good enough. We could have still lived with that but the project that got created had an absolute path dependency specific to the environment. Ok let’s look at this in perspective of a team environment. If you create project and check all the files in your source control, no one else will be able to checkout and run the project as is. They have to go and edit both project and launch configuration files. A big failure for us.

Testing

Being part of an agile team we like to test drive all our design and production code. In fact that was one of the reasons why we choose GWT. To write a unit test we had to use GWTTestCase, which is a wrapper over JUnit. But unfortunately it wraps JUnit 3 not the 4, which is bummer. Every GWT test we created we had to create a launch file at the same time so that we could run it form eclipse and CI box. And did I mention that this launch files will again have an absolute path to the environment it was created. We did tried to use relative path but never worked for us. So again if you are in a team environment how do you scale this? And did I mention that GWT tests ran really slow in hosted mode. A huge failure for us.

Using 3rd path libraries

Could anyone expect a decent size Java project without any 3^rd party library? To our surprise GWT doesn’t allow any 3^rd party jar, it has its own special requirements. First we had to add 3^rd party jars as module and it needs to have source and class files in same location. Now if you want to use apache commons for example you cannot. How many open source projects and tools do you know that follows this special requirement, only very handful of them? I do understand why this requirement is there but at the same time not having access to helpful libraries could slow your team velocity and throughput. Another failure for us.

So what happened next?

Within the second week of the project we scraped GWT and decided to go back to html/JavaScript. Even though we are facing the same testability challenges but our productivity went up. I am sure there are possible workarounds for all the problems I am mentioned up here. And I would like to hear them but if barrier of entry into GWT world is so high, I don’t see anyone using GWT in decent size project.

Join John Huston this Friday at 1:00pm Eastern / 10:00am Pacific for “Test Driving Everything – The new and improved Role of QA on an Agile”. https://www2.gotomeeting.com/register/612196746

One of the ways to help ensure that your iPhone application is friendly to users is alerting them to the possibility that they have no active network connection before your app does something that, well, needs a network connection. In fact, Apple recommends doing this to increase your chances of your app meeting their approval.

The SystemConfiguration framework provides a class called Reachability that provides a number of methods to make this job easier. Apple also provides sample code that shows how to use this class effectively. The following shows an easy way to register your application delegate as an observer of changes that are relevant to network connectivity, as provided through the Reachability API.

After you’ve added SystemConfiguration.framework to your project (it’s located in /Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS3.0.sdk/System/Library/Frameworks), you’ll want to add Reachability.h and Reachability.m to your project. These can be obtained through Apple’s Reachability sample application.

In your UIApplicationDelegate header file, define two properties like this:

Reachability *internetReach;
Reachability *wifiReach;

....
@property (nonatomic, retain) Reachability *internetReach;
@property (nonatomic, retain) Reachability *wifiReach;

Then, in the UIApplicationDelegate implementation’s applicationDidFinishLaunching: method, add the following
[[NSNotificationCenter defaultCenter]
addObserver:self
selector:@selector(reachabilityChanged:)
name:kReachabilityChangedNotificationobject:nil];
[self setInternetReach:[Reachability reachabilityForInternetConnection]];
// ***** insert call to app singleton here, if desired *****
[internetReach startNotifer];
[self setWifiReach:[Reachability reachabilityForLocalWiFi]];
// ***** insert call to app singleton here, if desired *****
[wifiReach startNotifer];

Also add a method as specified as the selector for the observer:

- (void) reachabilityChanged: (NSNotification* )notification{
Reachability* reachNote = [notification object];
if (reachNote == internetReach) {
// ***** insert call to app singleton here ******
// this may look something like [AppSingleton getInstance].internetReachabilityStatus = [reachNote currentReachabilityStatus];
}else if (reachNote = wifiReach) {
// ***** insert call to app singleton here ******
// this may look something like [AppSingleton getInstance].wifiReachabilityStatus = [reachNote currentReachabilityStatus];
}}

There are 3 comments above which specify that you can/should add a call to a method that updates an app singleton. This allows you to easily access network state at whatever point is necessary in your location.

After you have an app singleton set up (see discussion here), then you can take advantage of categories to easily access this information in your various controllers. We have added a method in a UIViewController category to show an alert if the Reachability properties in our app singleton reveal there to be a network connectivity problem. This provides an easy way to alert the user to what could be a frustrating error.

Special thanks to Patrick McMichael with the code listed above.

Join author Daryl Kulak at the Central Ohio Quality Assurance Association meeting this Thursday evening for Agile in the Bloodstream

Join COQAA for a “sneak peak” at the new book “Agile in the Bloodstream”. Author Daryl Kulak will highlight the topics of his book with a special focus on Agile testing. Come discuss how we can become less mechanical in our Agile implementations, and how to tap into the creative reserves of everyone on the team.

About the author Daryl Kulak is an Agile author, speaker and coach with Pillar Technology. He is the co-author of “Agile in the Bloodstream: Creating Change-Ready Teams using the Power of Systems Thinking”, which will be published in the spring of 2010. The book outlines how the key to Agile success, including scalability and sustainability, depends more on how a team grows its people than in the “best practices” it executes.

Location:
Information Control Corporation (ICC)
2500 Corporate Exchange Drive Suite 310
Columbus, OH 43231

Date/Time:
Thursday September 17, 2009
6:30-8:30 PM

Click here for more information and to register

Being the business analyst on an agile team is a little like standing up in a canoe. It’s more about anticipation and balance than control, as I had the opportunity to learn on a recent project.

The project team was responsible for delivering data from back-end systems to a mobile device. The team had two groups, one to develop the web services that provided data to the device, and the other to develop the device code itself. The two groups were located in the same building but not in the same room, so communication between them could break down. I saw that I would have opportunities to help them work together.

For example, I knew I needed to create an interface document describing the web services that the device would consume. I reviewed the device screen mockups and the website the device was supposed to imitate, and I talked with the developers working on the web services. Based on these I wrote an interface definition that I expected to be close to 100% accurate.

After I completed the document, two things happened. First, the two groups kept on doing what they had been doing, writing services and setting up to write code for the device. The services developers were presumably building the services in accordance with the document, and the device developers were not ready to consume them yet.

Second, as soon as the services people started building the services they discovered several places where they said they could not, or should not, implement them the way the interface document stated. I listened, and in most cases I followed their advice. It was early in the project and they knew their systems better than I did. I updated the interface document and took comfort from the fact that the changes had not cost the device developers any time.

If I had been on top of my game, I would have worked with the service developers to define Fitnesse integration tests, and the device developers would not have tried to consume the services until they passed the tests. Sad to say, I was just learning Fitnesse and still catching up on writing tests when the device developers began to consume the services.

Without supporting tests, it’s no surprise the device developers found problems. There were cases where data was populated in the wrong place or not at all. At this point I could have mediated between the two groups. That’s what I had done in creating the interface document. However, I did not do it this time. The device developers had immediate questions that only the service developers could answer. The easiest way to get answers was for the developers to talk together and for me to stay out of their way. I listened to their conversation, and by the end they knew how to integrate. I also learned what I would need to test.

You might ask, what was the value of writing the document at all if the developers wound up talking with each other and changing it anyway? The value was this.

• The exercise of writing the document got the service developers talking to members of the team other than themselves (i.e., me), helped them think through the services before writing them, and gave them a detailed target to shoot for.

• Automated tests could be created from the document to validate the services as they became available.

• When the developers could not do what they thought they were going to do, they sought to make the problem visible: “We can’t do it like the document says.”

• Even though there were a few problems, the services were still 80% correct the first time without need to take time from the device developers. When the problems were discovered they were small and resolved quickly.

Taken in perspective, it was a successful bit of BA work. All I had to do was anticipate a need, stay balanced when not everything went according to plan, and remember that the purpose of the document was not the document itself. It was the collaboration it created between the developers.