Tuesday, September 27, 2005
My (Markus) Interview on The Fox Show

Here is something that almost fell through the cracks of hurricane Rita:

Last week I gave an interview to The Fox Show (click here for a link to my individual episode). Looks like I went overboard again. :-) The whole thing is almost an hour long, which means I keep my record in terms of getting the longest shows when I give interviews (the same happened on .NET Rocks!).

The interview mainly focuses on using VFP and .NET together, and why that is important (or at least figuring out whether it matters for one personally, or not). I also talk a bit about CoDe Magazine, the Milos Solution Platform, and communities. I thought it was a fun interview to do, and I think there is lots of stuff there for VFP and .NET developers alike.

Sunday, September 25, 2005
All Systems Back Up and Operational

We just managed to completely restart all our servers and are back to what should be normal operating mode. The power situation may still be a bit shakey and we could experience additional outages, but most likely, we should be OK.

Really, not all that much happened where we are, even though we were pretty close to the storm. For those interested in the details, check out this blog.

Thursday, September 22, 2005
Hurricane Rita Downtime

EPS and CoDe Magazine offices will be closed for the rest of the week due to Hurricane Rita. Most likely, our servers will be down for the next few days, so none of our sites will be operational, and we will most likely not have any email access either.

Tuesday, September 20, 2005
PDC 05 - A Recap

PDC rocked this year. A lot of new technologies were shown, and many of them are important for all modern developers, including VFP people. Here's a quick recap:

From an EPS and CoDe Magazine point of view, we had a great conference. We were a media sponsor, had a double-sized booth, and a lot of traffic and excitement going. Our magazines were in all the attendee bags, so we were able to do other things at the booth. We gave away tons of bags that ended up showing up everywhere (we even saw a few at the LAX airport a few days later). We also had temporary CoDe Magazine tattoos. If you were spotted wearing one, you were eligible to win cool prices, such as a PSP. People loved this one, and we had a lot more people with tattoos than we expected. Some in places we hadn't expected either. ;-)

So long story short: We probably had more than our share of exposure at PDC. Kudos to the CoDe staff, in particular Tammy, Cleo, and Tom, who came up with all the great ideas. (And also thanks to Tammy's mother who helped out at the booth!)

As far as PDC in general is concerned, I was also rather pleased. There seemed to be a lot of excitement around new technologies. Here are some that I thought were cool:

1. Windows Vista. No need to say more.
2. Avalon (excuse me: Windows Presentation Foundation): The Northface demo at the keynote rocked. Some of the other examples (like the photo album) were pretty cool too. There were tons of session on WPF, and many of them were very valuable. VFP does not support Avalon natively of course, but Avalon UIs can still access VFP components through COM interop.
3. Windows Communication Foundation (formerly "Indigo"): Lots of great sessions on this too. Indigo is basically a new generation of web services (simplified said). Indigo replaces a lot of technology like Web Services, DCOM, Remoting, MSMQ, and a lot more. It can of course interact with all these technologies, but the real power of Indigo comes to light when both sides of the connection use Indigo (as would be the case in a distributed application). VFP of course can interop with Indigo through web services and DCOM protocols. I am still hoping for a tigher integration though. But considering that it is all based on managed code (".NET code"), it is probably a bit far fetched to expect that.
4. Windows Workflow Foundation: This was a new announcement at PDC. Pretty nifty. Workflow built into .NET/WinFX on a framework level. I have not yet had a chance to look into how and if this can be used from VFP.
5. Microsoft Expression: One of the highlights in my book. MS Expression is a suite of new design tools, including a new drawing program that is a mixture of pixel and vector based drawing. (Currently code-named "Acrylic"). Then, there is an Avalon/XAML designer called "Sparkle". This is a pretty cool piece, especially if you are into advanced UI design. And there even is a new web designer called "Quartz". So lots of new stuff here for both win and web developers. Check it out at www.Microsoft.com/Expression. Of course, all of this is a .NET exclusive...
6. LINQ (Language Integrated Query): The second major announcement at PDC05. C# and VB.NET will have query features integrated right in the language similar to how it workes in Visual FoxPro (except LINQ is a lot more powerful). This allows the developer to use SELECT-style query operations on data sources as well as pretty much anything else, such as XML and collections of objects or arrays. You want to select data from a database that is joined with controls on a form and data coming from XML and return a collection of business objects? No problem with LINQ! Unfortunately, this stuff will not release before Orcas (the next version of VS after 2005), but you can already get early bits! We will provide some in-depth info on this in the upcoming 2 issues of CoDe Magazine (first to the punch again ;-) ). You can also expect a lot of information about LINQ on the www.VFPConversion.com site.
7. Atlas: ASP.NET controls that use the new AJAX paradigm (which turns HTML-based interfaces into a richer experience). Pretty cool as well! (And once again a .NET exclusive...)
8. SideShow: Aux Displays are now called SideShow. This is still a very very cool feature.
9. Office 12: Quite radically different from an interaction (UI) point of view. No more menus and no more toolbars. Looks pretty neat, but I haven't had a chance to play with it myself. Can't wait to start using it though...

And there was a lot more. So there will be a lot of stuff to talk about for CoDe Magazine and also on this blog! There are a lot of very cool technologies on the horizon. At this point, practically all of these technologies are based on the Managed Platform (".NET"), and the few occasions where this is not the case one needs to use C++. But of course, we see it as our very purpose to make sure VFP developers get the information and tools needed to use these technologies as well.

So stay tuned...

Monday, September 12, 2005
Off to PDC

This year's main event is finally upon us: PDC (MS' Professional Developer Conference) in L.A. In fact, I would even consider this to be the main event of the last 2 years, since PDC is not an annual event. This is one of the few conferences I really am still looking forward to.

