Sunday, January 18, 2009

Identify the Subtle Bug.....

A friend of mine pointed me out to this.

This code has a subtle bug. What is it?
Hint: it has nothing to do with encryption.


using(RijndaelManaged enc=new RijndaelManaged(){Key=key,IV=iv,Mode=CipherMode.CBC })
{
//DO SOME WORK WITH enc
}


So to outline what and why this doesn’t do what is expected let’s review what this code is
shorthand for.

First:The using block is actually shorthand for a particular try … finally pattern.Roughly this code:

using (SomeDisposableType item = new SomeDisposableType()){}


Is equivalent to:


SomeDisposableType item = null;
try
{
item = new SomeDisposableType();
//DO WORK
}
finally
{
If (item != null) item.Dispose();
}


Depending on how IDisposable is implemented, there could be an implicit cast to the interface involved as well so you’d see ((IDisposable)item).Dispose(); in the finally block instead. Meaningless to the current concept however.

The new C# feature of Object Initializers are another form of syntatic sugar for really this:

SomeTypeWithSetters item = new SomeTypeWithSetters();
Item.Prop1 = “SomeValue”;


By writing it this way:

SomeTypeWithSetters item = new SomeTypeWithSetters(){Prop1=“SomeValue”}


So when you put them together (as in the original example) you would expect the code would be equivalent to this:


RijndaelManaged enc = null;
try
{
RijndaelManaged enc = new RijndaelManaged();
enc.Key = key;
enc.IV = iv;
enc.Mode = CipherMode.CBC;
//DO WORK WITH enc
}
finally
{
if (enc != null) enc.Dispose();
}


This is NOT the case however (and hence the bug)!Due to the nested statement rules in the C# spec, instead the compiler evaluates the code as a nested initializer block followed by a completely separate using block and not a unioned language construct!


RijndaelManaged enc = new RijndaelManaged();
enc.Key = key;
enc.IV = iv;
enc.Mode = CipherMode.CBC;
try

{
//DO WORK WITH enc
}
finally
{
if (enc != null) enc.Dispose();
}


Note: technically the compiler will actually emit two variables pointing to the same object. For clarity I’ve skipped that as it’s frankly not important to the example.

So if there’s something that goes hinky in the initializer block, the Dispose() method is NEVER called by your using block as the code has yet to enter it. All sorts of general badness may then follow. It might be as simple as inefficient use of critical or expensive resources to something as bad as a leak. In general, all sorts of badness, in varying degrees of said badness, may happen to your application.

After that: Hilarity Ensues followed by an immediate Epic Fail.


While I agree that this should be handled by a C# language specification change regarding how the using construct works with nested statements, this is currently how it works today. While not a bug per say in the compiler, it should be considered a hole in the spec itself. Maybe we’ll see this as a change in C# 4.0?


Original Credits : Jimmy Zimmerman
Source: http://ayende.com/Blog/archive/2009/01/15/avoid-object-initializers-amp-the-using-statement.aspx


Thursday, January 15, 2009

Cloud Computing and Economy

Cloud computing is a style of computing which packages computing resources such as processing power, storage, connectivity etc as a service and delivering the same to the consumer in a scale-free, cost efficient and timely manner over the web. Applications get into production much quicker than the traditional models by which applications are provisioned. This entails a shift in the way applications would be built, executed and also managed in the future.

In an attempt to understand the financial implications of the new cloud based model used for deploying and running web applications over the traditional client server web application model a little better, I will try and put it in the context of a hypothetical scenario which would highlight differences one would observe in both the cases.

A startup company that intends to have some web presence decides to build a self service web application which shall receive orders from their end customers. From a architectural perspective, they decided to build a simple data driven web application that is easily available over the internet to their customers. Let us assume that the application designed is a traditional 2 –tiered client server architecture.


So what is it that is required to build an application which is available over the Internet?

An attempt to mark out some of the key asks are in the list below and classified them under the various costing heads

Capital Expenditure
1. Construct a physical brick and mortar facility to host the servers including the cabling, USP/Generators to keep the server always ON
2. Procure a server grade hardware(s) for the client and server setup. In case you have availability requirements then you would have at the minimum two servers that bring in some redundancy to help achieve this. Additionally we would have to include redundant component such as NICs, UPS’s, switches
3. Software Licenses required to build High-Available web applications Windows Server OS’s, NLB, firewalls and security solutions such as ISA
4. Additional hardware and software cost required for setting up an available DNS server to resolve client requesting name resolution
5. Provision a static IP from your ISP
6. Database software licenses would have to be purchased
7. Operations and Management software licenses such as MOM, backup facilities.
8. Purchase a development system, assuming that you would want to have your development

environment separate from the production site
9. At the minimum Win XP license for developers
10. Purchase the Visual studio licenses to develop the web application
11. Purchase the developer edition db license for the persistent storage


Operational Cost
1. Registering your DNS addresses with ICANN
2. Per unit power charges for keeping the production systems always ‘ON’ including power consumed by the hardware, air-conditioning
3. Salaries to maintain and manage the infrastructure


Non-Operational Costs:
1. Carbon tax for companies running their own data centers


Opportunity Loss:
1. Sub-optimally utilized hardware
2. More time to market involved mainly due to the time spend on procuring and provisioning the resources


Now comparing this to an application which adopts to a cloud based architecture

The costs which shall be incurred would include:

Capital Expenditure:
1. Purchase a development system, assuming that you would want to have your development environment separate from the production site
2. At the minimum Win XP license for developers
3. Purchase the Visual studio licenses to develop the web application


Operational Cost:
1. Per unit charge to use the cloud OS services which will execute the web application
2. Per unit charge to use the cloud db services


As can be seen a business has been able to considerably eliminate its capital expenditure on IT, resulting in tremendous savings. Savings allows firms to invest in its core business areas that would lead to revenue generation. Moreover in these times of economic recession, credit for businesses is not easily available; hence any savings that businesses can achieve will help them to have that much extra to run the business.

In addition to having direct financial implications in terms cost, the cloud platform also help in enhancing the Time to Market of software applications

Time is Money
It’s an old cliché we all know and understand, but to what extent do we see IT able to support businesses in applying this in principle. Businesses have lost out on opportunities simply because the systems which they have build over the past decade or so have now become inept or non-responsive to cater to the growing dynamics of the business. Their architectures do not allow them to adapt to the dynamically changing requirements or even for that matter be elastic to cater to fluctuating user demand. Some factors effecting an applications Time to Market:
1. Time is spent on procuring or provisioning hardware or software while deploying a new application.
2. Time is spent on procuring or provisioning additional hardware if existing applications have to handle any growth in business such as during mergers/acquisitions, seasonal or market.
The evolution of the Web, SOA and Virtualization technologies have now amalgamated to herald this new style of computing. The Cloud inherits the intrinsic traits of these three technologies which allow enterprises adapting to this new style of computing build applications which are available everywhere, become agile and elastic to meet fluctuating user demand. It not only extends existing on-premise/hosted applications but also gives opportunities to realize existing architectural patterns more easily or even discover new patterns in which applications get developed, provisioned and delivered. All this in a relatively shorter span of time as compared to the traditional approach of constructing and commisioning applications.