ProSysPlus Blog

Specs: the Short way

2007-06-16T12:06:00.000-04:00

When I was writing my FORTH editor (a rite-de-passage for FORTH programmers) I decided against extending the editor so it could hold words longer than the 40-character by 25-line surface of the Commodore 64 screen. It would have been trivial enough to do, and I decided that what I liked most about FORTH, the immediate testability (because each FORTH word gets its data from the stack, which is immediately accessible from the command prompt) of each FORTH word, was enhanced by being able to see all of the FORTH "word" at once. Scrolling or paging was a good feature for those blessed with wonderful memories, and knowing my limitations ("a man has to know his limitations"), I decided against that feature.

I have the same perspective on specifications: each specification should be visible on one screen, without scrolling. From a content perspective, I like specifications to have 3 parts: the Problem/Challenge being address; a description of the Solution (this is the actually specification); and a set of Tests which will determine whether the Solution has been implemented. Notice there is nothing about implementation in the specification (although I will leave technical notes in there, as idea-starters, very subject to change at implementation). Below is a spec I wrote recently. What about large challenges? Think a Tree structure, with nested specs.

***************

Problem: we have to babysit the updates because if it craps out, it is not restoring and letting us know.

Solution: make the update restore everything to where it was, and let us know, if it craps out.
Elements of the solution:

Collection and notification of warnings and errors, by email, or if that fails, notifying the user to notify support.
Seamless rollback after errors: think "crash"
Lots of messaging during the updates, informing and entertaining the user.
Remove all worrisome messaging to the user

Testing:

Warnings will be emailed.
Errors will be emailed; if unable, will ask user to contact support.
After errors, system will rollback to prior state.
After a crash, next usage will rollback to prior state.
The user will see message changes or other visual stuff happening at least every 5 seconds. (This will be the last feature to be implemented, although it is an absolutely essential part of making the automatic update work with users.)
-- we should ship the fun stuff to be shown with the update, to keep it fresh.

Implementation Notes

Control attempts through main.ini, [UPDATER] section, with keys for LastVersionAttempted, LastTimeAttempted (timestamp), CurrentVersion, CurrentVersionInstalled (timestamp), LastInstallReport (timestamp)

Specs: Good, Good

2007-06-16T11:14:00.000-04:00

I've been reading Joel on Software, a collection based on the blog of Joel Spolsky. Mark, my colleague and boss at Dataworks (Matty's graphics are pretty cool, eh?), following up a link to Joel's blog, thought the book was good enough to get copies for Jeff ("gamer") Ference and myself.

Of course I only give links to Mark that agree with what I think <g>, so to some extent it's like reading myself, except much more entertainingly written. And there is some stuff I didn't know, e.g., the role of program managers at Microsoft (Joel was the program manager for what become VBA for Excel, when he was at MS).

It turns out that Program Managers write the specifications; but have no control, other than persuasion, over implementation. It sounds haphazard, but it also puts the responsibility right on the programmer, rather than leaving it sitting somewhere between the worker bee and the manager bee, where it would surely languish from inattention. It also puts a big emphasis on the specification, since the programmers aren't creating the feature list on the fly. Joel describes a specification that ran 500 pages. Ouch.

It's not that I haven't been in favor of specifications. My ideal has been, and is, that software should be specified as to functionality in such a way that a tester can determine whether it works correctly. This was before TDD (Test Driven Development) was an acronym, fwiw (at my age, at lot of stuff was so before it was an acronym <s>). My next entry on this blog will show you how I like to write specs.

Range of Convenience

2007-05-22T10:31:00.000-04:00

There's somewhat of a brouhaha running in the .Net world regarding the amount of complexity required in frameworks: http://weblogs.asp.net/bsimser/archive/2007/05/22/reusability-vs-ryo.aspx. One side says "keep it simple," the other side says, "make it complete."

The simple side will win; but the complex side will be able to prove it is theoretically correct, and so will delay the simple side winning. Theory wins in the short run, because lacking data we really like pretty ideas; reality wins in the end.

What this is really about, is Range of Convenience, but let me fill in the background for you.

A few years ago, I was emailing with a well-known developer, letting him know that his product really needed a GUI. He didn't see much need: he could do what he needed from the command line, more quickly than he could from a GUI. I pointed out to him that most developers do not have encyclopedic memories: they may have other qualities that make them terrific business software developers (such as the ability to imagine the cognitive experience of customers who don't have encyclopedic memories), but they do not resemble, in their pattern of cognitive strengths and weaknesses, him or his peers.

This developer, like the proponents of complexity pointed to in the blog link above, highlights the difference among people in what one cognitive theorist called "range of convenience," which has grown to mean the ways of thinking that are most comfortable, and most effective, for a given person. This mismatch in range of convenience has been a constant issue in .Net development: the growth of dynamic languages in .Net is proof, in a way that counts more than theory, that the original focus of .Net was off the mark for most business software developers. *

