Note: This article originally appeared in the April, 2010 edition of TEQ Magazine.

My grandfather enjoyed a simple lifestyle in upstate New York, so when he passed away last year there were only a few accounts in his name that needed to be closed. One was with his telephone provider. Usually when people talk about their “telephone provider” they mean “telephone service provider”, but not so with Papa. My grandfather leased a rotary phone for $1.75 per month rather than buying his own for $10. The phone he was given in 1967 served him well until the end. Over the years my family tried to convince him to join the modern world of touchtone telephone ownership, and along with it the ability to express your language preference with the press of a button. But my grandfather, bless his soul, sometimes preferred consistency over common sense.

If Papa were here today, and if he owned a computer (ha!), and if he had an Internet connection (double ha!), there’s no doubt in my mind which web browser he’d be using: Internet Explorer 6.

IE6 is to web browsing what a rotary phone is to calling. It’s ancient (IE6 was released in August, 2001), it’s slow (today’s browsers can render pages in half the time), it’s full of security holes (as of February 9, 2010, Secunia.com lists 24 unpatched vulnerabilities in IE6), and it simply can’t do all the whiz-bang things that modern browsers can.

I used to have a handsome head of hair, but it’s been replaced by a – some would say more handsome – bald dome. The cause? Genetics, and more than eight stressful years of crafting web sites to display correctly in IE6. Ask any web developer what the hardest part of their job is, and they’ll probably tell you it’s devising tricks to get IE6 to properly display pages. For nearly a decade, web developers have wasted countless hours struggling to fix IE6-specific problems. Their time could have been better spent creating new features, learning new techniques, or grooming the hair they’d otherwise still have.

Last month my company got bit by an IE6 bug in software we built for a customer. Our application turns form letters into PDFs, and it displays a list of the most recent documents on a page that we call the Print Queue. The page features a checkbox next to each document, and two buttons at the bottom: Print and Delete. Depending on which button is pressed, our software either prints or deletes the chosen PDFs. Unless you’re using IE6. In that case it always deletes the documents, even if you hit print. Yikes!

When you submit a web form, your browser is supposed to tell the server which button you clicked. But when IE6 sees a form that contains multiple <button> tags, instead of telling the server which one was clicked, it recklessly submits the name of every button on the form! Imagine if our nuclear missiles were controlled by a web page with two buttons: Disarm and Launch. Let’s just hope the Russians are using Firefox.

Last month was my tipping point. Instead of wasting an hour tweaking things for IE6, with my customer’s consent we completely blocked access to Internet Explorer 6 and lower. Time and hair are just too precious to be wasted on such problems, and fortunately I’m not alone in this belief. Google recently announced they will begin phasing out support for IE6 this year, and they are part of a larger movement to do the same. Although IE6 still accounts for 20% of web traffic, campaigns such as BringDownIE6.com are working to change that. Despite what you might think, these efforts aren’t anti-Microsoft. Although I prefer Chrome and Firefox, IE8 is a decent browser too.

If you’re reading this article I suspect you already stopped using IE6 years ago. But if you’re still developing web sites for it, I hope you’ll join the movement and abandon this hideous browser. Should you disagree, there’s this phone company in upstate New York I can highly recommend.

Note: This article originally appeared in the January, 2010 edition of TEQ Magazine.

If you were given the opportunity to travel back in time for one day, how would you use it? Would you try and stop a famous tragedy? Would you go back to witness an historical event, like the Beatles’ first appearance on Sullivan? Maybe you’d prefer to relive your happiest day.

For me it’s a no-brainer. I’d use the time machine to go back six months and stop myself from using SOAP in my last software project.

Last year my company developed warranty management software for a company that makes siding for homes. Our application manages most of the claim process from filing to payment, but one part it doesn’t handle is the scheduling of the home inspection. A third-party handles that step, and they have their own application that my team’s program had to interact with.

To get our applications talking, we decided to use web services with SOAP. It made perfect sense. After all, our situation was exactly the kind of data-exchange-over-the-web type of application that SOAP was designed for. We’ve used it before, and although we’ve never loved it, it still seemed like the best tool for the job.

But what started out as a two-week task turned into three months of debugging, handwringing, and self-doubt. Nothing worked as it should. First our Java application couldn’t connect with the proprietary authentication technique the other company was using. (Although SOAP itself is a standard, it can work with dozens of “sub-standards” which aren’t all well supported.) Then we had problems with decoding image attachments, data validation, XML file size limitations, and server conflicts with other programs. At one point the web service even failed when the other system’s clock fell out of sync because of daylight saving time.

SOAP’s not an acronym anymore, but when it was, the “S” used to mean “simple”. Ha! That’s like calling a cystoscopy a “simple procedure”. Sorry Dr. Smith, but what you once described to me as a simple procedure is actually the least simple thing I can think of. And the only thing more painful was that time I used SOAP in a warranty management application.

