Bring It On

The Linq query syntax in C# is almost like a SQL but not quite. Example:

from c in db.Customers
where c.City == "London"
select c;

Why is the order of select/from/where upside-down? Because this is more natural and SQL was wrong all along. Just kidding

To illustrate my point better, look at this SQL query:

SELECT Foo.Something, Foo.MoreOfTheSame, Foo.ColumnName,
       Bar.LastName as BarLastName, Bar.FirstName as BarFirstName,
       Bar.NeedsExplanation as BarNeedsExplanation
FROM AVeryLongNameForFoo Foo
LEFT JOIN AVeryLongNameForBar Bar ON
Foo.ID = Bar.FooID

If you’ve been writing SQL for years you probably wonder what’s the problem here? For me, it’s mentally parsing the query – in order to see what Foo is I needed to parse the text to the point where the table alias is defined (in the FROM part). For a computer tool this is even more difficult, in fact it’s impossible to provide intellisense at the point where you just typed SELECT Foo.[what should go here?].

Contrast this to the C# Linq example where both you and the compiler (or the IDE) know what each of the elements are at each point in the query. A win-win I’d say.

In my last post I showed how easy it is to add syntax sugar with extension methods. But that’s not all – even though from the call site the extension method looks like any other, it is a different beast altogether. This is obvious from the signature of the extension method – we are explicitly expecting the reference to the object of the extended class as the first parameter, unlike with the regular methods where this reference is implicit. If that’s really the case, what happens if you call using null reference? Assuming you check for null, this should work, right? It does! Here’s an (admittedly contrived) example:

using System;
using System.Linq;

public class Foo {
  public int Bar = 2;
}

public static class Extensions {
  public static bool IsTwo(this Foo foo) {
    return null != foo && 2 == foo.Bar;
  }
}

public static class Program {
  public static void Check(Foo foo) {
   Console.WriteLine(string.Format("The foo {0} two", foo.IsTwo() ? "is" : "is not"));
  }
  
  public static void Main() {
    Foo foo1 = new Foo();
    Check(foo1);
    Foo foo2 = null;
    Check(foo2);
  }
}

If the IsTwo was regular method, calling foo.IsTwo for the second time would be using the null reference foo2, and we would get a null reference exception. Instead, the output of this little program is:

The foo is two
The foo is not two

Use with caution.

Ruby is a very cool language, especially for meta-programming. The ability to extend any class is very powerful and can lead to a nice set of convenience methods. Rails in particular adds many, of which some are really popular since they read almost like English: 10.minutes.ago.

The .NET 3.5 does not bring us just LINQ and related functionality but also extension methods – a way to add a method to any class. This allows you to fairly easy replicate the example from above:

using System;

public static class Extensions {
  public static TimeSpan Minutes(this int minutes) {
    return new TimeSpan(0, minutes, 0);
  }
  public static DateTime Ago(this TimeSpan span) {
    return DateTime.Now - span;
  }
}

public class Program
{
  public static void Main() {
    DateTime now = DateTime.Now;
    Console.WriteLine("It is now {0}, 10 minutes ago it was {1}", now, 10.Minutes().Ago());
  }
}

You must reference System.Core.dll and implement your extension methods in a static class (whose name is not important). All extension methods must be static and have special first parameter this which denotes the target type you are extending. Running the above example produces:

It is now 31.8.2007 11:17:20, 10 minutes ago it was 31.8.2007 11:07:20

If you detest parenthesis, code this in VB.NET and you'll get almost a replica of Rails syntax.

Just lost three hours on this, hopefully the story will be useful to someone else too. I’ve been trying to use the WeakReference class for caching. The usage is simple – I have a (singleton) factory object which spits out objects of a certain class, let’s say Widget. At the same time the factory caches the Widget object so that if someone else asks for it, the same copy is returned (based on some criteria). In order not to keep the Widget objects in memory when nobody is referencing it, the factory keeps a WeakReference to a Widget, not a regular (strong) reference to it.

In an isolated (simplified) test case everything worked fine. I would produce one Widget object (thus storing WeakReference to it in a cache) and return it. Then I would make another WeakReference to the same object, then nullify the strong reference, call GC.Collect and test if the second weak reference is null. Like this:

Widget wg = WidgetFactory.GetWidget("Round", 32);
WeakReference wr = new WeakReference(wg);
wg = null;
Thread.Sleep(1000); // wait until Widget is constructed
GC.Collect();
Debug.Assert(!wr.IsAlive);

