Wednesday, 14 March 2007

The Fox is dead. Long live The Fox.

I suppose once Wally blogs about a topic, it has broad developer interest. I read the news on Visual FoxPro specific blogs earlier in the day, and I emailed the story to my coworkers.  Today, Microsoft announced the end of active development on Visual FoxPro.

Personally, this is not a surprise in any way.  Ever since the announcement that VFP would never move to 64bit, I've known this day was coming. Furthermore, I spent a day with the Microsoft PM for VFP in January, and he gave no indication that the future would be any different. With that said, I want to share my thoughts on what this announcement means for Visual FoxPro applications and developers.

On a DotNetRocks episode, Don Box was asked if COM is dead.  His response applies to Visual FoxPro as well.  Don replied, "COM isn't dead, COM is done."  That is the best summary I can think of regarding this announcement.  Visual FoxPro isn't dead, Visual FoxPro is done.  We can certainly unpack that in a number of ways, but I will mention two details to back up that statement.  Microsoft is releasing service pack 2 for Visual FoxPro 9 to make VFP fully Vista compliant.  Microsoft has developed a set of .NET managed extensions to VFP named Sedna, and released these extensions as shared source. 

So, we have a stable, Vista certified platform with a bunch of Microsoft developed hooks into the .NET framework.  They have provided VFP developers everything they need to maintain their existing apps on the most recent version of Windows, and they have provided the tools to extend those apps using .NET.  Now, I don't think anyone is suggesting green-field development with Visual FoxPro, but any existing investments are fully support until 2015, and extensible with development tools that are under active development.

Furthermore, Microsoft has provided a plethora of materials to help experienced VFP developers leverage their existing skills while moving to a new language and development environment.  Here are some of my favorites:

  • .NET Samples for Visual FoxPro Developers
    This is a nice collection of solutions introducing VFP developers to .NET basics using Visual Basic.  I recommend VFP developers download these samples along with Visual Basic Express.
  • Visual FoxPro Toolkit for .NET
    I love this toolkit, although I've never actually used it.  Let me explain, this toolkit provides a DLL which users can register to access VFP syntax within Visual Studio in either C# or VB.  I've never actually done that.  I use the help and the provided source code as a reference when I want to learn how to do something in .NET for which I already know the command in VFP.
  • Interop Forms Toolkit
    This is super cool.  This toolkit was developed for VB6, but works great in VFP, or any other COM enabled language.  It provides a set of COM wrappers around a Windows Forms component, so that you can launch a .NET form from within your VFP app.  This solution is rock solid and fully supported.
  • Interop UserControl
    This last tool is my very favorite.  It is not currently supported, but I've been in touch with the developers, and they are making progress on it.  They have even fixed a bug that I experienced when using this in VFP!  Quite simply, this is a project template which enables you to create a .NET user control, and register it as an ActiveX control, allowing you to display new .NET features within existing VFP forms! This is truly the secret sauce for extending existing VFP applications.

Let me explain the title to this post.  Truth be told, Visual FoxPro development will continue beyond Microsoft's current product timelines, but it will  not be called Visual FoxPro. Henceforth it will be known as LINQ, ADO.NET and SQL Server.  Members of the Visual FoxPro development team have been working on Visual Studio and SQL Server technologies for years.  Today's announcement means that they will be doing that full time. 

Alan Griver gave a presentation on LINQ at the East Tennessee .NET Users Group in January, and he made the best association I've heard for the connection between VFP and LINQ.  Alan said, "In Visual FoxPro, all data is converted to a common format called a cursor, and all data operations are made against the cursor, then updates are sent to their data source.  With LINQ, we replace the cursor with collections of objects."  That statement helped seal my enthusiasm for LINQ and the future of data access in Visual Studio and .NET languages.

I must emphasize that there is nothing to be afraid of.  There is no bad news today for VFP developers.  There is no conspiracy against Visual FoxPro.  This is a natural and logical business decision by Microsoft.  All the resources you need to continue developing data-driven software using RAD tools are available today, or coming in the next release of Visual Studio.  Let today's announcement be a reminder to you to download some code samples and read some articles so that you will be prepared for Orcas.

