The Never Ending Ooze

Friday, September 13, 2013

Learning ASP.NET WebAPI

Wednesday, September 20, 2006

Model Driven Architecture..Huh! What is that?

As you all would have noticed, lately I have been pondering a lot about architecture, design and the way software development can be made easier for the software community. Well, this led to me Model Driven Architecture. Now, you would wonder-what is different about Model Driven Architecture? After all, all software starts with design where you develop a sort of model of the end software.

First let me try to explain a problem which we software developers face almost everyday-CHANGING TECHNOLOGY. First there was VB, then came VB.NET, first there was remoting, then came web services. Each time a new technology comes into the market, lot of rework needs to be done. Add to this the plethora of rapidly changing requirements and the ability that your software needs to interact with other systems and you get a fairly complex scenario which haunts you everyday. I on a personal basis hate the client asking me to change the application so that his application can run on Oracle database as well.

Allow me to explain a little more, Model Driven Architecture is a new way of writing just what you thought-“Specifications”. Here, no technology is taken into consideration. So, what do you exactly write? You develop a platform independent base UML model aptly called Platform Independent Models (PIMs). You are not supposed to concentrate on the language to be used or the database on which the software will run or the number of frigging threads the application will spawn. You concentrate only on the functionality and the end behavior of the application. There is no relation what so ever with the implementation details.

So, what is the benefit of this sort of architecture?

With today’s fast changing technology environment, lots of new platforms and infrastructure are coming into the market. Now what happens to your existing applications? If your applications have been written solely targeted towards a particular platform or infrastructure, then they become redundant-right? So, that means you lose all your investment that you have been putting into technology hoping for a better tomorrow. Now, that’s a really scary situation. This is where Model Driven Architecture steps into the picture.

MDA is already being projected as the next big step to be taken by the software industry. At the heart of the MDA development is UML, which involves developing models in order to develop your application. So, during the analysis of the requirements, UML is used to develop a model in a standard way which acts like a blueprint for your application. But you would be wondering how can just developing a model, lead to the development of the entire application. So, here in order for the application to be targeted towards a particular platform or infrastructure, the Platform Independent Model needs to be converted into a Platform Specific Model (PSM). So, if you wish to put it into simple words, a PIM sits at the center of the application and then a PSM is written around the PIM. The PSM can be written in any technical language-be it CORBA, or .NET or JAVA. The business functionality and the behavior of an application are etched into the PIM and the UI and the UI components are written in any available language.

It is then the responsibility of the platform specialists to convert the model into one targeted towards a specific platform like CCM, EJB or MTS. Standardized tools are used in order to do this conversion from PIM to PSM. This is one area where a lot of scope is still there for research and development due to the fact that although the tools being used today use standard mappings to do the conversion, there is still a lot of human intervention involved. So, this is a sort of developing art which needs some hand-holding even today.

The next step is the actual generation of the code. Finally, the software developers would have heaved a sigh of relief here-after all what will they do if everything is done by the model. The actual code generation will involve generating a lot of configuration files, interface files and so on. If the models generated using UML are complete or encompass the entire functionality of the application, there will be lesser work to do during the PSM conversion phase and the better the application nitty-gritty’s and runtime behavior have been handled in the PSM, the lesser code will have to generated.

This type of architecture is still in its infancy stage right now and if you expect that you can generate all your code using models TODAY, then you are probably mistaken. MDA offers just another layer of reusability below the development tools which we all are already using these days. This art of architecture still has to grow a lot before we start searching for expert UML modelers rather than expert C# developers.

Wednesday, September 06, 2006

Domain Driven Design

Well, a couple of google searches later, I have come to know that there is infact a community of developers who are working on providing domain specific designs and they have coined a name to it-Domain Driven Design (DDD)-COOL!

DDD works on the assumption that all software that is developed is BASED on a proper understanding of the domain-its intricacies, its complexities. So, rather than spending hours trying to solve the technical complexities, a developer should be spending more time with the analyst or domain expert trying to understand the complexities involved in the domain on which the software or code piece is to be written. DEVELOPERS AND ANALYSTS WORKING TOGETHER??? Since when did this become possible? After all, they are supposed to be entirely different backgrounds. A developer might be someone who has done his B.S/B.Tech., whereas the analyst might be some arts graduate who has done his MBA from some B School and has some expertise on the domain say finance. How can these two different types of creatures survive together?

But howsoever impossible it might sound, the domain and technology experts need to sit together and pool in their knowledge of the domain so that it can form the basis of the software. Together, their knowledge can be invaluable (obviously only when the mostly egoistical programmer learns to share his/her knowledge ;-) ) This is not so impossible, since I have to come to know that in a large account of Tavant Technologies the developers are in fact working with the analysts in order to understand the financial domain more-thanks to Nitish for this information.

