The Search For The Ultimate Icon

In the last couple of weeks, I've been working on a Windows Application,
And while doing so, I've been exposed to the never ending chase after the perfect toolbar icon or tray image, and I have to say - I don't like it.

Well, my dear WinApp friends, search no more!

Thanks to Serge for enlightening us,it turns out M$ has already solve this annoyance for us (though they didn't bother to let us know...).

If you got to the VS.Net (2005) install dir:
***:\Program Files\Microsoft Visual Studio 8\Common7\VS2005ImageLibrary
You'll find a nice zip file containing every icon, image, and even animation you've ever dreamed of! (no, there is no Angelina Jolie animation there...).

Generic Vs. Generated Code

Most IT applications encounter the same challenges - whether its how to implement the best user experience or how to make the application as flexible as possible - these question will raise in every enterprise web application.
Than the only question on stand is - how to implement this?

A couple weeks ago I started a new job.
The first few weeks of a new job - to my opinion - are the most effective if you want to open your mind to new\different implementations - after all there is no one answer for any of these questions - each has its pro's and con's.

But I'd like to focus on one very basic difference between many of the existing solutions out there: should my framework be based on generic code that will know to handle a variety of scenarios and systems, or a set of wizards and code generators?

Why Should I Choose Code Generation?
1. Time: Yep, you can lower you eye-brow and think about it - how much lines of code are there in a framework like NHibernate, and how much are there in Wilson's OR Mapper?
Its not that I'm judging Wilson's complexity, on the contrary - although the time it takes to get a stable beta for a complex code generator is less the half the time it takes writing a generic code, in most cases it will support the same amount of scenarios and maybe even have more features (because it can enjoy the advantages of strongly-typed code).

2. Performance: Because of the nature of generic code, it must support a variety of scenarios, objects, context etc. - hence it will parse configuration files, load assemblies, use reflection, and many other performance killers, whereas when working with code generation, the code generated is designed for the specific page\scenario\object and will use no reflection or type casting whatsoever.

3. Debugging: When I first started using NHibernate, it was on one of the early betas (version 0.7 I think...), needles to say it was very unstable, but the most annoying thing was when I got an exception while using it - to start debug it and understand the cause of the bug took me a couple of hours since I needed to understand the "black-box" code.
In code-gen, the code is as simple as it gets which makes reading it a lot easier.

4. Ease Of Use: Drag N' Drop your entities, check the "Lazy-Loading" check-box, and vuala you've got yourself a fully featured DAL. no config file wars, no xml-schema lookups no tutorials to read.
Simply put - you need to no nothing (is it really an advantage?).
The amount time it takes to teach your users how to use a code-gen wizard is usually less the time it takes them to understand the xml structure of the "black-box" config file.

There are several more pro's to code-generation, and yet still they are usually not taken seriously, why?

There are several reasons, but to sum it all to 3 words: S - O - C. Separation Of Concerns.

In its nature, generated code is not stand-alone, it doesn't matter if it's in separate classes, files or even projects (though it might be enough in some cases), it is still strongly-coupled with your code, hence a change in your code will result in re-generational.

But this is the best-case scenario, think of a bug found in production, you have to re-compile the whole application because of a bug in your framework! whereas in "black-box" (generic code), you simply replace the framework assemblies (with care!).

Conclusion:
It's true, code-generation is sexier (I cant believe I say that!!!), but in real world (enterprise) applications, it's simply too risky.

Problems Installing IIS On Windows XP SP2

Hey,
Recently I've reinstalled XPSP2 on my machine, and had hard time installing IIS on it.
After some crawling on the net, I've found this work-around:

first, make a backup for this file:

%windir%\security\database\secedit.sdb

run this on command line:

esentutl /p %windir%\security\database\secedit.sdb

click ok on the message box, then install the IIS and insert the original winxp installation cd when prompted for files.

And vuala!

(Courtesy of Chaim)

JavaScript Properties

One of the most annoying limitations in Javascript - or better say in the java syntax, is that it doesn't support the C#\VB.Net property syntax.
So every time you want to create a property, you must create your own getter & setter like the following:

var _myProp;

getMyProp()
{
    return _myProp;
}
setMyProp(value)
{
    _myProp = value;
}

A couple of days ago I found a neat work-around for this limitation.

First, in the constructor, I'll define a span element which will be the host of our object:

function MyObject(id)
{
    this = document.createElement("span");
    this.id = id;
}

Next, I'll create the MyProp method:

this.MyProperty = function(){ return this._myProperty; }

Notice the behaviour of the MyProperty function is of a getter, now all we need to do is define our setter.

In order to do it, we use the span's onpropertychange event:

this.onpropertychange+=setterProxy;

function setterProxy()
{
    switch (event.propertyName)
    case "otherProperty":
        break;
    case "MyProperty":
        /* Here I can call my setter method */
        eval("setter_" + event.propertyName + "()");
        break;
}

And vuala we've got a getter & a setter just like in C#!

You can download the source-code of this example here

Flexibility Vs. Complexity

One of the features in ASP.Net 2.0 is dynamic compilation - the ability to execute your asp.net code without the need to compile it first.
Instead ASP.Net has a FileSystemWatcher that check for changes in *.cs files and automatically reloads them.

Although this feature is good in many ways, I'd like to focus this post on a specific drawback - design time.

More Flexible Or Too Messy
The dynamic compilation has the same drawback like .Net 3.0's anonymous types do.
Whilst you do get more flexibility to your code\deployment, I find it hard to believe a good design-time support will be - or I dare say can be available.

Even today when your WebSite application becomes bigger than 50~ web-pages, it is very annoying that your Intellisense starts to act funny because you wrote textBox instead of TextBox in one of your classes.

In my opinion, although the wish to extend and to make the language richer and more flexible is good, it can easily make your code too complex to maintain.
A good example to this tradeoff, is the reason why multiple inheritance is not supported in the .Net Framework.