Tod means Fox

Over at Geeks and Gurus, Steve Bodnar has been blogging about Fox Forward. If you haven’t seen his blog, take a look for some more insight into Fox Forward.

I loved Steve’s session on MapPoint. MapPoint integration might be my first session-to-realworld application: If not for production, for curiosity. (A Fox Trails experiment might be second.) Most of my VFP experience has been with municipal data (parcels, properties, buildings, addresses, etc) and MapPoint offers some interesting possibilities.

Bo showed us how we might embed our own custom EXIF (Exchangeable Image File Format) metadata into JPEG files using GDIPlusX. I’d like to experiment using a JPEG of a house as a portable data file, storing the house’s address as EXIF metadata and then using MapPoint to show me where it is on a map.

I’ll keep you all posted with my progress!

Yesterday was the last day of the conference, and I’m sorry it’s ended. I learned a lot and met a lot of great Fox developers (who are people too, by the way). As the sessions were winding down, many of us hung out outside the conference rooms chatting about all things Fox (and a little about cars). I spoke for a second time today (materials here), and was able to catch a few other sessions. Here are some of my notes:

GDIPlusX library

Bo spoke on the GDIPlusX Library. After a brief overview and some instructions on how to download and get the System object in memory, he took a moment to discuss how system.prg works. What a great piece of architecture. If you haven’t checked out the GDIPlusX Library, you should at least download it and review the system.prg file (and then all the others too). GDIPlusX looks a lot like the .NET implementation on purpose, and works the same too.

Of course, at the moment, my head is spinning on all the other implementations for this type of architecture (Math, IO, etc.).

Now here’s a great tip. Declared DLLs take precedent over function calls. Therefore, if you name your own function the same name as a declared library, your code won’t run — the library’s code will. Bo showed us how he and his team developed a technique to take advantage of this behavior. When you need a dll function, call a VFP function with the same name that DECLAREs the DLL and then calls it (passing in all relevant parameters). Now the DLL function is in memory, and next time you need it, it will use it instead of the function. This means that you only need to declare your DLLs when needed. It also means that CLEAR DLLS ALL commands won’t kill your app if you need a DLL after that call (by the way, this is something I lost sleep over a while ago when some 3rd party function issued this command). Additionally, you now only DECLARE the DLLs when needed. I think Bo mentioned that this technique was first used by Rick Strahl, but on a smaller scale.

Bo also talked about how the GDIPlusX help is coming along. It looks like we’ll have more help for this library than we’ll ever need. Bo and his team are doing an amazing job with it.

A great resource for GDIPlusX, other than the official CodePlex/VFPX site, is Cesar Chalom’s Blog. Cesar has a lot of examples and is very active on the project.

How to OGLE Your Application

Alen Stevens taught us about OGLE: “Optimized, Generic, Layer, Extensions”. The goals of OGLE apps is to be future proof, data source agnostic, location independent, and .NET accessible. OGLE relies on physical n-Tier development techniques, where XML is passed among layers. Using XML in this way helps applications to be future proof. After the session, I talked with Alan about the architecture and he reiterated the importance of using XML to pass data between layers. We’re also reminded that VFP is a state-of-the-art XML parser — faster and more reliable than other available technologies. Therefore, using XML to pass data back and forth is a natural fit for OGLE.

The presentation was a perfect compliment to the whitepaper Alan created. The slides helped shape out the logic in the paper. Now I’ve got my head around it. He walked through lots of code examples, demonstrating the basics of the architecture. I haven’t used com as a middle tier before, so I was glued to this session. I felt that Alan gave a great overview of the process and now I feel like I’m up to speed. He showed us how to set up COMATTRIB attribues, which specifies type library attributes and values for PEMs. This applies to OLEPUBLIC classes only. You can do things like insert descriptions and read-only attributes. These are exposed and can be read by other technologies.

OGLEing apps seem like a smart design move. The separation and isolation of layers in each tier are more dramatic and defined. Although I missed Alan’s test-driven-development (TDD) session, I got the feeling that OGLE is also quite friendly for TDD as well. Whether using FoxUnit (Alan loves this thing) or if you’re just writing stubs to test apps, the architecture makes it simple.

