I have to admit to being torn by this game. If the Pats win, they go 16-0 and are the first undefeated regular season team since the 1972 Dolphins. If they lose, hey, no big deal for the playoffs.
I am a lifelong Dolphins fan. I attended several of the '72 games with my father and was in attendance for that final game versus the Colts that sealed the Perfect Season.
But I have seen the '07 Patriots in action. Offensively, they are a juggernaut. They don't even bother with an honest running game since they can pass at will. I've watched 5 Pats games this year and the only weakness I see is perhaps in the middle versus the play-action run or power run.
Can the Giants stop them? Sure. The Ravens and Eagles almost did. Dumb playcalling and sheer luck stopped those two teams from winning.
Will they? Lord knows. Manning is not terribly reliable but the Pats may rest their players. This may be a game for the ages.
Saturday, December 29, 2007
Tuesday, December 25, 2007
Happy Holidays
One of the downsides to this time of year is that I don't have the opportunity to personally wish all of my friends and associates good tidings for the season.
I am terrible at keeping track of phone numbers and addresses. Just terrible. I don't send out cards because I know for every address I have right there are a gazillion I have lost or overlooked and I don't want to be unfair to those folks.
I can't honestly think of anyone in my past 25 years that I would not shake hands with or give a hug to for the holiday season. I am sure that there are those who would not return the feeling...heh.
To all of you, Happy Holidays and a prosperous New Year.
Next year, dammit, I will send cards and make calls. Help me out by emailing me at john.koziol@datamaxx.com with your current contact information. I'd love to hear from you all.
John
I am terrible at keeping track of phone numbers and addresses. Just terrible. I don't send out cards because I know for every address I have right there are a gazillion I have lost or overlooked and I don't want to be unfair to those folks.
I can't honestly think of anyone in my past 25 years that I would not shake hands with or give a hug to for the holiday season. I am sure that there are those who would not return the feeling...heh.
To all of you, Happy Holidays and a prosperous New Year.
Next year, dammit, I will send cards and make calls. Help me out by emailing me at john.koziol@datamaxx.com with your current contact information. I'd love to hear from you all.
John
Monday, December 03, 2007
Led Zeppelin
Anyone know why the fadeout music for almost all MNF fadeouts tonight were LZ song clips?
Monday, October 22, 2007
VFP9 SP2
Initial reports on this SP were scary so I pounded the crap out of it last weekend. Honestly, I didn't run anything under Vista because I wanted to test the core stability of the bit and I had no Vista machine handy anyway.
My conclusion is that this service pack is fine to run with. The fixes the dev team made to issues far exceed my expectations insofar as some of these issues have been around for a long time.
Good job to the devs at MS!
My conclusion is that this service pack is fine to run with. The fixes the dev team made to issues far exceed my expectations insofar as some of these issues have been around for a long time.
Good job to the devs at MS!
Wednesday, October 17, 2007
Express Lines
A quandry:
I was in the Express Line (10 Items or Less) at the store yesterday. I had 12 items but 2 were from "buy one, get one free" offers, so technically, I was buying 10 items.
Was I OK or breaking the item limit? Hmmmmmm
I was in the Express Line (10 Items or Less) at the store yesterday. I had 12 items but 2 were from "buy one, get one free" offers, so technically, I was buying 10 items.
Was I OK or breaking the item limit? Hmmmmmm
Saturday, October 13, 2007
I Need to Report a Kidnapping
Somebody kidnapped the Miami Hurricanes football team and replaced them with imposters. That must be it.
Thursday, October 11, 2007
The Modular PC
An idea I've been kicking around my head for at least 10 years is the modular PC. What's that?
Imagine a bricksized casing, slightly longer and thinner, with high-speed ports on all sides. Each brick would hold a part of the overall PC and would attach to other brings by stacking, being placed side-by-side, whatever - the ports would connect and link the components.
Individual bricks would hold the CPU, RAM, DVD, HD, and networking components. Other bricks could hold peripheral cards such as graphics and sound cards. Another could hold USB ports.
The brick housings themselves would be low-cost.
The big advantage of this architecture would be that you could swap out or add bricks as required over time to update your system. You might never need again to replace an entire computer.
Need another hard drive? Buy a hard drive brick and snap it onto the stack.
Now there may be a need for a bus controller brick but that's not a big deal I would think.
If upgrades were reduced to simple plug-ins then I would think the peripheral and upgrade market would explode as it would be cheaper and easier for the technically inept to pull off. The bricks would be plug-and-play.
What do you think?
UPDATE
Looks like someone's already done it to a degree, but not to the extent I was contemplating.
Imagine a bricksized casing, slightly longer and thinner, with high-speed ports on all sides. Each brick would hold a part of the overall PC and would attach to other brings by stacking, being placed side-by-side, whatever - the ports would connect and link the components.
Individual bricks would hold the CPU, RAM, DVD, HD, and networking components. Other bricks could hold peripheral cards such as graphics and sound cards. Another could hold USB ports.
The brick housings themselves would be low-cost.
The big advantage of this architecture would be that you could swap out or add bricks as required over time to update your system. You might never need again to replace an entire computer.
Need another hard drive? Buy a hard drive brick and snap it onto the stack.
Now there may be a need for a bus controller brick but that's not a big deal I would think.
If upgrades were reduced to simple plug-ins then I would think the peripheral and upgrade market would explode as it would be cheaper and easier for the technically inept to pull off. The bricks would be plug-and-play.
What do you think?
UPDATE
Looks like someone's already done it to a degree, but not to the extent I was contemplating.
FoxPro Advisor is No More
Just spotted this on the Wiki: http://fox.wikis.com/wc.dll?Wiki~FoxProAdvisor
Sign...yet FP another institution gone.
Sign...yet FP another institution gone.
Saturday, September 29, 2007
Testing 101
I peeked into the cube of our intern the other day and found him running a report where the font was too small to comfortably read. "Hey, good find", I told him. Where's the bug? I looked and the status was "Open".
"Why are you testing that?" I asked.
"I wanted to see if it worked", he replied.
"Is the bug open?"
"Yes"
"If you hit your hand with a hammer and haven't seen the doctor, is it still broken?", I said.
"Yes", in a small voice.
Testing truly is a structured and disciplined endeavor. We learn that everytime we let newbies loose.
"Why are you testing that?" I asked.
"I wanted to see if it worked", he replied.
"Is the bug open?"
"Yes"
"If you hit your hand with a hammer and haven't seen the doctor, is it still broken?", I said.
"Yes", in a small voice.
Testing truly is a structured and disciplined endeavor. We learn that everytime we let newbies loose.
Thursday, September 13, 2007
Why I was a No-Show at FoxForward
To put it simply, I'm on a very aggressive release schedule of a product for some law enforcement agencies. All vacation requests have been cancelled.
I had alerted management to FF months ago so, technically, I suppose I could have forced the issue but that would have been a bad signal to my workmates who are busting ass on this project. Also, my prepared topic was skirting client confidentiality since my firm had just rolled out a related product for acceptance testing.
I missed seeing Ed, Kevin, Garrett, and the rest, though.
Perhaps next year if Kevin is gracious enough to allow me to submit.
I had alerted management to FF months ago so, technically, I suppose I could have forced the issue but that would have been a bad signal to my workmates who are busting ass on this project. Also, my prepared topic was skirting client confidentiality since my firm had just rolled out a related product for acceptance testing.
I missed seeing Ed, Kevin, Garrett, and the rest, though.
Perhaps next year if Kevin is gracious enough to allow me to submit.
Wednesday, August 15, 2007
Death of a Peripheral
Lately my old and trusty VIAO began to lock up during large file saves. When I say lock up, I mean total machine catatonia and nothing but a ten second finger on the power button works. And that just powers down.
So, I have a problem. First things first, go to the Event log. Nope, nothing there. Second: Run troubleshooting for suspect devices (like the controller) from Control Panel and see what it says. It says everything is A-OK.
Finally, run hardware diagnostics from BIOS on bootstrap. Nothing there either.
I strongly suspect that a peripheral, maybe controller, maybe graphics card, is eating it during one or more function calls. But I have no way on knowing because it appears that whatever mean piece of silicon is doing this doesn't have the common courtesy to exit gracefully from an error.
Grrrr.
So, I have a problem. First things first, go to the Event log. Nope, nothing there. Second: Run troubleshooting for suspect devices (like the controller) from Control Panel and see what it says. It says everything is A-OK.
Finally, run hardware diagnostics from BIOS on bootstrap. Nothing there either.
I strongly suspect that a peripheral, maybe controller, maybe graphics card, is eating it during one or more function calls. But I have no way on knowing because it appears that whatever mean piece of silicon is doing this doesn't have the common courtesy to exit gracefully from an error.
Grrrr.
Friday, July 06, 2007
Moore's Law in Reverse
For those that don't know, Moore's Law is that the number of ICs on a given sized board (and, presumably computing power) will double at the same cost every 24 months. Considering Mr. Moore predicted this in 1965 I'd say he's been remarkably prescient.
I say this writing on a computer purchased in early 2002 with only minor RAM and hard disk upgrades since.
I bought my machine, a Sony VAIO, sometime in January 2002. It came with a 1.8 GHz P4 CPU, 128 MB of RAM, and Windows ME. The video card had 64 MB of RAM and it had 80 GB of hard disk space.
WinME was killed immediately in favor of XP. The hard disk developed a weird hiccup in early 2004 and I substituted a WD 160 GB drive for the main drive. Shortly thereafter I updated the RAM, RAMBUS and expensive, to 512 MB. Bought and installed a new video card in early 2005 with 256 MB video RAM. Total cost to upgrade about $500, mainly due to the expensive, and weird, RAM.
So now I sit with a fully capable machine with no real inclination to replace. And I see nothing, except for some nifty games, to compel me to upgrade in the next 12-24 months. When I do finally get a new machine this baby will probably be 7+ years old.
WTF? Is the technology now so mature that we can take our time to upgrade, secure in the knowledge that we won't be obsolete anytime soon? Seems that way. So, what does all the new 64-bit and dual core technology buy us? I'm not sure. I'm running Vista and VS 2005 without complaint.
This must be freaking out the marketing boys at Intel and AMD.
John's Law used to be replace your machine every 18 months or you're so far behind the tech curve you're in trouble. Hard to see an argument that it still applies.
Of course, my VFP friends know that VFP 9 happily percolates on any machine running Win2K (actually Win95 if you overlook some UI issues). Which translates to a base of a 60 Mhz Pentium and about 96 MB of RAM.
Amazing.
I say this writing on a computer purchased in early 2002 with only minor RAM and hard disk upgrades since.
I bought my machine, a Sony VAIO, sometime in January 2002. It came with a 1.8 GHz P4 CPU, 128 MB of RAM, and Windows ME. The video card had 64 MB of RAM and it had 80 GB of hard disk space.
WinME was killed immediately in favor of XP. The hard disk developed a weird hiccup in early 2004 and I substituted a WD 160 GB drive for the main drive. Shortly thereafter I updated the RAM, RAMBUS and expensive, to 512 MB. Bought and installed a new video card in early 2005 with 256 MB video RAM. Total cost to upgrade about $500, mainly due to the expensive, and weird, RAM.
So now I sit with a fully capable machine with no real inclination to replace. And I see nothing, except for some nifty games, to compel me to upgrade in the next 12-24 months. When I do finally get a new machine this baby will probably be 7+ years old.
WTF? Is the technology now so mature that we can take our time to upgrade, secure in the knowledge that we won't be obsolete anytime soon? Seems that way. So, what does all the new 64-bit and dual core technology buy us? I'm not sure. I'm running Vista and VS 2005 without complaint.
This must be freaking out the marketing boys at Intel and AMD.
John's Law used to be replace your machine every 18 months or you're so far behind the tech curve you're in trouble. Hard to see an argument that it still applies.
Of course, my VFP friends know that VFP 9 happily percolates on any machine running Win2K (actually Win95 if you overlook some UI issues). Which translates to a base of a 60 Mhz Pentium and about 96 MB of RAM.
Amazing.
Wednesday, June 20, 2007
The Future is Cloudy
Andrew MacNeill, a good guy, has been commenting on my World of Tomorrow posts. He brings up some legitimate points but I'm not sure he understands where I'm coming from. Or maybe he does. Andrew, if you see this, please comment?
The ambiguity may be my fault because with my recent promotion to QA Architect (new responsibilities) and my hectic homelife, I don't always flesh out my positions well. Being borderline crazy doesn't help either (heh).
I am fully aware of what's in CodePlex and I have availed myself of some of those cool tools. There are some great, great resources there and other sites that are free to use. Still, though, no framework or tool is going to completely insulate you from the .Net Framework and some of the (to a Fox guy) weirdnesses to be found there.
We need to take a step back here; most VFP developers of my age or older - the majority - came into the profession from others. There were (and are) no schools teaching Visual FoxPro in the US, although I have heard it's used in some Indian high schools. A lot of VFP developers became VFP developers because they had a burning need to solve a business issue and bootstrapped themselves into becoming developers.
This is probably why, it seems, the intersection of C++ and VFP developers is in my experience small. C++ developers started out wanting to be developers and it requires a good grasp of professional development skills to accomplish things in C++. They are further down the abstraction ladder from concept to end-user than VFP developers. They think differently.
Now, consider the planning that goes into a VFP line-of-business application as opposed to the same planning if one were to write a line-of-business app in C++. VFP does so many things for you that you can focus mainly on the functionality. With a C++ app, you have to spend a large percentage of your time thinking about housekeeping, memory management, database connectivity and concurrency...it boggles the average VFPers mind. And in my experience, it sometimes boggles the C++ developers mind as well.
I mean, nothing against Craig Boyd, but why in the hell does one want to mix XAML and VFP in the real world? Sure, it's a great intellectual exercise, but if XAML is where you want to go why involve VFP whatsoever? And why XAML? The builders are not there yet so there's a lot of hand-tooling...something VFPers generally detest.
Why not Adobe Flex and FlexBuilder? You have the simple object model and a great builder tool. Something VFPers like and can work with and, since it's RIA, a good foundation for the future.
On the opposite end of the equation, why not use FileMaker for Win apps? Simple, built-in DML...perfect for solving small or medium business issues.
My point here is that .Net architecture just doesn't work the way most VFP developers are comfortable with. There's too many moving parts. Simple issues become consumed by the sheer complexities of the platform. VS 2008 will solve some of these issues, ie LINQ, but not all of them.
.Net can do things that VFP developers have a very hard time with. But the opposite is certainly true as well. So why the push to move VFPers to the .Net platform unless it's a mainly marketing exercise?
Let me return to my last "WOT" post: RIA. Adobe Flex and MS Sharepoint and Sharepoint add-ons represent means to create rich-content business apps by making available a variety of canned widgets to simplify meeting business needs without complex coding. This is really all that a monolithic VFP developer looking to migrate his app to a future-oriented platform may ever need.
But there's also the "if it ain't broke, don't fix it" school. If your VFP app rocks, you're happy, your clients are happy, and you don't see difficulties ahead with Vista - ROCK ON! Sell those apps, keep the world happy, and don't embark on switching tools if you don't have to. Introducing risk out of fear and not need is a cargo cult-ish anti-pattern. Can you count the number of disasters you've seen because some bozo decided they had to use the newest and greatest for a project when they didn't have to and, subsequently, damaged or killed the project? I have seen my fill of those.
The ambiguity may be my fault because with my recent promotion to QA Architect (new responsibilities) and my hectic homelife, I don't always flesh out my positions well. Being borderline crazy doesn't help either (heh).
I am fully aware of what's in CodePlex and I have availed myself of some of those cool tools. There are some great, great resources there and other sites that are free to use. Still, though, no framework or tool is going to completely insulate you from the .Net Framework and some of the (to a Fox guy) weirdnesses to be found there.
We need to take a step back here; most VFP developers of my age or older - the majority - came into the profession from others. There were (and are) no schools teaching Visual FoxPro in the US, although I have heard it's used in some Indian high schools. A lot of VFP developers became VFP developers because they had a burning need to solve a business issue and bootstrapped themselves into becoming developers.
This is probably why, it seems, the intersection of C++ and VFP developers is in my experience small. C++ developers started out wanting to be developers and it requires a good grasp of professional development skills to accomplish things in C++. They are further down the abstraction ladder from concept to end-user than VFP developers. They think differently.
Now, consider the planning that goes into a VFP line-of-business application as opposed to the same planning if one were to write a line-of-business app in C++. VFP does so many things for you that you can focus mainly on the functionality. With a C++ app, you have to spend a large percentage of your time thinking about housekeeping, memory management, database connectivity and concurrency...it boggles the average VFPers mind. And in my experience, it sometimes boggles the C++ developers mind as well.
I mean, nothing against Craig Boyd, but why in the hell does one want to mix XAML and VFP in the real world? Sure, it's a great intellectual exercise, but if XAML is where you want to go why involve VFP whatsoever? And why XAML? The builders are not there yet so there's a lot of hand-tooling...something VFPers generally detest.
Why not Adobe Flex and FlexBuilder? You have the simple object model and a great builder tool. Something VFPers like and can work with and, since it's RIA, a good foundation for the future.
On the opposite end of the equation, why not use FileMaker for Win apps? Simple, built-in DML...perfect for solving small or medium business issues.
My point here is that .Net architecture just doesn't work the way most VFP developers are comfortable with. There's too many moving parts. Simple issues become consumed by the sheer complexities of the platform. VS 2008 will solve some of these issues, ie LINQ, but not all of them.
.Net can do things that VFP developers have a very hard time with. But the opposite is certainly true as well. So why the push to move VFPers to the .Net platform unless it's a mainly marketing exercise?
Let me return to my last "WOT" post: RIA. Adobe Flex and MS Sharepoint and Sharepoint add-ons represent means to create rich-content business apps by making available a variety of canned widgets to simplify meeting business needs without complex coding. This is really all that a monolithic VFP developer looking to migrate his app to a future-oriented platform may ever need.
But there's also the "if it ain't broke, don't fix it" school. If your VFP app rocks, you're happy, your clients are happy, and you don't see difficulties ahead with Vista - ROCK ON! Sell those apps, keep the world happy, and don't embark on switching tools if you don't have to. Introducing risk out of fear and not need is a cargo cult-ish anti-pattern. Can you count the number of disasters you've seen because some bozo decided they had to use the newest and greatest for a project when they didn't have to and, subsequently, damaged or killed the project? I have seen my fill of those.
Monday, June 18, 2007
The World of Tomorrow, Part Five
So as I last left you I mentioned two current buzzwords making the rounds: RIA and SaaS.
Upfront, I am going to ignore a lot of the theory and CIO-gibberish both of these areas and focus on what's important to the VFP developer.
First off, RIA. In plainspeak, RIA is an attempt to make browser based apps look and feel like rich client apps. Those of you who have paid attention to the last few years of VFP soundbites (which I helped write) will note that rich client apps were a selling point of VFP.
RIA is, potentially, a great direction for VFP developers to go towards. The tools insulate the developer from the background mechanics and allow the developer to focus on the business process. I go back to a previous analogy - do we want to build bricks? Hell, no, we want to build houses.
I'm time curtailed tonight....read up on RIA and think about it. More later.
Upfront, I am going to ignore a lot of the theory and CIO-gibberish both of these areas and focus on what's important to the VFP developer.
First off, RIA. In plainspeak, RIA is an attempt to make browser based apps look and feel like rich client apps. Those of you who have paid attention to the last few years of VFP soundbites (which I helped write) will note that rich client apps were a selling point of VFP.
RIA is, potentially, a great direction for VFP developers to go towards. The tools insulate the developer from the background mechanics and allow the developer to focus on the business process. I go back to a previous analogy - do we want to build bricks? Hell, no, we want to build houses.
I'm time curtailed tonight....read up on RIA and think about it. More later.
Sunday, June 10, 2007
Oracle, Unchained
I was at a presentation recently where Oracle's chairman was quoted as a fount of knowledge in an emeging technology.
Ellison? Doesn't anyone remember that everything Oracle has ever touted outside of databases has been shit?
I dread the moment that Oracle might wish to move to Atlanta and merge with Computer Associates. The merger of those two would create a state of negative energy in the universe and flip us into the true vacuum state where the universe would restructure itself to the lower energy level and destroy us all.
But before that happened there would probably be time for workers to put the new sign of the merged company on the side of the headquarters building:
SUCK Incorporated.
Ellison? Doesn't anyone remember that everything Oracle has ever touted outside of databases has been shit?
I dread the moment that Oracle might wish to move to Atlanta and merge with Computer Associates. The merger of those two would create a state of negative energy in the universe and flip us into the true vacuum state where the universe would restructure itself to the lower energy level and destroy us all.
But before that happened there would probably be time for workers to put the new sign of the merged company on the side of the headquarters building:
SUCK Incorporated.
The World of Tomorrow, Part Four
Funny enough, it was Visual FoxPro that was labelled difficult to learn and master. A Fawcette Technical Publications review of Visual FoxPro 6.0 in 1998 referred, tongue-in-cheek, to it's "simple, 5 year learning curve".
Yet, is it really that difficult? It can be, depending on what you need to do or on the standards expected by your client. For simple applications, though, it isn't very hard at all.
Contrast this with .Net. While the Designers are similar to the VFP Designers, the code behind the pretty pictures is daunting. Yes it's elegant and flexible, yes it's powerful but it's very difficult to do simple stuff that's not drag-and-drop from a toolbox.
Many of the VFP developers I have known really love the cool things you can do in VFP ... but usually don't have to. They'd much rather tweak their class and function libraries to do the grunt work and concentrate on the business task.
VFP developers, for the most part, freely give away their secrets and that overcomes a lot of the language difficulties. Those that charge for their wares do so because of their huge investment of time in their work and no one would expect less. VFP developers do not have to invent the brick to build their houses....unless they want to.
Not so in the .Net world. You may not want to invent the brick but few are going to give it to you. There sure are a lot of brick assemblies for sale, though. Good thing, because it would take you a long, long time to build that brick and you better have a good grasp of chemistry and engineering to do so.
In the last 18 months, I have led or managed small and medium sized development teams on monster .Net based projects, using ASP, C#, web forms, win forms, secure sockets, etc etc etc. The developers I work with are very talented folks. But I have had to really lower my expectations on the quantity of deliverables and the robustness of the initial builds. It is so, so easy to "blow up" Visual Studio apps because the amount of things the developers have to account for sometimes overwhelms them. A small behavioral tweak may cause 2 or 3 developers days to complete.
I can't even begin to describe how hard it is to get a robust, blind installer in place for these applications.
Upper management gets frustrated, understandably. They can't fathom at the gut level why it takes so long to deliver functionality that used to be delivered in a fraction of the time.
There are those in the VFP world who have transitioned to the .Net world and I say God bless 'em. If that's the tool that meets their needs, all power to them.
But I think the backlash "for the rest of us" is coming. Two acronyms: RIA and SaaS.
RIA (Rich Internet Applications) tools make it easy to put robust line-of-business applications up on the web quickly and with a minimum of fuss. SaaS stands for Software as a Service and is defined as centralizing data and code and selling business software subscriptions. There are several maturity levels of SaaS but, in the end, it deals with removing local, complex software and managing changes and customizations by scripting and configuration management.
Where does the VFP world fit in and what are the advantages for VFP developers looking for their next platform?
For that you have to wait for Part Five. Gotta go buy summer school clothes for my daughter.
Yet, is it really that difficult? It can be, depending on what you need to do or on the standards expected by your client. For simple applications, though, it isn't very hard at all.
Contrast this with .Net. While the Designers are similar to the VFP Designers, the code behind the pretty pictures is daunting. Yes it's elegant and flexible, yes it's powerful but it's very difficult to do simple stuff that's not drag-and-drop from a toolbox.
Many of the VFP developers I have known really love the cool things you can do in VFP ... but usually don't have to. They'd much rather tweak their class and function libraries to do the grunt work and concentrate on the business task.
VFP developers, for the most part, freely give away their secrets and that overcomes a lot of the language difficulties. Those that charge for their wares do so because of their huge investment of time in their work and no one would expect less. VFP developers do not have to invent the brick to build their houses....unless they want to.
Not so in the .Net world. You may not want to invent the brick but few are going to give it to you. There sure are a lot of brick assemblies for sale, though. Good thing, because it would take you a long, long time to build that brick and you better have a good grasp of chemistry and engineering to do so.
In the last 18 months, I have led or managed small and medium sized development teams on monster .Net based projects, using ASP, C#, web forms, win forms, secure sockets, etc etc etc. The developers I work with are very talented folks. But I have had to really lower my expectations on the quantity of deliverables and the robustness of the initial builds. It is so, so easy to "blow up" Visual Studio apps because the amount of things the developers have to account for sometimes overwhelms them. A small behavioral tweak may cause 2 or 3 developers days to complete.
I can't even begin to describe how hard it is to get a robust, blind installer in place for these applications.
Upper management gets frustrated, understandably. They can't fathom at the gut level why it takes so long to deliver functionality that used to be delivered in a fraction of the time.
There are those in the VFP world who have transitioned to the .Net world and I say God bless 'em. If that's the tool that meets their needs, all power to them.
But I think the backlash "for the rest of us" is coming. Two acronyms: RIA and SaaS.
RIA (Rich Internet Applications) tools make it easy to put robust line-of-business applications up on the web quickly and with a minimum of fuss. SaaS stands for Software as a Service and is defined as centralizing data and code and selling business software subscriptions. There are several maturity levels of SaaS but, in the end, it deals with removing local, complex software and managing changes and customizations by scripting and configuration management.
Where does the VFP world fit in and what are the advantages for VFP developers looking for their next platform?
For that you have to wait for Part Five. Gotta go buy summer school clothes for my daughter.
Saturday, June 09, 2007
The World of Tomorrow, Part Three
First off, I apologize for letting this drag on. I have been very busy with the 9-5 stuff.
In plain English: The fear amongst Fox-ers is not the language. An experienced FoxPro developer has no problems with VB or C# when it comes to the language. The fear is the .Net Framework itself.
And it's not just old Foxheads. I was involved in a discussion the other day with C# developers where nobody could figure out how to make a label transparent to it's container. Trivial stuff in the Fox world, but apparently in the Framework world it demands an intricate knowledge of dithering and other shit unless you want to hard-wire the color. Which runs counter to the OOP abstractions Fox-ers have been preaching and living by for 10+ years.
This is a big problem.
Alan Cooper once said, and I'm paraphrasing, that Microsoft gave you the periodic table and you had to make a broccoli. But this was in the early 90's when VB developers were just as removed from the intricacies of the OS and OS theory as the VFP folks are now.
Unless you have an in-depth appreciation of the way everything should work in the world of Windows or IE based net apps - which a lot of line-of-business Fox folks don't - you are screwed.
I think it also explains the massive drop-off of VB 6 hobbyists from the fold. Things that were simple are now inordinately complicated.
In plain English: The fear amongst Fox-ers is not the language. An experienced FoxPro developer has no problems with VB or C# when it comes to the language. The fear is the .Net Framework itself.
And it's not just old Foxheads. I was involved in a discussion the other day with C# developers where nobody could figure out how to make a label transparent to it's container. Trivial stuff in the Fox world, but apparently in the Framework world it demands an intricate knowledge of dithering and other shit unless you want to hard-wire the color. Which runs counter to the OOP abstractions Fox-ers have been preaching and living by for 10+ years.
This is a big problem.
Alan Cooper once said, and I'm paraphrasing, that Microsoft gave you the periodic table and you had to make a broccoli. But this was in the early 90's when VB developers were just as removed from the intricacies of the OS and OS theory as the VFP folks are now.
Unless you have an in-depth appreciation of the way everything should work in the world of Windows or IE based net apps - which a lot of line-of-business Fox folks don't - you are screwed.
I think it also explains the massive drop-off of VB 6 hobbyists from the fold. Things that were simple are now inordinately complicated.
Thursday, May 24, 2007
The World of Tomorrow Part Two
I wasn't really fair in my last post; I left too much information out of the equation. Here's the premise:
I am convinced that the Fox world's fearful and grudging adoption of .Net has nothing to do with coding. The "World of Tomorrow" referred to a scenario where 30's serials posited great leaps forward in technology and, implicitly, everyone's ability to understand and adapt that understanding. Billy builds his raygun.
Back to our real world. Billy builds his website and plops it on his Win2K3 web server. It fails. Why?
More in Part Three.
I am convinced that the Fox world's fearful and grudging adoption of .Net has nothing to do with coding. The "World of Tomorrow" referred to a scenario where 30's serials posited great leaps forward in technology and, implicitly, everyone's ability to understand and adapt that understanding. Billy builds his raygun.
Back to our real world. Billy builds his website and plops it on his Win2K3 web server. It fails. Why?
More in Part Three.
Tuesday, May 22, 2007
Sedna and The World of Tomorrow!
A play on words, yes? Think about it, though, "World of Tomorrow" stuff from the early 20th century was all about extrapolating trends towards the future following an idealistic evolution of existing techs.
What really happened was so much different. Why?
Think about it.
What really happened was so much different. Why?
Think about it.
Saturday, May 12, 2007
Welcome to Jiffy Tech
This is sort of a banner year for me. June marks my 30th anniversary writing code; September is my 25th anniversary of landing my first professional data-processing job.
I remember having a conversation with a friend of mine over beers back in the mid-80's. He was trying to understand exactly what it was I did and why it paid so well. I thought for a moment and replied that we were the "priests in the temples in the Dark Ages". We were elite because we knew how to read in an illiterate world. But one day, as technology spread, we'd be the new auto mechanics.
That conversation has stuck in the back of my mind for years and I sometimes look at industry and career trends and hold them against that half-joking prediction.
Now why auto mechanics?
I see a correlation between the automotive industry and information technology.
As to cars, from the late 1800's to the introduction of the Ford Model-T, very few people knew automotive technology. Those that did were well-schooled in every aspect of the cars and were paid well for their arcane knowledge. Operating a car required a far more in-depth understanding of mechanics than today. Pioneers in automotives founded large companies to make cars more understandable, cheaper, and more accessible to the masses - the survivors are Ford, Diamler-Benz, General Motors, and others. Studebaker, Willys, and others were competitive for a time but are now long-gone.
Experienced, independent mechanics today are paid reasonably well but a minimum wage high school kid can do most regular service on a car. However, cars are much more complex mechanically under the hood so, paradoxically, mechanics have to be superior troubleshooters than decades ago, before electronics, ABS, fuel injection, et al.
Looking at personal computer-based IT, from the late 70's to the mid-90's we have a parallel. For about a 15 year period, few people grasped the big picture in how to craft a computer application. Those that were successful at it commanded large sums of money. People not in the industry were scared to death of them. The early experts put together companies to sell cheaper computers or more understandable operating systems or languages. The survivors are Microsoft, Apple, Sun, Compaq, and others. Gone, but important in industry history, are Digital Research (CPM), Commodore, Ashton-Tate, and others.
Experienced, independent developers on average are being contracted at hourly rates we would have laughed at 15 years ago. Contract rates for developing in day-to-day businesses seems to be in the $20 - 40 an hour. This is for doing essentially the same work as commanded $50 -150 an hour 20 years ago. Factoring in inflation and other costs, contract developers are being paid probably a fifth of what they were 20 years ago.
And, like the automotive industry, the product has become easier for the consumer but much more difficult to engineer and troubleshoot.
When a network application of mine puked under FoxPro for DOS, it was either because of my lousy coding, a FoxPro bug, or a network error. 95% of the time I knew within seconds which it was.
When the code in an ASP.NET application pukes, if it's not a coding error you are sometimes in for a long, long troubleshooting session. Is it browser settings? Permissions? Database connectivity? Security policy? Much more difficult to assess. And I get paid a hell of a lot less to figure it out.
On the other hand, my teenage son can easily install an operating system and if was hired to do so by a local computer shop I imagine he wouldn't be paid much more than minimum wage.
Maybe it wasn't a joke after all.
I remember having a conversation with a friend of mine over beers back in the mid-80's. He was trying to understand exactly what it was I did and why it paid so well. I thought for a moment and replied that we were the "priests in the temples in the Dark Ages". We were elite because we knew how to read in an illiterate world. But one day, as technology spread, we'd be the new auto mechanics.
That conversation has stuck in the back of my mind for years and I sometimes look at industry and career trends and hold them against that half-joking prediction.
Now why auto mechanics?
I see a correlation between the automotive industry and information technology.
As to cars, from the late 1800's to the introduction of the Ford Model-T, very few people knew automotive technology. Those that did were well-schooled in every aspect of the cars and were paid well for their arcane knowledge. Operating a car required a far more in-depth understanding of mechanics than today. Pioneers in automotives founded large companies to make cars more understandable, cheaper, and more accessible to the masses - the survivors are Ford, Diamler-Benz, General Motors, and others. Studebaker, Willys, and others were competitive for a time but are now long-gone.
Experienced, independent mechanics today are paid reasonably well but a minimum wage high school kid can do most regular service on a car. However, cars are much more complex mechanically under the hood so, paradoxically, mechanics have to be superior troubleshooters than decades ago, before electronics, ABS, fuel injection, et al.
Looking at personal computer-based IT, from the late 70's to the mid-90's we have a parallel. For about a 15 year period, few people grasped the big picture in how to craft a computer application. Those that were successful at it commanded large sums of money. People not in the industry were scared to death of them. The early experts put together companies to sell cheaper computers or more understandable operating systems or languages. The survivors are Microsoft, Apple, Sun, Compaq, and others. Gone, but important in industry history, are Digital Research (CPM), Commodore, Ashton-Tate, and others.
Experienced, independent developers on average are being contracted at hourly rates we would have laughed at 15 years ago. Contract rates for developing in day-to-day businesses seems to be in the $20 - 40 an hour. This is for doing essentially the same work as commanded $50 -150 an hour 20 years ago. Factoring in inflation and other costs, contract developers are being paid probably a fifth of what they were 20 years ago.
And, like the automotive industry, the product has become easier for the consumer but much more difficult to engineer and troubleshoot.
When a network application of mine puked under FoxPro for DOS, it was either because of my lousy coding, a FoxPro bug, or a network error. 95% of the time I knew within seconds which it was.
When the code in an ASP.NET application pukes, if it's not a coding error you are sometimes in for a long, long troubleshooting session. Is it browser settings? Permissions? Database connectivity? Security policy? Much more difficult to assess. And I get paid a hell of a lot less to figure it out.
On the other hand, my teenage son can easily install an operating system and if was hired to do so by a local computer shop I imagine he wouldn't be paid much more than minimum wage.
Maybe it wasn't a joke after all.
Subscribe to:
Posts (Atom)