Looking back at 2008

2008 was a good year. Once I got settled in, the last year at my current job has been very satisfying.

I lead the effort on three AJAX projects using the ExtJs Javascript library. Learnt a lot about code optimisation and performance in AJAX projects, object oriented JavaScript, JSON, stuff like the CTE in SQL Server 2005. The client's comment "..one of the fastest web applications I have used.." validated the hard work we put into the projects. I have begun to post my experience with AJAX in the A for Ajax posts in this blog. There are 3 posts on this subject already, more will follow.

There was another interesting project - a BI application where the data was being presented through web parts - where we got to investigate more asynchronous activities - like asynchronous loading of the web parts and asynchronous calls to the database. The technical demands of the project kept us on our toes, but the project was ultimately scuttled by bad client behaviour.

The last year has also been about earning the respect of my colleagues at my current job. I have always been blessed with very good colleague work throughout my career: they work hard, they take responsibilities willingly, they have a hunger for knowledge, are open to new ideas and ways of doing things, they create the magic in the end product.

A very interesting aspect was the diverse clientele I had to deal with - across Australia, Canada, Europe and the USA. All of them have been, and continue to be, very tough customers. And it was, and is, a pleasure working with all of them. I owe a lot to them: the tougher the customer, greater the satisfaction of winning them over with your work.

The end of 2008 and the beginning of this year has brought more learning opputunities - in XUL, XBL, JQuery, technically challenging ASP.NET projects - and another tough customer.

Looks like 2009 will be a good year too.

A for Ajax, Part 3: Accessibility

“The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.” Sir Tim Berners-Lee

In Part 1 and 2, I reasoned why and how an Ajax enabled web application performs better than an application built the traditional way. So should we Ajax enable all our web applications? The answer is no.

A serious issue with Ajax enabled web applications is that of accessibility by persons with disabilities.

Most of the discussion center on visually impaired users who have embraced “the power of the web” through assistive technologies such as screen magnifiers and screen readers. The problem arises from the inability of Ajax enabled web applications to effectively communicate to assistive technology, especially screen readers, that a part of the page has been updated, and allow users to easily investigate those changes.

These articles detail the problem:
AJAX Accessibility Overview
AJAX and Screen Readers - Content Access Issues

