Error-handling: a fable in code

One of my favorite domains to review in existing applications, because it tends to be so error-ridden, is … error-handling. Too many programmers regard a language’s exception-handling syntax as a solution rather than just a mechanism, so error-handling tends to be misguided or at least neglected. A little more attention in this area often pays off with far greater end-user satisfaction. Perhaps the hardest part of handling errors is simply to remember that it is programming. I encounter many coders who appear to believe that it’s someone else’s job. In fact handling errors should be a routine part of definition and fulfillment of requirements. Here’s a parable about what often happens with even a single line of code: True-life rework An application needs to read a configuration file: fp = open(CONF, "r") While this is Python, what happens next is equally likely in Java, JavaScript (maybe with cookies), Java instrumentation,  Perl, C#, or other common languages. At this point, the application “works”, and attention moves on from this particular line to more pressing matters … … until the day CONF goes missing, and an end-user sees a traceback on her screen. That is clearly not acceptable, and someone quickly rushes try: fp = open(CONF, "r") except: pass into production while hunting down CONF. It turns out that the user had launched the application from a bookmark no one had considered (or disabled cookies, or had customized the installation in an unexpected way, or done any of the other things end-users do). Folklore within the organization concluded that the error was “fixed”, and someone elsewhere coded in protection against the bookmarking … … until the next time an end-user was clever enough to re-create a similar situation. This time, instead of appearance of a traceback, a distant part of the application broke down. Eventually, after too-much debugging effort, the code in the vicinity of CONF was upgraded to try: fp = open(CONF, "r") except: alert_user() return Business returns to normal … … until the day an end-user sees a warning on his screen about bookmarks (or cookies, or missing initialization), and is more frustrated than ever, because he already did what the warning advises. After more too-difficult debugging, someone discovers there’s a rare possibility that CONF hasn’t been properly assigned. The coders begin to realize the hazard of a “naked except“, and more carefully qualify: try: fp = open(CONF, "r") except NameError: alert_user_about_initialization() return except IOError: alert_user() return Problem solved … … until the day a sysad rationalizes networking in the back-office, and a critical file-share ends up with unexpected permissions. An end-user sees a warning about a condition that has nothing to do with firewalls, and is utterly frustrated until someone recognizes that IOError covers a multitude of causes. Soon our CONF reader looks something like try: fp = open(CONF, "r") except NameError: alert_user_about_initialization() return except IOError, e: if e.errno == 13: alert_about_networking() elif e.errno == 2: alert_user() return except: last_ditch_alert() It’s still not done. This is far from the end. The last iteration above of what started as a single line would eventually toss at least two more as-yet-undiagnosed problems. Something is clearly wrong. To reach this point involved multiple upset end-users and too-many late-night debugging sessions, and the “hot spot” of the initial open still is not “bullet-proof”. This is the point in a tale where I like to present a solution with almost miraculous powers. For this problem, though, there isn’t one; in fact, “error-handling” is so thorny that I’ve already collected a book’s-worth of material on the subject and its remedies. While there are plenty...

read more

Safety of WebSockets and other advanced parts of HTML5

Is it OK to use WebSockets? Absolutely. Why, then, reader Klaas Hemstra wonders, did I write in “The Dangers of HTML5: WebSockets and Stable Standards” that the WebSocket protocol is an “unstable spec”? The short answer is that this was the best I know in March 2011 when I wrote these words; the preceding hyperlink to the protocol definition was only finalized eight months later, in December of that year, for instance. Several of the other facts about WebSockets are different now. It’s worth taking a few minutes to get those facts right. HTML5 complications WebSockets are a Web standard for full duplex–simultaneous “push” and “pull”–communications between browser and server which “… slash the latency inherent in XMLHttpRequest …”, as I mentioned this summer in “Three main choices for advanced communications in HTML5“. Whole classes of applications, including performance-intensive games and demanding interactive medical programs, were restricted to the desktop until recently. WebSockets makes these practical within a standard browser. When 2011 began, most end users relied on browsers that did not support WebSocket. Worse, quite a few serious analysts suspected WebSocket compromised the security of the browsers that claimed to support WebSocket. While that didn’t necessarily mean that it was wrong to use WebSocket at the time, a decision to rely on WebSocket certainly wasn’t automatic. Now, it largely is. Internet Explorer 10, Firefox 6.0-current, Chrome 14.0 and above, Safari 6.0 and 7.0, several releases of Opera, including Opera Mobile (although not Opera Mini) are all among the browsers which do a good job with the WebSocket API. My conclusions: Sites need to explain clearly and accurately when individual write-ups were written or published or posted. “Application Monitor“, the Real User Monitoring blog, does this, of course. HTML5 is big and sprawling and full of activity. Don’t ever fall into the trap of believing that “Browser X supports HTML5” is meaningful. You need to think always in terms such as, “which parts of HTML5 matter to me?” and “how can I gracefully retreat if this specific implementation turns out to be impaired?” The WebSocket API is great fun, and lends itself to all sorts of interesting, high-performance Web applications. You can enjoy all this programming goodness...

