8:00 am – 9:00 pm

• Checked on customer stuff. All is going smoothly.
• Had an epiphany about visibility and contracting in general.
  • There are two types of software projects that succeed with the Government. The first is pure COTS. Think Microsoft Excel. The government buys copies and distributes them. It gets used because it’s widely available, and the user base is already familiar with it.
  • The second type is the full custom application. Someone who’s needs are not met by what’s currently available and has access to funds for the development process can have a team put together and have something built. Often this turns out not to be what they need, and the program dies, but enough programs succeed that the pattern persists.
  • VISIBILITY represents a third way. It works right out of the box like a COTS item, but without the large installed user base to support it like Excel has. Rather, it requires that the team that made it continue to work on it. Otherwise, the team disbands and the project dies. In this third way, the  team adds capabilities to VISIBILITY to get it to provide what most customers need, but because it has to be more general, it can’t be exactly the way that that the customer wants.
  • This means that VISIBILITY, although it still costs a significant amount (let’s say 60% of a full development effort), it’s not as emotionally satisfying for the customer as a full custom application. This implies that unless we find a customer that wants VISIBILITY with very minor changes, we’ll never be able to sell the concept.
  • That being said, VISIBILITY can serve two very useful roles. First, it can demo what we can do for a customer. Second, and more importantly, it can serve as a backstop to prevent FGM from being “low-balled” into providing a custom application for less that it can actually be done for
  • The strategy would essentially be as follows. We are contacted by a customer that wants a custom application. We bid 6 engineers for two years. They counter with 3 engineers for a year. We say that we can’t build a custom app like what they want for that kind of contract, but we can take VISIBILITY and extend it so that it can provide the same capabilities as the custom app, albeit in a less emotionally satisfying way.
  • This gives us a good bargaining position. The floor cost of a full development effort can be maintained because we have VISIBILITY providing the roll of the “low-ball” price point. If the customer is truly strapped for cash, then they can accept the VISIBILITY option. If not, then they can get the application that they want.
• Spent about 2 hours working on the space. Got material and paint for the molding
• Went to the Washington Flex User’s Group (http://www.dc-flex.or) meeting with Dong. Very interesting, Andrew Trice was the speaker. The subject was touch interfaces. About 17 people showed up. Most are developing smaller apps, though a few had dabbled with Maven, no one had been driven to it yet.
  • Check out gesture works, particularly their open source licenced version
  • Flash apparantly has a physics engine
  • These guys – http://www.openplug.com/ – have a compiler that turns flex into native code for a variety of devices
  • And most importantly, it looks like Spark is going to be the basis of Flex moving forward. Spark is a way of defining objects (appearance and behavior) independently of business logic, so that the “skin” of an object can be swapped in and out at runtime. This could be a very nice way of organizing our widgets such as the Advanced query widget Skins can be loaded based on the type of data that they see, instead of examining the data and deciding what component to load. Might even be possible to have some kind of dependency injection, since a skin can be specified using a style.
  • Spark is incomplete though. It will have DataGrid and AdvancedDataGrid as of Flex 4.2. Still, we need to get on this bus, I think.

8:00 – 4:00

• Chasing problems with MavenAssist so that I can get to problem with EdgeUtils not knowing about ManagedCan. Never really fixed this, but it works with maven compiling the SWCs and Flashbuilder compiling the SWF. Dong’s version on the Mac seems fine with both. WTF?
• Downloaded and built all of Vis2
• Talked to Mike about the FB4 issues. He has gone back to FB3 for his development. I think that’s OK, as long as we decide when we’re going to use FB4 for a new project.  Introspection appears to be coming along as well, which is cool.
• Helped Tom get MvnAssist working for him. There were lots of new changes from the version he was using, so now that it’s working for him, he’s going to add info to the documentation

7:30 – 3:30

• Checked up on things at the client. No problems, no meetings scheduled as of this morning. Will probably swing by on the way home too.
• Paint! Nope. Too busy.
• Working on Flex3/Flex4 issues. Need to get the <classifier> tag working in MvnAssist. Right now I’m producing
  • “Philm2repositorycomadobeflexsdkdatavisualization_rb3.2.0datavisualization_rb-3.2.0.swc”
• instead of
  • “Philm2repositorycomadobeflexsdkdatavisualization_rb3.2.0datavisualization_rb-3.2.0-en_US.swc”
• Went over servlets with Tom
• More moving