So neither way (the comprehensive, cover-all-your-bases way, vs. the focus-on-what's-needed) is wrong; each has a different range of convenience. And each is likely to appeal to a different segment of the software development population. Given the history (or at least the last 20 years of same) of business software development, from the rise of xBase in the mid-80's to the resurrection of dynamic languages within .Net against all odds, my guess is that tightly-focused approaches will find greater favor within low-budget business software development efforts, and theoretically-based approaches embracing comprehensive complexity will find favor with high-budget, management-by-committee software development efforts.

Oh, and that many of the high-budget projects will fail, and most of the low-budget projects will succeed.

_______

* Just one little example: in Visual FoxPro, if I want to response to a Lostfocus (onBlur) event, I write no lines of code: just stick in my code for what I want to happen. In .Net, I have to jump through hoops declaring a handler, hooking a method to a handler, removing the handler when I'm done, etc. I'm sure I am missing some wonderful functionality in doing it the VFP way; but I haven't missed it yet. :)

Why Silverlight Will Win

2007-05-04T10:02:00.000-04:00

Jesse Ezell's blog on Silverlight vs. Flash is compelling for one reason: Jesse has the down-and-dirty experience working with Flash that tells the real story. Those of us who worked with Flash as a development environment from back in the FireFly days (now grown into Flex) have wondered why it never grew in the ways it needed to: where are the 3rd-party data widgets that would give us the data-ui capabilities we need? The answer turns out to be in the poorly-implemented underpinnings of Flash itself. It isn't going to get better, is what Jesse demonstrates. And Silverlight (WPF/e) gets it right.

VFP to .Net RoadMap Updated Yet Again!

2007-01-31T15:57:00.000-05:00

We have decided to simplify our transition to .Net. No more baby-step by including a COM object for data access, just straight-ahead into the fray.

It remains to be seen how eliminating the baby-steps will affect the time schedule: our preliminary evaluation is that using the Strataframe tools will allow us to stick pretty much to a release date as projected (July), but most likely as a release that doesn't have all the libraries changes and helper routines that we would like to have available.

Other than getting there faster, we had the concern that ProMatrix might take objection to a COM object built on their framework being used to power an integration with another framework. Although one could argue (and there's a lot of evidence to support the contention) that a VFP framework and a .Net framework are not competing products, our history of good relations with ProMatrix make it worth going the extra step. VPM is still a great product, and we plan to be using it for 2 to 3 more years (Visual Studio 2007 will actually make it possible to switch to .Net and not lose more than about 15% efficiency from VFP, by my estimate).

Why Vista Counts

2007-01-30T23:32:00.000-05:00

I did get something out of the powerpoint-dominated <gasp!> developers session at the Vista Launch in Louisville, today: Vista will make a difference in the quality of user experience, if we change our ways of thinking about user interface. The ability to design interfaces that are, uh, Mac-like <s>, will make a huge difference, in a way that the Mac cannot (because it cannot reach most of the users).

All the hype aside, the difference is in the vector-drawing engine that allows us as developers, and the visual designers we have yet to hire, to create intuitive, appliance interfaces. Imagine a stack of open forms, on the desktop, turned sideways about 45-degrees, so you could pick the one you want by observing what is actually on the form as it is in that rotated position. Imagine a 1-to-many form, with grids at the bottom, where the part with the child grids folds up 45-degrees to yield screen real estate, but could still be edited in the folded up state. Imagine...

All the rest is pretty much old news. Well, metadata attached to documents, and background versioning of documents is also very cool, although both have been available in Linux for a while now. And the messaging stuff is pretty old hat, the ease of the solutions is overhyped (devil in the details, etc.), and easier solutions exist for most situations.

But the UI stuff is incredibly significant, not for now (when most machines won't be able to run it), but for the future. It will take time for us, who are in the graphic design dark ages, to adjust. So, time to check whether your video card can support Vista. Finally we get to do what Cooper et al. have been telling us for over a decade and still reach the vast majority of users. Now if only I could color within the lines...

VFP to .Net Roadmap Update

2006-11-28T15:10:00.000-05:00

Due to a variety of factors (illness, marriage, moving two households and one office, 6 cats, a dog, etc. 1200 miles to a new home, not all of the above to the same person) Frank and I have missed our projection for delivery of xCase2VPM V2. However, Frank arrives on Dec. 15, and his throat will be within reach of my hands for 24 full days, so we plan to make up some ground. <s>

Other than dates, the only big change is that we will be initially producing our product with, and providing support for, Strataframe (www.strataframe.net). It now supports the Infragistics controls we will be using and supporting. We still plan to support MM.Net (www.oakleafsd.com), in the cause of enhancing motivation through competition.

To reiterate our Roadmap:

Phase 1: xCase2VPM for VPME9.1

Full MetaData interface, written in .Net. xCase will be used for defining data, not metadata.
PSP Data Dictionary: the PSP DD will be used as the target of calls from VPME9.1. This will allow portability to the other two phases.
Libraries will be included in a subscription price that anyone can afford (more details to come).
VPME9 applications will run out-of-the-box due to some shenanigans in the libraries; convert your existing apps as needed.
Projected release: well, Frank goes back Jan. 9.

Phase 2: PSP4.NET V1

Same MetaData interface as in Phase 1.
Uses same PSP DD as in Phase 1.
Uses Strataframe and Infragistics controls for UI building.
Data hits a VPME9.1 COM object.
V1.1: View design in the PSP MetaData designer.

Phase 3: PSP4.Net V2

Full .Net application
Carry over PSP DD, rewriting code snippets in IronPython.
V2.1: MM.Net support

RTFHF: Read The Fabulous Help File

2006-10-18T14:13:00.000-04:00

If you ran into a file that was of type hexbinary, how would you go about using it in your program?

Here's what I would do:

1) open the VFP helpfile
2) click on the Search tab and enter "hexbinary" without the quotes
3) click on each of the 4 resulting topics, click on the text window, press ctrl+F, and enter "hexbinary" without the quotes

