Monday, March 26, 2007

Power of CSS

I noted Goran's earlier post about tables vs. css, especially about how tables are more consistently rendered than CSS. While I'm fairly well versed in basic CSS (cascading style sheets), I primarily think of it for font and basic style changes. Then I came across css Zen Garden: The Beauty in CSS Design - this site really shows the power of CSS. The basic HTML is simply a bunch of text using div statements - it's the CSS that creates the full effect.


It IS noted on the page that CSS isn't browser consistent - but it does give a great showcase of what is possible.


Great site!

Powered by ScribeFire.

Monday, March 19, 2007

In 21st century development, separate runtimes appear to be more popular than ever

Mike's post about the "Business Decision" to kill VFP reminded me I had this older post that was still stuck in drafts. As Mike says "Microsoft was hell bent against dynamic languages. But now? Microsoft is investing in creating versions of Python and Ruby for .NET and of course already has Jscript. If these dynamic languages can be developed for .NET, there's no reason VFP can't be ported to .NET."

I recall a time when the promoted disadvantage of FoxPro applications was that it required a separate runtime. "True applications don't need additional runtimes" was the mantra of many a developer, usually C at that time, but then when Visual Basic received native support as well, its developers joined that group (even though their support typically consisted of bundling the runtime directly with it).

Of course, it also made it easier to distribute VB applications when standard Office applications installed it by default as well. I even recall some discussion among FoxPro developers that all Microsoft had to do to make FoxPro applications more "acceptable" was to include the VFP runtime as a standard part of the OS.

No one makes those statements anymore. After all, Java requires a runtime (thankfully typically installed with your web browsers), DotNet requires a massive runtime (but since Vista, WinXP SP2 and Win2K3 all install it by default, no one notices) and now, Adobe's work with their platform independent Apollo will also require a runtime.

At least Adobe calls it a runtime - Java's Virtual Machine and DotNet's Framework all mask the fact that it's exactly what users have had to do with most applications for years. No one complains about this anymore.

But as FoxPro developers, we were often the ones who got crucified for having a separate runtime, until it become fashionable to do it.

Thursday, March 15, 2007

Forward to Fox in 2007

Awesome that Kevin Cully is going to be holding his Fox Forward conference again. Hopefully this time I'll be able to make it down to Georgia for Friday September 7th; Saturday September 8th; and Sunday September 9th, 2007!

And it looks like he's looking for some good sessions on a wide variety of items:

1. FoxPro Technologies
* N-Tier Applications And Foxpro
* FoxPro Framework Shootout
* New FoxPro Sedna Capabilities - Taking it to the max
* The SednaX Project
* Comparing WWWC and AFP
* Calling .NET constructs from VFP
2. FoxPro leveraged technologies such as ActiveX Controls, Plug ins, Backend databases, etc.
* GDI+ - Look at what's now possible
* Extreme UI Controls in FoxPro (Cubes, Mapping, Animations, etc.)
* FoxPro to alternate backends - MySQL, PostgreSQL, Firebird, DB2
* WWWC and Apache
* Linux as a development platform for FoxPro
* Open Office automation from FoxPro
3. Related and/or competing technologies from a FoxPro perspective
* Python / Dabo
* PHP-GTK - Fat client applications with PHP
* REALBasic - Cross platform, OO, Basic language
4. Computer based technologies that is non business application related (Servers, communications, graphics, etc.)
* Apache Web Server Administration and Tuning
* SourceSafe vs. CVS vs. Subversion - Source code control shootout
* Network and Internet Security for businesses

Great set of tracks there!



Fox Forward 2007 Conference - Looking forward to the future of technology from a FoxPro perspective!

powered by performancing firefox

Future of (your) Development Lies in You, Not Microsoft

