Come on, people, seriously.  You'd think that since Windows became a stand-alone operating system starting with Windows 95 some 13 years ago, they would have figured this out by now.  Why haven't any of the Windows releases since then incorporated being able to reconfigure the operating system without ever restarting?

Now it used to be that the whole "You have to restart your computer for these changes to take effect" thing was just a mild nuisance.  Unless it involved drivers, you could just click "No, I'll restart my computer later" and what do you know?  You don't even have to restart your computer half the time.

Has this improved at all in recent years?  No, in fact, it has gotten worse!  There are now artificial measures intentionally put in place to force users to restart.  For instance, after installing Windows updates, you will be prompted every 10 minutes or so that you have to restart until you do.  Or when a program is installed, it will not let you install another program until your computer is restarted.

Device drivers aside, as a developer for the past 10 years, I have never encountered a scenario where any installation step involved in installing a program could not possibly be done without restarting.  Why are users still being required to restart?  Is it because developers are too lazy to figure out how to enable the program to function without restarting?  Is it a "just in case" measure to reduce technical support calls?  Or maybe it has just become tradition.  In any case:

If your installation process requires restarting, your installation process was poorly designed and needs to be reworked.

This is, of course, unless restarting is necessitated by some external factor, in which case, said external factor (e.g. Windows) is a product of a poor design and I hope the designers (e.g. Microsoft) gets grilled for their gross negligence until they correct it.

Home users may simply find this annoying, but when you talk about servers, many of them must be kept up during certain hours, which means that some poor technician has to come in early, stay late, or spend part of his weekend performing updates to the servers, or else the company has to suffer a loss in productivity or even business during the time that the server is being restarted.  This is unacceptable when there is no reason why installing a program cannot be done without restarting.

Lately, I've been customizing my Wing.  I posted a topic on XDA-Developers.com regarding my most recent obsession with controlling the LEDs on it.  If you own a Wing/Atlas or similar HTC device, check it out:

http://forum.xda-developers.com/showthread.php?p=2059151

For those who don't know what a CAPTCHA is, it's a Completely Automated Public Turing test to tell Computers and Humans Apart.  It's those images that web sites sometimes display that contain distored characters or words that you are required to enter as text in order to verify that you are, in fact, human and not a computer program.

I've always liked the idea behind CAPTCHA, being very anti-SPAM myself.  But what constantly bugs me are the dozens of different kinds of CAPTCHAs I encounter that seem so easily defeatable.  For one thing, they make the text a totally different color from the background so that it could easily be isolated from it.  Second, they usually barely distort the text.  You know, I haven't the slightest clue how OCR (optical character recognition) works, but I bet I could write from scratch a program that could defeat 90% of the CAPTCHAs I've seen on the web.  But instead of egotistically trying to prove my programming prowess, I decided to design my idea of what an undefeatable CAPTCHA would be.  So I just quickly wrote up a rough draft.

Basically, I would think that a program to defeat CAPTCHAs would try to find patterns in the image that resemble characters, right?  My idea is that a CAPTCHA should not have any patterns or follow any rules that could be programmed against.  It should be completely random.  But how could even a human recognize the image if it were completely random?  Probability. 

The idea is that every pixel in the image is a random color; however, the random number generator is designed such that there is a slightly higher probability of the random color being darker where the text is.  So any color can appear anywhere in the image, but where the text is, it's a little more likely to be a dark color, even though it could even still be white there.  Humans can easily pick up on this, because our advanced brains are infinitely more intelligent than any software ever could be.  In fact, the entire makeup of our brain is about making connections even between seemingly unrelated things, whereas computers have to deal with descrete values.

Ok, so I guess this algorithm technically creates a pattern.  But it's the most random, least pattern-like pattern I could come up with.  Anyways, I bet you're just dying to see an image of what my algorithm generated...  Here it is:

It can easily be fine-tuned.  Plus this is a draft.  I would definitely add some distortion of the text before applying the color distortion.  In any case, it may seem easy to read or even defeatable, but look at it extremely close.  No two pixels next to each other are the same color, there are equally dark pixels in the background as the foreground and equally light pixels in the foreground as the background.

Please, I encourage you to open this image in your favorite graphics program and try to isolate the text from the static.  Try using software to defeat this CAPTCHA.  I'm curious to see how easily this can be defeated.

Comments?  Criticism?

I realized something while I was working on a project.  I thought it might be a useful idea, so I thought I'd write a post.

To help clarify the following, I will be using the terminology for generics as it appears in System.Reflection.  List<T> is an example of a "generic type definition", because its type arguments have not been specified.  Whereas List<string> is a "generic type".  T is a "type parameter" and string is a "type argument".