…

I’ll be sure to recap the entire event after my wife and I get out of the Tennessee mountains on Tuesday. I’ll also be at AFUG Tuesday night.

More on FoxForward over at Kevin’s blog: http://cully.biz/. Alan said he might post too, so check out http://netcave.org/.

Day two was a great day. I find that the size of the conference is perfect for the technologies being discussed. A lot of attention is given to the decline of conference sizes over the past 5 or 6 years. This is true for VFP and other conferences as well. But clearly, the number of “heads” do not diminish the worth of the presentations or the work that the speakers have put into them. I like the intimate atmosphere and will be looking forward to attending more conferences like it.

Fox Trails

Brian’s Fox Trails presentation was great. I didn’t know what to expect (even though I had heard of Fox Trails, and knew what it was supposed to do). I’m not a Ruby guy, and I’ve honestly never evaluated the technology. But his Ruby-borrowed techniques for accessing data and functions in FoxPro was eyeopening and insightful.

One of Ruby’s tenets is: “Don’t repeat yourself”. Brian was quickly to repeat himself… and he almost did. A hearty laughter ensued… Another Ruby tenet is “Convention over Configuration”, making applications more “self aware”. Using directory naming conventions, for example, allows you to write code that can assume certain things about its environment. I’ve always been a big advocate of “Reconfigure over Recode”. I should change mine to “Convention over Reconfigure over Recode”!

He introduced us to “MVC Architecture”, which stands for Model (data and access), View (presentation layer), Controller (business logic). This architecture parallels 3-Tier architecture which many VFP developers are used to. Those of you who have evaluated or are using Ruby will get Fox Trails right away. Those of you who do not, should take a moment to have a look.

Some additional information here and here. Check it out!

VFP Service Architecture

I’m really bummed I didn’t think of this before. I’m really bummed that I didn’t hear Stewart’s session 10 years ago. Come to think of it, ‘bummed’ is not really the word.

Stewart showed us how we can use service architecture, stored on the server as a process, to pass various tasks to the server for processing. As he mentioned, there are literally hundreds of services that you can create on the server. He demonstrated the Mailslot Messaging and PDF report generation. This means that you don’t have to rely on user’s workstation settings to send mail. It also means that they don’t need a PDF writer installed to print to PDF! You configure the service on the server, hit the service from VFP, and send mail; or print a PDF using GhostScript; or zip a file; or run some encryption; or send data via FTP; you get the idea. This architecture can dramatically reduce the amount of workstation configuration needed.

Later in the day, Stewart and I sat through Stephen Bodnar’s MapPoint presentation. I think his bulb went off when mine did. We asked Stephen, “could MapPoint be used as a service”? Because of cost and installation issues, it seemed like a perfect fit for service architecture. We’ll need to read the EULA agreement though. Stephen was skeptical. (More on MapPoint in a few sections.)

I also saw some old Fox commands that I don’t think I’ve ever had an occasion to use: “Save To” and “Restore From”. “Save to” allows us to store current variables and arrays to a variable file or memo field and “Restore from” allows us to retrieve variables and variable arrays saved in a variable file or a memo field, placing them into memory (according to the VFP9 documentation). Come to think of it, I’ve probably used them before, but just can’t remember. They seem too useful!

Developing in n-tier fashion

Michael Babcock showed us how to write non-monolithic applications in multiple tiers. He went through the basics of tier development ,from 1-tier up to n-tier and talked about Logical (same process) verses physical n-tier design (when you can’t see through the tiers, like when using a com server or the Internet).

Mike used the phrase “pass the buck” often to remind us that each tier has a job, and that all tasks (business calls, UI, data access, etc) should be handled in the appropriate tier. In other words, object responsibility. This discipline is forward-thinking and allows you to scale and upgrade applications easily. If you have ever wondered what it would take to build a web UI using your business and data access in VFP, n-tier (and perhaps with some Fox Trails) is the way to go. The same holds true for .NET front ends, mobile applications, and the like.