I want to close with a quote from Visual FoxPro MVP Craig Boyd, "If Microsoft is trying to kill VFP, then they're doing a piss-poor job of it." Amen, Craig.



 Thursday, 08 February 2007

Speaking at NashDotNet

I'll be speaking at the Nashvile .NET User Group tonight.  The topic is Windows Services, but I'm sure to get into my opinions of developer tools. :-)  If you are in the area, stop by.


 Saturday, 09 December 2006

Lambda, It's not a Fraternity

I did not study software engineering, or computer science in school.  When I began writing software for a living, I thought this was a liability.  I had a good long conversation over a bottle of Oban that changed my mind.  My good friend Wade has a BS in Computer Science and a MS in Industrial Engineering.  He also has plenty of bona fides in industry.

I expressed my concern about lack of formal training to Wade, then asked what he had learned in his CS studies.  His reply could not have pleased me more.  He told me that he came up with his own language and compiler implemented in Pascal.  I asked if this experience had directly contributed to his career, and he replied that it had not. 

While I believe credentials are important at the beginning of a career, I am more interested in what a job candidate has done than what they have studied.  I also knew then that despite having a MS in Education, I had learned the majority of what I found to be useful knowledge in that field through my own reading and experience.

That is why, dear reader, I was able to march boldly into a career in which I had no formal training and thrive.  I stopped seeing my lack of credentials as a liability.  I was already producing working software at my job, and I was studying like a fiend at home.  This continues to be my practice, and I have never regretted my lack of academic credentials, until now.

I like to follow the news at Reddit.  It seems there are a bunch of alpha-geeks who hang out there, and as a result there are an abundance of links relating to Lisp, Haskell and other "exotic" programming topics.  I read these articles out of curiosity, but I never found an application for the features that were promoted as world changing.

One of the topics that I have found particularly interesting is functional programming.  I don't fully understand it, but I have some idea of how it differs from the imperative programming that I do every day.  Recently some terminology from functional programming has popped up in my "normal" programming studies. 

Microsoft is currently cooking up an extension of it's ADO.NET data access technologies called LINQ.  This is a very interesting development, and I have been following along without actually trying the technologies yet.  One concept that shows up in functional programing and LINQ is that of Lambda Expressions.

This is where my lack of formal training shows up.  I never studied Lambda Calculus, and Joel Spolsky had me convinced that it was a useless pursuit anyway.  Now I have a keen interest in the application of Lambdas in my work.  I will attempt to share what I have gathered on the topic, as it pertains to practical software.  Any correction or clarification of this discussion is welcome and encouraged.

My current take is that Lambdas are a way of expressing value without actually storing the value in memory.  This preserves all meta-data about how the value was derived and how the values used to calculate our current value were derived.

At any point then, we can evaluate the whole thing and output a value, but we don't store the value explicitly.  The first thing I can relate this to is function pointers in C.  A pointer can point to the address of a value in memory, or the address of a function.  That's a rough association, but I need to start somewhere.

Another parallel I see is to dynamic evaluation at runtime.  I program daily in Visual FoxPro, and when I work in C# or VB I pine for the dynamic evaluation available in VFP.  While most loosely typed, or duck typed, languages can perform dynamic, runtime evaluation, VFP has true macros, and I miss them when they are gone.  Could it be that LINQ will allow me to interpret, compile and evaluate expressions (code) on the fly in .NET?

It is not only my study of LINQ that has piqued my interest in lambdas.  I have lately been pondering a problem in my free time.  I do this even though no one has assigned me a task.  When I find an interesting problem, I wonder how I would solve it.  I suspect most software developers do the same. The problem is this: How would I implement a long running (hours or days) process so that changing inputs and/or constraints do not require that I re-run the entire process to get the new results? 