The result would be that within 90 seconds I would see that strconv() would decode that file for me.

Now isn't that better than putting a question on the Universal Thread and having to wait for an answer? What was really amusing is that the help the user go who asked the question was a list of the first 3 items that came up in the helpfile.

Teach a person to fish...

Temporary Post Used For Style Detection (e25740fd-8137-4313-81b1-9aa6a80d3dcd)

2006-10-18T08:55:00.000-04:00

This is a temporary post that was not deleted. Please delete this manually. (73c0749a-9783-475b-8f0e-978ec865344f)

Business Rules Engines and The Man Behind The Green Curtain

2006-08-03T09:58:00.000-04:00

Business Rules Engines are the "next big thing." If it's going into Visual Studio's next version (Windows Workflow Foundation) you know that it's already here. Microsoft is never early, rarely late.

What these engines have in common is an attempt to simplify rules development so non-developers can create the rules, "look ma, no hands programming!" The assumption is that every type of business rule can be laid out ahead-of-time, and from there it's simply fill-in-the-blanks.

If it sounds too good to be true...

Here's what I know:

Business Rules in complex systems (no one hires me to write simple systems <s>) tend to be tied to the idiosyncrasies of the data structure, requiring, e.g., special views or other data operations, and therefore even if one could classify all these contextual variables, the list of contextual variables would be too numerous to be useful.
The ability to articulate domain knowledge for non-trivial business rules is typically not present in the domain expert: someone has to know how to tease out the fully articulated view, and translate that into actions.
The User Interface is an intrinsic part of Business Rule actions, and is not addressed by Business Rule Engines.>

In other words, the BR Engines do not hit the sweet spot encompassing domain knowledge, data actions, and user interface. They do not have a place for the Little Man behind the Green Curtain (Wizard of Oz reference), and having a person with intelligence and experience is what is required, by definition of complexity, to handle same.

The PSP Data Dictionary (part of the PSP4VPME package, and the upcoming PSP4MM.Net and likely the PSP4Strataframe packages) of course does that sweet spot, in my biased opinion. It has a place for Rules to be described in everyday language; and for common tasks, you can define a template for where you want it implemented. But all that is secondary to an infrastructure that allows you to implement complex rules complexly, all at the MetaData level.

LINQ: .Net is Looking Like, er, VFP

2006-07-14T00:40:00.000-04:00

A very interesting article in DDJ about LINQ, the most interesting being the addition to .Net of implicit typing. You know, create a variable and assign it to a known type and it becomes that type. Hmm... I think I remember doing that in some language that I use...

And how about this: you can run a Select against the result of a Query that you've run. That seems awfully familiar too, just can't remember where I've done it...

Not only that, but a WHERE clause can accept an inline function (a Lamba function). Imagine: you can write code and then have it execute without compiling it separately. That's almost as good as using execscript()!

Anyway, it's nice to know that they are listening.

One nice point: when writing SELECT statements, full intellisense will be available. That is cool.

European Summer DevCon 2006

2006-06-23T09:25:00.000-04:00

We have run this as a stealth operation for various reasons, announcing it only to those who are currently signed up for advanced support for xCase2VPM and the PSP Libraries courses. I thought we'd better put the announcement up here so other folks will at least know about it. Here goes:

Frank and I would like to pre-announce the Summer ProSysPlus DevCon, which will be held in Weert, NL (that's The Netherlands if you're wondering) on Monday through Wednesday, July 3-5. We will be introducing and training in the use of xCase2VPM V2. We will be taking registrations on our own web site (I offered to do it through ProMatrix, but Joe hasn't gotten back to us, and we can't wait any longer) later this week.

If you are already in Europe you have many options for getting to Weert, including rail from Amsterdam. If you are flying from the U.S., take a look at LTU airlines into Dusseldorf (www.ltu.com), as they have reasonable flight prices.

