Web applications that use JavaScript to manipulate the DOM will have difficulty when something does not work on the JavaScript side.  Particularly debugging a JavaScript that alters the DOM would be very difficult.  “JavaScript Debuggers Overview” in AJAXPath.com has some good pointers on tools that can help debugging JavaScript.

There has been constant debate about these two terms and how to draw a line between these two. There have been several discussions around this and always there is confusion when something is called as architecture and when it is a design. Bredemeyer.com is a good site that contains lots and lots of information on architecture. Today I was reading an article “Architect. What’s in a name?” and it is a great article that describes who an architect is from the term architect and also gives a great analogy to differentiate architecture and design.

Essentially any system would need some platform to enable the hardware, some programming tool to execute your programs, database management systems to hold content and so on.  Primary all these need to be present in a direct access storage device (DASD) since memory is volatile.  The best DASD that we all are aware of is hard disks. Now any hardware device is vulnerable to failure at some point of time.  Applications requiring fault tolerance in terms of hardware will go in for clustering mode where the hardware’s are replicated and one picks up control when another goes off.  The complexity of clustering is dependant upon the criticality of the application.  Since all the data including your program resides on a DASD typically hard disk, redundancy of it is very important.  Not only it addresses failover but since DASD has a slower access rate compared to the RAM, higher access rate is important to reduce those delays in the production environment.  How will redundant hard disks help? That is where RAID comes to help.

RAID stands for Redundant Array of Independent Disks. A RAID controller is a hardware that can divide packets of information in chunks and put them across multiple hard disks.  While reading back it would pick up the pieces, assemble, decode and send it to the processor as one piece making it look like the information is coming from a single hard disk.  There are various levels of RAID that can help in providing fault tolerance, higher throughput and so on.  The controller design gets complex as higher throughput and fault tolerance are required.  Here is a RAID tutorial that simply puts various levels of RAID, its advantages and disadvantages.

Trusted Computing refers to any design/development of digital devices that can be trustworthy and will not have behaved differently beyond what it was intended to do.  More on Trusted Computing in wikipedia but at the same time watch this short movie “Trusted Computing? Yes or No“. Hmm pretty interesting eh?

Happy weekend!

Agile project management requires that you keep track of iteration, stories under each iteration and tasks to be performed under each story.  Another key aspect of doing an iterative approach is to calculate the velocity of an iteration.  Calculating velocity helps in determining the team’s capacity to complete stories in an iteration. Velocity is calculated by comparing the estimated hours vs. the actual hours spent by the team in an iteration. XPlanner is an open source tool that can help automate capturing the stories, tasks, keeping track of the time spent by the team on stories and tasks and also calculating the velocity for an iteration.  It can produce the estimated vs. actual in graphical formats by iterations and stories.  It also provides features to export the reports in the form of PDF and XML data.

I was playing the game Jenga with my nephew last weekend. It made me think about the foundations and basics. First little bit about the game. The game consists of distinct wooden pieces, rectangular in shape. Three pieces form a layer. Each layer has the wooden pieces put together horizontally or vertically. But if the previous layer is placed with horizontal wooden pieces, the current layer is placed with wooden pieces put together vertically. The below figure would be more explanative than my previous statements.

Once stacked up like a mini tower, the game begins. Each and every member has to pull out a wooden piece from the bottom layers of the stack without making the entire building fall. The piece that has been pulled out has to be kept again on the top of the stack. Each person takes a chance in rotation and pulls out a wooden piece without bringing down the entire stack. This keeps going on until when a member pulls out a piece and the stack falls down. That person is out of the game and the next round of game starts with the remaining members. Though it was just me and my nephew playing the game, we had fun time together in pulling out the pieces and creating a tall structure that just stands on few pieces of wood in crisscross fashion. Again the below image is what something similar we ended up with.

Our play didn’t end there. The game triggered some thoughts to me on the importance of having a strong foundation.

1. It is important to identify the key wooden piece that has to be definitely there in the base to support the entire tower as the weight starts to build up over the top. I did some variations in terms of constructing the structure itself, for example a star shaped tower, a pyramid, a triangle tower and so on. But what were common with all these types were those key pieces that were to remain intact at the base to support the structure.
   Lesson: Identify the key components in your application; determine how important they are in making sure the application does not break down. You have to make sure that you identify all possible scenarios that could break that component and thereby break the system. And then you should find solutions that will address those scenarios.