By now, I hope most FoxPro developers (and others) have read the announcement and the various follow ups (and no this isn't meant to be link bait but more of an exhaustive way of reading about it all)

E-Week
Mary Jo
Craig Berntson
Yag's Thoughts and Comments
Alex Feldstein
Doug Hennig
John Koziol
Rick Schummer
David Stevenson
Randy Jean
Andy Kramek
Mike Feltman

and I'm sure there will be more before the week is up. As is always the case when these announcements hit, people will be asked "how could we possibly have been developing with a tool that's no longer around?"

I think Doug actually put it best when he said "I can continue to purchase VFP licenses for new development staff for several more years and I can continue to receive support from Microsoft until 2015. That's not definition of dead."

But in my correspondence with a colleague, yag's comment about resistance to learn a tool that is 18-23 years old (C and C++) instead of newer tools. How many applications used today were built with C and C++? Many of them are and continue to be - but I think most new projects are built using other tools. Even Java isn't as popular as it used to be when it was the "hot language du jour". Now tools like Ruby or Python are just as popular. And these are open tools - they are supported, not just by a vendor, but by an entire community.

Before I jump in on the community part, I also wanted to make a comment about Microsoft's development approach. They have a lot of great tools and amazing people. But one thing that has frustrated me and other developers is their need to continually RE-PACKAGE or re-design development approaches. And this isn't just with FoxPro and VFP. This is about development architecture. In the beginning was Client-Server, then DNA, then COM, then COM+, SOAP, etc, etc. You used to access data via ODBC, then ADO, now ADO.Net and now LINQ. You could build forms with VB, then in Visual Studio 2003, it was WinForms, and now it's WPF/E. And most of these changes in strategy have come out all within the past 10-15 years. This isn't to say they aren't good or great. But many of these changes weren't easy to bring about in existing code - they required redesign. The developers who jumped on one technology's bandwagon then had to be prepared to jump over to the next new one when it came out, because it was "going away". I'm all for "show me the best way to do something" but I think at times, Microsoft (and likely all developer tool companies) needs to realize that when a company makes an investment in a technology, when that technology changes even slightly, some managers go crazy and worry everyone with their "sky is falling" bit. That's not directly Microsoft's fault but it's a reality for many developers, especially those who spend 5 years learning a technology only to be told that it's not the right way to do it anymore. Sure, they have "experience" - but tell that to the 45-year old developer who is getting his pink slip handed to him because his manager loves the way the latest 20-year old builds his Atlas.Net application.

A better example : read Yag's post about Generation Y. here's just one take-away: "I worked with some interns who built an app and the first screen was just a search box - and it would search customers, inventory, orders, etc., and bring up appropriate ones. Very few menus - unlike in my day. "

Ten years ago, if you were asked to build a search screen in an invoicing application, the first thought would be at least 3 search boxes: customer, invoice # and maybe product.

And which one is better? Hard to say but the reality is that anyone with any exposure to the web (and that would be almost everyone in our area) is now used to a single search box.

Things change but also where they are being used also changes.

Development is about finding the right tool(s) for the right job. If you're building a new desktop application, you'll likely take a different approach than what you used ten-fifteen years ago. But if you've got a desktop application that works, you'll build on that foundation and make it better.

The computing desktop is going to change hugely in years to come. But it will take time. Microsoft has made noises to the fact that Vista (and its follow-up server) will be their last 32-bit operating system. Do YOU see yourself switching to a 64-bit computer in the next five years? I don't. Multi-core, etc - sure but 64-bit? Can you see most corporations changing in the next five years? Me neither.

But eventually, they will. But I would say that's a ten year timeframe, if not longer. By that time, what will a typical computer look like? Will the internet be everywhere via Wi-fi? I think the way businesses operate may also have changed by then so desktop applications may not be the best way for building a new application - maybe it's web or mobile or (and I shudder to think of it), on your phone.

There will still be a need for desktop applications (as they are thought of today) and Visual FoxPro can still build a killer desktop application. If you don't believe me, check out the work that the community, not just Microsoft, has done with VFPX. The work being done on Sedna is also community-driven - Doug Hennig, Rick Schummer, Craig Boyd, Lisa Slater and Colin Nichols among many others are the ones directly working on it. These aren't Microsoft employees. And while they work at Microsoft now, Yag and Calvin were also main individuals in the FoxPro community, pushing the product forward. No one thought that FoxPro could do the Internet until Rick Strahl made it easy. And the user interface work that is coming out of VFPX is completely amazing. If you wanted to build an Outlook-like or Office-2007 style application in FoxPro, people may have told you even three years ago you couldn't do it. Don't look now - you CAN! If you don't think that the community can make a difference, look at other community-based open-sourced products such as DotNetNuke, Ruby on Rails and the like.

Yes, the concept of an application will change - as developers (and as people), we have to be aware of it. But let's also keep in mind that just because the marketing message says "the old way is wrong", doesn't make it so. How many other "old" technologies are we still using and using well?

One day, we may not need a "car" as we know it - (I keep hoping Moller's SkyCar would do something but it doesn't look like it for a while), but as long as we have roads and the current infrastructure, we will so we keep on improving them but always within the boundaries of what is possible or effective.

With all of the changes that Microsoft has recommended over the years that I noted above, FoxPro has been able to take advantage of and it still does, mostly because of the innovations that the community has brought to it. Visual FoxPro is not the answer to every business problem - but neither is software alone.

Problems aren't solved by software - they are solved by people.

Wednesday, March 14, 2007

MS VFP starts its departure - are you ready for community-based VFP?

Looks like Craig Bailey got the first link up on this but every FoxPro developer needs to see it here

What does it all mean? Well, yes - no more "Microsoft" VFP after Sedna and SP2 - although it is supported through 2015.

But perhaps more importantly - all of the Sedna code is being released into Codeplex - so we can all extend it further. This is a very strong point as it means we, as FoxPro developers, can continue to expand on the tool and make it better.

There will always be areas that we might gripe and complain (for example, why can't we get a pre-processor at compile time?) - but we can find ways around it. Myself, I would love to see them release more internals to the code under a similar license but I don't think that will happen.

However, if you've read the other Craig's blog of late, you'll see that Microsoft is now switching whole-heartedly over to a 64-bit platform, which VFP was never going to support. Whether this is a good move for Microsoft or not, who's to say. Software development is changing and it's all about choosing the right tool.

Most businesses won't be changing to 64-bit anytime and until they do, VFP is still one of the best tools around for data access. And as long as MS continues to improve its Vista compatibility with Sedna (which I'm still not even that fond of), then it's still the right tool for many data-based 32-bit applications and as the VFPX projects show, there's no shortage of what you can do with it.

I still want to find other ways of baking new stuff with VFP, be it linking with open Web APIs, other databases and more. It's not the tool - it's what you do with it and with FoxPro, you can and still will be able to do a lot.

But yag, thanks for letting everyone know.

powered by performancing firefox



Update: Mary Jo notes it also here.

Wednesday, March 07, 2007

Poking around SQL Server's Transaction Log

I recently had the opportunity to try and figure out why SQL Server was doing certain things in one of my applications. This application was using CursorAdapters and for some strange reason, data was being cleared out (for no apparent reason, of course).

But in my searches, I started looking for a tool that would let me read SQL Server's Transaction Log. Sure, you can always restore it to a certain point - but when your customer has run their system for several days and then comes back and says "there was a problem a few days ago", you really don't want to suggest they re-enter all their data. I just wanted to know what the heck was going on with those SQL statements.

Now, you might expect (as I did), that Microsoft would offer such a tool directly within the SQL Server 2005 Manager but no - their "logs" are all about "Login Failed" or "Starting the service". Useless if you really want to see what's going on.

Now, if you Google SQL Server Transaction Logs, you'll see all kinds of tools available. Red-Gate and Apex were two that I looked at. Unfortunately, even though it's 2007, only one of them has access to the SQL 2005 logs and that was Apex. Red-Gate even has a funny story as to why they don't have SQL 2005 support. Red-Gate's product is only $195 while Apex's is considerably more but both offered eval versions which I thought would be enough to see what was going on.

I tried using Apex's and while it looked like it was showing me tons of information, it didn't actually show me the SQL that was being executed. Every now and then, I would see a record with a bit of data but for the most part, the log was empty. I've kept on trying to look at it to see if there's anything I can pull out - but for the most part, when looking at the way SQL tables are updated with VFP Cursor adapters , it wasn't very useful. (I don't know if it works better with direct SQL Pass through).

