Yesterday evening, I've delivered a talk on protecting your code. Frequent readers would recognize that the first half of the talk was actually written in depth in the first SLPS post. It's not perfect, but I had fun. But definitely the best I did in English, so far.

So for you who didn't quite caught up with what I was talking (I know, I mumble here and there trying to buy some time :D), I'll explain in depth through this post.

First of all, I'm going to reemphasize my point of view; open source does not work, for business. It might be good for education, community, or charity, but not for business. You're trying to sell something you share, that's just doesn't make sense. This is why, there's an inherent requirement to protect your code.

When we're thinking about protection, we'll think: "It's compiled! They won't/don't/can't have the source code." Wrong.

If you're still on this mind set, then you should visit (or revisit) the first part of this post. There I demonstrate how easy it is to convert any compiled .NET assembly back to it's original source code. This actually made up the first of three parts of the talk. Compiling a small application and decompiling it using Microsoft and third party tools.

The next part is about basic protection. Microsoft have bundled Visual Studio with Dotfuscator Community Edition. It doesn't do much (even though the UI provided so many different features -- disabled), only some simple renaming. I've demonstrated how to use Dotfuscator.

This is the original code, which is 100% reproducible:

And after obfuscation using Dotfuscator Community Edition, it will become, even though it's 100% reproducible, but it's harder to understand:

Several important points on obfuscation:

• The external interface to an obfuscated code will never be modified. This is to ensure that any code that depends on the interface will not break. Of course, this is basic logic.
• Dotfuscator stripped all namespace and rename everything to single letter alphabets (sometimes numbers if it runs out of z's).
• The obfuscation process happens after your code is done. Which means, it doesn't affect development, at all.
• Obfuscation, given enough time and effort, eventually will be broken. It's still reverse engineering, but with added hurdles to slow down progress.

You've seen Dotfuscator in action, now you'll want more. Unfortunately, more means money! You can easily search for obfuscation products using Google Live Search, so finding one is not on the scope of this post. I don't have any product ready, so I just try to open one of the users of obfuscator.

The company is Intersoft, the product is a UI control library. I "volunteered" to crack open their authorization code. Since good product requires good adversaries, therefore I embark upon the journey of the dark.

Here's one piece of the code which I have successfully decompiled:

This is only one part of the code which is the constructor. As you can see the obfuscator actually renamed parts of the code with unidentified characters. It's not easy to distinguish one with another, and in come parts of the code, Reflector crashes when trying to decompile it.

Long story short, I've been able to crack half of it (only the runtime component) in 8 hours. After that I lost interest, since buying it will be cheaper than hacking it.

Several important points on (expensive) obfuscation:

• The external interface is not change. Again, this is basic logic.
• Obfuscation, given enough time and effort, eventually will be broken. But since the hurdles are higher, the economics become: which one is cheaper; to hack or to buy?
• You get what you pay for. Expensive obfuscation will make your code less interesting to hack (except for hardcore hackers out there).

The third part of the talk is actually about Microsoft's product, Software Licensing and Protection Services, or in short SLPS. They have a product web site at root level (which means it's quite important) at www.microsoft.com/slps and if you have MSDN Subscription, you can get a free basic subscription to play with.