In .NET (C#), while a generic type definition can be referenced using typeof (e.g. typeof(List<>)) in order to get a Type object, you cannot declare a variable with a generic type definition type.  This is because the generic type definition isn't really a type in .NET, it's more of a template for a type.  Furthermore, generic types from the same definition do not automatically inherit from a common base class.  This presents a problem when you want to be able to reference an object of a generic type without knowing its type arguments.

I ran into this problem yesterday.  I realized, however, that since types can be distinguished by how many type parameters they have, a type that is not generic and a generic type definition with one or more type arguments can both be defined without causing a naming conflict.  This can commonly be seen with the old System.Collections classes and interfaces and the new generic System.Collection.Generic types (e.g. Stack vs. Stack<T>).

So I performed a little trick taking advantage of this in order to solve the above problem.  Here's some example code:

public abstract class TransactionField
{
    
}

public class TransactionField<T> : TransactionField
{
    private T m_Value;
    
    public T Value { get { return m_Value; } set { m_Value = value; } }
} 

Now an object of any TransactionField<T> type can be referenced as simply TransactionField.  This is great for referencing, but what about that Value property?  What if you need to be able to access that property for any TransactionField<T> object?  Check this out:

public abstract class TransactionField
{
    public object Value { get { return _Value; } set { _Value = value; } }
    
    protected abstract object _Value { get; set; }
}

public class TransactionField<T> : TransactionField
{
    private T m_Value;
    
    public new T Value { get { return m_Value; } set { m_Value = value; } }
    
    protected override object _Value { get { return Value; } set { Value = (T)value; } }
} 

It gets a little confusing with the naming.  But basically, TransactionField defines an protected abstract property _Value so that it can access the value stored in types derived from it.  It also defines a public property Value which provides public access to the value stored in the derived type via _Value.  Finally, TransactionField<T> defines a new property with the same name Value except this one uses the type argument instead of object.  

Now at this point, you might be wondering what the point of using generics at all in this scenario is.  Well, TransactionField<T> replaces the Value property with a typesafe one.  When you deal with the generic type, you won't need to cast any values.  This approach is the best of both worlds.  The object can be dealt with as an object of a generic type or a non-generic type, depending on what is needed for the code that is using the object.

Today I encountered an exception thrown from a class library I was using that had an interesting exception message.  Actually, the only thing interesting about it was how completely useless it was.  Without revealing the identity of the class library, I will paraphrase.  I was calling a method called "Initialize" on an object of a class, which I will call MyClass for ambiguity.  The exception message was...

"Failed to initialize MyClass"

Ok, let's examine this for a moment.  "Initialize" is the name of the method and, thus, what the method is supposed to do, which is what this is saying it failed to do.  Let me illustrate how meaningless this is by saying it with a slightly different wording:

"The method you just called failed to do what it is supposed to do to the object it was called on because of an error that we are going to tell you nothing about.  In fact, the original exception would have given you some useful information to go off of, but we decided to catch this exception and throw you this useless one instead, without even referencing the original as the inner exception we might add, because we enjoy frustrating our customers.  It's all part of our elaborate plan to make you contact us to help you solve the issue.  This way we appear needed to our employer even though we are lazy and continue to write crappy code.  We don't care that this wastes your time and contributes towards delaying the very time-critical project you are trying to finish while your boss rides you every day about where you are on it.  All we care about is keeping our jobs since we haven't the slightest clue what we're doing here."

The person I talked to today was lucky that I'm generally a nice guy, otherwise her day might have turned real ugly.  But, fortunately, it didn't waste too much time--if half the day doesn't count as too much time, that is.  It turns out the problem was quite simple.  The error could have easily been summarized in an exception message like "The given system name was not found on the given server."  Now would that have been so hard for the programmer who wrote that method to type that instead of "Failed for some reason"?

So next time you find yourself starting a line of code with "throw new", please, for the sake of programmers everywhere, at least say something about what the problem is, and include the original exception, if any, as the inner exception.

P.S. Comments are still not working...  Sorry.

Binaries: DuckTyping_0.9.30.zip (125.01 kb)
Source: DuckTyping_0.9.30_Source.zip (36.86 kb)

The static page explaining the duck typing project can be found here.

• Fixed: A stack overflow no longer occurs when a duck casting conversion infers the same duck casting conversion.
• Added: Some support for generic methods, but do not expect it to be bug-free.  I had to release it in this state so that the above bug fix would be released.  It should not affect other kinds of class members, though.

Sorry, but comments still don't work...  I'm working on it...

I have become aware that comments are not working on this site.  I was hoping to fix this quickly, but unfortunately, it may involve switching hosting providers.  In any case, I will post as soon as this is working.  Sorry for the inconvenience.

Though I haven't posted in a while since I've been busy, I am still working on the duck typing project.  I have at least one bug fix and I'm working on support for generic methods.  You can expect another release soon.  So stay tuned...

Phil Haack recently posted a blog entry on duck typing.  Read it here.  It gives a very good explanation of it and some of its advantages.

He also gives a very good example of a use for duck typing using my library.  His example demonstrates a feature that I like to call variance in class members.  Specifically, when duck casting an object to an interface, the object need not even implement the interface exactly.  Rather, its members may differ from those defined in the interface as long as the parameter types, return types, property types, and event delegate types are convertible to one another, which may be so via duck typing, as in his example.  Here is an excerpt from his example: (comments mine)

public interface IHttpContext
{
    // Note that the Request property returns IHttpRequest.
    IHttpRequest Request { get;}
}

public interface IHttpRequest
{
    Uri Url { get;}
}
 

In his example, the sealed class HttpContext is duck casted to IHttpContext.  Here is what some of the code might look like for this class for the sake of demonstration:

public sealed class HttpContext
{
    // Here, however, Request returns HttpRequest.  Duck typing still works because HttpRequest
    // can be duck casted to IHttpRequest, which is actually done behind the scenes when Request
    // is called on the duck casted object through the IHttpContext interface.        
    public HttpRequest Request { get { ... } }
    
    ...
}

A long-time friend and development mentor, Jordan Terrell, recently started a blog as well.  Very smart guy.  Be sure to subscribe to this one, as I anticipate many interesting posts.

Scott Hanselman recently posted a blog entry linking here.  Thanks Scott!

He mentioned an interesting question about how this duck typing library fits in with the new C# "var" style declarations and the new dynamic language support of .NET.  I thought I might briefly give my take on this.

"Var" style declarations have a similar but different purpose than duck typing.  When you declare a "var" variable, you are basically saying to the compiler, "You figure out what type it is."  The type is inferred at compile time based on the value that it is assigned.  Then, the variable can be used as if it were that type.  It basically amounts to syntactic sugar.  Duck typing is quite different.  When you cast an object using duck typing, you are instead saying, "It doesn't matter what type this object is, as long as I can interact with it in this way."  It has the advantage of decoupling from the actual type of the object.  This doesn't even have to be known at compile time. 

The original problem that prompted my investigation into duck typing is the problem of versioning in a plug-in system.  Say plug-in A was compiled to be used by version 1.0 of a program.  The program is then updated to version 1.1 and plug-in B is compiled for use with this version.  What about plug-in A?  When its reference to the program library is resolved, version 1.0 will be loaded, whereas the program will load version 1.1.  According to the .NET runtime, these are entirely different assemblies.  Plug-in A implements an interface from version 1.0 and thus cannot be casted to an interface from version 1.1, even if these interfaces are identical.  With duck typing, however, it doesn't matter what interface a plug-in implements, if any.  It can be casted to the current version of an interface as long as it implements all its members.  So problem solved.  Both plug-in A and plug-in B can be interacted with in the same way without having to update plug-in A.

This is similar to dynamic typing in other languages in that certain behavior is performed on an object without knowing it's type, and as long as that object supports that behavior, the code succeeds.  An advantage of duck typing, however, is that it must be known that the object's type implements all of the needed functionality at the time the object is casted.  It does not wait until the functionality is actually used.  Although this does not mean that more problems will be found at compile time, it does mean that problems will surface sooner when the program is executed, even if the code that uses certain functionality is never executed.

Binaries: DuckTyping_0.9.27.zip (123.65 kb)
Source: DuckTyping_0.9.27_Source.zip (33.94 kb)

The static page explaining the duck typing project can be found here.

For those of you who downloaded version 0.9.24 from the old site, there are a few minor updates:

• Fixed: Class member variance by duck typing an interface to another interface now works properly.
• Fixed: Now when duck casting an object to an interface that inherits another interface, the members of the later interface are also implemented (recursive).
• Added: Already, when multiple methods are found that match an interface method, the "best match" is chosen; however, now the return type is taken into account for the sake of explicitly implemented interface methods that may differ only by return type.  (Example, the GetEnumerator() methods of System.Collections.Generic.IEnumerable<T> and System.Collections.IEnumerable)

Feel free to leave general comments on this post about the duck typing library.