Frans Bouma's blog

Scoble (among others) writes about a situation which is a given in any marriage where one person is gifted with 'geek-genes' and the other lacks every single one of them. Here in the Netherlands we even had a term for those wives which feel neglected because their husband is spending more time behind the keyboard than with her: "Computer weduwe" or in English: "Computer Widow".

... for my blog, that is. I tried to mimic the style we use for our company website. It has some bugs actually. Working on it :)

What follows is quite embarrassing actually. Yesterday, I was reviewing my own code and optimizing it a bit, looking for ways to make it even more generic, adding more constructors for ease of use, you know the whole 9 yards. In the O/R mapping layer which is targeted by the generated code of LLBLGen Pro, the application I've been working on for the last 5 months, I use a dynamic query engine (DQE). This DQE is specific for each database vendor so you have a special DQE for SqlServer, one for Access etc. The DQE constructs query objects which contain a command object, the parameters and all other necessary objects and data to get the query executed. All methods are static.

Today I've seen some people hammering stacks of MSDN cd's onto the heads of some other people who obviously talk about what their employer wants to hear, f.e. Matt Puccini and others.

A short remark which can save you tremendous trouble and hours of hairpulling: if you want to test if your objects can be serialized, do not, I repeat, do not, use the XmlSerializer class when your object has properties which return / accept an interface. The Soap serializer will work with these properties just fine, but the XmlSerializer will barf it can't handle interfaces. I just spend an hour rewriting some interfaces, crawling through google groups and finally discovered the XmlSerializer class isn't about serializing at all.

Sam Gentile, among others, pointed us to two articles at Microsoft about the speed of managed code, how to optimize your code, tools that can help you and low level insight of what's going on in the CLR when it comes to the storage of data and GC. There are two articles: Know what things cost, and a primer about how to write fast managed code. I first read the 'know what things cost' article. It is a well written article and some good info if you are interested in that info. However it's not that useful for optimizing your managed code, if you ask me. I'll explain that in a second. The other article appeared to me as very useful, because it describes problems and gives hints to think about.

Randy Holloway wrote about his vision on Linux and then especially about Linux on the desktop. I disagree with his vision, I think Linux is definitely an option for the desktop at the moment and thus also in the foreseably future. It will become the option for the desktop when Mono is completed. The reason for this is simple: a lot of Windows programs will be written using .NET. If you can run these programs on Linux too, using Mono, what's keeping you on Windows? Perhaps the games. But definitely not the business applications, since the Linux version for spreadsheets, browsers, wordprocessors, emailprograms and other every-day software are solid today, even when compared to Microsoft Office XP.

Paschal L posted this snippet from the introduction speech by Paul Flessner (SVP) at Teched: "...A couple other things on SQL Server: Our developer edition used to sell at $499. We're lowering the price to $49, announcing basically today, and that will be embedded -- (applause) -- thank you -- that will be embedded and picked up, we think, by other tools vendors. Borland has already announced that they'll be picking it up and shipping it with their C# development environment...."