SOAP has good intentions, and with enough effort it can be made to work well. But the problem with SOAP is that it’s built on top of many layers, and with each new layer comes a new set of complications. SOAP tries to be an all-encompassing protocol, and although this makes it powerful, it also makes it complex.

Fortunately there’s an easier way of exchanging data between programs over the web. It’s called Representational State Transfer, or REST. Unlike SOAP which is a protocol, REST is more of a general approach to sharing data between a client and server. A RESTful web service forgoes complicated protocols, and instead takes advantage of HTTP’s underutilized features.

Imagine you run a business that rents camels by the hour. In addition to allowing reservations on your web site, you want to open your system to third party brokers. The brokers use their own software to compare prices and make reservations, and they’re not going to rent out your camels if you don’t give their software a way to hook into yours. You decide to make your reservation system available to theirs via a RESTful web service.

With REST, you expose your software’s functionality via meaningful URLs, and you take advantage of HTTP’s “verbs”, which are called actions. For example, if a broker wanted to check the availability of your two-humped camels, their software could issue a GET request of http://www.carav.an/camel/hump/2. To make a reservation for a camel named Gobi on April 12th, their software could issue a POST request of http://www.carav.an/camel/gobi/2010/04/12. To check on the status of reservation #123, they could issue a GET request of http://www.carav.an/reservation/123, and to cancel that reservation they could issue a DELETE request of the same URL.

Unlike SOAP which is limited to XML, RESTful web services can share their data in any number of formats, such as XML, JSON, or CSV. REST replaces complexity with simplicity, and it takes better advantage of existing methodologies instead of inventing its own. Although it lacks some of SOAP’s strengths, such as a unified way of defining your interface, it makes up for it with its ease of implementation.

The next time you develop a web service, consider this alternative to SOAP. Although we can’t travel backwards through time, at least we can use REST to save it.

Note: This article originally appeared in the November, 2009 edition of TEQ Magazine.

This is an actual email I once received from a friend:

Date: October 27, 2005
From: (I’ll protect the not-so-innocent)
To: Michael Righi
Subject: number

071-89122

That’s it. Nothing more to see. Just a vague subject and a mysterious number.

The email probably made sense at the time, but today I have no idea what question it was answering. And what kind of number is that? It’s clearly not a phone number, and it doesn’t follow any common patterns like credit card or SSN. Maybe it’s a numbered Swiss bank account I forgot I had.

This email suffers from a lack of context, but that’s not to say it didn’t have any at the time. The problem is that the context was likely provided by a phone conversation I was having with my friend. I’m guessing it went something like this.

Me: “Hey, I forget the number for the XYZ. Do you know what it is?”
Friend: “Sure, check your email. I just sent it to you.”
Me: “Got it! Thanks!”
Friend: “Anything for you. You’re such an awesome person, Michael!”
Me: “And you’re a great judge of character!”

Contextless emails are one of my biggest pet peeves, because they’re confusing and unsearchable. My email archive represents the collective knowledge of everything that’s passed through my inbox since 1996, and I’m constantly searching through it. What’s the phone number for the plumber I hired five years ago? Where does my customer like to play golf? Which bondsman does my attorney recommend? All of these questions can be answered with a quick search.

I rely on email searches so much, that I often send emails to myself with information I might need one day. Here’s a recent example:

Date: October 1, 2009
From: Michael Righi
To: Michael Righi
Subject: Rachel is Allergic to Buckwheat

Rachel is allergic to buckwheat. It will kill her. Quit offering her food that has buckwheat in it, like multigrain pancakes or anything from Kashi. She’s starting to think you’re doing this on purpose.

Keywords: allergy, allergies, buckwheat, buck wheat, allergic reaction, Rachel, EpiPen, benadryl, ways to kill my employees

I can never remember what Rachel is allergic to, but now I can do a quick search to find out.

When I send emails to others, I don’t go as far as adding keywords in the message, but I do provide context with descriptive subjects and message bodies. Instead of sending an email that says, “Their number is 412-271-9293”, I’m more likely to say, “The phone number for Beasley Plumbing is 412-271-9293.”

Not everyone is good at writing descriptive emails, but fortunately tools exist to make their emails searchable anyway.

Apple Mail is my main email client, and I use a plugin called MailTags. ( $29.95 from indev software ) When I receive an email with little or no context, MailTags lets me add my own keywords for quick searching in the future. This is especially useful for emails with PDF or image attachments that couldn’t otherwise be indexed.

Outlook users might benefit from Taglocity, which offers email tagging and more. Although I’ve never used it myself, I’ve heard good things, and I encourage you to learn more at http://www.taglocity.com/.

Gmail calls their tags labels, and you can even create filters to automatically assign them, such as “attachment” to emails with attachments or “family” to emails from certain addresses.

These tools are great, and I recommend you use one, but the best solution would be for everybody to start sending more descriptive emails from now on. As Rachel will tell you, this isn’t just a matter of convenience. It’s a matter of life and death.