Design Patterns based on Domains

Recently we have been discussing around domains-which problems we had faced while working on what domain, how we had solved it, which domain offers more job opportunities and stuff like that. This made us come up with the premise that probably there should be design patterns targetted towards specific domains. Since design patterns offer solutions to complex problems which have been faced by developers across technologies across the world, maybe there should be a forum where similar design patterns are discussed for problems faced while developing an application for a particular domain. Dont you think this would offer more lucid designs and help architects and developers to think alike. Rather than focussing on some technical issue, they can rather concentrate on providing a better solution itself to the user. Need to do some research on this.

Friday, September 01, 2006


Recently I was going through Peter Bromberg's blog and happened to go through his archives. I saw the article This Just In: AJAX doesnt Have to be -- AJAX, which was sort of his views (against) about the AJAX hype. Google certainly seems to have upped the hype on this very OLD technology by incorporating it in almost all of its products. As the term Google is growing in the market, so is the term AJAX. Every web developer wants to use XMLHTTP web requests in order to seamlessly integrate page post backs and add his/her own touch of Googleism to his/her website (even I have tried that and my current application is completely done using XMLHTTP web requests)

Setting up test environment.....What is involved?


We have completed the development phase and need to deploy the app to
the test environment. Needed to know what all things are involved in
setting up the test environment.
the application consists of Serviced Components and ASP.NET 2.0
pages/code and SQL 2005 database.

I think i would need the following:

Need to install the Serviced components on the test server
Copy over the ASP.NET pages and the precompiled Code behind.
However I should use the existing database server setup in the test
environment. I think it is a bad idea to backup the DEV database and
restore it to the TEST database, since it would already contain the
data that is supposed to get populated after you run the application
and play around with it right???


An insight into deploying a .NET web application:

I think using something like NAnt and CruiseControl would be a much

better option. You can also create a deployment project for your web
app using VS.NET

If you prefer to use the manual way, you just need to simulate your
development enviroment on the test machine-folders and stuff.

Copy over your web app dll to the bin folder and make sure you copy all
the aspx pages. You dont need the code behind.

Regarding the database, create scripts for all your tables, sps,
triggers etc and run the script on the test/staging machine. This
should also populate the tables which are necessary to 'start' the
application such as user roles etc. Other than this, the transactional
data should not be populated using these scripts. The data should be
populated next.

I would suggest not to use your development data on the staging
machine. Create scripts to insert values into the newly created tables
and then populate the data. Make sure someone who knows the
functionality of the application and has an overview of the database
design, but doesnt know the code does this, as then the testing will
bring out some bugs which developers tend to hide using 'manipulated

Thursday, August 31, 2006

Testing.....WHO? ME?

Testing.....WHO? ME?

Being into the IT industry for the past 4 years now has given me a fair idea of testing and the advantages it brings with it. But one thing that I have never done is thinking about what would be the best way to design a test case document, is there any formal definition of a test case, what all should a test case not have and so on.

Recently when I was given this responsibility of managing a project, i really thought of giving it a thought. We were supposed to implement ISO 9001:2000 in our project and this meant documenting each and everything, and test cases form an integral part of the software development life cycle. So, let me rephrase the statement as "I was FORCED to give it a thought".

A test case is an entity which fully tests all the related aspects of a requirement in an application-be it functionality, be it UI, be it database. In other words, it tests ALL the aspects of a feature or requirement. It includes:

  • The reason why the test is being done.
  • The process that would be followed for doing the test.
  • The scenarios that would arise out of performing a particular test.
  • The criteria which would decide when a test has failed.
  • The criteria which would decide when a test has succeeded.
  • Any specific software and hardware requirements for the test.
  • The assumptions that have been done in order to write the test cases.

This is too much of work to do-right? So, then who knows about the project so much that he can write the test case document? The project manager? Does he have all the time to write these test cases? I dont think so...I can feel this now that I am doing project management. In most of the cases, it is mostly a Quality Analyst/Engineer or a team of QAs who sit down along with the Project Manager/Leader, understand the functionality of the entire task and then accordingly write the test cases. Once the test cases have been put down by the QA team, the document has to be reviewed by the peers.

Figure 1.0 lists a sample detailed test case document which the QA of my team Vidya Nair wrote for one on the various modules of the existing application I am working on.

Once the test cases have been reviewed by the peers, it should function as a tool to help the developers in their development. This is one reason why I believe a QA team has a BIG role in delivering the product bug-free and with the best quaity on time. One of the issues, which stops a QA engineer from coming up with a good test case is the plethora of information available to him/her. The key here, I guess is to "work smart"-Pick out the most important scenarios and frame your test cases accordingly-think about the scenarios which are critical for the application to function and work on them first. Then, if you have sufficient time, you can work on more test cases having a lower priority.