My first reaction is to store all interim calculations in a data cube, so that I can recover as much of the previous work as possible before I have to recalculate.  This is a reasonable approach to a point, but I cannot calculate all possible outputs in my original run, so I will only be able to go back to the point that outputs begin to change, and re-run the process from there, and in some cases this would mean running it from the beginning.

It seems that in this scenario the business rules, or constraints, matter as much as the explicit inputs. In fact, the business rules are inputs to the expression building engine, while the data inputs are passed to the built expressions.

I conceive of this like a query execution path in a SQL engine.  Once the system has determined how best to evaluate the query, much of the work is done.  You can then change the inputs to the query and the server will evaluate it the same way it did before.  My hypothetical, long running, complex process benefits from a similar approach.  Determining how best to evaluate the inputs is half the work, and this is defined by the constraints in the same manner as the table schemas and indexes determine how a SQL engine will evaluate a query.

It now appears imperative when executing a long running process with high CPU requirements that we record how we solved the problem as well as what the solution was.  In this way we could run the process from the start with new inputs and simply re-evaluate the pre-built expressions.  We could also change our constraints and only rebuild the expressions affected by the changes. 

This approach also allows us to solve the problem iteratively.  By setting thresholds on how detailed we want our expressions to be, we could form estimates, and then run the process again building ever more detailed expression trees, asymptotically approaching a precise answer.

This appears to be what functional programming is built on.  This lack of "side effects" also has other practical advantages such as thread safety and high parallelizability.  At least one functional programming advocate is willing to argue that these advantages qualify functional programming as a silver bullet.

 In this context, a silver bullet means that the technology provides an order of magnitude improvement in productivity and or performance.  This is a bold claim, but some of the arguments are persuasive, if not for a full order of magnitude, then for significant improvements. My favorite argument from the above linked essay applies directly to my hypothetical long running process:

The order in which statements are executed, and hence the execution trace of the program, is completely irrelevant. Thus execution order is revealed as a major source of accidental complexity which Brooks mistook for essential complexity, but which is eliminated in pure functional programs.

 If execution order is truly inconsequential, then we can modify our constraints and inputs constantly in order to arrive at the optimal result.  It remains to be seen if I can design a solution of this type in .NET with the new LINQ extensions, or whether I'll need to dive into Lisp, Scheme, Haskell, Erlang et. al.  One thing that is certain, is that I'll find out, and I'll share my understanding here.  Now, if you'll excuse me, I have some reading to do.


Everybody's Got One

I like to write code.  It isn't the best way to solve every problem, but when it is the correct solution, I love to lose myself in code.  Unfortunately, I seldom start from a clean slate.  Most tasks involve correcting, extending or interacting with "other people's code."

This is why the post My Personal Pet Peeves I See in Other People’s Code by Ramon Leon was so much fun to read.  I know where he's coming from, and I enjoyed his ho holds barred ranting.  Sometimes you just gotta' let it out.

Still, I found myself arguing with Ramon in my head, "Hey, that's the way I write code.  There ain't nothin' wrong with that!"  Except, maybe, just maybe, there is, unless there isn't.  My point is that while we all have opinions, it is a slippery slope to create too may concrete rules regarding style.  Like the pirate's code, "they're more like guidelines."

So, what follows is my rant about Ramon's rant.  If I don't argue with one of his points, then the reader should assume that I share it.  Let's get started:

Ignorant Prefixing:  I agree, except in cases where there is already a large code base using this style of naming.  Then the rule for consistent style takes precedence.

Single Exit Points:  I largely disagree.  If a method is small enough to fit on a single screen, it is simple enough to have a single exit point.  My one exception is to put something like the following at the top of a method:

If (noChanceInHell) return false

1000 Line Methods:  I like the rule of not having to scroll when reading a method, although in practice, I break the rule as often as I comply.  I wholly agree that the method name should be the only documentation needed about the purpose of a properly atomic method.  In fact, more developers need to read chapter seven of Steve McConnell's excellent Code Complete to learn how to properly name routines.