read more

Enterprise IT Industry Trends 2013-2014

IT industry trends this year are all aiming towards one goal – accessibility. We’ve all heard the phrase ‘cloud’ tossed around a few hundred times this year, and the phrase ‘private cloud’ has just recently stepped on the scene. However, the newer trends surrounding these phrases are anything but dull or regurgitated. 2013 is proving to be one of the biggest and most exciting years in IT innovation and here we discuss some of the most prominent topics. Without further delay, here are a few of the biggest trends to hit the IT scene this year. The Ever-Changing Cloud 2013 is all about cloud computing. In fact, Forbes magazine predicts that almost 60 percent of all enterprises will be using some form of cloud computing before the year is over. Enterprises are enduring so much change that they are no longer able to make use of VPNs, so cloud computing is a must. The prediction is that more businesses will use a hybrid version of the cloud that allows them to switch simultaneously between public and private clouds, which gives them a fair lead on their competition. For this new hybrid cloud to be as useful as predicted, there is a need for better security and a total revamp of current cloud-based apps. In addition, it is important to decipher the various interdependencies of these apps and the systems with which they interact. BYOD is Back Mobile devices are dominating technology and more companies are adapting the BYOD trend. Why is this? Because it is getting harder to get employees to put their devices away. So, instead of punishing employees for using their devices at work, companies are encouraging them to bring them in and use them to increase work productivity. Companies that follow the BYOD trend created personal clouds that allow employees to access work-related apps. Not only this, but employees are able to access data from anywhere with an internet connection. This is great news for those in sales or IT. No more lugging around laptops to access your work database, it can all be accessed securely using your tablet or smartphone. However, it also raises a key question: How can those in charge of an organization’s IT systems ensure the consistent performance of their applications? Security Anyone? What about security? 2013 has that covered too. Forbes has coined the recent rush for security as the “new arms race” and rightfully so. It is, after all, the one thing that could make all of the above trends succeed or fail. Companies are pushing for identity security with a two-factor authentication method. This may include passwords plus fingerprints, or retinal scans and voice access. Whatever these companies chose as their ‘beefed-up’ security protocol, cyber criminals or unauthorized persons will have a hard time accessing any sensitive information. IT Operations professionals must make sure that these extra security measures do not slow down performance, however. It is clear that these trends introduce new challenges for IT Operations teams within the enterprise. Some of these challenges are already being addressed, while others still require a solution. Those teams who are proactive in analyzing their individual needs as well as reacting to these trends will see the most...

read more

Server-sent events a good choice for datacenter monitors

