Cool CommandBars Library

Andrew Ross MacNeill recently reviewed Alex Grigorjev's CommandBars Library product for VFP, in a FoxPro Advisor article.  It looks very cool, and Andrew has a short "screencast" on his blog, where he demonstrates how to implement a simple CommandBars control in VFP -- much better than just reading about it.

Andrew Ross MacNeill's blog

Andrew Ross MacNeill's CommandBars screencast

Alex Grigorjev's website

Why Blog?

Why Blog? From a business perspective blogs are no different from marketing channels like video, print, audio or presentations. They all deliver results of varying kind. The kind you can expect from blogs is mainly about stronger relations with target groups important to you. Below are a few blogging advantages we hope to benefit from.

Customer Relationships
In a forum where your main objective is not to directly sell, you'll have a more personal relationship between you and your customers. Blogs are a fast way to engage customers' discussions, provide tips and insights or receive feedback.

Media Relations
It's every PR-consultants dream to create a channel where media regularly check what you have to say, instead of media just being passive - sometimes indifferent - recipients of press releases.

Recruiting
If you establish your company as a thought leader, people in your business will pay attention. They'll read and discuss what you have to say. Chances are good they will see you as an attractive employer.

Testing Ideas or Concepts
A blog is informal. It's part of a conversation where people (often) can comment, and the blog can provide you with a measure of value. Publish an idea and see if it generates interest. Does anyone link to you? What do they say?

Search Engine Optimization
Google and other search engines reward sites that are updated often, that link to other sites and most importantly, that has many inbound links. Start a blog at your regular site and your ranking will receive a boost.

Blog Entries
Don't be as concerned with the length or style of your entry. Keep the focus on sharing your thoughts and opinions on a particular subject. That's what readers are most interested in.

Visual FoxPro: Where Does the Roadmap Lead?

I'm on the road between VFP conferences at the moment, having just left Advisor DevCon in Las Vegas, and headed next for the DevTeach conference in Montreal.  The major buzz at DevCon centered around the keynote, where Ken Levy reviewed the official VFP Roadmap that Microsoft posted on June 1.

Ken didn't really elaborate, because the roadmap is intentionally vague, giving the Fox team a lot of leeway in what will be included in Sedna.  Nothing has been ruled out, including the possibility that Sedna could evolve into VFP 10.  That possibility is quite remote, especially in view of the fact that it costs a lot more marketing dollars to do the branding, packaging, and everything else that goes into a new full version.  While I don't remember it being said directly anywhere, a VFP 10 version might logically extend the support window for VFP, which is currently through 2014.

If the Sedna effort simply consists of downloadable add-ons to VFP 9.0, VFP developers will get more new features than if the development budget was cut by the amount it would take to create a full-blown new version. 

In the meantime, the official roadmap allows Microsoft to keep all their options open.  After all, the Sedna effort is directly related to Microsoft technologies like Whidbey, Yukon, Indigo, Avalon, and Orcas, none of which will be released anytime soon, and some of which are quite a ways off.  No one knows how those products will finally be implemented, so there's no way to tell right now what Sedna will include for VFP compatibility and leverage.

What's the bottom line?  While I can't possibly predict what will happen to VFP over the next couple of years, a few things are evident:

1. VFP is not dead yet.  Heck, even FoxPro 2.6 isn't dead – you undoubtedly either know of 2.6 apps that are still running and being maintained or are working on one of them so yourself.
2. The core VFP product is not going to be enhanced (see the roadmap) to add more features.
3. The bulk of the Sedna effort is to ensure that our apps that run in VFP 9.0 will continue to run into the Longhorn era, and that they can be as .NET-"compatible" as is reasonably possible.
4. VFP is not a strategic tool in the Microsoft suite of software.  Does that surprise you?  It shouldn't, given what Microsoft has been saying ever since .NET was announced.  As I read in an online magazine article last week, '...Microsoft has spent more money developing and marketing on .NET than NASA did to put a man on the moon...'  It makes no difference that VFP is the awesome tool that no one else cares much about.
5. VFP developers love their VFP, and the VFP community is as passionate as ever

I think it's important to keep in mind that Microsoft is not compelled to keep the Fox team working on VFP at all.  There was some speculation after the release of VFP 8 that is would be the last release.  After all, it was, in my opinion, the single most feature-laden release since VFP 3.  I remember Ken Levy asking folks at conferences after VFP 8 was released, "What more can we possibly do with the VFP core product?"  VFP 9 is a killer product that answers that question well.  The fact that the Fox team is committed to work on "whatever comes next" over the next 2 years is by far the best news a die-hard VFP developer could hope for.  At a minimum, the roadmap ensures that the VFP apps that you and I are developing right now will continue to run on the Microsoft platform for many, many years to come.

The Cost of Automated Testing

Testing of software ranges from no testing to a full Software Quality Assurance (SQA) group. There are costs associated with each method along that spectrum that are employed.

The cost of not testing can be as extreme as incorrect calculations, lost data or lost revenue. Users are not usually trained in software testing so they are inefficient at determining and reporting issues. Assuming that no actual harm is being done by running the untested software, the best that happens is unproductive users as they struggle to do their jobs.

Automated testing such as unit testing and acceptance testing adds cost and time to the development cycle. Thorough manual testing has a similar effect. For these reasons it is tempting to eliminate testing to “save money”. Sometimes the testing is done in an ad hoc manner, randomly poking around in the application.

At the end of the spectrum with no testing, the costs are almost totally hidden in the overhead of daily business operation. Of course if orders are lost or prices are calculated wrong or some other very noticeable issue arises then the costs might become clearer. All software will be tested. Some applications will be tested by a test plan and others will be tested by trial and error.

Managing the costs up front where they are more visible is easier than waiting for them to appear later. Is it really cheaper to eliminate testing from the development cycle?