Opera is 15 years old! I first started using the browser back in 1997 or so when I was working at OU doing support and web design for the financial departments there. I had gotten interested in web design in 1994 or so and was completely self-taught, but I had become interested in CSS and standards as soon as I’d learned about them. After I moved here to Norway in 1999 and was looking for a job, I checked out Opera’s website for job opportunities, and lo and behold, they were looking for a webmaster. I applied and had an interview with Jon and Håkon. They seemed to be impressed by my code, which was a major ego boost for me, given who they were and what they represented.

I got the job. I think I was their 26th employee. I was 22, and I felt like my career was really getting off to a good start—this was just the kind of work I wanted to do, and Opera was really the place to be for someone interested in standards. It still is! It was a really fun, informal environment and I enjoyed working there.

Just a few months thereafter, however, my grandmother died, and I fell into a seriously disabling depression. I was on sick leave for a year, and tried to come back to work after that on “active sick leave”, but didn’t manage to make it work out, so I had to quit. That’s still upsetting to me to this day, almost 10 years later, as I see the direction they’re gone in and how it still mirrors my interests in usability and standards. It was such a missed opportunity. I’m trying to get back into the workforce now, but I don’t think I’ll ever have the chance to make a difference as I might have had working for Opera.

After Firefox, and after Chrome, people have been quick to predict Opera’s demise, but I don’t see that happening anytime soon. Opera’s rock-solid grounding in and commitment to usability and standards—both on desktop environments and other platforms—ensure it a place in the game for a long time to come. Their research in these areas and promotion of these values is still sorely needed. Here’s to another 15 years—I look forward to seeing what they do next.

Most people have heard about the issue with Amazon labeling books with GLBT themes as “adult”, and thus no longer displaying them in search results or sales rankings. Last night when I did a search for “homosexuality”, the only results I got were anti-gay propaganda; “A Parent’s Guide to Preventing Homosexuality” is the #1 result. There are three theories about what happened: it was a “hack”, a glitch, or a policy decision.

I contacted Amazon via their web form:

I am extremely disappointed to read that you have labeled all literature with homosexual themes as “adult”, thereby making it unsearchable. I have been a customer of your company for 10 years and have spent many thousands of dollars at your store. If this is truly a corporate decision and not a glitch, and if it is not rectified, I will no longer be doing business with your company.

And today received the following response:

This is an embarrassing and ham-fisted cataloging error for a company that prides itself on offering complete selection.

It has been misreported that the issue was limited to Gay & Lesbian themed titles - in fact, it impacted 57,310 books in a number of broad categories such as Health, Mind & Body, Reproductive & Sexual Medicine, and Erotica. This problem impacted books not just in the United States but globally. It affected not just sales rank but also had the effect of removing the books from Amazon’s main product search.

Many books have now been fixed and we’re in the process of fixing the remainder as quickly as possible, and we intend to implement new measures to make this kind of accident less likely to occur in the future.

Thanks for contacting us. We hope to see you again soon.

I hope they’re telling the truth. Thus far the search results look the same as they did last night.

I’ve learned an important lesson the hard way this year: addressing a problem too generically is setting yourself up for failure.

I don’t consider myself a programmer, but given who my husband is, I’ve been steeped in agile philosophies for nearly a decade, and most definitely consider myself a proponent of such ideas. I can see how they can be applied to almost any aspect of life, but I was really looking forward to giving them a whirl when I took a contract earlier this year that I’d decided to solve using JavaScript. The script ended up being a lot more work than I’d expected, and while it worked perfectly, the amount of DOM interaction it required made it entirely too sluggish to be practically useful. In the end I had some ideas about how to speed it up, but since I’d been working on a fixed price (something Johannes had thoroughly castigated me for) I figured it was best just to deliver it how it was.

Why did the script end up being so much work? I’d been hired to do a specific job–to adapt tables in a web application to fit the size of the viewport, with the table header remaining fixed while the table contents scrolled if the table was too large to fit within the viewport. In order to do that, I’d set the scipt up to gather information about the original table, process it, then write the new, adapted table into the document.

The stupid decision on my part was the first part of that equation: gathering information about the original table from the document. Stupid because, in an earlier contract, I’d been the one who styled the original table in the first place! Without even having thought about it, I’d defined the problem too generally. My job had not been to create a solution to turn a standard table into a fluid one. My job had been to turn those specific tables into fluid tables. If I’d been clear-sighted enough to solve that problem in the first place, the script would have taken a lot less time and have (hopefully) been fast enough to be usable.

The problems we’re given are specified by the existential quantifier (∃), not the universal quantifier (∀). Theoretical and practical aspects of falsifiability are addressed in computer science classes and tied to real-world examples, right? From talking to Johannes I’ve learned that defining the problem too generally is frequently a problem for developers, however. I think people somehow feel it’s cheating to solve a problem only for specific circumstances. In reality, it’s the only thing that’s possible. We can save a lot of time, energy, frustration, and cash if we keep that in mind.