Codeasaurus Rex

February 9, 2009

Dealing with web email flakiness

Filed under: General, Howto — Codeasaurus Rex @ 2:21 pm

A lot of webpages are now done with AJAX (fancy Javascript) or just Javascript. This allows a webpage to remain responsive even though your session has timed out and and you’ve been logged off by the web server. You may even be able to navigate to a “compose email” page without server interaction, which makes you think that you’re still online and can compose and send email.

Well, you can compose to your heart’s content because it’s still being handled locally by the browser but when you try to send the email, you get the “session expired” raspberry from the server because your session timed out long ago. Oh, and by the way, your work has disappeared too!

I got bitten by this a few dozen times before I developed this simple (though annoying) workaround: before you ask for the “compose email” page, first do a “check email”. If you’ve been logged off, you’ll find out before you waste time writing something that will be lost. If you’re still logged in, at least it will restart the session expiration timer so you’re less likely to be logged off while you’re composing your email.

Nowadays, I try to realize ahead of time whether something I’m writing will take a while. (Notice that this could happen even with a short email because you can be interrupted by something, anything.) During peak hours when the session expiration times seem to get shorter, I try to remember to save composed email text to a separate, local editor session so that I can be philosophical about the server silently logging me off before I try to send the email.

One could ask why the Javascript doesn’t just back up “email composed so far” to a local file before the server expires your session. First, that would require additional server interaction, which programmers are trying to minimize. Second, it breaks the simple paradigm of user-initiated actions. Third (and most importantly) it means granting the webpage the ability to save files to disk without user input (a big security issue).

You could argue that the webpage could ask the user first, but remember that we’re dealing with a scenario where the user might have walked away from the computer to deal with an interruption and is unable to grant that permission quickly enough to satisfy the web server. There is still the possibility of squirrelling the email away in browser memory somewhere, but that implies extra user interface complexity that the email programmers haven’t seen fit to provide.

Remember that browser technology was invented to enable hypertext browsing, not rich client interaction. However, rich client features have been tacked on using hacks that are either clever, hideous or both. Until the bugs are worked out, or we’re all using Outlook or some other local, non-web-based email client, we’ll need workarounds like the one suggested to smooth the way.

August 21, 2008

Cloud computing or privacy: choose one

Filed under: General, Security — Codeasaurus Rex @ 12:00 pm

The concerns that I’ve had about my own use of third-party-hosted email and CRM have just gotten a shot in the arm by a Security Focus article from Mark Rasch.

As a software developer, I was seduced by the incredible ubiquity and accessibility that browser-based apps provided. Now, however, I’m tending towards the view that if it’s personal, private or sensitive, it doesn’t belong in an electronic medium that was geared from the start towards publishing and not protecting data.

I think it’s time reconsider the tradeoffs of third-party hosting and take control of our own data on hardened server appliances that we own ourselves. As Rasch’s article claims, at least the authorities will need a warrant to seize personally-held data before they pool it for use by any official anywhere for whatever purpose. The protections for my data held by phone companies and ISPs have been under full-scale attack by the government for the last few years, and I don’t expect this trend to spontaneously reverse itself as the price of disk storage continues to plummet.

I therefore predict that there will be a backlash against data-holding service providers in favor of user-owned and user-controlled server appliances simply to escape from the threat of essentially warrantless snooping. Another possibility is to continue to use third party services, but only store encrypted data on them when privacy is at stake: this would require a complete rethinking of the client side and could tip the scale in favor of rich clients.

Read the article here.

September 26, 2007

Cognitive dissonance

Filed under: General — Codeasaurus Rex @ 11:13 am

cognitivedissonanceimage

September 8, 2007

What we used to call systems integration is just system administration nowadays

Filed under: General, Mainframer makeovers — Codeasaurus Rex @ 2:01 pm

This morning I was reading a book on an open source CMS (Content Management System) called Joomla (Rahmel, Dan. Beginning Joomla!: From Novice to Professional. Apress, 2007. ISBN 1590598482). Joomla is a framework into which you insert website content, and the framework manages things like layout, user management, content submission, pre-publishing review etc.

As I read the third chapter’s section on troubleshooting, the following statements really grabbed my attention:

  • The multiple programs employed by a Joomla site have to integrate properly and “play nice” for the CMS to function properly.
  • Because of the multiple technologies involved in Joomla, it can sometimes be extremely frustrating to track down the source of a problem.
  • Since Joomla requires essentially four different servers to work together in order to function correctly, you may run into a variety of problems during installation.

It suddenly hit me as these sank in that configuring a non-trivial website nowadays is really what we used to call systems integration, an honorable (and once lucrative) calling.

