Tod means Fox

The W32.Ukuran.Worm, which is running wild currently in Vietnam, attacks FoxPro data files by truncating them and replacing them with spam data, according to the Bach Khoa Internet Security firm. The problem is estimated to be that 50,000 computers are infected or at risk.

What I find interesting about this article is that it appears there are quite a lot of FoxPro programs floating around in Vietnam! But why is there only 1 signature on MasFoxPro?

Anyway, the moral is (as it always is): make and keep reliable backups. I’ve got in the habit of dumping my tables to CSV (COPY TO filename TYPE CSV) as well as physically copying them as part of my backup routines (this is in additional to the normal backup software that runs on my client’s servers). The CSV file allows me to recover data that might otherwise be lost due to some extremely damaged file that can’t be recovered by other means. I’ve never needed to go back to the CSV, though.

The other moral is to keep your virus files up to date!

Andy Kramek put together a fantastic blog entry earlier today, titled “Creating Classes with a Factory“. This type of design pattern belongs to the Creational family of patterns, and is used mainly to, um, create things!

What I really like about Andy’s entry is his emphasis on metadata to accompany the pattern. He writes: “[metadata] is what makes this implementation so useful in my opinion, and why VFP is such an ideal tool in which to implement this particular pattern”. And of course, he’s absolutely right!

But more importantly, Andy has uncovered a very useful function of metadata that can be applied to many other elements of software development. That is, the ability to use metadata to store code snippets that can be updated or tested by developers while the executable is running. This isn’t only a handy time-saver, but it’s also a great way to compartmentalize code, deliver custom functions to clients, and build robust and scalable solutions. By including code in memo fields, you can customize applications without changing the core engine. And, as Andy pointed out, you can test various implementations while running the executable.

I’ve used this approach for many years; for as long as EXECSCRIPT has been around. I’ve used to it generate SQL statements on the fly, run conversion routines (some clients like data stored using inches, while others prefer millimeters for example), and separate complex and specialized algorithms that have different implementations depending on the client. I rely on it heavily for all my data integration tasks. In fact, logical data maps (which are more than just “logical” in my world) are used solely to drive all data transformations — not a single piece of business logic is included in the application. The alternative to the metadata approach is to embed these things into the source code itself — but in my experience, this just leads to greater maintenance, regression headaches, and clients that need to wait a little longer.

Using metadata allows you to separate functionality from implementation. In the case of Andy’s Factory pattern, this is one of his important bullet points. In Visual FoxPro, we have the luxury of an in-house, native database that is fast and easy to use. Perfect for metadata (even if you’re using some other database for the backend).

In the article “Life After dBase“, authors Doug Barney and Thomas Caywood conduct a rather entertaining and informative interview with dBASE II creator C. Wayne Ratliff. If you get a chance, have a read. I found what he had to say about FoxPro most interesting:

Barney & Caywood: FoxPro is sort of alive and well. Microsoft isn’t promising anything beyond the next version, but that whole dBASE community is really loyal to the FoxPro product.
Ratliff: For good reason. … FoxPro is more rigorous in its data approach than dBASE II was. It’s — maybe user-friendly isn’t the right word — it’s just friendly. It’s easy to do stuff. It’s easy to make mistakes, and I think that’s what all the rigor is going toward, trying to protect people from themselves. You can just get down and dirty with the data in dBASE and to a slightly lesser degree with FoxPro. If you have to go in and write an access program, and I did a lot of Visual Basic access work three or four years ago, it’s another step harder. They just keep getting further and further away and more rigorous. There are things like data hiding and safe typing and object-orientation and all that stuff. It takes more programming effort to get something to happen than it did with dBASE.