No support for static Extension Methods - bummer!

I wanted to add an extension method to Debug, which would automatically write a given set of parameters separated with commas (to generate CSV files). However, since extension methods are not supported for static methods, and the Debug.WriteXXX are static - it's not possible. Bummer!

Yet another missing feature in C#/CLR ...

SQL Server 2005 rantings - User Defined Aggregate Functions are nice, but not there yet...

1. Why can't there be UDA's in T-SQL? Granted, it's easy to write it in CLR, but sometimes it would be simpler (and more appropriate) to write it in SQL. It also took me a while to figure out that indeed there is such limitation...

2. UDA's must be serializable. Why? I don't know yet (still need to figure that one out), although I have some ideas, but anyway it's besides the point - it's a must and I assume there are good reasons for that. The problem is that whenever you're doing something slightly more complicated than just an average or Product, you need to accumulate all the values until you get to Terminate() (e.g. a variation on STDEV). This means that this list you've just accumulated could grow significantly. Now to the pitfall - when you use user-defined serialization (which you would have to in this case), you must specific the maximum size that the UDA structure could grow to. This maximum size is limited to 8000 bytes (*sounds familiar...). So in my case, I'm using a UDA over double values, and thus I'm limited to aggregating a little below 1000 records. IMHO this reduces the practical usage of UDA's to about 50%...

3. I tried to write a UDA for decimal data. No matter what I did, it constantly produced a function defined to return decimal(18,0). In other words - no decimal numbers to the right of the dot. In the end I didn't have the time to find out the KB article talking about it, but I suppose there is - I pretty much tried everything. In my particular case using double values was an acceptable compromise - it won't always be that way...

Learning Machine Learning - The WEKA Way

If you're interested in working with or learning about Machine Learning, you really MUST check out WEKA. When I first saw WEKA, a few years ago, it looked like a cute tool to start learning ML, with a very small set of implemented algorithms and only available for Java developers. Now, it has become a very rich research platform, in which one can easily test a very wide variety of ML algorithms with endless tuning parameters and analysis tools. You can read data directly from a database and you can now even run WEKA directly from within your .NET code (check also this) !!!!!

I'm a complete newbie with WEKA, but it seems that it's going to be a lot of fun and much faster working with it than anything I did before. I just hope it will hold up to the expectations that are building up in me now...

One more thing - notice that there is the "book version" and the "developer version". The former is the one on which their book is based on and is not expanded (only bug fixes). The latter is the version that is on constant development, has more features, and significantly more implemented algorithms.

AI AI AI AI AI ...

My curiosity has been arisen big time. Apparently, there is a new kind of malware, which involves the use of natural language dialogue to extract information from users, in the disguise of a flirtatious conversation. It's called CyberLover and was apparently developed in Russia. According to PC Tools, this program can converse with a human for 30 minutes without the dude being able to see he's talking to a robot.

The Turing Test has officially been passed...

Read the original warning issued by PC Tools, or an article at ComputerWorld.

AMAZING!!!

A Killing IDE Feature I Would Like To See

A long time ago I used to use BugTrapper - an application that sits on the production server, records every instruction, and makes it possible to "play" everything back, step by step. It's a great tool to analyze bugs and especially crashes "post mortem", as long as it's not related to some obscure race condition (the overhead of using BugTrapper often ruling out the race in the first place).

I think there definitely is a case for applications like this, and the fact that Mutek hasn't been able to push itself farther into developers' awareness is quite surprising to me.

The feature I would like to see in an IDE is a mini-BugTrapper. I would like the IDE to be able to record up to a certain amount of instructions (say up to 100,000) during debugging. How many times did you stop at some breakpoint and suddenly realized you should have put this breakpoint a little bit earlier in the flow? You really need to see  the value of some parameter, or the actually executed flow, a few steps back - but you can't. The only thing the IDE gives you is the static current call stack - which just isn't enough. You want to know what variables caused you to get into that current call stack, but that's beyond the scope of the IDE's features.

That's, IMHO, a killing feature that could significantly boost debugging time.

Is GOTO always evil?

The other day I decided to use a "goto" statement in my C# code. It was a difficult decision to take, and was primarily motivated by the need for readability.

Apparently, Linus Torvalds also thinks there are cases where "goto" is appropriate, so I'm in good company...

Thanks to Scott Hanselman for pointing to this thread.

VB Grrrrrr...

Yet another MSDN and .NET WTF:

I'm currently implementing some temporary code that was written in VB into our C# infrastructure (let's skip the details). Anyway, there are parts in the VB code that I would like to group because either they are currently not being used, or for some reason I want to hide it from view and get to it at some later phase.

Obviously, a #Region directive seems like the best solution.

My VB is quite rusted, but using common sense I tried using  the same syntax I'm used in C#. But alas - it didn't work. So I searched MSDN - hey, it should work! Well, VB have this little difference that the identifier_string MUST exist and it must be surrounded by quotation marks. OK, no biggy, I usually put it there anyway.

But why doesn't it work?

Well, there is this tiny little limitation, hidden from you if you rely solely on MSDN, that "'#Region' and '#End Region' statements are not valid within method bodies."

Which raises two questions:

1. Why, in Heaven's name, should there be such a difference between C# and VB. It's just a freaking compilation directive!