In case you've been on sabbatical (don't we all wish!), Xcase2VPM V2 will consist of PSP4xCase, a VPM application and engine that moves data to the PSPDD. Most work now done in xCase in terms of attributes will be done not in xCase, but in PSP4DD, a .NET UI hitting against the PSP4xCase engine for moving data from xCase to the PSPDD, and against the PSP4VPM engine (written in VPM) for moving information to the VPMDD. Most information during development will be moved at runtime, to minimize turnaround time when developing. E.g, you will be able to change registrar code for entities or fields in the PSP4DD interface, and simply rerun the form. The PSP4VPM Libraries will enable this dynamic VPM DD updating.

xCase2VPM V2 (the entire package) will be available only by annual subscription, which for current users is $495 ($695 for new users). This includes the product(s), version upgrades, Groove Support (all topics) and all videos. The cost of the DevCon is also $495, which is a real bargain. New users who purchase the Subscription and the DevCon together can take $200 off the price of the package.

Note: attendees will be creating two applications and convert one application during the DevCon: if you want to particpate in this, you will want to bring your notebook computer with you. You will find it handy to have wi-fi ability (b or g) during the training sessions.

Here's the tentative schedule

Monday

AM: Building an application using VFP tables

Noon: lunch at the Pub

PM: Installing the system and exploring the parts

Evening: Pizza Party

Tuesday

AM: Building an application using SQL Server

Noon: lunch in Town

PM: Converting a VPME9 application

Evening: Greek dinner

Wednesday

AM: Review: Software Development MetaData Features

Noon: Subs/Sandwiches

PM: Q&A; the .Net UI Examined

Evening: Pub Crawl

The ProSysPlus Roadmap for VFP and .Net

2005-06-09T09:19:00.000-04:00

Craig Berntson has blogged that the just released Visual FoxPro Roadmap signals the official end of Visual FoxPro. Sedna is thought perhaps to be the 10th planet, which makes it the one after 9, as in VFP9. But others think it is not a planet, not the 10th. In other words, the codename was very smartly chosen to reflect the fact that there will be no definitive VFP10, and that even if one were to call it 10, it's in such a cold, dark, lonely place where nothing lives, that no one would want to spend time there.

It's been fun. The Fox Community was and is very special.

The "contest" blog that precedes this one is actually the ProSysPlus Roadmap for VFP/VPM and .Net, if you read between the lines just a little. This fleshes it out a bit.

* we will release xCase2VPM V2. It will be a separate VPM application, using its own MetaData tables, hooked into VPME91 at design and runtime. It will allow initial development in any datasource available in xCase.

