Key to successful Software Development

One fine day when I was quite bored with my regular work, I went across to my colleague - Niraj Khatmode’s desk and was discussing about the paper that he was going to present in one of the conferences, later I was distracted by a book that he was reading on his PC before I got there. I asked what this book is all about and as he explained it fascinated me to read it. The book was "Extreme programming explained" authored by Kent Beck. As a programmer its title really impressed me.
I am a programmer since 7 years now and all these years I have been evolving as a software developer; in this evolution I have gone through some good, bad and worse phases of a software development life cycle. All these experiences have thought me certain elements about software development life cycle (SDLC). A chapter from the book “Four variables” talks about those elements.
The elements are very straight forward and are very much dependent on each other. Right dose of each of these elements will lead to successful and satisfied software development.

• Cost
• Time
• Quality
• Scope

When I retrospect and relate these elements with my past projects, I can imagine the reasons behind the good, bad and worse situation that have happened. Software development is a collaborative work between the customer, manager and the executing team and usually the customer and the manager are the forces that manipulate the above elements; however it’s difficult to control all the four elements together because if one increases or decreases the other element has an adverse effect, which means customers, managers get to control any three of the elements while the development team will have to deal with the resultant value of the fourth element. To prove this, let’s consider customer, manager try to control all the four elements by deciding that "you are going to get all these requirements done by the first of next month with exactly this team with a quality that is up to the usual standard”. When this happens, quality always goes down since nobody does good work under too much stress. Also likely to go out of control is time. At the end what you get is crappy software late.
The solution is to make these four elements visible to everyone (customer, manager, and team). This way all can decide and can consciously choose which three elements to control. If they don't like the result implied for the fourth element, they can always change the combination of these elements.
There is not a simple relationship between the four elements. For example, you can't just get software faster by spending more money. As the saying goes, "Nine women cannot make a baby in one month." and on the contrary, eighteen women still can't make a baby in one month.
In many ways, cost is the most constrained variable. You can't just spend your way to quality, or scope, or short release cycles. In fact, at the beginning of a project, you can't spend much at all. The investment has to start small and grow over time. After a while, you can productively spend more and more money. The time element is often out of the hands of the project manager and in the hands of the customer. Quality is another strange element. Often, by insisting on better quality you can get projects done sooner, or you can get more done in a given amount of time. There is a human effect from quality. Everybody wants to do a good job, and they work much better if they feel they are doing good work.
Now I have started believing that the one element that drives the control over cost, time and quality is the scope. As a software developer, I should give more importance to the scope element because If I change/eliminate/manage the scope the managers and customers will get better control over cost, quality and time. It has been fairly observed that developers complain about the requirement not been clear and there is a discrepancy between what we gave them and what they actually wanted, this is an absolute truth of software development. On the contrary as a software developer if you start thinking from the side of a customer you would agree that development of a piece of software, changes its own requirements, as when the customers see the first release they learn what they want in the second release or what they wanted in the first. It’s a learning curve and it’s a valuable learning because it couldn't have possibly taken place based on speculation. It is learning that can only come from experience. But customers can't get there alone. They need people, who can program, not as guides, but as companions
What if as a software developer I see the "softness" of requirements as an opportunity, not a problem?  Then I can choose to see scope as the easiest of the four elements to control because, I can shape it, a little this way, a little that way. If time gets tight toward a release date, there is always something that can be deferred to the next release.
All these controlling elements would make up-to great software and I believe all this can be possible through the agile way of development.

Portal Development Basics Part 1

Portal Development Basics Part 1

If you have been part of application development or even if you are application user for a quite long time now, then you must have sensed that heart of any application is “content”.  As things advanced we realized that “user experience” is important as well. The lack of a standard approach and technology to address user-experience requirements, such as personalization, customization, and content aggregation in web applications, led to ad hoc ways of implementing these features. The result was maintenance nightmares, lost developer productivity, and longer turnaround time for incorporating new features.

With evolving Java portlet technology it allows us to quickly develop a web application providing service orchestration. Java portlet technology it isn’t standalone technique to achieve development, it uses traditional JSPs and servlets to build application along with portlet. On top of that there is MVC frameworks like Spring MVC portlets allows you to develop individual portlets in the Spring technology. This blog shall aid you understand fundamental need of portal development and getting familiar with different aspects of it. Next blog will talk more technically about different standards of Java portlet technology JSR 168 (Java Portlet Specification V1.0), JSR 286 (Java Portlet Specification V2.0).

Portal Overview

A portal is a web based application that comprises of many small web applications called “portlets”. Primary goal of a portal system is to facilitate personalization, authentication, and content aggregation from different sources and hosts the presentation layer of information systems. Aggregation is the action of integrating content from different sources within a web page. A portal may have sophisticated personalization features to provide customized content to users.