2. Assuming there is some justified reason for that (which I doubt - I guess it's just a non-implemented feature) - would it hurt someone to put this info in MSDN so I won't have to get crazy trying to figure out why it doesn't work?!?!

And now to a personal to-remember note:

I relied solely on Intellisense and Resharper to know the code is wrong. I'm using the C# only version of Resharper, so I have no idea whether Resharper would have been more helpful. Anyway - had I compiled from the beginning (or at least looked at the message Intellisense gave me) - I would have seen much sooner why it doesn't work...

Could the World become a Better Place?

Shai Agassi is a person who doesn't have to prove himself - he's done it 400,000,000 ($) times and much more. I had the chance of working for him at TopTier, though at the time he was mostly in the US and I don't think he'll remember me.

He's now investing all his power in the Project Better Place, with the goal of transforming our fuel-based cars into electric-cars, by providing the necessary infrastructure and business plan.

Will he succeed? I sincerely hope so. I am also willing to be one of his first customers for a pilot plan in Israel. If anyone is to succeed in such a project - it's him.

Some say his real goal is to own the software that will handle the whole system. Well, I think that if he succeeds in this project, it makes complete sense and there's no harm about it. If making this world a Better Place means Agassi will own the most important software in history - so be it!

In any case, I admire him for being ready to risk his most valuable asset - his reputation - for this huge and very risky project.

If you want to keep track of what's going on, I suggest you read his blog.

Good luck Shai!

Changing the number of maximum Internet connections

I know it's an old story, but every time I need it I have to go and search for this information, so I'm posting it here for later reference.

For a reason I don't know (and don't really care), Windows limits the number of concurrent Internet connection available (with XP I think you get 2 concurrent connections in HTTP 1.0 and 4 in HTTP 1.1).

With contemporary computers and the bandwidths of these days, this limitation is archaic to say the least.

So, if you need to be able to handle more simultaneous connections, you just need to add two entries to the registry. To simplify it, just copy the following lines to a file with a .reg extension and then double-click it. It will change the configuration to allow 50 simultaneous connections ;-)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings]
"MaxConnectionsPerServer"=dword:00000032
"MaxConnectionsPer1_0Server"=dword:00000032

On the superfluousness of the Singleton pattern in .NET

We all know the Singleton pattern. It's intent is to "Ensure a class only has one instance, and provide a global point of access to it." (from GOF). There are many possible implementations of it, some are good, others are to be ashamed of. You can find a good review by Jon Skeet, or on Patterns and Practices where you can also find a successful implementation using double-locking mechanism. By the way, the implementation in "Design Patterns in C#" by Steven John Metsker was utterly dissapointing, to say the least.

But this is all assuming you indeed need a Singleton pattern. If you read the Intent, as defined by the GOF carefully, there is nothing in simply using a static class that does not meet this intent. At the time of writing the Design Patterns book, the GOF didn't have C# or .NET. Back then, they were mostly relying on C++ and Smalltalk. I'm not proficient in Smalltalk, but I know that with C++ there were problems with static and global variables. For instance, it wasn't clear what their order of instantiation would be, nor when the destructors would be called. So when you're working with good old C++, you just have no choice but to use the Singleton pattern. With .NET, however, things are different. Instantiation of static classes have a clear and deterministic behavior. With destruction, of course, it's different, but most cases where you need a Singleton you'll keep it alive as long as the program is running anyway.

In the Design Patterns book, there are some other "consequences" which could end up as reasons for using the Singleton pattern instead of simply a static class:

1. Permits refinement of operations and representation - or in other words - a Singleton class can be extended by means of inheritance. Most cases I have encountered, there is no inheritance going on with the Singleton, and if there is, then the actual Singleton is the last in the hierarchy. Even more so - many implementations use sealed classes either for performance optimizations or simply because the pattern wouldn't work with inherited classes.
2. Permits a variable number of instances - or in other words - one day, some 5 years ago, some freaky newby will invent a reason to use multiple instances of the Singleton and you should make it easier for the idiot to do the change. One word: YAGNI !

3. More flexible than class operations - same as the 2 previous items

So, why would you use the Singleton pattern in .NET instead of just a static class?

1. Inheritance - I said in most cases there is no need for it. There is always the exception... You can see one on Jon Skeet's blog.

2. Destruction - when you want to keep a reference counter of the number of consumers, and somehow destroy it when it's no more in use. Complicated, especially given the non-deterministic destruction of objects in .NET.

3. Other static functionality - if you need some static functionality that should not cause the actualy 'Singleton' to be created (any call to a static method will cause the ctor to be called). Note that this is also a problem with most of the pattern's implementations, because they rely on a static field/ctor.

4. Parameterized contruction - this seems to me like the most likely reason to use the Singleton pattern instead of a static class, but here again there is a problem because most of the cleanest implementations rely on the static constructor. The idea here is that sometimes you want the Singleton to be initialized with some parameters, so you can't rely on the paramterless, static ctor.

Now that that's settled, and given the name of my blog - why not using the Singleton pattern?

1. As a general principle, I like using patterns when they are needed, no more. So the main reason why not, IMHO, is that in most cases it's simply superfluous - you end up spending design/coding/unit testing/qa/debugging/etc time on something you don't need. Smart.

2. Some of the implementations are really clean and neat (see, for example, the 4th in Jon Skeet's list, which is the one I used to use before I understood I don't need it).

3. Inertia - Most of us are still in the C++ state of mind that there is no other way to really "Ensure a class only has one instance, and provide a global point of access to it." .