Declaring Variables at the Top of a Method:  I agree with the dictum to declare variables at the minimum scope, but when the minimum scope is the method,  as opposed to a loop, then I like to see them declared, and initialized, if reasonable, at the top.

Error Code and Switch Statements:  I like to return a bool from my methods.  Many routines are just initializing some environment for the Main Event®.  In such cases I will use the following structure:

LOCAL returnVal as Boolean

returnVal = .F.


  CASE NOT DoThis()

  CASE NOT DoThat()

  CASE NOT DoTheOther()


    returnVal = .T.


RETURN m.returnVal

The reason I can do this, is that I program primarily in Visual FoxPro.  You just can't do this in VB and C# switch statements.  I am bitterly reminded of this every time I work in either of those languages.

I admit to ignorance of the Samurai Principle, and I can definitely see it's application, but there are many cases where I would rather check for a boolean result than do yet another try catch (YATC).

Overall, Mr. Leon's rant is well informed, entertaining, and educational.  Highly recommended.


 Wednesday, 06 December 2006

UML Sucks (Really!)

I recently received a comment on my blog about a comment I made on another blog.  Ain't the Internet great?

Here's the response I sent:

Hello Nick,

Thanks for alerting me to the need for a contact link on my blog. :-)

While I don't use UML, and neither do any of my coworkers, I have mixed feelings about the need for it.  It seems perfectly reasonable that we should agree as an industry on a common set of symbols to represent OOP concepts, but UML has a typical "design by committee" feel. 

In his comments to the "5 Books" post, Jonathan Allen brought up something that I was aware of,  but never expressed precisely.  He said that the object model is the most malleable part of the design.  This is absolutely true.  This is actually the conceptual basis for iterative, agile practices.  The most critical aspect of the initial design, in my experience, is the interface between the UI and the object model.

While changing the UI is frustrating for users, it is not a technical challenge.  Refactoring the middle tier requires discipline to avoid introducing errors, but should not affect other parts of the system.  It is a well designed interface contract that makes for an extensible system.  This is why SOA with its service contracts is appealing.

Unfortunately, UML doesn't address interfaces (or at least poorly addresses them).  It seems obsessed with minutiae in a parody of academic distraction.  The only time I see UML in my daily development is in technical books and articles, and even then a Visio diagram would usually work better.

With regards to your objective of developing "ways to improve UML interaction to be more practical," I encourage you to ignore UML initially and define your problem clearly.  It seems to me that the problem does not involve UML, but the need for communication between developers, sometimes from different cultures, and on separate continents.  You are most likely interested in the visual display of information as it pertains to object oriented analysis.

If I am correct in my assumptions, then I do have some resources to recommend.  As I mentioned in the blog comment that you referenced, Peopleware is essential reading for understanding the human interactions surrounding software development.  For understanding objects, and by understanding I mean grok in fullness, I have found nothing better than The Object Primer.  Finally, when it comes to the visual representation of information, there is only one person you need to study, and that person is Edward Tufte.  Tufte makes mincemeat of systems such as UML.

If you are looking for a software solution to capture design ideas, then you should be familiar with mindmapping applications such as Mindjet or FreeMind.  I also have begun using Microsoft OneNote and have found it useful.



 Tuesday, 07 November 2006

Please Don't Name a File Setup.exe

After doing all the downloading from my previous post I have one big request from the software development community.  Please don't name your install file Setup.exe.  Try instead Setup<Application Name><Version Number>.exe or some varient of that.

I just downloaded the Windows SDK and the file was named setup.exe.  I download all files to the same directory, and decide what to do with them from there.  I don't want to have to rename your file in order to prevent it from overwriting another file with the same name.

While I'm on this little rant, I'm tired of iTunes always downloading with the name iTunesSetup.exe with no version number.  It seems rude to me for Apple to assume users want to overwrite the previous version they downloaded, and thus lose the ability to roll back to a previous version if they don't like the upgraded "features."

Thanks, and have a nice day.


Free Directory Sync Software