To get a feel for portals, you can visit the iGoogle portal (http://www.google.com/ig).  In the iGoogle portal you can see portlets showing emails from Gmail, headlines from CNN, content from YouTube, and so on.

Portlets are not widgets

While looking at iGoogle example you might start wondering what makes portlet different than web widgets as we know today. A developer can quickly develop widgets having some knowledge of Javascript and XML, however Java portlet concepts require deep learning curve to understand its fundamentals. Portlets are well suited for medium to complex application requirements as found in enterprise applications.  

Why use portal?

Quick answer is when you want to develop service oriented architecture. As portlets represent services and are pluggable components, you can get plug and play behavior using portlets. Because portlets can interact with each other at the user interface layer (a process referred to as inter-portlet communication), they play a major role in developing SOA applications. The portlet container is responsible for handling the communication between portlets.

The portal infrastructure, which includes a portlet container and portal server, provides portlet instance lifecycle management, instance pooling, content caching, security, a consistent look and feel, and single sign-on features to your web portal.

Let’s take example of iGoogle portal we talked about. As a user you need to frequently check your emails, browse videos on YouTube, take glimpse of news from news articles and keep updated on technology trends. All of these web applications have their own business requirement and data sources which you will need to browse individually. If we have a single point of entry using a single sign-on feature to allow access to all of these applications then that would be better solution.

Let’s say that as an employee of an organization you need to frequently access organization-specific business-to-employee (B2E) applications (like time card, help desk, knowledge management, and service request applications) so you can keep track of missing time cards, recently published articles, closed help desk tickets, and so on. These different web applications have their own data sources, and you’d usually need to go to each of these different applications to access this information. Certainly this isn’t an optimal way of accessing information and services, because you need to go to different web applications and authenticate each time. An intranet site that provides a single sign-on feature and access to all these different applications would be a better solution.

By providing the single sign-on feature, if the service provider has provided easy access to the B2E applications, but you still need to filter the information that interests. Like if you interested to know more about Java technology trends only. You will have to search for Java articles in primary application. Individual application will have some level of user preference managed as personalization. But ideal scenario for user to have unified view of all services is in single application itself. This is achieved using portal development as seen in iGoogle today.

The portlets can be personalized by users to change the number of emails displayed in the portlet, the number of CNN headlines they want to view, the location they want to receive RSS feeds from, and so on. Users can drag and drop these portlet windows on the portal page to customize the way.

Where portal doesn’t work?

Portals aren’t the answer to every business requirement; organizations should consider carefully whether there is a business case for developing a portal. If the requirement doesn’t require gathering content from distinct information systems to loosely integrate disparate systems, the business should consider developing independent web applications to meet the business requirement. The personalization and customization features of portals are important from the user’s perspective. From the business’s perspective, the most important requirement to consider is content aggregation.

Reference

Portlet In Action

Kindle Fire opened an Open source model for mobile

With rise of open source software platforms everyone was convinced that the Open source model will never go down. But start of 2007 Apple announced about their new innovative mobile technology ‘iPhone’. Apple came with an appealing and winning model, most of them agreed. 
What it also brought is closed and proprietary model that wouldn’t leave a scope for mobile open source platform. They said mobile and open source together would not work. That this market was too closed. That the carriers would not allow any openness. 


It turned out to be false, because Google made Android open source and it became the fastest growing OS of all time, passing Apple at a speed nobody expected. Here comes the ray of hope for mobile to go open source again, but again not everyone was optimistic about Android that time.
Today we hear about Kindle Fire and I am confident that it is going to be the biggest competitor for Apple in mobile space. Well, I wouldn’t term ‘kill’ as it is not going to suddenly drop Apple market but it will live with it for a while. Good question to ask is – how did Amazon managed to challenge Apple in a jiffy?


Open Source.


Think about it. Amazon took an open source mobile operating system (Android), forked it, changed the UI a little and added a few apps. With that, it is going to build the most successful tablet of our times.


Amazon couldn’t stand a chance without open source. It gave them speed and time-to-market. It gave them a stable and high-quality platform. The ability to compete and innovate. And maybe the biggest advantage of all: an enormous development community. All things we always said open source would bring to the table, making a huge difference.


The Kindle Fire is yet-another demonstration of the power of open source. The innovation is not going to stop here. Expect even greater things in the future. With the market moving towards HTML5 and the open web, we'll be talking about the dominance of open source and openness again and again. 


And yes, open source in mobile is doing way better than in the PC world. And yes, it is clearly showing to be the winning model. 

What is Open Source?

Open Source Software (OSS) is a computer software which is developed and distributed openly. The development can be undertaken by individuals, groups or communities, organizations,companies,educational institutions and all sorts of other combinations of developers.

The basic principles of Open Source Software are controlled by a number of different license types:

GPL - gnu General Public License - which, in very brief summary, says that the source code of the software must be made available, can be changed by anyone, provided that all copyright notices are left intact and that any on-provision of those modifications is covered by the same license;

BSD - Berkeley Software Distribution License - which, in brief summary, is very similar to the GPL license except that you do not need to on-provide the source code.

MPL - Mozilla Public License - which, in again brief summary, is similar to GPL but it allows redistribution of executable under separate license - so if you make a modification or a special version of a system you are able to distribute that in executable form only - but the devil is very much in the detail here big grin


There are many many more license types within the Open Source world.

But, Open Source Software does not automatically imply "Free".  Many valid and excellent Open Source projects ask an initial purchase price for their software - but, depending upon the license they are operating under, they may distribute that software with the Source Code so that you can then add to, enhance, or modify the software to suit your requirements - as long as you stick to the terms established in the original license.

Ultimately, all of this has a revolutionary effect on the software and the availability of software components for developing your own programs.

Total Cost of Ownership (TCO) and migration costs are lower, licensing costs and tracking are eliminated, your software is more likely to be secure, stable, future-proof - its better no matter the angle!

Navigation timing API

Introduction

This specification defines an interface for web applications to access timing information related to navigation and elements.

The API will allow web application to gather performance metrics about various factors such as page redirect, DNS lookup, connection & secure connection statistics, request/response time, various events, etc. that were not possible with API script before.

Following is the graphical representations of a typical HTTP request response cycle for a web page.

Use case

Performance measurement has always been a bottleneck for web applications. The traditional way to calculate page load time is to write JavaScript to measure page load time. But in majority of cases they are unable to provide exact figures for user latency as in case of below script. It calculates the time it takes to load the page after the first bit of JavaScript in the head is executed, but it does not give any information about the time it takes to get the page from the server.

var start = new Date().getTime();

function onLoad() {

  var now = new Date().getTime();

  var latency = now - start;

  alert("page loading time: " + latency);

}

Examples

The previous example can be modified to measure a user's perceived page load time.

function onLoad() {

  var now = new Date().getTime();

  var page_load_time = now - performance.timing.navigationStart;

  alert("User-perceived page loading time: " + page_load_time);

}

Good question to ask is that the ‘Date’ object will rely on system date time set on user machine which can be easily tampered between the performance measurements. To resolve this, browsers will record monotonic time by recording system date time while starting performance calculation.

All new knockout JS will certainly knock you out!

Recently while I was going through my linked in news feeds I happen to come across a post from one of my friend which briefly mentioned knockout JS, my curiosity took me to its website.

Watching the 20 minute video from the founder; completely knocked me out. I must say I fell in love with this amazing JS library. 

Here are few interesting features that knockout JS provides, you would read the same on its website

1.  Declarative Binding
2.  Automatic UI refresh
3.  Dependency tracking
4.  Templating

With these features in place; and a strong MVVM design patter knockout JS stands out from other JS libraries.  

Apart from this, Knockout JS also has an excellent community support, which generally lacks with most of the libraries that hosted publicly.

Where do I go from here?

For more details, examples, source, and downloads, see the project’s homepage at http://knockoutjs.com

The Messaging API

Introduction

This specification defines an API that provides access to messaging functionality in the device, including SMS, MMS and email. It includes APIs to create and send messages. These APIs complement what sms:, mms:, and mailto: URI schemes provide with:

• the possibility to attach files to messages,
• A callback on success / error when a message is sent.

Use case

To describe use case, first I would say many browser today already support messaging by supporting frequently used ‘mailto’, and not so frequently used ‘sms’ URIs. While the API certainly addresses a different use case (access from scripting code), it would be very useful to describe how the URI-initiated messaging is different or equivalent to the API-initiated messaging. For example, should browsers make sure that the user experience is always consistent across these two methods of messaging? Or is it acceptable if URI-based messaging uses an external user agent whereas API-based messaging uses a browser's internal capabilities?

At the very least, it would be useful to point out that URI-based messaging exists, and that page authors have the option of using URIs instead of having to write scripting code. in terms of accessibility and platform robustness, it will be quite a while until page authors could rely on the API alone; at least as a fallback solution, messaging URIs probably always are a good idea.

Since not all devices will have all messaging functionality (e.g. a phone may have only SMS and MMS while a PC may have only e-mail) there is a need to indicate that implementations need only expose available functionality.

Examples

The following code extracts illustrate how to create and send messages. Sending an MMS with an attached picture, if device supports it.

function successCB() {

   alert("The Message has been sent successfully");

}

function errorCB(error) {

   alert("The Message could not be sent " + error.code);

}

if (navigator.device.sendMessage) {

   picture = document.getElementById('attachment').files[0];

   navigator.device.sendMessage("mms:+460000000001?body=Welcome%20%to%Atlantis", [picture], successCB, errorCB);