2. The stronger the base was, the less shaky the structure was and it was easy to pull out the wooden pieces without much care. When the foundation pieces were barely there to support the structure, it was difficult to pull out a piece from any part of the structure and required a great effort, time and concentration to pull it out.
   Lesson: With a stronger base in place, it is easy to manage the components that use those base components. It becomes easier to manage and restructure the components surrounding the base easily.
3. In the beginning stages of the game, some of the wooden pieces were not attached to the structure at all and came out so easily as though it was lying around away from the structure.
   Lesson: Identify that each and every piece of the system that you have put together is necessary. Watch out for those pieces that really do not add any value to the system and could be handled by any other piece easily. This could be resultant of consciously overdoing the reusability concept and trying to develop too much loosely coupled system.
4. The final point that came to my mind was there was a limit to bear the weight however strong the foundation is. As we kept pulling out pieces and started putting it on top, at one point there was a loss of balance and the base could not support that imbalance and the tower fell off at that point.
   Lesson: Any system will have a scope within which it could sustain being alive. As we keep upgrading and enhancing the system, there might be a possibility that more and more components are piled up on one single layer and that could mean some heavy load on the base. You might have tried to address the business need over the period of time and constantly kept adding more to the system. And if this was not done keeping in mind the design and its scope your system could break at some point of time. Every system has a lifetime and as business needs change, so do the design and technology needs. Keeping it in mind and maintaining a strong base would help in a longer system life.

I was reading through an article “The value of self evaluation” in the online newspaper “The Hindu“.  It triggered off some thoughts about appraisals and I wanted to share them here. Over 9 years of my experience in this industry, I have gone through a dozen of appraisal periods including mid years.  During appraisal period I have heard people crib “Oh my God its appraisal time”.  It is a usual scene people fill up their appraisal forms, think through all day to identify what they have done that year that is worth putting it.  Sadly some of them may not even know what their objectives are, leave out meeting them.  An appraisal is a project by itself, only thing here is that it is planning well in advance and executing it through out the year and closing it in the year end identifying what went right and what went wrong.  I have seen people struggle to complete the form in two ways.  One is to write down what they have accomplished and another to rate themselves on whatever they have written.  In terms of rating themselves I have also seen two categories of people, one set of people who overrate themselves and the other who underrate.

A primary question that dooms often is the difference between what is expected achievement vs. what exceeded the expectation.  It is very important that both the appraiser and the appraised understand what has been set, what has been achieved, and what was done beyond to rate it correct.  The easiest way to complete your appraisal without any fuss is to keep track of your doings through out the year.  It then becomes a copy paste during the appraisal time.  Moreover when you record your activities then and there, there is a high possibility that you will cover important points and incidents worth adding value to the work you have done.  You can keep track of your doings by maintaining a document or the best way would be to maintain a mind map.  Mind map would help you capture your emotional quotient of the work in terms of pictures and color information.  This will help you talk to the appraiser and bring out those emotional moments.  If you strictly follow discipline in maintaining your record you can change the “Oh my God” feeling to “Wow its appraisal time”.

A common mistake web developers do is to put anything and everything in session (a session is a special type of object provided by the web technology/framework to store objects within it that will be retained from the time a user enters the system till he/she leaves the system). A session level object occupies memory till the user session is closed. There are three ways a session could be closed.

1. If there is a logout link in the application, clicking on that link would logout the user as well as clear all the user’s session related objects.
2. The user might close the browser window abruptly.
3. The user is idle for some time and a session timeout is set to clear off all his session details. This is what would happen after some time in case of point 2.

You are in control in case of point 1, but in case of point 2 and point 3 there are going to be some delay in terms of really clearing the session in which case the objects for a session would remain in the memory. We are talking about one single user’s session here, but when the web application is in production it is going to be hit by more than one user at a time. Say if the number of hits expected to your site is n; multiply it by the number of objects that you have stored in your session. That many objects would reside in the memory.

So you have to be really stingy in using sessions and wherever a value is needed only for a request, use the objects at a request level scope, so that once the response is sent back, the objects for that request are cleared. Store objects in session that will really be needed throughout the user’s session. For example the user’s login details might be necessary to make sure only a user who has logged in is able to access certain pages. Consciously deciding on what to go into session and what not is very important and can save memory on your server which in turn could increase the load capable by your server.