James Edwards, presenting his findings on how screen readers dealt with Ajax enabled web applications [http://www.sitepoint.com/article/ajax-screenreaders-work], remarks: “I’m forced to conclude that, unless a way can be found to notify screen readers of updated content, Ajax techniques cannot be considered accessible, and should not be used on a production site without a truly equivalent nonscript alternative being offered to users up-front.”

In 2006, Freedom Scientific, the developers of JAWS, a widely used screen reader indicated that version 7.1 of the software would be designed to work with Ajax based applications:
Developers Working to Overcome AJAX Accessibility Issues

This 2007 article indicates that, though some improvements have been made, the current level of support for Ajax in screen readers leaves a lot to be desired:
Improving Ajax applications for JAWS users

With Ajax pushing the boundaries of technology on the Web, and screen readers still stuck on outdated technology, it is very frustrating for the innovative developer.

However, there are other areas of accessibility where the developer can be more attentive to his users: think of people with learning/cognitive disabilities, for example, people who can’t use a mouse: did you provide them with an alternative to that cool drag and drop feature? Do you really require that drag and drop feature?

Some initiatives are underway: Charles L. Chen and T.V Raman has come up with a JavaScript framework - AxsJAX - for enhancing the accessibility of AJAX applications. “The AxsJAX framework helps inject accessibility features into these applications so that users of adaptive technologies such as screen readers and self-voicing browsers experience the same level of interactivity that is now taken for granted by users of Web 2.0 applications.”

The W3C has begun working on a standard that “defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.” This standard is currently a working draft. It will be a while before this is a recommendation, and developers and manufacturers of assistive technology understand and implement it.

Till then, if we have to develop a web application where accessibility is mandated, it is best to go the traditional route.

Further reading:
Accessibility Links
IBM Human Ability and Accessibility Center
Microsoft

Firefox extensions:
Fire Vox: a cross-platform self-voicing extension that includes early support for most of the leading edge features of W3C ARIA
Fangs: a screen reader emulator

A for Ajax, PART 2: Some data to substantiate claims made in Part 1

In Part 1 we discussed that an Ajax enabled application will perform better than a traditional web application. In this post we substantiate this claim with some data.

We compare a web application built the traditional way, in ASP.NET 3.0, with the same application built the AJAX way. Both application fetch data from the Northwind database using the same stored procedures. All the stored procedures have a wait period of 1 second to simulate delay.

We use Fiddler and Firebug to monitor the HTTP traffic, and the Web Application Stress Tool to load the sites with concurrent requests, and examine some of the data generated.

You can read the entire document here [http://docs.google.com/Doc?id=dcggqmtv_36c2tjrqg4].

The source code of the example applications, the Fiddler data used in this post, can be found here. The code is in C#, targets the .NET 3.5 Framework and developed using VS2008 SP1. The Northwind database is included in the download, you can either copy it to the App_Data folder of the applications, or attach them to SQL Server 2005. Rememeber to change to the appropriate connection string in the web.config.

A for Ajax, Part 1: Expectations from Ajax enabled web applications

Many of today’s web applications are Ajax enabled. What are our expectations from an Ajax enabled web application vis-à-vis traditional web applications?

Traditional page-based web applications process every request entirely on the server and sends across a HTML response that is rendered on the browser of the client machine. The HTML will contain the content [the HTML markup] and data. Refer Figure 1.














Figure 1: The traditional request-response web application architecture [please click the image for a larger view]

This request-response strategy is characterized by:
• high end server hardware.
• a browser on the client machine acting as a dumb terminal.
• complicated state management.
• the user waiting for a response after every request because of the synchronous nature of the request-response operation.

Considering that client machines are quite powerful nowadays, it makes sense to move part of the processing from the server to the client. This is the strategy followed in Ajax enabled web applications. The immediate gain is that this frees server resources, allowing the same server hardware to service more client requests concurrently. Ajax enabled web applications scale better than the traditional applications.

In an Ajax enabled web application, the only time the server processes a request entirely on the server is when the page is loaded the first time. This is the only time that the server serves content and maybe some data. For subsequent requests it serves only raw data, encoded in a given format. The client receives data feeds and updates only the parts of the Web page that have changed using JavaScript. In Ajax enabled web applications, UI updates take effect without postback. Refer Figure 2.















Figure 2: The Ajax enabled web application architecture [please click the image for a larger view]

Since only raw data is served, the size of the data is much smaller than what would be served by a traditional web application. This speeds up individual request and response, resulting in reduced network traffic and bandwidth requirements. Ajax enabled web applications are faster than the traditional applications.

By default the request-response strategy of an Ajax enabled web application is asynchronous in nature. This means that the user can continue to use the application while the client requests information from the server in the background and updates the UI [think Google Map]. Ajax enabled web applications are more responsive than the traditional applications.

In Ajax enabled web applications UI processing happens at the client. This makes it possible to achieve rich functionalities such as drag and drop, auto-completion, smooth animation, client side calculation, validation, etc. JavaScript libraries, such as ExtJS, bring in more sophistication to the UI. Ajax enabled web applications result in a rich user experience.

In summary, Ajax enabled web applications [with respect to traditional web applications] can be expected to:
1. scale better
2. have better overall performance
3. result in a richer user experience

Copy database diagrams in SQL Server 2005/2008/2012

To copy database diagrams from database dbA to database dbB, run the following in the Query Analyser:

INSERT INTO dbB.dbo.sysdiagrams
SELECT[name],[principal_id],[version],[definition]
FROM dbA.dbo.sysdiagrams

--SELECT * FROM dbB.dbo.sysdiagrams

[Thanks to Pankaj Saha, a colleague at work, for this code snippet.]

Edit: This also works for SQL Server 2008.

Edit: This also works for SQL Server 2012, Service Pack 4.

Edit: Some other links that could be useful:
http://stackoverflow.com/questions/3310137/sql-server-2005-how-to-copy-a-database-diagram-to-another-server
If you get an error "Cannot insert the value null into column "diagram_id"", check this out: http://social.msdn.microsoft.com/Forums/en-US/sqldocumentation/thread/767de035-5509-4150-af21-8b6752653f05

Hierarchical Data

A lot of real life data is hierarchical. Some are naturally hierarchical, like a family; others are classifications, like the folders in windows explorer. Either way, this data can be quite complex. Hierarchical data is best represented as a tree because of its ability to present the complexity in an easy to understand manner.

In data driven software, hierarchical data is often stored in a database, and presented in a tree control. Most tree controls will accept XML as data. You can retrieve hierarchical data from most databases in XML format. However the shape of this XML is hardly ever compatible with that required by the tree control, requiring transformation of the data XML to a shape acceptable by the tree control. One approach is to use XSLT to effect this transformation.

This requires the developer to develop an XSLT file. However, many developers find it hard to develop in a declarative language such as XSLT.

In this article, we discuss how to:
1. retrieve hierarchical data from the SQL Server 2005 database as XML data, using Common Table Expressions or CTE.
2. develop an XSLT to transform this XML into a shape acceptable to the tree controls. We will develop XLSTs for the ASP.NET 3.5 tree control and a custom tree based on the article Advanced UI Design Using XML and XSL. The code download also has an example of an ExtJs tree.

Download the article and the code here. [Click on the file name and click the Save As button.]

Or, download the article [http://www.mediafire.com/?jmhcjz9bygm].
Download the code [http://www.mediafire.com/?xmm2xjzmxjv].

The Singleton and the .NET framework

Taking advantage of the .NET framework, a singleton can be implemented as
follows:

// .NET Singleton
sealed class Singleton
{
private Singleton() {}
public static readonly Singleton Instance = new Singleton();
}

Read the article at http://msdn.microsoft.com/en-us/library/ms954629.aspx