But wait, what’s that Sleep doing there? Well, my real test was actually failing all the time. I looked, then looked again in my factory code and there was nothing out of the ordinary there. Or at least it seemed like nothing strange was going on.

Turned out that Widget is constructed by asynchronous fetch of data from somewhere. To do this, Widget called ThreadPool.QueueUserWorkItem passing in an anonymous delegate wrapping its method. This was the second strong reference to the Widget, thus the weak reference stayed alive.

Duh.

Besides from missing the new/official name for the Visual Studio “Orcas” (it’s 2008 apparently, but might not ship in 2008) I completely missed one interesting low-key announcement from Microsoft: there will be a new product coming with the 2008 release called “Visual Studio Shell”.

It’s easy to explain what this is: it’s a GUI shell part of the regular Visual Studio, but the contents are up to you. Differently put, it’s a foundation for you to build your own tools based on the Visual Studio GUI platform. Doesn’t this sound familiar? Doesn’t Eclipse RCP offer similar set of functionality?

Yes and no. Visual Studio Shell is meant to be used for the development of IDE for custom tools and programming languages. In one of the deployment scenarios, your components will integrate into full Visual Studio (if installed on the target machine). In another, the shell and your content are installed as a standalone application. In both cases, the IDE is optimized for languages and tools but not for any kind of GUI application.

This is an important point. While some developers enamoured by their IDE might think it’s a good idea to build an end-user application that looks exactly the same as their IDE, end-users disagree. For most applications, zillions of dockable windows only add to the UI overload and confusion. I’ve been there and done that: only the most complex enterprise applications need this level of customizability. Look at mass product like Microsoft Office 2003 – it has task pane that looks like dockable pane, but there’s always at most one open (you can switch to different views inside the task pane though).

Eclipse RCP on the other hand advertises itself as a generic GUI tool. Unfortunately, I see this leading to the development of RCP based end-user apps by overzealous developers. This is not a big downside of the Eclipse RCP platform as such, I just think that it should be advertised for what it is – a tool that rose from the IDE meant for the creation of IDEs and tools. In fact, when you look at the list of available commercial RCP applications, you’ll notice that most of them are tools for engineers. It’s a good thing developers are applying common sense to this issue.

In any case, there are two platforms now for developers to base their tools on, both are free and well established. This is great news for those looking to build custom tools that are not really IDE plug-ins: not only do they get a basic GUI for free, but they don’t have to “force” their end-users to have the “full” IDE installed (in case of Visual Studio, this means that you don’t have to have a commercial version installed which saves money).

