Using Re-Use...

As discussed in last post re-using existing code/components is one of the key thing for better development. Every organization will have repository of reusable components but how do we ensure their re usability? From my recent observations things that can be reused are

1. Common functionality exposed as services
2. Validation and other similar utilities
3. Edit rules and other UI logic

One stage where we can identify reuse is during design phase. You can easily identify the reusable services/components at this stage, But you can identify reusable validation utilities and other reuse opportunities only if you undertake detailed/low level design. But how many times we perform low level design? In these cases onus of identifying the reuse lies with developers and development leads. But bigger challenge here how will these guys know that there is some thing that can be easily reused? As a simple example a developer who is required to do date validations will know that there is a Date validation utils already written by some one else? In general hectic schedules it is very much possible that we oversee reuse opportunities and end up coding again (reinvent wheel).

The thumb rule that I like to propose for developers is... while coding if you happen to code any thing that is not very close to Business of the application, then there is an opportunity for reuse. For example if you are coding a rule like - calculations based on some combinations of values selected on UI and some algorithm specific to application then there wont be much reuse opportunity. But if you are coding some Date validations, UI edit rules using Javascript (like restricting text field to accept only numbers) there is chance for reusing some thing existing. If you observe these are independent and had no close relationship with any business logic. In these kind of cases, you can search your organization's repository to find out suitable utilities.

I will continue discussing this topic with specific examples in further posts.

Recently I read some overview of Language called Scala which promises excellent support for component development. And it says Software development will become similar to assembling hardware. Means you will just need to put together some components and get the final product. This is an interesting thought and planning to spend some time on this.

A Good Developer

What it makes to be a good developer? This question keeps popping now and then in my mind especially when I hear complaints from managers and leads saying their developers are not good enough. In Sun Tech Days couple of years back, there was a session according to which below are the 7 best habits of a good developer.

1. Understanding the Problem
2. Use appropriate tool
3. Strive for Simplicity
4. Keep your code clean
5. Learn to debug
6. Leverage whatever available
7. Plan ahead

Lets discuss these in the context of general projects in Indian service industry

1. Understand requirements. This doesn't mean developer must have domain knowledge and understand business requirements but at least they must understand what should be done on click of Submit, click on Cancel, what formatting and validations need be done etc

2. Tools should have been decided before development start so lets not dwell much on this

3. 'Think Simple' - I keep telling my developers. Your performance is not measured based on number of lines you code or how complex your logic is.

4. Learn to code lean and clean code. This is possible only when following coding standards becomes a practice rather than compulsion. Also developer should emphasize on learning programming than programming language. I don't mean we don't have to learn any language but if you don't know how to solve a problem and write a basic algorithm there is no use of becoming an expert in Syntax of any language. Again you don't have to solve complex issues. Take for example age validations, if you don't know how to calculate age is there any use even if you know whole Date API in Java? Also emphasis more and more going in getting things done than on how? If developer gets a function point implemented that's enough, we rarely see leads reviewing for algorithm or developers caring to analyze their logic. No one to blame because of time lines but if you want to become a good developer your logic and its performance does matter a lot. Remember the Algorithmic subject thought in college and the order of executions?

5. Debug the code - No one writes a perfect code in one shot. With the latest IDEs and plug-ins debugging is easy than coding.

6. Leverage whatever available - Most of the things we do these days we are not the first ones doing them (Unless you are lucky like me). Refer organization's reusable repository, colleagues experience or online community to get the code. God had given us Google and a brain to use it.
7. No need to stress about time lines... Think and plan ahead. One of my professor used to emphasize to have complete algorithm written on paper and analyzed before even writing single line of code. Plan should include similar thing.. plan what to be coded and how to so that you wont end up with rework or stuck in middle.

To summarize, to become a good developer first thing to learn is problem solving (say analytical skills or whatever). Learn from all possible sources (read open source code, online material etc).

As Brian Kernighan and Dennis Ritchie say.. "only way to learn programming language by programing in it".

Any training can teach you API but not thinking.....

HTTP Session Managemet - Restricting approach

