In LLBLGen Pro I currently use the 1.7.4.0 release of the Magic Library for several GUI elements like docking windows. As this release was the final release before the library went commercial, no support was given, but that version was free, came with sourcecode, so no complaints here. As I'm adding new GUI functionalities to our O/R mapper, I required a nice tab control which not only looked nice but was more flexible than the .NET tab control. As Magic contains such a tab control, it was the obvious choice.
However I ran into all kinds of bugs and after a day and a half I gave up (which was yesterday). So I googled a little for tab controls but on the freebee side, nothing was very usable, so I went to Component Source and browsed their catalog. I took my time, as a lot of vendors have something to say about their product. I registered at Component Source to download a trial of some tab control (which wasn't that great) so they had my email address and of course started tracking me.
Today, I received an email from a Component Source sales person, that I'd spent more than half an hour on their site in a specific category and if I needed help selecting the product I want.
I was stunned. Their system apparently tracks visitors, which is perfectly fine, but their system is also clever enough to list the people who apparently have trouble making a choice and that they perhaps need assistance. 
A perfect example of how IT can help your business and how software can make the difference!
(Btw, I chose the Infragistics suite, as it was the most stable control set and contained the most value)
Microsoft made me a C# MVP! . I don't have to add that I'm very very very happy with this title and I hope I won't disappoint as an MVP in the coming year.
The story is a little funny so here it goes. First they mailed me (in March) on an account which I don't read anymore because it receives a truckload of spam every day (and bounced emails because it apparently is used by spammers as from-address). Then, I received an email on... April 1st, which was sent via this blog. Needless to say, I was a little sceptical 
. However .Text also includes the IP address of the sending host which was a Microsoft IP address. Strange things happen then: sceptic thoughts fight with pure joy. After replying the email, it turned out to be a legit email, and I became an official C# MVP!
The1 has posted my entry to his Phraser programming competition here. It's in C# and shows some basic techniques like clever usage of a hashtable and recursion. A list of all entries to the compo can be found here. Competitions are fun, it keeps the mind fresh .
My algorithm is based on encoding words as digit sequences and then matching the sequences with the phone number at hand. I first thought an algorithm which calculates all permutations of the phone number in characters which would then be compared with a word list would be more efficient, but a fast calculation showed more than 11,000 different permutations had to be calculated each time. An average human knows roughly about 8,000 words (or less) so a wordlist would be more appropriate. Although I learned from my years in the demoscene that precalculation is key to be efficient in some algorithms, it is also key which precalculation you perform.
Joseph Cooney wonders which sourcecode should be read by a programmer to learn to become a better programmer. I'd say: none. At least, not the code for which you don't have the design documents or algorithm descriptions. A lot of code is very bad and it's pretty useless to just read code. The reason for that is that code is the end phase of programming software. What's way more important is the algorithm or set of algorithms the code has to represent. Only then you can learn something, because you can then see the start (algorithm) and end (code) of a transition every developer has to make a lot of times. Only with the algorithms in your hand you can check if the code you're reading is good code or not: if it doesn't describe / represent the algorithm(s) it has to represent, the code is buggy, bad and should be rewritten. You don't know that if you read sourcecode without the algorithm descriptions.
Some developers like to read other people's code to learn 'new tricks'. If a developer says that to you, you immediately know the developer doesn't understand what software engineering is all about. Software engineering and programming isn't about 'tricks'. It's about algorithms and their implementations in sourcecode. The more 'tricks' are used to implement an algorithm, the more an implementation will become unmaintainable and more complicated to understand, while an algorithm is describable in normal text, so the sourcecode should be as simple as the algorithm description. Yes, this results often in dull code, which is not the stuff the developer looking for tricks will get exited about. He/she will probably describe the code as 'not that good', because no trick is used.
If you want to learn something, read the book 'Algorithms' by Robert Sedgewick. Very old (1988), but very good and very real even today. The code is in C, but what's important is to learn to write these algorithms in VB.NET or C# so you'll learn these algorithms back to forth and back so next time in your own code you can make the better decisions. Last time I read it was in 1991 and I opened it last week again, what a wealth of information.
Looking at other people's code, just to learn things is, in my humble opinion, more or less a waste of time. Look at the theory behind the code, you'll learn much more from that. "Why" is it constructed that way, is way more important than "How" is it constructed. And trust me, the Why is not picked up from sourcecode, but from the algorithms the code has to represent.
Alex Thissen reported yesterday (and we all know what day it was yesterday ) about a rumour that Objectspaces would be removed from .NET 2.0 and would be released as a separated package.
It's a rumour, posted at a date when you can't trust any website, but let's say that it is true. I said as a reaction on Alex' blog:
Dropping it would be the right thing to do. Objectspaces is not something that should be part of the framework. The reason for that is that it is completely closed: any RDBMS vendor will be pissed as hell because they can't create support for their database in Objectspaces, i.e.: illegal tactics from MS to promote SqlServer through Objectspaces. Remember: it is completely impossible to write a query engine for objectspaces which supports Oracle plus it is impossible to produce a mapping schema which supports oracle, as the mapping schema can't store sequences nor can it cope with catalog less database designs.
Apparently this was not what some people wanted to hear: I am biased, I spread FUD, I am bashing Objectspaces all over the web and newsgroups and apparently I'm advertising at the same time my own product.The hostility with which this was expressed surprised me. It is the same kind of hostility you find in .advocacy newsgroups when you're telling the crowd your (competing) product is way better. (anyone who has participated in a shared thread in the C# - java.advocacy newsgroups knows what I'm talking about )
Why the hostility? Well, some people confuse marketing with technology and vice versa. These two things are two separate aspects of a product. Objectspaces, or any other part of .NET 1.1 or framework, is just a piece of technology you can use or not use. It has a set of specifications and if they meet your requirements, it's great, if not, you have to look further for something which does. Nothing special, happens every day.
A company selling products wants to sell as much products as possible for as long as possible. This has nothing to do with the quality of the product or what it does. Though, it helps if the product is of a higher quality than 'crap' and that the specifications of the product appeal to a lot of people, however everyone reading Dilbert on a daily basis with thoughts like "Oh yeah so true!" knows that these two product aspects aren't necessary to get a successful product. Some marketeers or sales strategists claim they can sell air for money if they have to. To get a product sold, you need a good marketing strategy and a good sales strategy. There are a lot of different strategies to choose from. One in particular is interesting for this story: using the availability and success of your product A to sell your product B.
In this strategy, A is Objectspaces, B is Yukon. Again, this is all about selling products using a technique to get them sold and has nothing to do with what Objectspaces is, what it does, what it can or can't do from a technical point of view or what Yukon can do or has to offer. In fact, these strategies are not designed by technical people (most of the time). Why would a designer of Objectspaces care if it is open for 3rd party RDBMS vendors? No software designer wants to hear his/her software is not well designed because it hasn't foreseen any future additions while it would have been so simple to design a system to support these.
Objectspaces, in its current state, will support SqlServer only. Microsoft has said it will add support for other databases later. When, is unknown (but most likely in the successor of .NET 2.0, as it would require a framework patch, i.e. another version). If Objectspaces is part of .NET in this state, it will be sad from a technological point of view (a lot of people use .NET with other databases, so they have to skip Objectspaces and probably have to shell out money for a 3rd party tool, and it is unnecessary to cripple the tool as a generic design is not hard in this case), but it is brilliant from a marketing/sales point of view: Objectspaces will be available on every system on which .NET 2.0 is installed. With a good marketing strategy which uses both hype and PR, a lot of developers will look out for Objectspaces because it is presented as a product that will save them a lot of trouble and time and thus money. Because it is available in .NET 2.0 and thus in Visual Studio.NET, or whatever editor used, it can be used by everybody using .NET 2.0 and because .NET 2.0 is free, Objectspaces is free too.
Due to the fact it will be available to a very large audience, and because Microsoft will document it in the .NET 2.0 documentation, will set up examples, presentations, webcasts etc. etc., a lot of people will try it, probably like it and will ask their team leaders to adopt it in the next project. Again, the story is not about the quality of Objectspaces or Yukon, just about marketing techniques and sales techniques. It's obvious what will happen: due to the strong linkage with SqlServer and Yukon, if you want to use Objectspaces, Yukon or SqlServer is the choice for your back-end database system. Any other database type will not work with Objectspaces in its current state.
Of course, not all developers will switch to SqlServer or Yukon because of this, like not all developers will use Objectspaces, however it will be a decision influencing point in a lot of projects. Add to that, because of its availability everywhere, Objectspaces will be known by a lot of developers, which has its advantages too: a lot of people use it, so a lot of people know the solution to a problem and if you as a developer switch jobs, your new employer will probably use Objectspaces as well which can be huge plus.
So to summarize: make Objectspaces popular, use Objectspaces to make one particular product (and Objectspaces, being an O/R mapper, requires a persistent storage (database) like every other O/R mapper does ), in this case SqlServer / Yukon, the only choice, and you have a great way of selling more licenses of that product, thus SqlServer / Yukon licenses.
As you can see, this is clearly a marketing/sales strategy to sell more products of type B, through A. Although this strategy affects the technical realization of Objectspaces, it's not related to the technical aspects of Objectspaces, as Objectspaces is not going to be better if it just supports one database: a more generic design is for OO fetisjists more appealing as well as for developers using Objectspaces, as they can use it with more types of databases in that case (if an Objectspaces query engine is available). See it as the DataSet. The DataSet can be used with any .NET provider available, as long as the provider obeys a set of interfaces. It would be considered not that great if DataSet objects would be usable solely with .NET's own providers and 3rd party providers wouldn't be able to use DataSet objects.
Objectspaces is an example of how marketing/sales strategies influence technical designs. Any software engineer would have designed Objectspaces as a generic engine which could use query engines which implement a given interface. That way it would be generic and every database vendor, like Oracle and IBM, could develop their own query engine for Objectspaces. This is not the case. Not because the designers don't know what they're doing, I'm the first to say they do know what they're doing, but because it would be horrible as a marketing/sales strategy, as you'd miss the opportunity to promote SqlServer / Yukon through Objectspaces.
This is the confusion some people have. By saying something about the marketing strategy embedded in the design of Objectspaces, you're not saying anything about the technical side of things or the quality of the tool. I think for clarity in discussions about products which are, sadly enough, subject to a marketing campaign, it's best to keep these two worlds separated.
Am I biased because of this? No, I don't think I am. I'm geek enough to find aspects of competing technologies great and well done. Am I bashing Objectspaces? No, I don't think so either. I'm bashing the strategy of using the design of a software product to sell more products. I do that because I like well designed software and I find crippling a design because of a sales strategy or marketing strategy not good for my profession in general. Furthermore, bashing a competitors product (in this case Objectspaces) is not helping the basher, at least in my point of view. The reason for that is that I firmly believe in telling others what the advantages are of what you have to sell. Bashing the competition makes your competition look bad, according to your bashing, but it doesn't make your product instantly great, as you don't say a thing about your own product.
Back to the rumour at hand. If it's true, would that be great for Objectspaces (and thus for you, as a developer)? You bet. Because it will then not have the necessity to serve as a marketing tool, but can be designed as it should have been: as generic as possible, so 3rd party vendors can add their own logic to the Objectspaces engine. You see: as an O/R mapper, Objectspaces abstracts away everything from the database used. So the more databases supported in Objectspaces, the better it is for developers using Objectspaces, and the more open Objectspaces' architecture is, the more 3rd party vendors are able to write classes which make it possible to use Objectspaces with their database. For the developer nothing changes technically, as he/she will work with the interface and API Objectspaces offers.
We now have to wait till there is proof that the rumour is true (or not), and if it's true, that Microsoft will change the Objectspaces structure so 3rd party vendors will be able to write their own query engines for Objectspaces. Personally I think Microsoft should take the bold step and proof the rumour to be true, just for the profession of Software Engineering, and at the same time Microsoft should allow the designers of Objectspaces to design a generic architecture, instead of an architecture which is crippled to serve marketing/sales figures. There is still plenty of time to successfully produce such a system.