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

Software Development Should evolve and not desolve

I have written several titles , i have made a big leap in software development strategies. I have utilized domain engineering culture towards developing software. I am against reactive software development. I talked about AZURE , about Google ready to GO , I took you down to the Spider Web Land while telling how we can be Green too. These are very good articles that reflects the happenings in todays agility driven software world. For this flow to continue, todays topic is how we grow our development process with emerging technologies.

All problems and solutions in software land revolves around how we allow our software development process to evolve. How do we grow our process of development? what can we do to ensure our processes are check listed.

Why should software development evolve?
Enterprises needs solutions that fits in properly into their businesses. They require an extensible software packages that makes for quicker responsiveness in changes. They want to say hey "Lets GO" and we are all moving. But wait a minute, we are all moving ? should we all be moving? As part of movements, we shouldn't move too fast nor too slow, we should allow development to grow from an infant into a more mature development process. "Lets GO" though sound more like carry along, but in most contexts "Lets Go" is used by people who does not know how the software will be build (Imagine a plumber fixing your telephone), so i take the word "Lets Go" as being too reactive.

Software development should be allowed to evolve because its a culture driven activities that we must all conform to, there is no island of knowledge, developers should share knowledge. Strategies/standards/patterns are not paper works, sweet tongues, and big grammars. They are meant to be observed and not to be written down or praised. They are critical to business success and they should evolve as the software evolves.

To complement and supplement evolution of software development, developers should be allowed to use their creativity, software process should have a process too, that means the development strategies should always have its own parent strategies to checklist.

Can we be smart with SMART ?

The SEI (Software Engineering Institute) , developed a migration technique called SMART (Service Migration and Reuse Technique), this enable teams of professionals to actualize reuse SOA (Service Oriented Architecture) pattern properly and deliver what a client wants rather than polluting the entire solution with noise.

Migrating legacy systems are becoming problematic because, if proper planning is not observed, we might end up migrating problems we are trying to avoid.

The SMART initiative allows professionals to engage with customers/end users and document their needs, according to their needs, SMART can be strength ed to cater for it. It allows organizations to identify problem areas before software is reused. There are now several versions of SMART which addresses different problem areas. The following have been developed after the initial SMART Methodology :

1. SMART-MP (migration pilot)
2. SMART-SMF (service migration feasibility)
3. SMART-ENV (environment),
4. SMART-ESP (enterprise service portfolio)
   
5. SMART-SYS (system)

All of these are designed and tailored to needs of the customers. This is how flexible we should allow development strategies to evolve.

Reactive Software Developement ( A Lazy Man Engineering ).

What is Reactive Engineering?

Reactive engineering is a principle that most software organizations tend to follow when they fix and sell. Reactive is reacting to problems that could have been resolved if a proactive means is followed using the following : development trends, processes improvements (SPI) , common sense and having smart people take the lead. Reactive can make organizations believe they are closer to the deadline dates, while it makes them believe so, it become tragic when such reactively built software fails, and cost your company millions , or that reactive solutions is not precise enough and cost lives.

Reactive is not only a problem of software engineering, but a problem for the world, we are not fully prepared for worst cases. This article will only point at reactiveness towards software engineering.

When ever a problem occurs during the development or testing of a solution, reactive tends to fix the problem alone, this is more error prone, because what you think you just fixed may introduce another bug latter on.

For software developers, Continuous Integration can make your unit testing strategies proactive, when you make a simple changes, you will need to run all unit tests to see what breaks and what does not.

Development front has improved over the years. We have experienced the leap from assembly languages, procedural, object and object oriented languages. In this modern day of software engineering where domain principles are adopted to further solve development strategies pertaining to its domain area, software is adopted as part of a necessity for todays businesses to survive and for tomorrows businesses to emerge. This means, many businesses large and small all relies on software for their businesses to run smoothly. But what are we software developers/engineers/architects doing to ensure softwares are built in a proactive manner using agile domain engineering principles as opposed to reactive software development.

Scenario One

Ping Pong (Canonical Naming) softwares are aeronautical software development agency based in Asia, Ping Pong develops software that enable an aircraft control systems. Ping Pong in the early years does not have a clearly defined engineering principles that guide the production of its software (This is counter dangerous because Ping Pong are releasing softwares that does not follow regulations and principles) . This software company is endangering the lives of its users and passengers. Ping Pong, in the other hand are very reactive to software changes and bug resolution.

Although Ping Pong are very reactive, they have not met the standards of software engineering principles because they have refused to follow the ethics and professional obligations to the general public.

In real life there is no such company as Ping Pong, this is just an illustration and an example to show how we may be risking life, billions of monies because we bought a software that hasn't followed due diligence. We do not want reactive software engineering but domain engineering, which will keep you proactive and will make your software resilient to future changes.

Scenario Two

Know All software systems is based somewhere in Europe, know All softwares cannot see beyond itself, it does not recognize the fact that software development has evolves, and there are patterns that enable developers to do it right as opposed to do it any how.

Since Know All seems to know it all alone, they do not realize that tools have emerged and processes have changed and the world is moving forward and not backwards. This organization is the father of all reactive technologist, because they hire people that are good in fire fighting, and people who will hide most software problems under a simple fix called hacking (Again Hackers brothers i do not intend to cross the line). Software development is not an industry of patching, there should be no heroic patching, all stakeholders should follow the same patterns of domain engineering so that people speak the same domain vocabularies.


I will always follow a proactive development practice, it saves time and money and it help prevents the image of the software organizations.