* the same User Interface and same MetaData structure will be used to work with .Net frameworks. Code within the MetaData will be written in Python in the case of .Net, which is easily learned by VFP programmers (dynamic execution, dynamic typing). We will attempt (and we'll see how successful that is) to translate VFP code into the Python snippets required for this effort: if we are successful, the same MetaData used to run your VPME91 application will run in .Net.

* with regard to .Net frameworks, we will support Mere Mortals .Net, because it has the kinds of hooks we need (it helps to have been on the initial beta and have asked presciently for what we would need a few years down the road <s>), and because it deals with the inevitable idiosyncracies inherent in any complex system, in this case Visual Studio. We don't want to learn Visual Studio idiosyncracies: we want to develop software, and Kevin and Rick's work on the framework provides that insulation. What makes MM.Net different is that it is class-based, instead of generator-based: we will be subclassing it to make it work dynamically with MetaData.

* should ProMatrix come out with a .Net framework, we would be delighted to support it. Joe and Steve have shown a connection with the "domain expert" developer that is unmatched. Given an architecture consistent with subclassing, to which they have already demonstrated an allegience in VPME, there is no reason we couldn't integrate well with such a .Net product. As of this date, however, there have been no announcements out of Tampa, other than an aside in the newsgroups about moving "as fast as we can" to .Net once VPME91 is fully implemented, nor have we had personal communication from Tampa on this subject. We will be watching and hoping.

As indicated in the linked xCase2VPM announcement above, we will be revamping our training offerings. Due to the change in the focus of xCase2VPM, there is no possibility of working with xCase2VPM without using the PSP Libraries: so the distinction will cease to exist. In for a penny, in for a pound, as they say in non-Euro England. There will be one product and training offering for VFP; and another product and training offering for .Net. Each will include videos, online discussion, and free updates for the year covered by the training and support package. The first year is free with the product; after that it's about 60% to renew for the next year. Very reasonable company rates for multiple developers will be available. To repeat: there will be no separate product offering, since without the libraries, the product won't do anything. Purchasers of the VFP-based product will enjoy a 40% discount on the .Net product (hey, you're family <s>).

There are, indeed, worlds beyond our VFP solar system, and the journey is underway.

The Blog'n my way to the PDC Contest

2005-06-07T17:16:00.000-04:00

This contest is offering free registration to the MS Professional Developers Conference (PDC) to those who are creative, write good, er, well, and will bring value to the community through what they blog at the PDC.

Now, you all know that over the last year Frank and I have blogged about Avalon, Indigo and IronPython, showing cool things about .Net present and future to the Visual FoxPro senior developer community (no one who takes our training is unable to write a class when they are done <s>). And while it's true we may have echoed a few disparaging comments about .Net made by senior members of the .Net community, with some occasional hyperbole (it should have been 125 outsourced .Net developers to replace 5 VFP developers, not 250, but it sounds so much better at 250, and language skills being what they are, it seemed justified at the time, sorry), we are ready to make amends, especially if it will get us free registration. That's right, us: Frank Camp of Weert, NL, who has all the .Net credentials, and me, who doesn't dream in Dutch. Get that, Jeff? We need two registrations.

And yes, while what we had to say about Avalon (creating a sandboxed VFP would be more efficient in terms of the runtime download and the size of the executable object) and Indigo (most remoting is best accomplished with simple REST; it's generally more efficient to zip a dbf and use that locally than to wrangle with overblown XML) wasn't in the most positive vein, we did at least get the word out there, right? And since the VFP team would rather quit their jobs than write a sandboxed VFP (one would have to guess that the actions would be equivalent <g>), we do have to admit that Avalon Express might have a future, made all the brighter by the fact that Adobe, who never saw a developer they didn't either despise or ignore, will shortly own Flash. And if one must engage in large-scale remoting of complex applications (undoubtedly in support of the Oxymoron Dept.), at least Indigo is a good first step toward bring remoting technologies under one syntactical roof. So we haven't been entirely negative, have we?

In that same comradely spirit, back to the amends: we are announcing today that Version 2 of xCase2VPM will have the same User Interface (UI) and the same data structure for both xCase2VPM V2 in support of Visual ProMatrix 9.1 (the VFP-based framework) and for xCase2PSP.Net (the .Net-based product), in support of MM.Net and presumeably (but they haven't asked us what our thoughts on it might be) the recently-sort-of-announced-we'll-start-on-it-Real-Soon-Now Promatrix .Net framework. How can that be, running dynamic code stored in metadata, with .Net being a static behemoth (oops: supposed to be doing amends here!)? Well, let's just say that a VFP developer capable of writing a class object can learn Python in a weekend. Wouldn't you like to come to Naples, FL for a weekend and learn Python? So, anyway, you define all your metadata-based actions, like dynamic control access, or control state, or entity-availability for CRUD, or dynamic blank checking, etc., and, true, you'll have to rewrite some of your code when you move to .Net (although our ability to translate the code into Python should be pretty good), move your UI over, and you're done. We had to rethink the way we were doing things (in effect whatever framework you are using ends up calling our objects for metadata-based actions), but for a chance to get two free PDC registrations, we will not only grovel, we will refactor!

Now, you may think this is a shameless and meaningless ploy. That we really only wanted to construct our interface once, as a VFP/VPM app which runs twice as fast as a Winforms app (this isn't the amends paragraph, Jeff, that's the one directly above...), and that we are touting this decision as though we had made the design decision specifically to get the registrations. Hah! That's our reply: hah!

As for what Frank and I would do there at the PDC, let's start with what we won't do:

1) we won't report the news that everyone else is reporting: you'd have to be uninterested in what is happening in your own field of work to not hear the news, and since you subscribe to this blog, we know you are interested, so what would be the point?

2) we won't feed you pseudo-news cooked up by the MS PR machine, unless it comes with a very good dinner, in which case we will use the telltale line "while dining with confidential MS sources..." You are warned. To Confidential MS Sources with dinner invitations: we're available every evening at this point.

Now for what we will do: Frank and I will dog down representatives of all the major MS .Net teams, asking them embarrassing questions, and reporting their answers. "Why can I write a builder in 4 lines of code in VFP, and it takes 10 pages in .NET?" "IronPython can execute dynamically: why are there no equivalent dynamic features in C# and VB.Net?" "Can you show me how to navigate to the web site where I can get the Great Plains SDK?"

We'll also look for the people who really do get it. Maybe someone will get smart and bring Sara Ford to the PDC: she gets it. Hey, maybe Jim Hugunin (IronPython) will be there! Not to mention the VSData team, which largely consists of former and present VFPers. I've found in the past that a good single malt (perhaps The Macallan in memory of Tommy Rettig, which we did in Palm Springs a few years back) does much to warm hearts and loosen tongues.

And finally, of course, Frank will pursue a path of serial intensive socialization in the specialized ecologies maintained for that purpose in and around conference facilities. That boy can drink beer! And most of the time he remembers, too, so we'll be able to blog most of it!

Since I spend a good part of my day exercizing (now stop laughing: I've turned over a new leaf, and yes, it's a big leaf, but at least I can turn it over), I'm the one who will be out with the exercize crowd early in the morning, or in the gym during cocktail hour. Thus the value of the dynamic duo: we are dynamic at different times of the day. <s>

The image below clicks through to the blog site where this came from, so they know to come and look at what's written here. Go ahead and click, so they think a lot of people read this blog. <g>

PS: Jeff -- we'll need Pre-conference registrations with that, so we can truly cover the entire conference. Thanks, and be sure to stop by for some of that single malt.

Yahoo Productivity Suite: Almost Good Enough

2005-05-03T10:24:00.000-04:00

If you haven't been following it, there's a revolution going on, and it's about your workaday desktop. The new Yahoo productivity suite, which works right out of Yahoo Messenger and Ajax-enabled web pages, is the first serious contender. There will be more.

Here is an overview of the Yahoo productivity suite:

The Calendar can be shared; each entry can be either Private, Busy (no detail), or Public; who can see it is adjustable, as is who can change it for you. The ability to create meetings is present, including looking for a free time. Tasks do not have to be time-driven. You email can send meeting requests.

It's a very decent start. The Notepad is weak, having no formatting capabilities, nor outlining capabilities (ActiveRenderer is working on web-based outlining capabilities outside of Userland Radio). There is no threaded discussion capability so useful for workgroups, nor any task management capabilities. But none of these is rocket science.

And, of course, none of this is capable of working offline.

What the Yahoo productivity suite demonstrates, however, is the power of the Ajax approach to web UI. Solve the offline capability (and this is not rocket science either; XML is XML whether it is going over the web or being deposited on the local storage device) and add functionality, and where does that leave Microsoft Office (overkill for 95% of what people do in the office)?

And if that's the case, where does that leave the need for an operating system to support Office?

And if that's the case, where does that leave our applications, which depend on that operating system?

Oh, btw: intellisync between Yahoo and Outlook is free, from Yahoo. They know who they have in their sights.

Prediction: within two years either Yahoo or Google (more likely both) will have Office-killer productivity suites available on the web for free.

Adobe and Macromedia: A Match In More Than One Way

2005-04-18T10:50:00.000-04:00

CNET reports that Adobe will buy Macromedia for $3.4 billion. This is a perfect match in more than one way. Technologically, the best CSS web design tool (Adobe's Go Live) and the best frame/dhtml design, extensible tool (Dreamweaver) complement each other nicely: put both sets of strengths in one product, and that's what you and I both want for our web design purposes.

Unfortunately, both companies have a similarly dismal record in relating to developers. Macromedia showed promise for a while, but about a year ago began chopping up its developer relations in the name of profits What they did was simply end the developer software package: it wasn't cost-effective for them. They began the process by taking a survey in which they asked what could be left out of the developer package and how much more could they charge for this lesser package: I imagine I was not the only one to provide them with an earful of response.

Meanwhile, Adobe has consistently maintained a pricing model that excludes vertical market embedding. Well, they had a slight mis-step in 1998 or 99, when they sold a PDF printer driver separately from the rest of their heftily-priced products. But they recovered quickly and took it off the market.

What's even more interesting about this is that each of these companies was vying for the desktop: Macromedia with it's Flash MX, which offered the benefits of Longhorn in terms of lightweight application UI, and offered it on any platform that could run Flash; and Adbobe with its interactive additions to the PDF format, making it capable of data round-tripping. How can the combined company maintain its value, when one of their technologies will end up being either killed or maimed?

On the other hand, Adopbe/Macromedia may have been heartened by Microsoft's recent actions toward developers and partners. First, the Partner program, in which Partners were heaped with software so they could become familiar with Microsoft software through use, and develop software that ran on Microsoft software, is being transformed into a marketing-driven "sell software or die" model. Yes, they created a nice first-year model to help companies join up, but beyond that, the marketing mavens have taken hold. The program itself is in serious disarray. Try to find training on Great Plains (you remember: Microsoft acquired them a few years ago). If you persist, you will be given a website where you aren't eligible to sign up for training. And there it will stop, with the mildest of apologies, and no promise of action. You see, Microsoft doesn't have a vested interest in its Partner program: it farms it out to third parties. They have no power to change anything, so nothing changes based on what is happening in reality, in the field.

Second, Microsoft's actions in pricing VS2005 Team System, so that Partners and MSDN Universal Subscribers will have to pay extra to get it, is a sure sign of self-destructive insanity. Someone at Redmond has forgotten that development software's purpose is to keep the business software world a Microsoft world, not to be its own profit center. Maybe it can be a break-even center, maybe not: what counts is the result in terms of business software development. Any idiot wanting to make his corporate chops can sound like a hero issuing the call to make this or that a profit-center. It takes a leader to prevent such idiocy from taking hold.

I'll see about being more cheerful next time. <s>

Source Control HOWTO

2005-04-05T23:26:00.000-04:00

Eric Sink, lead developer and co-owner of SourceGear (SourceOffSite, Vault, etc.) has written a neat Source Control HOWTO, actually on online book. By the time one finishes writing the software for the 3rd time, one can claim an understanding of the domain, and he has that.

How Do You Explain Pair Programming?

2005-04-04T23:51:00.000-04:00

How Do You Explain Pair Programming? provides in a very few words (Less Filling, More Taste) a persuasive marshalling of substantiation for the proposition that Pair Programming will lead to software than is higher in quality and more timely.

MSDN Nuggets Are That

2005-04-04T12:56:00.000-04:00

MSDN Nuggets is a collection of "cutting edge" 10- to 20-minute videos showing "how-to" do neat things with VS 2005, SQL 2005, Asp.Net 2.0, etc. They are producted by MSDN UK. Less Filling, More Taste.

Tip: Adding Recalcitrant Project Files To Source Control

2005-02-15T21:53:00.000-05:00

We put our projects in Source Control, for all the usual reasons. And, like anyone who uses Source Control through the VFP Project Manager, we occasionally end up with files marked with a Question Mark (?) in the PM, meaning that the file is not in Source Control and needs to be. Rightclick on the file, and you are likely going to be told that no files require adding to Source Control. Rats.

The answer, I thought, was to rebuild project/recompile all. Which works, but takes a bit of time. Today, I discovered you can cheat: Build EXE/recompile all -- but when the dialog comes up to select the EXE path and name, press cancel. The Add to Source Control dialog will then come up, with all those recalcitrant ("no, no, anything but Source Control, don't make me go!") files listed. Go figure.

The VFP Sandbox: What The World Needs

2004-11-30T12:38:00.000-05:00

This is about the need for a VFP sandbox. It's a realization I've come to slowly, after having explored two promising technologies which, when reduced to fundamentals, are promising mainly because they offer a sandbox in which to operate on the client's machine, in a distributed environment.

First is Groove. Frank and I organize most of our work lives within the Groove environment: think Lotus Notes (Ray Ozzie took his money and knowledge from creating Lotus Notes and created Groove) on the internet using server-coordinated P2P. Groove is also a development platform: what it offers is a sandbox in which you can safely play within corporate nets (I know people running it in pretty tight, security-wise, environments). I've been using Groove for a long time now (probably about two years), and most of my work life is organized on Groove.

Second is Flex aka Flash Remoting, nee' Firefly (if you know the history, you are seeing my early adopter roots here). As conceived and marketed by Macromedia. Flash MX utilizes Flash movies to provide a sandbox on the client machine in which code can run, and interfaces and data manipulated. Macromedia would, of course, like to sell you server software to make it work, but the API is deconstructable (and has been, in a PHP version). What Flash Remoting offers is a sandbox on the client, in which we developers get to do useful things.

I like Groove; I think Flash Remoting could be really neat. And they are both dogs, compared to VFP. The ease with which we can move data over the internet, manipulate XML, the speed and sophistication of VFP's interface (never thought you'd hear that one, right? <s>), not to mention the speed of local data handling, make VFP a superior product in all regards for a distributed desktop client.

Nor is the size of the runtime an issue: Groove issues updates about monthly that come in at 25MB or so. And the Flash application, in which remoting runs, is not trivial either. The VFP runtime at 4MB is peanuts (add another 1MB for the regional dll). As for in-place updates, Rick Strahl has been doing that for years now, over the internet, on program instantiation.

Nor is there much competition in the pipeline, although the idea behind Avalon is to give that sandbox; but who could compare writing a desktop application in .NET, with local data handling, to VFP? By the accounts of those in the know, the .NET UI is half the speed of VFP. And comparing XML datahandling in .NET with local data in VFP is too cruel to .NET to put into words.

So why isn't VFP used for distributed applications? It's not size; it's not capability. It is because it is not a certified sandbox application. It's possible to trash a network in no time at all from with VFP. <s> The work to make a version of the VFP runtime as safe as Flash (mainly having to do with what can be written where, or what can be executed), and to guarantee authenticity with a digital certificate, is relatively trivial, at least compared with the everything else that already exists in the product. And doing so would ensure the life of VFP for a considerable time to come.

The Case for Presentation Layer Metadata

2004-11-04T11:10:00.000-05:00

Now that Microsoft (in the upcoming Visual Studio Team version) will be integrating data design tools with development tools, it's time to move on to another battlefront. (If you're new to this Blog, we've been integrating data design tools with our development toolset for 8 years, worked on it for a couple of years before that, and demonstrated the concept in the Event-Driven book a decade ago.)

As you can guess, this involves Presentation Layer Metadata. Here are some examples of what we currently do in our toolset with presentation layer metadata:

-- control whether controls associated with fields are enabled or visible, on a dynamic basis, including EnabledOnlyWhenNew and EnabledOnlyWhenUnchanged
-- control whether data CRUD controls are enabled, on a dynamic basis
-- control whether edit surfaces (forms; pages) are editable; appendable; deleteable; viewable, on a dynamic basis

We have the facility for specifying the type of control (class) a field should use, but aren't using that yet. I don't think that would need to be dynamic, but I suppose that's possible also.

Given that we already control field triggers for filling in from Lookups and inter-field calculations, that doesn't leave much coding on the design surface. Which of course is the point.

In most cases whether I am using a Fat Client (traditional app) or a Thin Client (web app) or a Middleweight Client (Flash application; Java applet), I want the same UI behaviors. I have the same objections to coding these Presentation Layer behaviors into the interface as I do coding Data Layer behaviors into the interface: it's more work, and leaves me more open to error.

I wonder whether it will be another 10 years before the big guys catch up...

After Fulfillment, What Next?

2004-10-28T11:53:00.000-04:00

I was born in Massachusetts, and as a youngster would walk down the street on a summer afternoon, into the coolness of my grandmother's house, to listen on her table radio to the Red Sox, with Curt Gowdy broadcasting. Like most of those born in New England, I was thus infected with the Red Sox virus, by which we were condemned to root for the Red Sox, regardless of our current place of residence, for the rest of our lives. And watch them lose in the World Series, when they weren't beaten by the Yankees before they got to the World Series.

Now, of course, the goal of our rooting has been reached: the Red Sox have won the World Series. Now, the price of success must be paid, and it's looking like a high price, indeed.

No, I don't refer to the inevitable breakup of the team: to be so good means the team has more good players than it can afford. A sad, free market truth -- witness the 2004 Marlins, my adopted team here in South Florida, where losing Pudge's bat made the difference between postseason and not.

The big problem is that those of us with the Red Sox virus now have to face other sources of unhappiness in life. Until now, when looking at why life is unfulfilling, we could start with the Red Sox and go no farther. Which was darned convenient, not having to look at any other sources of unfulfillment in life. I foresee great revealed unhappiness in New England over the next 9 months.

It's a situation similar to completing any big life goal, I guess: it happens on completing dissertations for doctorates, when software ships, and so forth. Suddenly, this "thing" which has occupied attention is no longer there, and everything else pops out. And because these other things have lain relatively unattended, they may not be in such great shape.

I've seen two approaches to this problem of apres le victoire: move on to another project right away (the Microsoft approach, from what I've heard); and have other engaging interests.

But, of course, September isn't that far away, is it?

VFP Can Be Integrated With Visual Studio

2004-08-30T21:20:00.000-04:00

We have been told, over and over again, that we would lose key functionality in VFP if it were ported to work with the Common Language Runtime, i.e., the CLR, i.e., Visual Studio .NET. This is because the CLR is not made to be used with dynamic languages. Well, guess again: Jim Hunginin has been creating IronPython - a fast Python implementation for .NET and Mono, and is now working at Microsoft continuing that work, and helping other dynamic languages integrate with .NET.

Frankly, most VFP developers would be pretty happy with Python. Either way, things are looking up for the longterm future of productive software craftsmanship.

Old Dog, New Trick: ReadOnly Column Made Editable By The Keypress

2004-07-04T16:47:00.000-04:00

I'm so happy, I'm going to strap up my rollerblades and do the neighborhood! <s>

Anytime I learn a new trick, I get really happy; especially after about 8 hours of bouncing my head off the proverbial brick wall.

Here was the issue:

I had a datetime field (for c/s compatibility that's all I use; VFP can map the change with MSSql, but that isn't the only backend in town) which was in an editable grid, using a txtSmartDate (Quicken-like) control in a column. Now, the txtSmartDate control (from the PSP Libraries) accepts a date, datetime, or string date, and using access/assign returns the right value to the calling party. And sure enough, it works fine in a grid.

The problem was the non-selected rows of that column in the grid (using Sparse = .T., for display consistency). There, unless the column was adjusted just right, some of the time showed in the non-selected rows.

Adjusting the column width seemed a bad idea: it would leave the application at the mercy of the user's display, at the least.

My first attempt involved adding code to the INIT of the txtSmartDate instance that reset the controlsource of the Column to "ttod(" + this.cSaveControlSource + ")". This indeed took care of the display issue (BTW: InputMask and DynamicInputMask and Format of the Column all failed). It left me with one problem: because the Controlsource of the Column was not editable, the Column was automatically set to ReadOnly: that Column in grid was no longer editable. Bummer.

After bandaging my head from the repeated blows against the brick wall (give me an American flag with 13 stars and I would have fit right in a 4th of July parade), I had the thought that I would somehow force the Keypress event in the txtSmartDate instance to fire: which would be fine if the Column had a KeyPress event. But, while sitting in the KeyPress event of txtSmartDate I thought: why not set the txtSmartDate's ReadOnly attribute to .F. on each keystroke, and then process the Dodefault()? I had seen, using CodeMine's Object Inspector within the last year, a control go back to ReadOnly after being manually set to ReadOnly = .F., so maybe it would stick long enough to work.

And of course, I'm writing this because it did work.

Time to hit the road, keeping the streets of Naples Park safe for Democracy. Hopefully I will hit the road only with my rollerblades. <s>