His business object demonstrations were great, showing the group how to correctly use the business object tier. He also went through the proper methods for using the user interface and data tiers of the design. He walked through real-world scenarios of how you might use an Oracle back end verses a CSV file using the same UI and Business Object. Mike was engaging, well prepared, and his presentation was spot on.

Map Your Data

Using MapPoint, automating it, and utilizing it through ActiveX on a VFP form, Stephen Bodnar brought us through the basics of using the tool. MapPoint with VFP is very cool. He talked about his trip back from an Advisor conference in San Diego back to Detroit (they were grounded on 9/11); then showed us the map of their travels (we hear that Whil Hentzen is a speed demon, averaging something like 80mph on the trip back).

The idea with MapPoint is to use maps to show geographic information in a better context. Just like Google and Yahoo.

I’ve been waiting to see this presentation all day because I have about a million and one needs for a solution like this. Whether showing a map of property sales, or inspection routes, this tool can certainly be used in many different contexts. I’ve been preparing myself for diving into GIS applications (probably ESRI’s tool) for this very purpose. Now I can evaluate MapPoint as an alternative, feeling confident that it will work with VFP and that it will give me the routes and maps I need for my apps.

MapPoint has its problems, though. It is not updated frequently, and all address data needs to be exact for the tool to work correctly. You need to spend about $200 per license on every machine that uses MapPoint.

I also learned a new trick. In VFP (starting in VFP7) the Object Browser can be used to create a set of #DEFINE statements which lists all the constants in a type library by using drag and drop from editor window. The only problem with this approach is that VFP truncates decimals if contained in the constant. Rick Strahl’s tool, “Get Constants” circumnavigates this known VFP bug from the object browser. His tool is here.

…

On to day 3, the final day of FoxForward 2007!

I’ve posted my programs and presentation slides for my presentation: “Data Warehousing with VFP” in the Download Section. Please have a look, download the material and get back to me with your questions!

Update

I just fixed a broken link on the Download page and also uploaded three additional zip files:

1. Logical Datamap (LDM) Database
2. Staging Directory Structure
3. Dimensional Model Database

Well, not my Mustang, Hertz’… actually. When the clerk behind the counter asked, “Do you want the Nissan Sentra or the Ford Mus…”, I interrupted: “Give me the Ford! Yup. I want the Mustang”. Not that I have something against a Nissan, but come on… Ok, sorry for the digression.

So far I’ve had the pleasure of meeting Kevin Cully, Dave Bernard, Edward Leafe, Mike Babcock, Garrett Fitzgerald, Bo Durban, and others. Today, I attended track B, seeing two presentations after the meet-and-greet. I didn’t hang out too long after day 1 though, mainly because I needed to go home and write my presentation (just kidding).

Instrumenting VFP

In the first session, Dave Bernard talked about Instrumenting VFP. Like logging application performance, diagnostics, or errors, instrumentation gives you a look into your application. Dave called it “Application visibility”. With it, you can track behaviors, and do a lot of interesting things, like examining mouse clicks (the user swears they didn’t press ‘delete’, but our instrumentation says otherwise); performance bottlenecks (that SQL statement used to run good, what happened?); and even user actions to the point of fine tuning navigation (if users constantly want point D, but are forced through A, B, and C, there might be an opportunity for a shortcut).

Dave talked about how the Coverage Profiler, Error Messages, and Asserts are reactive and not proactive. Instrumentation is proactive. Instrumentation allows you to call your user as soon as they get an error. It allows you to measure function performance over time. Sounds a lot like 80/20 analysis! This technique allows you to refactor code as often as needed throughout the life cycle of a product, without involving the customer.

In my session, I talk about some similar techniques for logging ETL performance in VFP. I didn’t call it instrumentation, in fact, I just called it ‘logging’ for a lack of a better term. Now, I have something to call it! Thanks Dave!

Web Connections 5.x

Stein went though some of the new features that can be seen in Web Connections 5.x. Rick, as expected, has given us some great improvements and new features that will prove to be quite useful for those using WebConnect. I’m not currently a WebConnect user, but wanted to see what all the fuss was about. Bottom line? Rick is a brilliant developer, and his application gets an A+ (in my book).