So today, I had the scenario where a field in a table was blanked out on the 5th even though it had been filled in earlier in the day. How could this have happened? I took a look in the ApexLog and it shed no information. I played with database backups and was able to identify exactly when the problem took place but without access to the log, how could I see what happened?

As luck would have it, I did another google search and came across an undocumented command and function that's been around since SQL 7.0 (so why it's not documented is beyond me except this posting explains that MS won't support it). DBCC LOG or more importantly

SELECT * FROM ::fn_dblog(null,null)

which returns a cursor that is the essence of the transaction log.

It's not very readable but let me share a few things I did learn about it and how I was able to use it (if someone has more information, please let me know) - I tried googling for more details but in the end , it was simpler to find it myself).

The table has a messy structure - and it's changed from SQL 2000 to SQL 2005 so I won't bother putting it in here.

The OPERATION field tells you what it was trying to do. The key entries here are LOP_BEGIN_XACT (which tells you when the transaction was started - and fills in a valuable field named begin_time). There's also a LOP_COMMIT_XACT which fills in end_time.
In between those two records is the actual work which unfortunately doesn't have its own begin_time or end_time. So you can actually fill it in by doing a quick little program like this:


curls = "X"
ldb='x'
scan
if operation='LOP_BEGIN_XACT '
ldB = begin_time
curls = current_ls
else
if previous_l=curls and ISNULL(begin_time)
replace begin_time with ldb
endif
endif