HTTP Session management - a frequent discussion point in many projects and frequent reason for performance issues in the projects. Recently I happened to review a project which takes nearly 5 mins to load a page that contains a table data. And after visiting this page application becoming slow. Reason is, application retrieves all data in one call and stores it in session scope and is not removed after traversing out of the page.Time and again managers feel need for design that controls session usage. Recently I initiated a discussion on IASA forum to gather ideas from community. I always felt HTTP session proper usage should be more of guidelines than framework. But if session timeout is more than usual 20mins, we might have to go for policing policy. Based on responses in the forum and my experience I think of below solution.

1. Applications cant totally avoid session but should limit the usage. So while design identify the objects required to be maintained in HTTP session. Create a Class which will act as place holder for all data to be kept in session. This will be POJO with the objects that require to be kept in session as fields. So only objects that have setter method on this object can be set to session.


2. Add a Session Listener. This will be a class implementing HTTPSessionListener. This need to be configured in web.xml. There are three methods in this interface. One of the will get executed whenever an attribute is added. This method in listener implementation should remove the added attribute excepting the predefined ones. (Apart from the object of above class, application container will keep some objects in session. Listener should discount them too. This will restrict the HTTP Session usage)


3. Container object created in step1 can have a public method to calculate the size of itself (which means size of objects in session). Application can use this method for auditing like displaying http session data from application on a special page etc.


4. Above solves one part of the problem, application still need to take care of clearing the data (by assigning null to the field). This can be taken care by application code. If need to be part of framework you can provide a configuration file which defines permitted data for each action/module. Define a some Intercepting filter that will examine the Container object and remove the unwanted data.

Its easy to implement and maintain. As every one agree its good design and implementation adhering to design that will result in good application

Achievements

So far my posts are on professional side and today I thought of giving some personal touch starting with some achievements of mine. So far I achieved little... As every one I like to brag (rather blog) about myself. Here are list of few of my achievements

• Getting into HCU (Hyderabad Central University/University Of Hyderabad). Got 14 in All India test. More than achievement this is a good break for me - March 1998.


• 
  
  First prize in Non-technical event during an all India meet in Pondichery University - March 2001.


• 
  
  Kudos from CDAC boss on contributions to AKSHARA (Word Processor for Indian Languages) project - June 2003


• 
  
  Appreciation from Michel Cohen client architect with 17yr exp; "you are quite but do good job" - Feb 2005


• 
  
  Recieving best contribution award from CEO, UBoC - Oct 2008 (photo on top).

But biggest moment is obviously getting married - March 2008.

I created a Virtual Machine...

Today I created a OpenSolaris virtual machine... feeling great. I used Sun xVM Virtual Box.

I first came accross xVM during this year Sun Tech Days. I was planning to start on this for quire some time and finally started on. Its cool and easy to set up. Downloaded and installed the xVM virtual box. Then downloaded the OpenSolaris .iso file. Followed the instructions and created the open solaris virtual machine. Tried to do few things on Solaris.. played games and then thought of creating a "Hello World" java program. Then realised I forgot most of Linux commands especially using Vi editor. I stopped today to refresh my Linux knowledge. I love to discuss my furthur expirences with virtual box and knowledge on Virtualization in next of my future blogs.

Technologies for 2009

As per recent report below are the top 10 technologies for 2009

Virtualisation
Cloud Computing
Servers -- beyond blades
Web-oriented architectures
Enterprise mashups
Specialised systems
Social software and social networking
Unified communications
Business Intelligence
Green IT

I will try to discuss these in my future blogs

Rich Internet Applications - Brief Intro

Recently the term RIA (Rich Internet Application) is used or heard frequently. I was reading different articles, white papers etc on this topic. Also started working on Flex. I am summarizing my readings in this blog.

1. Evolution of web

Computer applications started mainly as desktop applications where whole application code resides on user’s desktop and executed from there. Later we saw emergence of Client-Server architecture which led to web applications. With growing maturity in web model more and more processing is moved to Server and clients became thinner and thinner. In any traditional web applications most of the processing is done on Server. This model looked apt till recently. But with growing complexity of web applications and growing need to improve the user experience, drawbacks of the web model started to surface. One of major drawback is inability to have any processing logic at client side. This necessitates every request to go to Server.