Thursday, August 10, 2006

Some basic rules of development

Some Basic Rules of Development

1) A development team should have a single design authority. The best systems have one member of a team who dominates the design and development and has a clear view of where the system is going. Without this strong focus and lead, many projects throw together a set of conflicting ideas and the system will ultimately stagnate or become extremely difficult to maintain. This person needs to be big on communication and small on ego.

2) Code should be documented, but not overdocumented. Lots of documentation does not equal good design and will not guarantee a good, well designed system. A system can have a good design even with minimal documentation. Especially, keep in mind that the initial set of documentation is for the DEVELOPERS THEMSELVES.

3) Good people build good systems, bad people build bad systems. No amount of processes or documentation will change that, it will only make a relatively small increment in system quality. The overwhelming factor in developing a quality solution is to hire good people. NASA statistics have shown productivity differences of 1000% between their best and worst people.

4) Design for change and flexibility. Things will always change, do not tie your system to rigid principles or business processes that change frequently. Break your system up into its OOP oriented objects and define them as early as possible in the development cycle. Make sure everybody on the team understands what the objects are and what their purpose is, and how they will interact with each other.

5) Don't build a foundation on a sand dune. The first few steps in the project are usually the most critical: the choice of tool, platform, architecture etc. If the wrong choices are made, it can result in a lot of rework and will destroy the motivation of most development teams. If you find early in your process that a decision may have been wrong, be smart enough to change it instead of attempting to "Band-Aid" it into functionality.

6) Keep it simple, don't build in complexity that doesn't need to be there. Don't spend time making the system portable if it doesn't need to be. If you're using SQL 2005 and are going to stick with it, use all the SQL 2005 specific features you like. "Explicit code is easier to understand, which makes the code easier to modify" -- Martin Fowler

7) Use accepted and well-known technology. Niche tools/technologies are expensive, lack support and it can be difficult finding people with the right skills, particularly a couple of years later.

8) Deliver often. A project taking more than 6 months before delivering software will likely fail and the reasons for it being built may not even apply anymore. Delivering often provides good targets for developers and good visibility for the system in question. If you have 3 Alphas and 6 Betas over a short period of time, that's better than no Alphas and one Beta. User feedback is extremely important in being able to be flexible enough to make mid-course corrections.

9) Don't add extra people to a team to try and speed up development. Increasing the size of a team mid project will almost certainly slow development down. A team of 4 to 6 developers is enough for most projects. Large projects should be broken down into small development teams of this size.

10) Use of industry-accepted development methods: object-oriented design and modelling, well-structured development process, unit testing, sound documentation, use of version control tools, project management tools.

11) Communicate often within the team. You don't need four different people each creating their own Data Accesss helper class when if they had all sat down and discussed it first, everybody could all be using the same one, with better features.

12) Above all, do be nice to your development team. Developer turnover in the middle of a project can really send expenses through the roof, and morale down the toilet.
~Peter Bromberg

Friday, June 30, 2006


If some one has ever used Google Suggest, then they have seen AJAX (Asynchronous Javascript and XML) in action. I have been using Google Suggest for quite some time now and never bothered to ponder over how this thing works. I had been discussing this with my colleague Sanjeeva for quite some time but really came to know more about the technology when an issue came up in my current project.(happens with me all the time-when I use it, I get to know more. :-) )

Google has been vigorously using AJAX lately-take Google Maps or Google Suggest-both are based on the fundamentals on AJAX and work beautifully. I really appreciated the idea of the search engine telling me what to search ;-) And what more-these applications are doing beautifully-check out these analysis of the same- Gmail, Google Suggest and Google Maps.

The issue is as follows -- We have a web application which displays beautiful reports to the user apart from having some other nitty-grities. Apart from the graph being displayed on the page, there is a plethora of information being shown to the user. Then the customer asked us to add a filter to the chart so that the user can get a new chart based on the filter chosen. Doing a postback would have been good and beauifully traditional, BUT then the entire page would be loaded again and this would make the user mad waiting for the entire information to be loaded up again. Just to make myself clear, when I say 'traditional' approach, I mean that any user action, say a button click) in the web page would lead to a postback (if configured that way, of course). So effectively it means a HTTP request would be sent to the server. On receiving the request, the server would take appropriate action and return a rendered HTML page back to the waiting browser. But the question that is obvious out here is-what if the page is very heavy? Wont the page take a lot of time to load again when all the user required was something refresh the chart when he/she changes some display criteria? How many times have you banged your head on the table, when you select 'India' in your drop down and the page is posted back to fetch all the states that are a part if the Indian Republic? Why dont the application developers just send the states back to the browser when the country is selected? Why do they have to load the entire page again? Quite obvious questions and these are what came to my mind...

