Month: May 2013

Ok, not the company, just anybody who was ever involved in their web browsers.

I’m writing a web application. I’m trying to make it modern with good UX (User Experience). Sometimes my boss’s decisions go against that desire, but I do what I can. Real world requirements aren’t always as straight forwards as the stuff you read in “Design For Hackers”.

So this week, I did a new part of the app. It was finally working the way I wanted to on real browsers, so then I turned to IE testing. It didn’t work right on anything older than IE 10. After two days of screwing around, I had a workaround that worked ok on IE 8 and 9 – it didn’t look too much worse than it does on real browsers, just different. That’s good, because the boss says that IE 8, because it comes on Windows 7, is the corporate standard and I don’t have to support IE 6 or IE 7. So I upload my test code to their server and clicked on the link, and it looked like a dog’s breakfast. Turns out that Microsoft, in their infinite wisdom, have decided that when something is on your intranet, should run in “compatibility mode”, which basically means it acts like IE 7.

IE is supposed to recognize a header, “X-UA-Compatible”, which is there so the web developer can tell the browser which version of IE it’s written for, but because Microsoft are a bunch of idiots, they decided that the “use compatibility mode on the intranet” setting should override this. I can’t think of a single reason for this, other than sheer idiocy.

On StackOverflow, a user offered up a “simple” workaround – all you need to do is get every web server on the corporate intranet except yours to change to serve up a “X-UA-Compatible” that specifies compatibility mode, and then the sysadmins to change the default setting on the Active Directory servers (and probably Citrix as well) to make sure people’s logins allow the setting from the web server to take precedence over their login settings. That of course pre-supposes that you can even find every web server on the corporate intranet. And find their owners. And get those owners to sign anything without 12 years of running around making business cases and getting manager approvals. And then get the web servers actually configured that way.

I think it would just be faster to wait for every computer in the company to be replaced by one running a better OS. Or the heat death of the universe.

So off I go to try to find a work-around that works on IE 7 as well.

Debian stable just updated. Usually when Debian drops a new “stable”, it means its bombproof as hell and tested out the wazoo. This time, I’m not so sure that is true.

First candidate is a virtualbox that I use to keep some client data on an encrypted partition and safer than just leaving it on my desktop machine.

First attempt threw some errors about problems with “default-jre” and “openjdk-6-jre”, but I don’t use java on this virtualbox so I just removed them.

Second attempt gave a huge problem because of some conflict between CPAN installed Perl modules in /usr/local/share/perl/5.10… and the new 5.14 modules. It seems to me that the installer should just remove /usr/local from the Perl paths and ignore any locally installed stuff.

I tried removing that directory manually, but by that time the install was so screwed up that I actually went back to a clone I’d made of the virtualbox and tried again. This time I removed the JRE stuff and moved /usr/local/share/perl out of the way. The upgrade went much more smoothly, except the screen goes totally blank for a long time during the upgrade, and when it’s done the reboot prompt is showing empty boxes instead of letters. Fortunately I guessed correctly as to which box was the “ok” button.

After it upgraded, I discovered that Postgres 8 was marked as deprecated, so I did a pg-dumpall, removed it, imported the dump into Postgres 9, and all was well, no problems. Then I had to get RT working again, so I used aptitude to install as many of the packages as I could that formerly had been in /usr/local/share/perl. The only one I couldn’t find a deb for was Plack::Handler::Starlet, so I let CPAN install it.

Once that was up and running to my satisfaction, I figured it was time to move on to my linode. The linode hosts my navaid.com databases and a bunch of mailman mailing lists, and not much else. Remembering the Postgres 8 to 9 thing, I made sure to pg-dumpall before I started. There were no files in any local perl directories, and no jre, so I was good to go.

As it was updating, I saw it removing the Postgres 8 version of postgis. Oh oh, I thought, that’s not good. I’ve discovered in the past that you can’t simply recreate a postgis database using a pg-dumpall dump. So after the upgrade, I of course tried to install postgis for PostgreSQL 9, and once again panicked as it dragged in a ton of X11 crap I don’t need. Then I tried and failed to do a restore of the dump file. What I ended up doing was

1. creating the database user for that site
2. creating the databases for that site
3. running the scripts that come with postgis for creating the spatial functions
4. coping the pg dump file, and cutting out anything related to other DBS, and cutting out the drop and creation of these DBS.
5. running this cut down version of the dump file
6. making another copy of the dump file that includes all the other DBS, including the drop and create commands and running it.

Everything seems to be running now.

Some time I’ve got to go on and upgrade my xen host and guest oses on my colo box, but I’m really reluctant to do that one because if something goes wrong, I’ll have to drive in and try to fix it while standing in a freezing cold server rack farm.