Internet Explorer 6: The Cancer of the Internet

For the past few weeks I've been working on a project at my former employers, VSA Partners. I've been working on a pretty complicated web application, a sort of live search for product lines where you can drag sliders to specify the attributes you'd like. Very cool, and it works absolutely beautifully in Firefox 2/3, Safari/WebKit/KHTML 2/3, and Google Chrome, not surprisingly. Its performance is by far and away the best in the nightly build of Webkit and Google Chrome, again not surprisingly because those are essentially the same browser and existing on the bleeding edge of browser technology. So far, so good. Internet Explorer even runs it tolerably well, with a 2.5 second lag when the page is first loaded and a 0.24 second lag between user interface interactions; resetting all the controls to their original state takes 2.3 seconds.

And then there's fucking Internet Explorer 6, rubbing its shittiness in our faces much to our collective shame and chagrin.

For this project, I knew that IE6 would be a major bump, so I did my homework on it. I read all the Microsoft Developer Network articles on the subject (and yes, there are MSDN articles specifically about workarounds to IE's craptacularness), the not-so-swift Javascript execution in Internet Explorer. In particular there is a nice three-part article series on there about some of the specific sore spots in IE6's performance. I read up and then applied what I had learned to my code. The result was slow and steady performance improvement over the course of a few days, but overall an abject failure. But, this failure doesn't belong to me; I'm not going to claim it, as tempting as it is for me to believe this is my fault. This particular failure sits quietly and slovenly on the shoulders of Microsoft. Internet Explorer 6, according to W3schools (source: http://www.w3schools.com/browsers/browsers_stats.asp), is still used by about one in every five internet users. This means that, as a web developer and designer, if I ever create anything that can't run or looks terrible in IE6, I've automatically lost one in every five people, 'cause let's face it, those people aren't upgrading anytime soon. Internet Explorer versions 6 and 7 make up 44.2% of internet users.

A little bit of background for those who aren't technically inclined (and for those who are but love reading about Microsoft's many failures). Internet Explorer 6 is notoriously difficult to develop web sites for because it has poor or nonexistent support for many of the new standards that are supposed to make web development simpler. Internet Explorer's rendering of web sites hearkens back to an earlier, more innocent time, when there were no massive javascript applications, when web sites were simple, god-fearing websites and IE6 was all you needed. Times are very different now. With the rise of web applications moving the heavy lifting of making the web work over to the client side, the fastest browser wins, and accurately rendering XHTML code to web pages is fundamental—obviously—to the viability of a browser as a platform. In short, web browsers are now expected to be platforms similar to an operating system. As it happens those two tasks, rendering code accurately and executing javascript code swiftly, are the two things at which Internet Explorer is the absolute worst.

In the case of IE6 I don't think it's fair to poke fun at its javascript interpreter. As I said above it was a different time, and javascript really hadn't come into its own yet. It was rarely if ever used for anything move involved than overcoming the shortcomings of CSS and XHTML code. But nowadays we write whole applications in Javascript and skin them with XHTML/CSS, so IE6's relevance to our present-day world is waning fast. Its javascript interpreter may be apples to today's browsers' oranges, but that still doesn't make reliance on it a forgivable offense. Even since I've been writing them web applications have exploded in popularity and scope. As I've positioned myself to specialize in their design and development, I feel pretty good about this. But there's just one problem... IE6.

In a modern web browser I have access to all the new innovations in browser technology over the past decade, but in IE6 I am stuck in the last century. Yes, that's right, Internet Explorer was released in 2001 and, but for security and aesthetic changes, hasn't changed much. Internet Explorer 6 is still the sorrow of the internet, and something tells me those 18% aren't going to upgrade soon. So... I have an idea.

Fuck 'em. That's right. Fuck 'em. They're using a browser that came out before the dot-com crash; they shouldn't be expecting the internet to behave the same for them. At this point I think it's okay to say, Yes I will look at it in IE6 and if there's a quick fix I can apply I'll do it but I will not burn hours and hours tweaking it. Overall this will mean less money in the short term but it will mean better productivity, more websites launching on time, and the betterment of the internet in general.

Once we stop caring about IE6, it's no big deal to write javascript that futzes with the layout of the page (IE6 is notoriously terrible at manipulating DOM objects), or to write elegantly simple CSS layouts, or to write heavyweight application suites. It'll be a better world and when the IE6 users are finally forced inevitably to upgrade, the rest of the world's web will be ready for them. They'll arrive with fanfare to a beautiful and useful web populated by tools that are as easy to use as they are powerful. I'll be here at the bleeding edge... waiting. Come join me, space cadets.

RubyConf 2008

I'm finally back in Chicago after a long weekend in Orlando, FL, at RubyConf '08. As my first large-ish conference I really don't have a lot to compare it to besides Great Lakes Ruby Bash earlier this year, but I've gotta say it was a pretty great time. There's something about Ruby programmers, I think, or maybe it's something about us that makes us want to become Ruby programmers. It's really very simple: we're doing this because we love it.

We do. Programming PHP was a job to me. Programming python was a slightly more enjoyable job but it still felt like work. Programming in Ruby feels as relaxing to me as painting does. It's not just a job to me, and I'm passionate about it; I get the feeling that I'm definitely not the only one and that's pretty cool.

All around a pretty good crowd and a pretty good weekend. A lot of scotch and bourbon was consumed. I'm glad I made the decision to avoid the free beer Saturday night on account of everybody was way too hung over the next day and I felt just fine. Had a good time anyway, paid far too much for some bourbon at the hotel bar, and observed the bizarre crowd at the hotel bar. I don't think any of those people were prepared to see the hotel lobby filled 24/7 with bearded nerds on laptops, but whatever. We're cooler than the tanning bed convention folk anyway. 

Once I get some of my thoughts together on the conference and the world I'll write some more. Ciao ciao space cadets!

Xmas

I'm down in Saint Louis for Xmas right now. On the way down I met this girl, Martha, and thought it was so totally random but then I remembered that's basically how I met Leila (s/bus/airplane/). Have I really been meeting random people everywhere all this time and only just now, now that I've got a system in place for this sort of thing, am I remembering them? I can't tell if my memory is getting better or if I'm getting better at not relying on it. If there were a way to test it....

Since Friday's shenanigans at the office I've been getting back into poker, even to the point that I'm currently designing a kind of poker server that multiple clients will be able to connect to at once. Here's the twist: I want to attract other programmers to write plug-ins for it so that I can see what the bot programming community is up to with poker. Historically, bots have not been very good at this sort of thing. They're not good at reading humans on such little information—meanwhile humans can read other humans very well because, well, we're all humans. That's a big advantage, particularly when a human can read someone's face. There are microscopic movements someone's face makes when making decisions regarding money. Certainly a computer could be trained to pick up on these, too, but I think that would be pretty weird literally building a poker robot rather than just a wee online bot.

I think this is my new hobby, though, until I can get an apartment with a garage so I can go back to building stuff. I want to write simple bots and monitors if for no other purpose than to keep my AI skills sharp. In this case, I think my favoured approach is going to be a neural network with an input set for each player which will carry a normalized signal from that player's current bet. For those not in the know, a back-propagation neural network is basically a computer simulation (and an inaccurate one, but authenticity is easily trumped by effectiveness) of a connected network of brain cells. Each layer is triggered by the inputs of the previous layer, multiplied by weights. Back-propagation is where, upon a result, the weights are adjusted layer by layer so that the result next time will be closer to the desired one.

Since humans could intentionally play crazy during the first few hands to un-train the net for later, it seems like a pretty bad idea to back-propagate mid-game, but perhaps that would be safe as long as the human players can be trusted not to exploit it too much. Also, the more established the neural network's paths, the harder it would be for a human to exploit its mid-game learning, yet to a certain extent it would be able to adapt its gameplay to each player's style. I've learned in the past that artificial neural networks are best kept small, though. My best one ever was actually not a neural network at all but a single perceptron (one "neuron" of a neural net) with a couple hundred inputs and meta-inputs. I did this mostly as an expedient, since back-propagation is way harder to program than perceptron learning, but it ended up being rock-solid. I'm not even really sure if, at the time, back-propagation was an option since this was for a class.

Oddly enough, a single perceptron with a sigmoid function to introduce nonlinearity into the threshold computation might suffice. At any rate, I am much more experienced using perceptrons than I am neural networks, and I know a lot more tricks with them. The beauty of the way I'm programming this is that I can try both and have them battle against me and against each other! The notes are in my private wiki now . . . I suppose I should get going and start writing the monitor. Wish me luck, space cadets, and I'll see y'all at the tables.

I, for one, welcome our new Ruby on Rails overlords

Ok. So. It finally happened. I am learning how to use Ruby on Rails, and I'm really enjoying it too. Craziness.

Now... I just need to get Brandon to learn Haskell. Then we'll be straight rockin' it!

A Life Without Functional Programming

max
man where the fuck would I be without lambda expressions?
Riddle me THAT, Nick!
I'd be lost and drunk in a gutter somewhere covered in filth, that's where.

ninjatune5
that and swimming in bitches