The difference between Microsoft and partner offerings is in the way the code protection does. While partners sell obfuscators, Microsoft sells encryptors. So your code is 100% not modified, but encrypted. This encrypted code will then run in a Secure Virtual Machine, or in short SVM. SVM itself runs on top of CLR (so it's still managed code). Moreover, Microsoft also offer activation services for your protected code. So when you pay for protection from Microsoft, they give you the ability to sell your software. Money out, money in.

Details will be in part three.

I went to a computer book store today, and found lots of interesting books that we can only download back in Indonesia.

They are pictured sitting on top of my trusty laptop.

• The Wisdom of Crowds, James Surowiecki
• The Mythical Man-Month, Fred Brooks
• Code Complete, Steve McConnell

I already went 2/3rd of Wisdom of Crowds, after that I'll re-re-read MMM (I went through it twice during my undergrad years - read on computer screen, bad for eyes).

I spent around $200 for all three. This should keep me reading for the next 2 or 3 months... :D

I also found more good books (which I can't buy yet, out of budget):

• Design Patterns, GoF (this is definitely the next buy!)
• Refactoring Databases, Scott Ambler

Another book is also coming from U.S. together with my new mouse, it's about the history of personal computer... Fire in The Valley by Paul Freiberger. This book have been turned into a movie titled Pirates of Silicon Valley. Can't wait to read this one.

Some years ago, Norman wished that we conduct a tech talk with a real architect to get the real feel of what an architect does. Well, we never did that, but there's something (actually, a lot) you can learn from Singaporean architecture related to software engineering.

Right now I'm talking about a facade. I'm sure you all have heard or used this pattern. I've heard this once, and then again recently. Both are bad design, IMO. In both design, a business facade is merely a middleman between web service and O/RM. The facade was doing nothing other than being another layer of indirection (which is bad, if done overly). Imagine something like this:

 

Object has a collection of ObjectB which needs to be populated on load (eager-loading). Every time an Object is retrieved from the web service, the client will need to call the second web service (that retrieves the collection of ObjectB). All calls made by the web service could've gone directly to O/RM, but in this case, we add another layer between them. We don't need it.

So what's a facade, anyway?

An example of a very distinctive facade is an old cinema redeveloped just downtown Singapore.

This is The Cathay. You can find the history of the building on Wikipedia, this is not a history blog.

Back to the topic, you can see the brown, art-deco style part on the center, this is called the facade of the building. It's the front face of the building, covering the massive construction behind it. The idea of a facade is an indirection so that you don't need to deal with the complexity of logic. Security check on the facade doors, for example, will almost screen all visitor to the building.

Taking the analogy to software engineering, a facade should hide the complexity of the logic, too. Fixing the diagram above, it should look like this:

Now, the client will only need to call one web service to retrieve Object and all related ObjectB. The facade becomes a composition orchestrator. The facade have the knowledge of what objects required when retrieving another object, the facade have the knowledge of how to retrieve it, too. A facade can call more than one O/RM function, can include logic, but should not call another facade function.

Now that you know have learnt a good facade by example of a physical building architecture, I invite you to start using this analogy when creating a facade. Please save us, developers, from the need of writing a useless middleman code. Thank you.

So earlier this afternoon I delivered a talk about new language features in .NET 3.5 for Singapore audiences. I admit it's not the best talk I've ever done, even worse, it's not even good.

For you guys who didn't grab the concept or wanted to know more, below is the long explanation about how things should've gone through...

First of all, I've created a small console application, to display the result of the code. I can type all code but no result, that's uninteresting. So for the talk, I've created a search application. I have not emphasized this basic functionality of the application during the talk. A search application is the easiest form of querying a collection of data, so it should be very natural.

Up next is the "source query" we are going to use throughout the talk. Previously the talk was designed for this query to be put at the final conclusion, where all of the features combined. This time, I tried a different way.

The "source query" is then translated to "ordinary function calls".

Note to self: the appearance of Lambda expression there is quite confusing. I should use anonymous method or standard delegate next time (to ease the transition from 2.0).

To make sure that both syntax behave exactly the same, we're going to switch to demo mode to see it in action.

Here's the code for "source query":

return
    from cookie in christmasCookies
    where cookie.Name.Contains(lookup)
    select cookie;

And here's the code for "ordinary function calls":

return
    christmasCookies
    .Where(cookie => cookie.Contains(lookup))
    .Select(cookie => cookie);

If you run it, both will return same result. I can open it using Reflector to see similar code for both function.

Now that you know the syntax equivalence of the "source query", we can move on to discuss each language features that is used to make LINQ actually works...

The first and most visible is Extension Method. The methods called in the "ordinary function calls" are one-to-one replacement with LINQ keywords; where for .Where(), select for .Select(), etc.

Extension method enables you to add method to an existing class without limitation of the class' inheritance modifier. You can add method to an abstract, sealed, normal, or even interface.

To illustrate the usage, I've created a simple extension method for speech synthesis. It also outlines the ease of use of .NET TTS engine.

Here's the code:

static class SpeakExtensions
{
    public static void Speak(this string str)
    {
        System.Speech.Synthesis.SpeechSynthesizer synth = new System.Speech.Synthesis.SpeechSynthesizer();
        synth.Speak(str);
    }
}

Now you can make any string to .Speak() by calling the extension method. Take note that you are not subclassing or recompiling the System.String class.

Advanced note: under the hood, extension method uses a concept of static class/method to do it's magic (that's why it has to be declared inside a static class). Static class and static method are basically available to be called from any part of the code (provided you referenced them). Now if one of this method takes an instance of an object and do something to it, you can achieve the extension method behavior. But, using this path will make your code very messy (lots of static calls). Extension method hides (not removes) all the mess under a very elegant syntax.

Next huge part is Lambda Expression. This part is almost one-to-one replacement with "source query", because this part encapsulates the logic of the query. On the slide we have two logic, the first one is selection logic, and the second one is output logic.

Lambda expression relieves you from having to define the parameter types and the rigid structure of delegate instantiation. It is actually 100% exchangeable with anonymous delegate or standard delegate.

To illustrate this, I have created a code of how lambda have evolved from delegates.

Here is the "standard delegate way":

foreach (int i in wholeNumbers.FindAll(EvenNumber))
    Console.WriteLine(i.ToString());

...

private static bool EvenNumber(int input)
{
    return (input % 2 == 0) ? true : false;
}

Note that you need to define the named delegates first before you can use them in the .FindAll function.

And here's the "anonymous delegate way":

foreach (int i in wholeNumbers.FindAll(delegate(int input) { return (input % 2 == 0) ? true : false;}))
    Console.WriteLine(i.ToString());

Note that you still need to pass in parameter types (v2.0 is already smart enough to infer the output parameter type).'

And here's the newly invented lambda expression:

foreach (int i in wholeNumbers.FindAll(input => (input % 2 == 0) ? true : false))
    Console.WriteLine(i.ToString());

Note that there are no delegate declaration or parameter type setting.

Then come the shortcut trio; Object Initializer, Collection Initializer, and Auto-Implemented Property. All three can be easily recognized as syntactic sugar (well, almost all of the new features are syntactic sugar -- it runs on top of v2.0 CLR!).

These features simplify object declaration and instantiation. The first two are easy to understand, auto-implemented property also very simple.

Note to self: I should've written a small program on the fly for the demo. No need to prepare anything. Create classes with auto-prop, and then instantiate it using both initializer, and then output the result to screen.

Then come the confusing part, Anonymous Types. It's easy to use this in query, but it's not easy to create a real-world application for this.

Anonymous types enables you to have a strong typed class/type, without the need to declare any of the property, or even better, without the need to declare it.

The question I have not been able to answer is, in real world, when do you need to use anonymous types. In a real world scenario where all business entities are perfectly defined, I don't see any usage of anonymous types. Note that, this feature can be great if you're prototyping some application or creating some object on the fly (and still keep the strong type).

Opening the DLL using Reflector is one way to make sure that the classes are generated on compile-time rather than run-time (thus, keeping the strong typing).

Note to self: think hard on creating a good scenario for this feature demo.

The final one is Type Inference. I predict that this will be the mostly used feature since it is both convenient and safe to use.

Type inference relieves developer from the need to specify a type to a field on declaration. The type is inferred from the first assignment. The field is neither variant (can be of any type) nor System.Object (which will need boxing-unboxing process when used).

To illustrate this, I create a simple code below:

var inferredField = 1;
inferredField = "One";

You will not be able to compile the above code since the compiler will infer and declare the field type to System.Int32 (the first assignment). If you're trying to assign a string literal to an integer field, you will get compiler error.

But wait, there's another feature? Yes, and it is called XML Literal. Should the previous speaker (name hidden) does not spoil this, it would be the big closure of the day. (hey, no offense man, we didn't sync up on this one :D)

Note: I didn't even bother to put anyting in the slide because of the suspense it creates.

XML Literal enables Visual Basic developer (yes, you read that right -- this is a VB-specific feature!) to copy and paste an XML file into the code as an XML (not string). Not also that, you can also output an XML using this feature. So you can write XML inside your VB code using some XML Literal, some LINQ to XML, and some plain old function call. It sounds mixed up, but it does the job. (And that is what VB does -- the job.)

To illustrate the usage, I created an XML reader in place of the collection initializer:

Dim xmlCookies = _
<ChristmasCookies>
    <Cookies>
        <Id>88653C79-2F49-40fd-9BBD-38EE0B5C69CA</Id>
        <Name>Chocolate Mint Cookies</Name>
...

Return _
  From cookie In xmlCookies...<Cookies> _
  Select New With { _
    .Id = New Guid(cookie.<Id>.Value), _
    .Name = cookie.<Name>.Value
  }

Neat!

In Summary, here we have the list of new features I have explained. Just in case someone missed the name of the feature.

Note to self: should tell a little summary about each feature (forgot to do this earlier).

And comes the standard blurb slide. Shameless self-promotion and contact methods.

Done!

(P.S.: In case you didn't notice, you can click on each slide picture to get a bigger view of it)