Off the Shelf: The Retail & CPG Blog

Citrix has created a version of it's "Go To My PC" product that runs on the iPAD. Interesting.  This means that someone carrying an iPAD could connect to any PC over the Internet (that security rules allow) and run it from the iPAD.  This raises questions about whether a laptop will eventually be made obsolete by this kind of technology. 

Consider why we carry a laptop with us anyway:  we want access to data, the Internet, and various applications.  Nowhere in that list is a need for the data to be with us physically at time when we don't need it.  In fact, that is a negative given that a lost laptop can be a serious source of panic, depending on the data on it.

The iPad is not really a complete replacement for a Laptop, regardless of the quality of the connectivity.  It does not have a hardware keyboard so heavy typing is not practical.  In addition,  response-time sensitive applications like online video games would not be practical.  However, for many business applications these problems are not a big issue. 

Imaging a world where you carry a tablet PC and a keyboard in your briefcase.  Whenever you need data, you turn on the tablet, connect to your PC at home, and start working.  If you need a keyboard, you pull it out of your briefcase and use it to compose a long document.  (If the document is short, you could just use the tablet's virtual keyboard)

Then next logical step is to get rid of the laptop completely.  You could purchase a VM that is hosted for you as a service.  At that point, your tablet could connect to this virtual laptop, and your need for a physical device at home would be gone.

Posted by Stephen Alan Potts at 3:54 PM | Permalink | Comments (1) | TrackBacks (0)

Web-based applications need respond quickly to user actions.  Nothing will kill the popularity of a site or application faster than excessive lag time between user action and system response.  All of us can recall site that was so responsive that it was fun to use; unfortunately, this is not common.  More often we remember sites that were so slow as to be nearly unusable; this is very common.  We are often left to wonder why more companies don't spend the time and money necessary to improve their performance instead of adding new features.  Perhaps, it is not a lack of will, but rather a lack of know-how, or a lack of tools that show where the performance bottlenecks are.

Web-based applications are more complex than traditional server-based or mainframe-based apps because they are made up of multiple components (written by different vendors) that run on different computers.  A large retailer's web site will be composed not only of the site's application code, but  also browser-side logic,  and database logic. Even if the site's code is running well on the browser, one or two of the other components can make it seem "dog slow", and make your company look incompetent. 

You can easily determine that your site is slow, but why it is slow is rarely obvious.  Given the number of places that could be causing the slowness, this is not an easy question to answer.  What is needed is a comprehensive profile of your application that tells you where the site is spending its time.  Once you know the identity of the slow components, you can tune and reengineer them.  Getting that visibility is the problem.

Back in the good old days, we debugged applications using Integrated Development Environments (IDEs).  The IDEs contained a single-step debugger and the tools to examine every variable's value, to set break points, etc.  Web app IDEs have these same capabilities, but only in localized pieces.  We have the ability to look into the actions that take place in the browser or in the application (J2EE or .NET)  server or in the network or in the database.  However, these views are disconnected from one another, making it difficult or impossible to find bugs that originate in one component but manifest themselves in another.    

The ideal tool would be able to show you the duration of an action from the browser through the network to the HTTP server, then the application server and the database.  It would then pick up the response and trace it all the way back until it displays in the browser.  Unfortunately, no one tool allows us to view every component, but one tool, Dynatrace (Dynatrace.com) gives us a large portion.  The Dynatrace product installs on both the browser and the backend systems.  It can profile a transaction from the beginning in the browser, pick it up in the Application Server and monitor the calls to the database.  All of this activity is then reported to you on a single console.  The internal database processing is not visible.  (For that, you would use tools provided by the database vendor.)  The behavior of the network is also not visible in Dynatrace, so tools like Wireshark are still required if the Dynatrace tool isolates the problem to the network.

In the next post, I will talk about how Dynatrace works at the program level.

Posted by Stephen Alan Potts at 1:41 PM | Permalink | Comments (0) | TrackBacks (0)