“Three main choices for advanced communications in HTML5“, which I posted two months ago, excluded one obvious candidate for “advanced communications”: HTML5‘s server-sent events (SSE). To my surprise, no reader asked me why. Despite this, it’s time to explain SSEs, why I didn’t mention them earlier, and why they are particularly interesting for real-user monitors and related datacenter “dashboards”. Simple demonstration Start with a peek at this example. Most will see a little digital clock which reports the time on one of our servers, updated every second; the background color of the display cycles red-yellow-green as the display updates. What good is that?! In isolation, it doesn’t look like much; it was (barely) possible to create similar effects with browsers fifteen years ago, and there are surely already enough clocks in the world. As a model for applications that help in the datacenter, though, this small demonstration has a lot going for it: server-side requirements are as minimal as can be. The supporting executable in this case is twelve lines of bash, and, at the cost of a little obfuscation, it could be reduced to five. No particular language or library is required; SSE is another one of the interesting features fully available to simple-minded CGI coders using twenty-year-old technology. It’s also light-weight on the client side, requiring only a single JavaScript function definition. Transport is by way of good-old HTTP, so SSE travels well through typical enterprise networks. With one notable exception, which I explain below, the demonstration performs well in all sorts of environments, including smartphones, tablets, and a range of old and new laptops in our office. SSE’s “push” is just the right kind of programming for many cases that interest me. I often need Web applications with the intelligence to display useful information, but also update that information as new results–a misconfiguration of a customer account, an overfull filesystem, congestion on a subnet, or so on–arrive. What’s the catch? With all this going for it, why didn’t I include SSE in my earlier list of established HTML5 communication methods? Internet Explorer (IE) doesn’t support SSE, and I’ve found no one who claims to know of a definite plan for a future version of IE to do so. In the context of conventional Web application development, that’s enough of a reason on its own to decide against even a documented W3C standard. SSE has other blemishes. It’s had a reputation for memory leaks, which I’ve never made the time to analyze for myself. SSE is a unidirectional communication, and many of today’s sexiest applications seem to fit a two-way “chat” better. Easy to start Still, plenty of shims are available to extend SSE support to IE, memory leaks are correctable, SSE’s light resource demands are appealing, its minimalism is a good fit for all the devops who aren’t full-time programmers, devops staffs don’t require IE compatibility, and a simple push is the right approach for a lot of what we do in the datacenter. Try SSE for yourself; it should take only a few minutes to put together a “Hello, World!” that makes sense in your environment. With that in hand, you’ll be in a position to judge what SSE can do for your next...

read more

Three performance tips: measurements and techniques to pay off for the long haul

“Real User Monitoring” has probably convinced you by now that application performance is both important and inadequate; so what do you do about it? Accurate measurement and identification of a problem is the first step, of course. When you’re ready for the second step, here are three quite different approaches you can apply with proven records for delivering both quick results, and enough depth to reward you for months to come: Low-hanging fruit: HTTP payload basics I like the folks at Radware for bringing together two values in their public writings: they base their comments on actual measurements; and they offer practical, positive, and realistic advice. Tammy Everts, for example, often teaches that images can be compressed, delivered in appropriate formats, and sensibly sized. That’s a great place to start any performance-optimization project. Take advantage of what’s right in front of you: browser tools Most front-end developers have a sense that browser debuggers are potent, and have improved a lot in recent years. They’re essentially indispensable for making the most of the functionality of HTML5, JSON, CSS3, and all the other technologies likely to appear in modern applications. Not so well-known is that nearly all of these debuggers provide rich performance introspection. With Chrome DevTools, for instance, a favorite of many colleagues, you’ll want to learn at least the Timeline, Audits, and heap profiling. Other browsers also go a long way in analysis of your code which leads to specific suggestions likely to improve performance of your application. Network modelling Last week I mentioned “Network emulation for the cloud“. It’s worth a few more words now. Shrinking downloads and easing browsers’ chores are two traditional but distinct ways to improve the performance of Web applications. Separate from these in both means and ends is engineering modelling of network traffic. With increasingly sophisticated and complex networking between providers and end users, however, prudent network modelling has become essential. You can read for yourself why author Nick Hardiman expects that “[i]n a few years … IT testers will wonder how they managed without it.” Conclusion You don’t have to put up with mediocre performance. Whatever the current shape and substance of your applications, it’s almost certain that you can take at least a couple of steps today to improve it enough to please your...

read more

True scientific revolution: radical sharing

Ready for the future? “Warming Ocean Threatens Sea Life” is it. It’s not the climate change content of the article on which I’m focused at the moment; that’s a topic for another day. More singular, and worthy of our attention now, is that this article is the first in Scientific American to be accompanied by its own IPython notebook. ‘Have a question about how the author performed his statistical reductions, or exactly what was in his datasets? It’s all there. You can review or extend the calculations yourself. So can the five, or fifty thousand, other people in the world qualified to judge the analysis. This is how science deserves to be done. I recognize every generation imagines its own shufflings to be unimagined leaps. In this case, perhaps, the conceit is justified. The science of recent decades has been deeply plagued by faulty and improperly-analyzed data. The most certain fix for this defect is well-organized, transparent, teamwork or collective action: “open-source science“. IPython, a fascinating project of research neuroscientist Fernando Pérez, already has a strong record of achievement in encouraging scientists and engineers to share not just their ideas, but details of data technique. IPython isn’t alone; such other open-source products as Sage, TeX, R, the Open Genomics Engine, and arXiv have great stories to tell, and a few proprietary products,...

read more