endscan


The current_ls is a unique identifier for the transactions. The Preview_l is really previous_ls but when you copy it to a table, you'll lose all of the nice field names.

At any rate, another key field I found was allocunitn which if you STRTRAN(allocunitn,CHR(0)), you'll find the name of the table that is being updated.

Then you can look specifically for rows with an Operation field of LOP_MODIFY_ROWS, LOP_INSERT_ROWS or LOP_DELETE_ROWS.

The final field that I found useful was at the end of the field list and is named log_recor3. This field has a bunch of binary data in it but when you look at it, you can see the data that is being modified or added.

I couldn't really figure out the best way to determine which field was being updated, except by looking at the data that was in there. If a field is being updated, it will show the OLD value and then the new value. For deletes, it shows the data it is deleting and for inserts, it shows the actual field values.

It would be great if it was documented somewhere - but I imagine this is one of those proprietary things for Microsoft. The strange thing for me though is why I was able to find it in the Transaction Logs but ApexLog couldn't. Go figure.

If you are working with SQL Server and have a need to look at the log, I hope this post helps - if you have some more ideas as to how to figure out what the heck is going on in there, let me know.

At the end of the day, it turned out it wasn't the SQL Update at all - the user had blanked out the value by accident and we weren't trapping for it. Four hours of trying read the gibberish of the SQL log - but hey! I found out I don't really need to spend the money on a log tool persay (Apex is about $600) because I could find it all with one little "undocumented" feature, that definitely deserves more page ranks because the noise when you search for Transaction log reading makes it harder to find the things you need.

Simple-Talk - transaction log

powered by performancing firefox

Friday, March 02, 2007

Southwest Fox 2007

Both Rick and Doug have announced the new Southwest Fox conference for October 2007.

The tracks look really great: covering everything from fundamentals to extending and managing the software business.

Can't wait to hear more about it.
Check it out on swfox.net!

powered by performancing firefox