Here is where we thought of taking help of AJAX.

An AJAX implemented web page removes all this HTTP request-response pain by adding a sort of layer in between. AJAX allows the user to use JavaScript to send XMLHTTPWebRequest to the server by making HTTP requests (GET/POST) without reloading the page. Basically, it is just old wine in a new bottle since technologies like XMLHTTPRequest etc were already there in the market for quite some time when Mcrosoft introduced it in IE 5.0 and Apple in Safari 1.2 and Mozilla in Firefox 1.0 onwards. The server handles the request and sends a response which MAY NOT be XML-it can be something as simple as comma separate list or simple string.

A couple of Google searches later I was ready with a fully functional AJAX implemented web page.

This is the javascript that was added to the aspx page --

var xmlHttp;
var requestURL = 'some aspx page made to handle the ajax request';
var is_ie = (navigator.userAgent.indexOf('MSIE') >= 0) ? 1 : 0;
var is_ie5 = (navigator.appVersion.indexOf("MSIE 5.5")!=-1) ? 1 : 0;
var is_opera = ((navigator.userAgent.indexOf("Opera6")!=-1)(navigator.userAgent.indexOf("Opera/6")!=-1)) ? 1 : 0;
//netscape, safari, mozilla behave the same???
var is_netscape = (navigator.userAgent.indexOf('Netscape') >= 0) ? 1 : 0;

function show_data(strName)
//Append the query strings to search for to the requestURL

var url = requestURL + '?q=' + strName + '&ajax=1&dummy=' + new Date().getTime();

//Create the xmlHttp object to use in the request
//stateChangeHandler will fire when the state has changed, i.e. data is received back
// This is non-blocking (asynchronous)

xmlHttp = GetXmlHttpObject(stateChangeHandler);

//Send the xmlHttp get to the specified url
xmlHttp_Get(xmlHttp, url);

//stateChangeHandler will fire when the state has changed, i.e. data is received back

// This is non-blocking (asynchronous)

function stateChangeHandler()
//readyState of 4 or 'complete' represents that data has been returned

if (xmlHttp.readyState == 4 xmlHttp.readyState == 'complete')
//Gather the results from the callback
var str = xmlHttp.responseText;
var temp = new Array();
temp = str.split(',');
//Populate the innerHTML of the div with the results

document.getElementById('SOMEHTMLIMAGECONTROL').src = temp[0];

// XMLHttp send GET request

function xmlHttp_Get(xmlhttp, url)
{'GET', url, true);

function GetXmlHttpObject(handler)
var objXmlHttp = null;
//Holds the local xmlHTTP object instance
//Depending on the browser, try to create the xmlHttp object

if (is_ie)
//The object to create depends on version of IE
//If it isn't ie5, then default to the Msxml2.XMLHTTP object

var strObjName = (is_ie5) ? 'Microsoft.XMLHTTP' : 'Msxml2.XMLHTTP';

//Attempt to create the object

objXmlHttp = new ActiveXObject(strObjName);
objXmlHttp.onreadystatechange = handler;
//Object creation errored
alert('IE detected, but object could not be created. Verify that active scripting and activeX controls are enabled');
else if (is_opera)
{ //Opera has some issues with xmlHttp object functionality

alert('Opera detected. The page may not behave as expected.');
return; }
else { // Mozilla Netscape Safari
objXmlHttp = new XMLHttpRequest();
objXmlHttp.onload = handler;
objXmlHttp.onerror = handler;
} //Return the instantiated object
return objXmlHttp; }

The function show_data is called on some event say the change of drop down or click of a button.

The changes that were done in the code behind are --

string ajax = "";
ajax = Request.QueryString["ajax"];
if(ajax != null)
Response.Write(imageURL + "," + imageBarURL);
//imageBarURL is the path to the image which will be displayed on the webpage.

You would notice a small thing in the javascript above-"&dummy=' + new Date().getTime();" This was done so that the caching effect of the browser can be done away with. I know it is a hack-but it works.

A better way would be to expire the cache on the parent web page or user control as follows --
//Avoid the caching effect in Internet Explorer
Response.Buffer = true;
Response.ExpiresAbsolute = DateTime.Now.Subtract(new TimeSpan(360, 0, 0, 0)); Response.Expires = -1;
Response.Cache.AppendCacheExtension("max-age=0, no-store, must-revalidate"); Response.AddHeader("Pragma", "no-cache");

The above works on IE 5.0 and above, Mozilla Firefox, Safari, Netscape 7.0 and above.