Let’s look at what’s involved:

  1. You need to configure a webserver: Apache is the industry favorite, and its complexity and flexibility easily surpass that of yesterday’s mainframe transaction processing monitors. If it’s your baby, you have to configure it; if a hosting service provides it, you still have to know how to adjust to their configuration of it, and maybe even add to their configuration to make your stuff work.
  2. You need a database: MySQL is the zero cost-of-entry favorite and powers a lot of commercial websites and enterprise systems. Installing and maintaining a database used to require a DBA, but now you’re the DBA even if a hosting service is involved.
  3. You need something better than a text editor and an HTML cheatsheet: even Dreamweaver and FrontPage are no longer sufficient to put up a website any more. Unless you’re going to spend the rest of your life manually updating site maps, links etc., you need a CMS like Joomla. Large companies used to spend hundreds of thousands of dollars on CMS systems comparable in power to Joomla, but now you download, configure and administer Joomla and similar software yourself.
  4. Joomla and many other modern web apps require PHP: PHP is an open source hypertext preprocessor that competes with Active Server Pages and Java Server Pages for the task of server-side, dynamic webpage generation. PHP cuts across three other systems, bridging Joomla and HTML to the database while executing as a web server plugin: if PHP ain’t happy, ain’t nobody happy. Who’s responsible for PHP configuration problems that cross web server, database and CMS lines? You.

I remember putting out a certain amount of effort in the early eighties getting my mind around a mainframe transaction monitor, its client/server architecture, SQL and a couple of programming languages. This stood me in good stead for about ten years, and then all hell broke loose:

  • Interfacing with client PCs using a potful of techniques and technologies ranging from serial cables through Ethernet either directly or through a variety of middleware
  • Open Systems (AKA “Interfacing with Unix”)
  • Furry little mammals (PCs) raiding the nests of the dinosaurs (mainframes) and making off with their applications and budget
  • Programming Language Du Jour
  • Programming Paradigm Du Jour
  • TCO (Total Cost of Ownership) Wars
  • Thin Clients
  • Death of Thin Clients
  • Resurrection of Thin Clients and the Second Coming of the Mainframe

But I digress…

Many of us had to develop systems integration skills during while interfacing big iron with other big iron, and then big iron with minis and PCs. What hit me just now is that the same skills apply to modern technology, except that instead of worrying about

  • RS-232 versus current loop connections,
  • number of data, parity and stop bits and how parity is handled,
  • SNA? Token Ring? Ethernet? And if Ethernet, what flavor? etc., and
  • strange little ad hoc data communication protocols,

now we can put away the wire strippers and adjust

  • httpd.conf,
  • php.ini, and
  • many other knots of configuration data.

The important point here is that the thought process is pretty much the same: you have multiple systems, each complex in itself, interacting and requiring exact configuration to interoperate successfully. Things don’t install, or they install and they don’t work and then you need the same simplify the problem, divide and conquer approaches that worked twenty or more years ago, only in a more abstract space of malleable configuration settings usually stored in editable text files.

An unsettling corollary of all this is that the kids that keep modern software systems up and running need to master a considerably greater wealth of detail than us old folks were ever called upon to learn. Whether modern systems are as reliable is another question (though not addressed here). They are, however, orders of magnitude more capable when they are up and running: I know, because I have had my hand in some for a few years now.

What makes it all work, however, are the online forums where people post their difficulties and usually encounter immediate aid and comfort: without these support networks, a lot of modern software installations would never quite work right, if at all. And because the forums archive their posts and responses, you often need only moderate skill in searching the web to find that somebody already ran into your problem and that someone else already provided the solution. You only need to post a query if your forum search didn’t find the answer.

In summary, the indispensable, highly-paid systems integration skills of yesterday are pretty much expected of the average system admin today. Even worse, the average developer may not get very far without a considerable mastery of the same material unless he or she has chosen to specialize. Specialization, however, is a dangerous strategy in a world strewn with the corpses of yesterday’s technologies du jour. I think Marshall McLuhan nailed it years ago when he predicted that we would end up as hunter-gatherers of information. Welcome to my world.

June 24, 2007

Point of departure

Filed under: General — Codeasaurus Rex @ 3:05 am

This is my entry point into the blogosphere.

To begin with, I intend to compare current web technology with the expectations ingrained in me by years of large, mission-critical systems experience. I’ll go easy, though, because I’ve also had my hand in sub-mainframe technologies going back to

  • CPM
  • Commodore 64
  • MS-DOS 2.0
  • CBASIC
  • Windows 3.0
  • Xenix
  • the 128K RAM Macintosh
  • CompuServe

and remember them fondly.

I also remember, although less fondly, the crazy early years of the World Wide Web when volumes of copy-and-mangle HTML with ransom note-typography spilled from the pens of budding Shakespeares only to emerge disfigured from the incompatibilities of the Browser Wars, and CGI programs ruled the Earth. Toy systems were deployed as business websites and keeled over during the first flush of success, while us pros wondered “Why doesn’t anybody seem interested in our knowledge of how to build large, scalable systems?”

Oh, well, the lessons of the mainframe era were ignored but eventually relearned although modulated by new technologies and their tradeoffs. This blog will start off by stacking some of these new-fangled techniques up against the Old Ways, especially some of the Old Ways that haven’t been much improved upon. (Feh!)

Well, I guess that pretty much pigeonholes this survivor of punched cards and teletypes, Codeasaurus Rex.

Powered by WordPress