CoDe Magazine is a Silver Media Sponsor, so we should be fairly visible at the show. If you want to talk to me/us or our authors and editors, stop by at our booth (#516)!

See you in L.A.!

Saturday, September 10, 2005
Southwest Fox: The New Number 1 in US Fox Conferences?

The (Visual) FoxPro DevCon has had quite a turbulent history, from the humble beginnings in Toledo (Fox Software), to the "official" Microsoft FoxPro DevCon, to a joint operation between Tech Conferences and Advisor, to DevCon the way it is today, hosted by Advisor in Las Vegas.

DevCon is still a valuable event, but compared to previous years, it has changed drastically. The value in terms of content is still there, but the community part (by many considered at least as valuable) is all but gone. At the most recent DevCon, hardly anyone from the old "Fox Gang" was even there. Bummer!

Also, many other events that covered FoxPro in the past are no more. Whil Hentzen's Great Lakes Great Database Workshop is no more. FoxTech Toronto is no more. And even for Advisor's DevCon, no announcements have been made about when and where future events will be help (which is highly unusual for Advisor, and makes me wonder...). Only DevTeach Montreal (a conference we are heavily involved with) has a significant amount of VFP content. Beyond that, one has to go to Europe or South America to find FoxPro events (such as the dFPUG conference in Germany, or the Czech DevCon in Prague...).

But there is a new event that seems to be taking the spot of the "can't miss conference": Southwest Fox!

There seems to be a lot of excitement about this conference. The community seems to have adopted this conference as "their" event, and there are many great speakers. And while I am not sure what Microsoft's official take is on the conference situation, I am getting the impression that they have taken a liking to this conference as well. So as far as I can tell, this is going to be the event to be at for people interested in VFP conferences. Plus, the cost is real reasonable too!

So will we be there? Yes. We are still working on details though, but Rick Strahl will be there for sure (in fact, he is even hosting a separate event for West Wind users). Rod Paddock is scheduled to be there as well. Personally, I have a conflict, but I am hoping to work that out as well, so I think there is a good chance I might go too! I sure wouldn't mind hanging out with the Fox Gang again...

Wednesday, September 07, 2005
More About Interfaces: A Specific Example

One of our customers who currently is in the process of moving his development efforts from VFP to .NET recently sent me a very good question about interfaces. I get similar questions a lot and they seem to be very typical for VFP developers who are moving to .NET (not surprisingly). So I decided to put some of it on this blog:

Markus,

I read your article in Foxpro Advisor May 2004 about interfaces and polymorphism, but I'm still a bit puzzled by your philosophy in Milos about the use of interfaces. I see that you might want a virtual method to have parameters whose types are interfaces rather than (abstract) classes---so that other classes that do not derive from the given abstract class may use the method. But I'm not clear on why your have so many methods and properties return values that are interfaces. For example,

Why does BusinessEntity.GetBusinessObject() return generic type IBusinessObject instead of class BusinessObject? Why is the property BusinessEntity.AssociatedBusinessObject of type IBusinessObject instead of BusinessObject? Why does EntitySubItemCollection.GetItemObject() return generic type IEntitySubItemCollectionItem instead of the specific class? Similarly, why do Add(), GetItemByIndex(), ParentEntity and this[int] have return types that are interfaces, not classes?

Theoretically, I suppose the answer is the same: so that these methods and properties may be used with classes that do not inherit from the provided or usual parent class. I guess I'm just having trouble imaging situations where this would be useful.

Also, I'm wondering if it would be advisable to add overloads of the these methods and properties in my application-specific subclasses that return object of application-specific classes. For example, is it OK to have an overload of CorporateUnitBusinessEntity.GetBusinessObject() that returns a CorporateUnitBusinessObject? Or would you advise just using the interfaces?

If you have time, could you explain this a little more, or refer me to other articles about it? Thanks.

Note: This customer is using our Milos Solution Platform. The particular objects and classes he refers to are all Milos components. However, everything discussed here applies for all .NET development.

Here's the answer I sent:

Basically, the interface defines the contract. It says "this is what we want a business object to be like, and we shall now refer to it as IBusinessObject". From that point forward we really do not care what someone does to comply to this contract as long as they do.

Now of course, we would not want everyone to implement their own business objects from scratch, so we provide the default implementation in the form of the BusinessObject class. This makes it very easy to conform to the standard.

You could also conform to the same standard by using a different class that implements the same interface. For instance, we are about to provide an EnterpriseBusinessObject class which works better with Enterprise Services. That object has to be subclassed from a special class in the .NET framework. Had we not provided an interface, then this would not be possible, because we would have to inherit from BusinessObject. But since we could not inherit from BusinessObject and the enterprise class from the .NET framework, this would not work.

Similarly, it could be that someone you want to sell your app to already has other infrastructure in place that does data access and other things our business objects do. If you want to use that person's object in your app, then all you have to do is add an implementation of IBusinessObject, and you are done. But if the interface was not available, then you'd have to change the inheritance structure of the other person's class, which (if possible at all) would have almost certainly broke that object.

So using an interface provides an extreme level of freedom, reusability, and integration. In addition, providing the default classes provides great simplicity. We have a general rule that for everything we do, we first create an interface and then create a default class that implements that interface.

And as an answer to the following part of the question...

"Is it OK to have an overload of CorporateUnitBusinessEntity.GetBusinessObject() that returns a CorporateUnitBusinessObject? Or would you advise just using the interfaces?"

...I sent this:

Yes, absolutely. You do not even really have to worry about this. GetBusinessObject() always expects an object of type IBusinessObject as the return type (you can only override that method. Overloads can only be created by different parameters... return types are not considered for overloads, since an app can completely ignore return types).

Anyway: You do not really have to worry about the particular type in this case. Consider this example:

public override IBusinessObject GetBusinessObject()
{
    return new CorporateUnitBusinessObject();
}

Now while this looks like we are returning the type CorporateUnitBusinessObject, we really are returning IBusinessObject, because since CorporateUnitBusinessObject inherits from BusinessObject we automatically have an object that implements IBusinessObject (since BusinessObject implements IBusinessObject). So in fact, this object IS of type/interface IBusinessObject (and then some... but that is ignored here and all the methods that call this method do not care about the extras anyway).

So in essence, the above example is exactly identical to this:

public override IBusinessObject GetBusinessObject()
{
    CorporateUnitBusinessObject obj = new CorporateUnitBusinessObject();
    IBusinessObject ref2 = (IBusinessObject)obj;
    return ref2;
}

This is where the strongly-typed nature of .NET really kicks in. Since we wanted to creat a generic way for all business entities to get a handle to the associated business object so tasks such as saving can be handled automatically. Of course, in a strongly typed language, we had to specify a type, but what was that type going to be? BusinessObject? In that case we would have given up a lot of flexibility since we would have entirely relied on inheritance, which is a somewhat limited technique, since a class can only inherit from one other class. Should we have typed it to be CorporateUnitBusinessObject? Obviously not an option, since we had no clue someone was going to create that object. Should we have used type "Object"? That would have nullified strong typing and all the benefits and quality improvements that come along with it. So using the interface really makes generic programming like this possible in .NET and at the same time allows holding on to all the quality gains.

For all VFP developers, this is a very unusual thing to do though, because we just never had the concept of interfaces in a meaningful manner. I always find it very easy to explain the fundamental concept of interfaces, but once it comes to the implications (this is only one example), then only real-world implementations do the trick.

Interfaces are very interesting. They are so foreign to VFP developers, yet they are so helpful in creating flexible and powerful application architectures. Interfaces are easy to explain but the consequences are hard to comprehend until all of a sudden, one day you will say "heck... now I got it! How could I have ever done without interfaces?". Maybe this message will help you to get a little closer to that point (unless you already reached it...).