We are progressively getting more and more spoiled by the features of a modern IDE . Each new version brings better intellisense, code generation and sometimes even mind reading (that's what it looks like, anyway) features. It’s hard to imagine how could we have ever worked without an IDE.

The feature I’d like to comment on today is background compilation. Jeff complained how C# should have offered it, just like VB.NET does. Ian chimed in asking if IDE could refrain itself from constantly compiling his VB.NET code and do what C# compiler does – wait for user’s explicit action. These are two opposite approaches – is there a better one that could satisfy both sides?

Maybe. Just like VB.NET, Java code in Eclipse is checked all the time, as you type. But the compilation only happens when you save the file. You do get red squiggly lines while you’re typing obviously incomplete statements, but the IDE goes out of your way and even helps you whenever it can. Post-save automatic compilation actually works great and is quite hard to shake off – I miss it all the time when I switch to C# in Visual Studio 2005.

Ideally, this could be a global IDE setting, or per-language one. If you want background compilation (it suites your coding style) turn it on, otherwise don’t. Ian has a point here: it probably has more to do with the way you code than with anything else, background compilation itself is inherently neither good nor bad.

If you are following the .NET related news your best bet is to subscribe to Mike Gunderloy’s Larkware blog. He is a human aggregator – if there’s a download to check out, a blog post detailing some obscure (or not so obscure) programming problem or anything else newsworthy, he’ll catch it and link to it. His blog is an excellent information source for all things .NET related.

Or so it was. A couple of months ago, Mike defected from the camp of Windows developers into the great unknown called Ruby on Rails. Fear not, he’s still doing what he does best - good writing and collecting interesting links from all around the world. His new blog can be found at A Fresh Cup. But it’s completely Rails oriented and Mike’s career seems to be heading exclusively into Rails. What’s “even worse” is that he switched from Windows to (gasp!) Mac OS X

What happened? Mike has been living off the contracting on Microsoft technologies for years. He invested a lot of time and probably gathered a lot of clients over the years – why would he throw all that away?

Some of his own comments and the comments on the forums of the Softies on Rails echo the same kind of sentiment – developers just can’t keep up any more. Microsoft is constantly (re)inventing itself, putting out newer and newer technologies, never stopping to catch a breath. With the rise of transparency this has become even worse (or better, depending on how you look at things) – now we get to try every alpha, beta or RC of whatever chefs in Microsoft decide to lay upon us.

In a way, I was lucky - at the time the .NET (by my own account, the dominant programming technology on Windows for the foreseeable future) came out, I was too busy working on other things. Thus I practically skipped version 1.0, touched a bit 1.1 and jumped fully in with the 2.0. By the time I needed to do GUI I was already exposed to WPF (.NET 3.0) so I skipped Windows Forms (I did a lot of similar work over the years in MFC and don’t want to do it again, thank you very much). The same happened to ADO.NET: don’t even get me started with all of Microsoft’s technologies for data access – Jet, ADO, RDO, UDA, OleDb, ADO.NET and finally DLinq. I thought DLinq might be the one they’ll stabilize on, but apparently I was wrong since next-next version will brings us entities framework.

The others were not that lucky, they absorbed each and every new thing Microsoft put out. That was their job, you know, the thing that puts food on the table.

It just keeps on going. Year after year, just as we adapt to the new wave another wave comes. Unfortunately, in the last couple of years it was impossible to transfer your knowledge forward. If you were a MFC programmer, not many things worked the same in the .NET. If you’re a Windows Forms programmer, just forget everything you’ve learned when you jump into WPF. If you did some Remoting, it’ll be useful but the model is sufficiently different in WCF. Before we adapt to .NET 3.0 we’ll have 3.5. If we’re lucky, we’ll get a bit of break then, but who knows. Look what’s going on with Silverlight (which is in itself a great technology I’ll talk about in another post).

No wonder people are switching to different platforms. The amount of information to digest is staggering and despite the Rails being moving target, Rails is still easier to follow.

My advice to those sticking to Windows? Try to filter the technology and pick (if you’re in a situation to be able to choose) only the technology that’s obviously:

• fundamentally better than the previous one
• is here to stay (I know, recognizing this is a lot easier said than done)

I’d also recommend against spreading thin over all of the technologies Microsoft offers – if you’re a desktop applications guru, don’t try to be a guru for the Web apps, databases and whatnot. Don’t get me wrong – you almost have to dabble in Web technologies and you must know decent amount of SQL even if you are a SOA architect, but you don’t have to know each and every detail.

To those leaving Windows (some actually are trying to run Rails on Windows, which might become  reality pretty soon) and jumping on the Rails bandwagon, I wish you all the best. Rails is a fine piece of technology and Ruby is a great language. I hope you’ll have fun.

Last time I touched this subject was to recommend Charles Petzold’s book. In fact I said something that I’d like to correct now. I said:

If for some reason you must choose only one book on WPF, you should choose Petzold’s.

A new book arrived that changed my recommendation: Adam Nathan's WPF Unleashed. It does not go as much in depth as Petzold’s but overall, due to the use of color for everything (even source code) and a lot of pictures, it fits the need of most of the developers better.

 

 

 It’s funny how after reading the same kind of criticism on Jeff’s blog (Petzold’s book is dry, we want more screenshots and color), the only thing Charles was able to mutter (at first) was that:

Apparently the battle for the future of written communication is over. Prose is dead. PowerPoint has won.

What a knee-jerk reaction! I definitely never expected this from an accomplished author.

There is no argument here as to whether the content is more important than form. What people as saying is that you can’t have UI book without a single screenshot!

Finally, my overall recommendation still is: if WPF is central to your future work, buy all of the books you can get your hands on, assuming the book got good reviews on the blogs of people whose opinion you respect. Commenting on Charles’ reaction above, Don Box said:

If a given technology is central to what I’m building, I’ll buy many books on the topic based on the principle that I will opportunistically glean value from them at some point.

I couldn't have said it better myself.

Oh and by the way, Chris Anderson’s WPF book is out (he is one of the architects on the WPF team).

 

 

 

You’ve read about this many times – hobbyists, beginners and accidental developers prefer Visual Basic over other languages. I don’t disagree in principle but would like to point out why.

Historically, VB was the only environment that offered easy GUI development. Beginners don’t like console applications, they want forms and buttons. Thus it’s not the language they are gravitating toward, it’s the IDE.

That said, beginners also don’t like strict rules. They don’t want to strictly type the variables nor to even declare them at all. VB allowed all that, but so did Python and Ruby. Yet they did not have a fancy IDE with drag-and-drop GUI creation.

Don’t forget the horde of hobbyists who used to program in BASIC (all capitals) in the old days of 8–bit and 16–bit computers; Visual Basic is a BASIC after all, isn’t it?

Visual Basic has been and still is quite a chatty language. For beginners this is great – you don’t need to overcome a steep learning curve as the code is immediately readable (code is read many times more than it is written). Since you’re not gonna write a ton of it you never get tired of long lines and lots of words. Compare this to the cryptic curly braces used in C++/Java/C#, semicolons everywhere etc.

This deliberate toning down of VB continues to this day. For those who wish to do “real” programming with VB.NET (the only supported descendant of the VB languages branch on Windows platform) this hand holding can become quite a nuisance. Recently I was trying to explain the fundamental advantages of the generics to my wife (she’s trying to get Microsoft certified and is using VB.NET). I made sure that the relaxed settings that allow you not to declare the variables were all turned off. But the following code snippet compiled without warnings (!):

Dim ls As New List(Of String)
Dim li As New List(Of Integer)
ls.Add(1) ' should not work
li.Add("2") ' should not work

How is this possible? This is a classic example of the kind of type safety that usage of generics offer. What does this code snippet produce? Let’s have a look at the real truth^(TM) in the shape of IL decompiled source using the most excellent Reflector:

Dim ls As New List(Of String)
Dim li As New List(Of Integer)
ls.Add(Conversions.ToString(1))
li.Add(Conversions.ToInteger("2"))

The compiler worked really hard to help you ignore the types and convert the values as needed. By chance, this will not fail at runtime because "2" is convertible to Integer. I’m not sure if a developer should consider this helpful or not. After all, what is a hobbyist doing using generic collections?

Finally, why did this compile? Because the settings for “compiler relaxness” exist both globally (for all projects) and locally (for each project). Turned out the project was opened from Microsoft provided demo CD and the settings were relaxed on the project level.

I stumbled upon something that looked so unbelievable that I simply had to try it. Suppose you want to build a browser based application, rich in functionality. These types of apps are increasingly often now called RIA. If it’s going to be .NET based, you’d probably want to make it WPF based (XBAP). Silverlight is a possibility too but let’s say that because there’s no way of having full CLR available you disregard it.

Since the app is already .NET 3.0 because of the WPF, why not use WCF for the network connectivity? Well, there is one problem you can’t overcome – WCF does not run in a partial trust scenario (at least not in the .NET 3.0, 3.5 should partially resolve the issue).

Let’s say that you’d rather use WCF and thus you give up on the XBAP and decide to go with the full blown WPF app, ClickOnce installed.

What you want to have is a simple stocks service - the server will fire the notifications when the price of a particular stock changes and the client will display it somehow, in a table or maybe as a fancy chart. The screenshot to the left shows two WinForms based applications (prototype obviously, real app will use WPF on the client), service and the client that communicate through WCF.

You need a two way channel – subscribe for updates to the server and then later on receive notifications from the server. Because you don’t want to have problems with the firewalls and such, you decide to pick one of the bindings with HTTP based transport. What do you know, there’s one binding in WCF that perfectly describes your needs – it’s called wsDualHttpBinding.

The app works as the screenshot shows, and it’s literally a couple of lines of code. It’s really easy to add transport and/or message security, transactions and whatnot, so what’s the problem?

The problem is the way that wsDualHttpBinding is designed. To support two-way communication, two HTTP connections (so two TCP connections) are used. The problem is that the second one, used to send messages from server to the client, is actually initiated from the server. Why is this a problem? Because client needs to be able to listen on a port, thus you need to have this port open on the firewall!

This makes no sense because one of the primary reasons you chose HTTP based transport is to avoid issues with the firewall. If I did not care about firewalls, I would have chosen TCP based transport like netTcpBinding which also gives me the benefit of using single TCP/IP connection for two-way communication. In fact, if the client had a simple one-way firewall protecting only incoming and not outgoing traffic (Windows XP firewall works like this as do many of the home routers/wireless access points) this would work even better – no need to touch the firewall!

But wait, why does wsDualHttpBinding require two TCP/IP connections? HTTP as a protocol is one-way, but it’s higher level than the TCP/IP, and it certainly was possible to use single TCP/IP connection for a two-way HTTP communication. I can only guess that time and/or resource constraints cut this feature out. Unfortunately, there’s no mention of rectification of this problem in the “Orcas” release.