JavaScript Journey Part 1 (Ninja Returns)

Today's application development is more focused on the web, we have experienced a shift in momentum from a typical desktop, dynamic website/web application to a more advanced web technologies that utilises HTML5, CSS3, Web components, advanced object oriented Java Scripting, AJAX and above all, Single page architecture. Complete evidence can be obtained from every nook and cranny of the web, cloud computing, mobile technologies and smart technologies. Coexisting applications is becoming the future focus, and to do this graciously, we must re-webify and take on the current mindset "The web is now becoming the desktop".

JavaScript is one of the oldest technology that refused to be replaced but instead, continue to get updated and deliver the modern day web, with its complementary technologies (CSS, HTML, XHTML, XML, XPATH), JavaScript is here to stay and to continue to drive forward our desire for very rich disconnected user experience over the web (GMail is a good testimony and the latest yahoo mail).

A not so long time ago, JavaScript was used by many, in its basic form. For form validation, browser navigation, cookie manipulation,  browser histories e.t.c Little did we know that JavaScript does have the potential and capabilities of solving the same complex problems that the modern object oriented compiled programming platform are solving. It is even  more better when the JavaScript V8 engine can run on the server, making JavaScript not just a browser based technology, but a server based technology too.

Single Page Architecture (SPA)

Web based application that runs as a single page but delivers the feel of a desktop over the cloud. This architecture does not favour the post back/refresh mechanism that was a dominant architectural standards sometime ago, though many developers are still doing this, including myself, because SPA is not a one solution fits all problem architecture. There are some real world problems that can only be solved by postbacks/refresh mechanism, in fact, the issues of standardising the W3C standards across all browsers (a.k.a Web components) even makes SPA architecture very difficult to work with, but there are ways around it, communities were formed and we have several OSS (Open source software's) that helps make life a better place to live in the world of SPA. See the below diagrams for the simple architecture cardboard for an SPA architecture.

Components of the single page 

Template engine: there are many available JavaScript template engines available as open source frameworks. They are responsible for rendering the templates which are part of the HTML or are computed as part of the HTML and JavaScript. A template engine would read the template based on known configuration patterns and if based on discover-ability architecture (software following a declarative pattern) would facilitate JavaScript views discovery. The template approach should not only define how data binding should be ensured or if a particular section is a single object binding or multiple object binding. Equally they should specify in the HTML data annotations for discovering a view, a data annotation for exposing triggers, events, handlers, a data annotation for model expression (regex). Will give full coverage of template engine later in other episodes of JavaScript. A good pseudo example of configuring an html section as a template and view is as follows:

 The pseudo template description above leverage's the web components custom element specification. A view is described as x-view with children which can be x-field (for describing fields for data-binding and/or rendering), x-association (for describing the association of inner views, for instance a customer view has multiple address views). More complex information will be given in the template engine section in other episode of this series ...

View engine:  based on the template that are described and pseudo example given above, the view object should be created as to, one view declaration to one view objects. I will give you further hints and approaches to the ways you can create a list view which only data-binds when you bind data, and a view object would be created for an list item when it is interacted with (giving us the power of lazy view object initialisation, and ability to bind 100s of data without worrying about how many views object's that will be created).

The view engine is responsible for the object oriented representation of the view template described in the template engine section. In fact a view object is a JavaScript object that can be described like so:


The framework would auto discover the view and would create an example view object like above.

Security context: a single architecture would require security to be built atop especially the type that assigns roles and responsibilities to the users based on allocation. So for instance, if user A can access a particular section of the SPA/form/view/x-field/associations the relevant security privileges will be allocated to the user. The security concept of an SPA would be to the granular level, security features can be added to views and parts of the view (called view policies). As of writing, there are no interesting security frameworks out there that can provide such level of granularity on the JavaScript side unless it is custom built. I have lead a particular SPA project where we built such rich security features, that it self is an episode on its own. A context object need to be readily available to be passed after a user login, this object would contain context aware information related to the current logged on user. An example is as follows:



above gives a skeletial view of what a typical security context object would contain. more details will be given later.

Observer model: View objects changes (field and association changes) need to be observed, a type called observer model is required, which tracks changes in a view object, as the view object changes, the observer  model changes. This kind of architecture can be traced back to the MVC (Model View Controller) GUI pattern. Fields themselves are observable, the views are observables and provides notifications to the observers or listeners. Also, property change notification can be implemented in the observer model, this will make the observer model to notify interested listeners to register and listen to when a model property changes. The concept of the property change notification makes the observer model observable too (two directional observations).


View Presenter: The presenter pattern is a architectural pattern that enables the events,  model binding and general house keeping functionality for the views. While the view is responsible for controls, rendering and input, the presenter will handle control events, register cross server events, listen to global/user context changes to notify the view. The presenter is where the developer concentrates his/her coding in this architectural style. Events will be handled, forwarded, dispacthed, propagated, delegated etc. The presenter is more concerned with separation of concerns and testability of the core functionality. Presenter is where the code gets interesting, but could become very ugly if all sorts of events and business functionality are handled in there (We need to watch the code-base).



if you go back to the pseudo template engine declaration, you will notice an attribute declaration within the x-view element, this declaration is to specify what presenter is need to be used against the view in question. Back to the presenter declaration above, there three life cycle methods (preInit, init, dispose), these events will be raised throughout some stages in the presenter lifetime. You will also notice the global getView and getEventBus function, they do the exact thing that the code describes. The getView gets the current view that was initialised with this presenter and the get eventBus gets the eventBus that is specifically made for this presenter. The eventBus can be used to listen to both presenter level events, view level events, cross presenter events and of course server sent events in case websockets are in use or the Server Send Events (SSE) is leveraged.

Lookin deeply into the presenter declaration, in the preInit life cycle method, you can get a good example of how view controls/fields events are registered. The example given registered changed event on the firstName field. Also the association added event was registered into when an address view is added, the event is fired.

Server side controller and actions or event web api: The wonderful thing about spa is, it is server side agnostic, it can consume data from different endpoints technologies, languages. It can in fact leverage COR (Cross Origin Request)  to pull data from different domains. We can leverage on the ASP.NET MVC view controllers for servicing the html s and the templates when requested by the spa page, and equally we can leverage on the  asp.net mvc web api for REST styled architectural data in json format.

Custom controls: the HTML controls cannot be enough, the HTML5 standard controls and functionality will not be enough to build a responsive SPA based architecture, jquery controls are too tied with jquery but can be abstracted into your spa architecture. You need to buy into the idea of custom controls, controls like tree view are not standard HTML controls, nice looking controls like auto complete are not standard controls, so you need the abilities to allow your development to introduce custom control as the requirement of your application gets bigger, or more so, if the same code are to be reusable across your architecture. see an example of custom control :



The control description above, describes a tree node structure. As you must have deduced from the type of the control that it is a "TreeControl", the name is the name that will be given to the instance of that control, note, a control can be a member of a view and some controls can allow for databing from the view observer model, of they are responsible for fetching their own data based on configurations sets. A nicer way to architect a control is to introduce an BaseControl which all other controls can inherit from using a prototypical inheritance of any form of JavaScript inheritance of your flavour.

This is just a quick peek spa architecture intro. I will be introducing more in dept blogs on other useful architectural approaches and patterns that can be used to fulfil the needs of spa.

to be continued ...

AppFabric Caching: Not noise, but a flawless initiative

Application state  is one of the  most underrated aspect of any software development. Developers want to solve problems quickly enough and ship the next generation of software into the market without ever considering how maintaining application state cross servers or domain could be a plus, one of the most demanding software success criteria of today. Because software engineers are so much in haste and there are several pushes from top management, engineers sincerely bend the rules of good principles and shippable product that meets the market demand. How we manipulate and use data should be the paramount goal of any successful application, Are we doing it? how do we fail over? what happens if a sever is down? Will my session pick-up from where it stopped? Is the appkication stateful or stateless? How do we Increase the capacity of the software without changing any code? Can we administer our cache as part of infrastructural benefits?

Every software application conduct the activity of data processing at one particular time or the other. Because software components need to process data to function efficiently, some of these data should be readily available to the software. In fact, data processing brings more sense to the use of computers. Will computer be meaningful without data processing? Despite differences in software platforms, operating systems, user base, software application tend to face the same problem over the cause of time, Data!

Different types of application consumes/dispense data using varieties of formats, platforms, serializations. The realization that bringing data closer to where it is needed, has gainfully helped several applications in the area of performance.

Enter enterprise computing (The problem statement)
Enterprise development is more focused on efficient data usage. Software Applications commanding thousands/millions of user base falls under this category, so as software application that require intensive data processing. Banking software, media data processing/CMS, financial applications, ERPs, e-commerce, m-commerce and pure engineering based software applications, belong to this category.

With the growing number of complexities in today's business and engineering world, data  need to be safe, efficiently delivered, durable and highly available. We need to access and process data when it is required. Without heavy reliance on the database system/and other data sources, data can span multiple computers in the same co-location, and can also span multiple disparate systems to form a cluster of data which are readily available for the enterprise.

It is now becoming more challenging for the enterprise to set-up the infrastructure for proper real time data manipulation, relational database is losing its popularity and paving ways for NoSQL initiatives and memory databases which are now gaining the momentum. Software need data to be its closet allies and not travel across tiers and layers before data can be reached. With this known challenges, if you are using the right tool and encouraging your development team to focus more on data efficacies, then you are one step close to high availability of data and prevention of data loss.

AppFabric Caching, once code named Velocity, is a Microsoft initiative to solve the problems faced by distributed computing, it enables enterprise development to cater for heavy throughput which is one of the demanding factors of todays successful businesses. Efficient use of data is the bedrock of any per formant application and the ability to process these data using good principles without painfully stressing out data sources would give you a first class win in today's competitive and aggressive market place.  whether you are operating a software shop, or you are buying from a software shop, or you have your own in-house/outsourced developments or you want to build future application which can scale across multiple computers (This includes mobile, web and desktop applications).  The caching solution brought to the table by Microsoft owns AppFabric should not be underrated. 

With the growing number of Microsoft enterprise product stack, AppFabric caching is an addition to the family which we get for free and also builds on-top of existing technologies. It enable clusters of cache servers to act as a single application cache, by allowing a distributed caching systems which scales across multiple caching cluster through a single cache system point (Referred as the entry point). AppFabric can automate installation of itself on any other computer  without user interaction, if the current appFabric caching service need to scale to another computer using the same configuration, you can easily run a command line task which will process the installation while also suppressing any GUI messages.

Good bye sticky session welcome AppFabric
Asp.NET begins a session throughout the duration of connection to the server using either in process state provider, out process state provider or SQL Server sate provider, these three are the default state session store supported by ASP.NET out of the box. User Session can become idle if there was no interaction with the web server within a duration. Each time a user initiates a requests to the server, the users session is renewed and all user objects that are in that session gets automatic promotion to the next expiry time. Asp.net session provides each connected client with a unique session id which is stored in the client cookie for request and response identification, although asp.net can operate in the  a cookie less session mode, this is not so friendly because of the generated url. Cookie less session adds the session id to the url using the following format:

http://example.com/folder/(session ID here)/home.aspx 

AppFabric caching builds untop of existing technology and provides for a high end state store, which does not only leverage on high availabilities of data but readily available at all time. By adding configurations (for xml configuration) or using code based configuration, and also using the AppFabric session state provider, you will have appfabric readily available to you. Sticky sessions are more useful for small applications whose user based are quite small and does not store heavy data into the session. Because sticky session makes use of memory web server memory, then that means the session cannot scale into other computer, there are no ability to add new cluster for higher throughput. If the web server is down, the session goes dow.

Caching Advantage
The AppFabric caching is readily available for use in any .NET languages, each caching sever is hosted using windows service, you can run commands on the service using windows power shell using AppFabric Cmdlets. There is also an open source software out there, the AppFabric management admin tool which you can leverage to administer your cache clusters.

I started using the caching service since it was code named Velocity (a beta product then in 2009), the latest version available can be used in production ready environment. Setting up a cache server couldn't have been more easier with AppFabric caching, the relevant components are: the cache server (a windows 7, 2008, 20012 server), the cache host (A windows service) and the cache configuration which is a per cluster configuration.

Although, cache configurations can be located in a shared folder using an XMl file format, or using Microsoft SQL server, or using a custom provider. Cache clients  need to reference AppFabric dlls to communicate with the cache clusters. Also cacheable objects need to be marked serializable or be marked with the DataContract attribute and all its serializable memebers marked with DataMember attribute.

I will be providing another post on how to use and setup basic AppFabric cluster.

Separation of concerns: The proper use of technologies

Have you ever written or programmed in such a way of convoluting functionality with business rules, data transfer objects, Domain driven Design (DDD), ORM standards etc into one single partition of your enterprise level application.

1. Do you at all, think of your system as a piece of components with its own concerning functionality?
2. How often do you do pure object orientation? (How often do you conceptualize your application as real world artifacts)
3. Do you just code to solve business problems, or do you engineer code to be used to solve business problems?
4. Do you have overlapping functionalities frequently in your projects?
5. How do you integrate your system with legacies or third party? (Do you just integrate or add a layer of integration).
6. Do you examine the commonalities and/or variabilities of your system before re-inventing the wheel.
7. Do you know the paradigm: System of Systems
8. What about aspect oriented programming? (how do you keep cross cutting concerns at bay?)

I can go on and on, but I'd thought i should take it from simple facts, so that upcoming software engineers/developers are inculcated. The success factor of an enterprise application development, is the domain knowledge, how often do you review and conceptualize your domain?

Domain engineering (Now called product engineering) is a systematic way of conceptualizing application components into families of systems to be later reused to solve problems within the domain. Although the concept of domain engineering is a different topic for another day, most software development IDE's are beginning to integrate this concepts into their systems.

Again: What is separation of concern

Separation of concern is a computer programming paradigm that stressed out the abilities to modularize , conceptualize , hides external impediments , follow LOD (law of Demeter or principle of least knowledge).

Although technologies had helped improve software development from 10 folds into higher number of folds in recent times, still, most development lack the knowledge of bringing this technologies together, rather they create an over complicated system which undermine the intentions of advancing technologies.

Are new technologies really new?

New technologies are not really new, they a proven approaches/standards blueprints which had been adopted by wider communities in the past before it became a technology. I would say, make a research on a new technology to understand its root and to understand what the drive and multivations are in the first place.

Latest .NET most misunderstood technologies

1. ASP.NET MVC. Try to understand what the real MVC paradigm means. MVC is not a technology but a methodology.
2. WCF is not RPC (Remote procedure call). The contract first development is not actually contract first, its Interface/Code contract first because this will still auto generate the WSDL , xml schema's etc. try to manually create wsdls and schema when integrating with different languages or platforms. Or understand how this work and how you can leverage message based achitecture instead.
3. Entity Framework: Is not an holy grail nor a silver bullet. ORM's has their strengths and weaknesses, use patterns with ORM's or avoid most pitfalls when using ORM's.
4. AJAX: Do you understand XMLHttpRequest and Response? have a look into the root of all AJAX evils, its a must understand.
5. WWF: Why the sudden changes in .NET 4. When to use and how to reduce its noise.
6. MEF: managed extensibility framework. very nice, but it is not a replacement for dependency injection framework.

This list goes on and on, but for now, i will stop here and let us have a think. Microsoft did invest alot on these technologies and upcoming technologies for us to have our concerns separated.

Demystifying Drag and Drop in ASP.NET (Part 1)

This is not particularly and fully related to ASP.NET but the main project which I extracted this concept from is an asp.net project, so I have decided to present an asp.net example.

As a requirement for one of my pet projects, I am required to create drag and drop event handler on an scheduler/events calendar. This threw me into the dark side of javascripting, ASP.NET ICallBackEvent interface, post back/viewstate dodging.

I searched the web for an existing solutions that will enable me drag events memo from a date to another date using JavaScript. Most of the approaches that I encountered are either too complex or overly complicated for the simple scenario

Then I stumbled on this particular script at Web Tool kit which blew my mind away, this JavaScript particularly simplifies the cross browsers headache when trying to handle mouse events across browsers. And its simple object oriented approach to handling and delegating event for drag and drop is just fantastic.

Then something happened
I was looking for a solution that will enable me to drag an event from one data point to another. The solution i am talking about above though perfect but it has not fulfilled the entire drag and drop functionality. I can drag and drop, but when droping, the element being dragged should be attached to the object in the drop zones.

For clarity, try the drag drop sample below. Please note that the two drop zones can allow drag gable elements to be dropped upon them, and that you cannot drop items outside of the drop zones. To give a clear comparison then try the example given in the original script, located here , then you can understand the concepts of drop zones and drop targeting.

Drop Zone 1	Drop Zone 2	Collection Area
		Draggable 1 Draggable 2

The above drag and drop simulates the drop zone functionality which allows drag able elements to be dropped into the zones without hassles.

The missing points in original JavaScript, is the fact that drop zones are not recognized. I will take you bit by bit into how I have improved and added new functionality to the original code :

Identifying the container

The container element for this page example is a table with id = 'main'. A container is an HTML element which will contain the drop zones, note, any html which can contain other elements (p, div, table li etc.)element within the body section of an HTML document can be used as a container. This example makes use of a table as the container.

<table id="main" cellpadding="6" cellspacing="6" border="1">
<thead>
<tr class="style1">
<th class="style1" valign="top"> Drop Zone 1 </th>
<th class="style1" valign="top"> Drop Zone 2 </th>
<th class="style1" valign="top"> Collection Area </th>
</tr>
</thead>
<tbody>
<tr>
<td class="zone">

</td>
<td class="zone">


</td>
<td class="zone">
<div id="dragable1" class="element-class">
<h3 class="box-head">Draggable 1 </h3>
</div>

<div id="dragable2" class="element-class">
<h3 class="box-head">Draggable 2 </h3>
</div>
<span id="writtable">

</span>
</td>
</tr>
</tbody>

</table>

Some table cells within the table main's table row have the class name zone identifying them as the drop zones. Any element with the class name = "zone" can contain draggables.

Any element can also be dragged (except td, th etc. ), so far they are registered using the following javascript snippet.

DragHandler.attach(document.getElementById('dragable element'));

Registering/Preparing the Container and Drag able objects
We needed to look up the DOM and hook events on the drag gable's and retain drop zones into a Position object created below.

var zonesArray = new Array();
var index = 0;

window.onload = function () {

var dragable1 = DragHandler.attach(document.getElementById('dragable1'));
var dragable2 = DragHandler.attach(document.getElementById('dragable2'));

var main = document.getElementById('main');

for (var j = 0; j < main.childNodes.length; j++) {

PrepareDropZones(main.childNodes[j], zonesArray, "zone");
}
}


function Position(element) {
this.X = findPosX(element);
this.Y = findPosY(element);
this.Element = element;
this.Width = (this.X + element.offsetWidth);
this.Height = (this.Y + element.offsetHeight);

this.IsInCordinate = function (XCord, YCord) {
if (XCord > this.X && XCord < (this.Width) && YCord > this.Y && YCord < (this.Height)) {
return true;
}

return false;
}
}

The above code is the missing point in the original code, and the part where elements are dropped. As soon as an element is dropped, the mouse coordinates X and Y are checked against the drop zones X + width and Y + height , if the mouse is within coordinate, then the element is dropped. Shown below is the code for checking drop zones when an element is dropped.

// private method. Stop drag process.
_dragEnd: function (e) {
var oElem = DragHandler._oElem;

var x = parseInt(oElem.style.left);
var y = parseInt(oElem.style.top);

oElem.dragEnd(oElem, x, y);

var evt = e || window.event;
var evtTarget = evt.target || evt.srcElement;

for (var i = 0; i < zonesArray.length; i++) {

var dZone = zonesArray[i];
var cursor = getMousePosition(e);

if (dZone.IsInCordinate(cursor.x, cursor.y)) {
dZone.Element.appendChild(oElem);
oElem.style.left = 0;
oElem.style.top = 0;
break;
}
else {
oElem.style.left = DragHandler._beginX;
oElem.style.top = DragHandler._beginY;
}
}

document.onmousemove = null;
document.onmouseup = null;
DragHandler._oElem = null;
oElem = null;
}

Download the source code (VS 2010):

SOA : The golden bullet of our time

The hype in todays enterprise development world is SOA (Service Oriented Architecture), as enterprises are becoming conversant with this buzz, so as medium and smaller companies are considering joining the band wagon of this development strategies that is gaining momentum in todays enterprise computing.

SOA as the name suggest is a development strategies that tries to put decoupling in mind from ground up by using the notion of services. Although decoupling is un-avoidable when we engineer software/component but to a degree of efforts, SOA allows you to take advantage of seperation of concerns service orchestration, Service Choreography, REST Architecture and Service reusability. Decoupling is bad to some extent because this business of ours is all about integrating stuffs (coupling), there are types of coupling that make sense and there are coupling that makes no sense at all. The following are sample of types of coupling :

Business Coupling : In the real world where we make money and apply both theorical and practical knowledge to software engineering, we cannot avoid integrating systems with legacies and new applications. Business coupling makes sense because we tend to apply rules of data interchange between disparate systems why we avoid any form of tight coupling to reduce the dependencies amongst participants. This is an exact coupling that SOA would allow, the business logic codes are exposed as a service and there are no dependencies between services and consumers. Although business coupling could lead to plumbing if developers do not take into account the tenets of Service Architecture.

Plumbing Coupling : This type of coupling is what most developers that are just finding their ways into true software engineering processes do. This coupling is bad and does not add any value to your assets and infrastructure. In my years of experience, i have encouraged developers and have educate developers to move away from this development practices because as long as you continue to plumb couple, your system will die naturaly without any cause. Plumbing is a sin that we all must have committed one way or the other and the only ways to cleanse ourselves from this sins is to embrace SOA and try to pay back our technical debt by constanly reviewing and refactoring our code.

Having understood the two most common coupling, we should now know where SOA fits in software engineering. SOA allows us to expose business functionalities without exposing the underlying code by enforcing a data-interchage driven by SOAP (Simple Object Application Protocol) by encouraging metadata interchange. SOA is client/devices/platform independent so far we follow the W3C semantics of SOAP and the WS-* specifications.

The Tenets of SOA

1. Explicit Boundary : Service should communicate with themselves in a true and loose coupled manner using agreed messaging construct (SOA encourages SOAP Envelopes). As long as there is no rigourous dependencies amongs services, services should be able to send and recieve messages between themselves without the knowledge of where they are located. Services are platform angnostic by default and should use this effectively. A service boundary starts from the service contract, all communication agreements should should be based on contract.
2. Services can be autonomous: This encourages us all to build services that are independent of other services, and since we cannot achieve one hundred percent service autonomous, we can still strive to build services that are cleanly seperated from dependants, an example of such service is a service which serves as a router or facade for other services. Services can be autonomous: This encourages us all to build services that are independent of other services, and since we cannot achieve one hundred percent service autonomy, we can still strive to build services that are cleanly seperated from dependants, an example of such service is a service which serves as a router or facade for other services.
3. Shared Contract: Service clients talk to services using a published contract. The contract is an interface where service clients communicate with the service. The service client is not required to know the intricacies of the service because the contract sits between the client and the service. Most dependencies are on the contract and not the actual implementations of the service.

To be continued ...

Hit Your Deadlines and Incur Technical debts

We all owe our developments more time to do it right. Software developers are humans too, we can make mistakes, take short cuts , hack , hack , hack and wala! we think we are done , we think we have produced the most changeable solution, the most elegant code, we think we have added value to the business because it works (Hey it works). Well wait until business changes mind, wait until your company buy in a new solution to enhance its business, this is when it will occur to you that you have produced the most crappy software of the year.

Sorry Guys, do not judge me by my writings. I have been in many situations in the past, instead of learning from it i fall into the same pot hole again and again. All in all, software architecture plays a dominant role when building enterprise applications and since i wasn't the architect, i fell into the same pit again.

What is Technical debts

The metaphor "Technical debts" was developed by Ward Cunningham (The man behind wiki) It means design / code / architectural debts that we owe our developments , since we are humans and we want to meet our targets we can bypass some development strategies to make a shortcut, so that we meet the deadlines. Meeting the deadlines doesn't mean we would not re-pay our technical debts (This is one problem that most people/organisations make). We need to go back to the drawing board and re-sharp , this will enable us to learn more on the product and this will strengthen our knowledge of the entire system.

Knowing when to re-pay your debts

You can choose to continue incurring more debts (This will tie you down to the system), or if you are smart enough or at least someone in your team is an anti-hacking developer (A design pattern loyalist) , then you can choose to refactor mercilessly.

Nobody ever said it was going to be easy, but at least you are making the first move to improve your system. Re-paying technical debts is a culture that all software professionals should imbibe. A development team should aggressively encourage this practice , or else none of the team members would come in terms with their weakness or forgotten errors.

I know its good to go faster to the market, but at-least let us look back and re-pay those debts that might come back to hunt us.

What do you think i am doing right now, of course "I am re-paying my debts"

They are here! April 12 2010

If you read my last post about the long awaited Rosairo , you will understand fully well, the richness of what the future hold in stock for all of us.

Come This April 12, the .NET community will experience a change in software development while leveraging the .NET 4.0 and new enhanced WWF (Windows Workflow Foundation), Advanced and Rapid WCF (Windows Communication Foundation) . This will mark the true begining of us all in the .NET Land.

In my experience with developers, catching up with technologies is very difficult because of the rate at which technologies changes in the .NET front. This might leave some developers obsolette because some have'nt tried their hands on LINQ , Extension method , anonymous type e.t.c This isnt nobodys fault but some justifications while this new futures are there. I recently interviewed a C# developer remotely about his abilities on the .NET framework, he said ! ".NET stopped bieign .NET since 3.0/3.5, he went on saying that .NET 2.0 is the best of all."

Everybody is entitled to his/her own opinion, if a new feature appeals to you, use it, if else then throw it away. Visual studio .NET IDE now allows you to switch frameworks, so you can go back to previous framework version.

Never the less, new changes are driven by Customer requirements , bug fixes , industry defined and endorsed patterns. So not to worry, because They are here already!

I cant wait no more , click here to try it out