This requirement gave rise to a new model—the Rich Internet Application (RIA), which is “a cross between Web applications and traditional desktop applications, transferring some of the processing to a Web client and keeping (some of) the processing on the application server”

2. Rich Internet Applications (RIA)

There are different technologies available in the market for developing rich Internet applications. Most popular of them are Flex, Java (AJAX etc), SliverLite, JavaFx etc. Before looking at these and other technologies, it is important discuss the crucial aspects of rich client technologies. Rich client technologies should:

Provide an efficient, high-performance runtime for executing code, content and communications. The principle here is that the end-user experience of HTMLbased web applications suffers from a variety performance related challenges. These include the request-response page rendering model; the need to dynamically generate large blobs of text for transmission of simple data; the lack of client-side data storage; the inability to easily invoke and use remote business logic, and even the basic graphics model of HTML. These all must be improved.

Integrate content, communications, and application interfaces into a common environment. The end-user experience of the Internet today is fragmented into the HTML browser for textual content and basic application interfaces; multiple messaging clients for performing communications functions; and multiple media players for handling audio, video, and other forms of media. Rich clients need to provide deep integration for all of these types of interaction.

Provide powerful and extensible object models for interactivity. While web browsers have progressed in terms of their support for interactivity through the Document Object Model (DOM), JavaScript, and DHTML, they still lack the richness needed for building serious applications. Rich clients need to provide a powerful, object-based model for applications and events. This common object model must integrate user interface, communications, and system level services.

Enable rapid application development through components and re-use. Rich clients should support powerful component-driven development, enabling both third party and corporate developers to easily reuse visual components to accelerate development, and give junior developers access to complex functionality. These components should integrate seamlessly into the design time environment for ease of development.

Enable the use of web and data services provided by application servers. The promise of rich clients includes the ability to cleanly separate presentation logic and user interfaces from the application logic hosted on the network. Rich clients should provide a model for easily using remote services provided by back-end components, whether hosted in an application server or accessed as XML web services.

Embrace connected and disconnected clients. While many users have gotten used to having to be online and in a web browser to perform work, the reality is that most applications would benefit from the ability to be used offline on occasionally connected devices such as personal digital assistants (PDAs) and laptops. Likewise, many applications require support for persistent connections with two-way, notification-based communications. Rich clients must enable both of these types of applications to be easily built and deployed.

Enable easy deployment on multiple platforms and devices. Internet applications are all about reach. The promise of the web is one of content and applications anywhere, regardless of the platform or device. Rich clients must embrace and support all popular desktop operating systems, as well as the broadest range of emerging device platforms such as smart phones, PDAs, set-top boxes, game consoles, and Internet appliances.

3. Characteristics of RIAs

• Accessible to the user without a separate installation process
• Supports robust, local application processing on the client side
• Provides a rich, full-featured user interface that closely matches the look and feel of a native desktop GUI
• Allows you to present information more effectively — providing immediate visual feedback
• Can provide greater ease of use — a standard Web browser is used to access the application
• Simplified maintenance — RIAs reside on the application server and there is no client component — update once on your server
• Support a full, event-driven user interface model.

RIAs utilize relatively robust client-side rendering engines that can present very dense, responsive, and graphically rich user interfaces. In addition to offering a wider variety of controls (sliders, date pickers, windows, tabs, spinners, gauges, and so on), RIAs generally allow you to construct graphics on the fly with either Scalable Vector Graphics (SVG) or some other mechanism. Some RIA technologies can even provide full-motion animations in response to data changes.

Another benefit of RIAs is that data can be cached in the client, allowing a vastly more responsive user interface and fewer round trips to the server than with HTML. For wireless and occasionally connected devices, the trend is definitely toward rich clients and away from text-based Web clients. Applications running on laptops can be designed to work offline or to at least degrade gracefully when connectivity is lost.

4. Application of RIA

The six key business applications that are motivating overall RIA spending consisting of

• Enhancement of existing web applications
• High-transaction and event-driven Internet applications
• Next-generation portals
• Enhanced business intelligence solutions
• Application modernization
• Peer-to-peer or mashup solutions.

5. Choosing an RIA solution