Stein had a good presentation and was able to get the finer points across to a variety of users (some people in the room were not doing any web development, while others were experienced Web Connect users). Stein showed us some of the WYSIWYG features built into the Visual Studio editor that Rick implemented. We also got to peek at some of the new AJAX functionality. Nice job, Stein, and great framework Rick!

Day one went by pretty quick.

On to day 2! (And back into the Mustang!)

In the book “The 80/20 Principle: The Secret to Success by Achieving More with Less“, author Richard Koch describes how a minority of “causes, inputs, or efforts” will lead to the majority of “results, outputs, or rewards”.

A great demonstration of how the 80/20 Principle (aka Pareto’s Law) works can be seen through examining source code. Clearly, a small minority of code in an application produces the vast majority of business benefit to the user. Usually, this code is well defined, tested, and performs great — after all, it is the core of what the application does. Once in production, this code is low maintenance. Any changes or enhancements are usually well scrutinized and will be tested thoroughly. Your applications are bought based on this core minority of code.

Then there’s the other code.

The other code plays more of a supporting or supplemental role: It’s the code that handles your ultra-cool menu system; It’s that extra group of reports that seldom get run; It’s that cool Calendar control that seemed like a good idea at the time; It’s all the extra features that you’ve tacked on over the years. This vast majority of code contributes least to the business needs of the application, costs you the most money to maintain, and is likely to contain the most bugs.

So what’s a developer to do?

Surely bells and whistles, gold plating, and other extras help sell the product. So I am not an advocate of stripping software down so that it is only functional. Software users expect to have a somewhat enjoyable experience behind the keyboard. Boring, functional applications would look a lot like a dos window and be the subject of many scornful conversations at the water cooler.

Instead, get the most bang for your buck. Identify the 20% and expand it. Identify the 80% and depreciate it. Revisit and repeat at each release cycle. Easier said than done? I’ll give you an example:

80/20 In Action

The volume of user reports in a mature application can get out of hand. I’ve worked on Applications in the past that have had more than 100 user reports. One day I wondered (out loud to my coworkers) which reports were actually being used. No one truly knew the answer, but we all had a hunch that the answer was “not many”. So, I added a secret logging script in my report class that logged report usage to a flat text file stored in the root directory of the application. I stored the report name, the user, and the timestamp. We retrieved the file when dialed in for support services. I found that out of 130 custom reports, only 6 were being used on a regular basis at about 100 installed locations, and a whole 50% of the reports were never run at all over the test period (11 months).

Whoa. Consider now that we spent time regression testing these reports during our latest release, that we regularly trained our users on how to run them, and that they are all included and dutifully updated in our documentation. Bad management? Poor software design? Scope bloat? Or just a perfect demonstration of how the 80/20 Principle works in software development: you decide.

The solution in this example was simple: We stopped supporting the unused reports (we continued to monitor the usage logs) and would not add any new reports without careful consideration. It felt good to trim the fat and in the end, we saved ourselves a considerable amount of work.

80/20 Analysis

During the different release periods of the software life cycle, an 80/20 Analysis should be done to both identify the core minority and the excess majority. Start with actual features (User Reports, Ad hoc Reports, Custom Query Engine, the Internet Backup Utility, Etc.) and then drill down into each feature and look for low hanging fruit. Once identified, monetize its impact on your engineering, quality, and client services teams. Also, place a value (using real sales dollars if available) on the feature itself.

This kind of analysis should reveal some interesting things about the software. If there are gray areas, for example if you are unsure of what is being utilized, consider doing something like I did to track report usage. Coverage profiling engines will allow you to identify seldom run or never run lines of code. These areas might give you clues as to what code will buy your house or pull you under. You can create a simple but professional survey on your website and ask your users what features they find most helpful and which features they don’t use. Not only would this survey tell you what is not being used, but it could also help you identify areas where you can increase the 20%.

For more information on the 80/20 Principle, I invite you to pick up Richard Koch’s book at Amazon. Have a read, and share with me your thoughts!

Buy The 80/20 Principle: The Secret to Success by Achieving More with Less now at Amazon.