A co-worker asked me yesterday if there is a way to use Kdiff3 to synchronize directories similar to BeyondCompare.  I briefly attempted this task in the recent past without success.  It turns out that it can be done, but I went on to look for dedicated file sync/backup software.  Here is a list of what I found:

Whew!  This is obviously a common user need.  I wonder why it isn't baked into the operating system, or if it is, why it isn't more easily discoverable.  I have not evaluated all of these (I've wasted enough time finding the links and making this post :-)), but I have launched all of them that do not require an install.

I'm currently using SyncBack to back up files between an external drive and my local disks.  It is polished, and meets my needs.  Feel free to try the others and post your experiences in the comments.


 Monday, 02 October 2006

Oh, so that's what it takes...

For the past six years, I've been watching the national political debate with fascination and disgust.  I find the "Cult 'o W" stickers especially fascinating.  I wonder how far some of these folks, my friends and neighbors, will go in support of authority and conformity.

This past Thursday I was truly and honestly depressed.  I am a student of history and a patriot.  I love this country and its founding principles.  I have never found evidence of a society with more freedoms and opportunities for a population as large and diverse as the United States of America.

Last Thursday, the Senate voted to dispense with protection of our freedoms guaranteed by the constitution in preference for a more monarchial concentration of power.  I was disgusted.  I wondered if there were any patriots left in Washington D.C.  I again wondered how far people would go to maintain membership in the cult.

Friday, we got the answer to my query.  People are naturally parents first, and Republicans (and Democrats) second.  The cover-up of the sick, predatorial behavior of one congressman has shown the threshold for blind conformity and rationalization.

Michele Malkin is just to the left of Anne Coulter, who in turn is just to the left of Attila the Hun.  Ms.  Malkin is in my estimation a crackpot.  Even she had this to say about the Foley scandal:

There is a time and place for attacking the Dems and the MSM. Now is not that time. Parents need assurance that their kids are safe on Capitol Hill. If Beltway GOP elites can't understand this, they are beyond hope.

I couldn't agree more.

Lest I think that humanity has triumphed, Matt Drudge is around to remind me that some people have no integrity, but only want to be liked by whomever they consider to be the "cool kids."  Here are his truly disgusting remarks on the Foley matter:

And if anything, these kids are less innocent — these 16 and 17 year-old beasts…and I've seen what they're doing on YouTube and I've seen what they're doing all over the internet — oh yeah — you just have to tune into any part of their pop culture.  You're not going to tell me these are innocent babies.  Have you read the transcripts that ABC posted going into the weekend of these instant messages, back and forth?  The kids are egging the Congressman on!  The kids are trying to get this out of him.  We haven't got the whole story on this. 

There you have it, these teenagers were asking for it.  It's their own fault.

To the rest of my countrymen who are as genuinely appalled by the cover-up of this horrible man's actions as me, let's work together to make this a country our children can be safe in.  While we're at it, let's make it a country they can be proud of too.  I would be proud to work with any other American to make that happen.



 Thursday, 21 September 2006

Next time, tell me something I don't know!

Pure Nerd
78 % Nerd, 34% Geek, 26% Dork

For The Record:

A Nerd is someone who is passionate about learning/being smart/academia.
A Geek is someone who is passionate about some particular area or subject, often an obscure or difficult one.
A Dork is someone who has difficulty with common social expectations/interactions.
You scored better than half in Nerd, earning you the title of: Pure Nerd.

The times, they are a-changing. It used to be that being exceptionally smart led to being unpopular, which would ultimately lead to picking up all of the traits and tendences associated with the "dork." No-longer. Being smart isn't as socially crippling as it once was, and even more so as you get older: eventually being a Pure Nerd will likely be replaced with the following label: Purely Successful.

Now it's your turn. :-)



[UPDATE]  I found this test, and only scored 72.

I am nerdier than 72% of all people. Are you nerdier? Click here to find out!
 Wednesday, 20 September 2006

FoxForward Conclusion

I skipped morning sessions on Saturday so that I could prepare some changes for my demo that my coworkers recommended.  I did make it to lunch, however.  <S>

In the afternoon, I saw David Stevenson's sessions on the CursorAdaptor and XMLAdaptor respectively.  David showed some interesting functionality he had implemented in his CursorAdaptor subclasses.  I'll need to wade through the code to fully absorb what he showed.

David's session on the XMLAdapter started as I would have expected, comparing XMLAdapter functionality with CursorToXML() and XMLToCursor().  Things got more interesting when he began working with the XMLTables and XMLFields collections directly.  By the end, he was loading schema-less XML with embedded elements and showing us how to use Xpath statements to map this format to related cursors.  This tip alone is worth the price of admission to this conference for any developer who has spent his time trying to solve the conundrum of emended elements without foreign keys.

Saturday evening at the Ale House I tried a delicious local brew called a Sweetwater420.  I also had a great time talking with other attendees.  I especially enjoyed meeting Ed Leafe.  Ed is the author of the Business Object base class in CodeBook.  I have spent many hours studying that code and learning from it.  It is satisfying to have the opportunity to thank someone in person for helping me along my way.

While we were talking at dinner, I was reminded that Ed is the source of one of my standard practices.  It was in Ed's code that I first saw the GarbageCollect() method which NULLs out any properties with values of VarType = "O".  These days I use Bindevent() to bind destroy to my CollectGarbage() (renamed to fit the coding standard :-) ) method in my base classes.  orphaned object references are one of the most frustrating problems to debug in FoxPro, and this simple fix removes them forever.

Next I moved to Craig Boyd's booth, because I hadn't had the opportunity to do more than introduce myself to him.  Craig is a passionate guy, and we got into a discussion of the FUD (fear uncertainty and doubt) being spread by some parties regarding Visual FoxPro and .NET.  I love these type of discussion.

Sunday morning was showtime for me.  I spent the morning testing my demos one more time.  Saturday night, I discovered a bug involving spaces in a file path, so I felt it was prudent to test everything one more time.  Although my session was sparsely attended, the audience seemed truly interested, and actively engaged.  I enjoyed this session, even though I was the presenter.

After my session was lunch, where I won a VFP hat!  I spent some time on the back patio listening to Ed Leafe and John Koziol swap stories about conferences past, and ask each other "where are they now" about members of the VFP developer community.  This was a nice bonus.

The last two sessions, for me at least, where Craig Boyd's discussion of cryptography, and Bo Durban's discussion of the new GDI+ classes from the VFPx project.  These were both awesome sessions.  I already use Craig's vfpencryption.fll in my work, and he showed me many new uses for it.

I've been working with GDI+ lately using both the flat API, and the VFP foundation class.  Bo's session showed me that I need to stop wasting my time and focus on the VFPx class library.  There is more in there than I can possibly relay.  Bo had a nice interface to launch samples and then show the code.  When I got home, I downloaded that library and found that the form Bo used is included in the .zip file.  In fact, there is a .APP file you can run and see most of what I saw without driving to Atlanta.

The biggest surprise to me was that the library included a class for accessing resources in uxtheme.dll.  I have seen several attempts by VFP developers to produce custom controls that reproduce the visual style of Windows XP.  The problem with every implementation I had seen before, was that they mimicked the default blue theme.  If the user ran a different theme, the Visual FoxPro control would not display the new visual style.

By documenting the API to uxtheme.dll for VFP developers, the VFPx developers have made this issue a thing of the past.  I have already begun implementing a Theme Explorer UI in the style of the VB app that pointed the way for the VFPx team.

Speaking of VFPx, an audience member offered to help work on one of my proposed Team Foundation Server tools after my session.  I told him I would speak to Craig about putting it in VFPx.  Craig told me where to find the application form.  I've since submitted my application, and I hope to be contributing to VFPx soon.

In summary, I think Kevin Culley did an outstanding job of putting this conference together.  I predict that in the coming years there will only be two VFP conferences worth attending.  Southwest Fox in the West, and Fox Forward in the East.  I know I'll be back next year.