IE Compatibility VMs Under Virtualbox

jacob | 08 February, 2012 14:04

As a web developer, I always face the specter of how my pages will appear in IE browsers. We've been able to abandon 6 recently, but 7-10 are still with us, and for some projects I need to test what those users will see.

As a Linux guy, installing Internet Explorer natively is not really an option. Anyone on a non-Microsoft platform hasn't been able to run IE since IE 5.5 or so. However, Microsoft has provided a way to test their browser: by downloading a Internet Explorer Application Compatibility VPC Image.

These "images" are actually virtual machines running a whole Windows operating system. They require some serious horsepower and disk space &emdash; downloading all the VMs comes to a whopping 14 GB — and the trouble doesn't stop there. These images are actually set up to run under Microsoft's "Windows Virtual PC" software. Surprise surprise, Windows Virtual PC is restricted to... Windows.

No matter, the images they use are very basic disk images, and completely supported by Virtualbox, including the open source version included in Debian Squeeze. There was just one point of contention that I ran into: Virtualbox tried to connect the disk image to a virtual SATA controller, which caused the VM to bluescreen and reboot repeatedly.

Once you switch your disk image to a virtual IDE controller, it seemed to work alright. This lets me troubleshoot issues that only appear in specific IE versions, and also let me make sure people still stuck on Internet Explorer can use the pages I develop.

If you still use Internet Explorer, and aren't stuck by policy or some other reason, consider switching to a better browser. There are better options out there — and your local web developer will love you for it.

Linux, Browser, troubleshooting | Permalink | Comments (4) | Trackbacks (0)

Odd __FILE__ Behavior in PHP

jacob | 06 December, 2011 10:44

Just wanted to note a very bizarre bit of behavior that I noticed with some of PHP's predefined constants.

The $_SERVER['SCRIPT_FILENAME'] variable in PHP gives you the currently executing script's file name - no surprises there. It always gives you the name of the parent script, though; so, if you include a file, and reference $_SERVER['SCRIPT_FILENAME'] in that included file, it will give you the address of the including file.

For example, if we execute test.php, and it includes lib.php, a reference to $_SERVER['SCRIPT_FILENAME'] in either file will return "test.php". Here's the code:

  

  test.php:
<?php
echo $_SERVER['SCRIPT_FILENAME'], "\n";
include('lib.php');
?>
lib.php:
<?php
echo $_SERVER['SCRIPT_FILENAME'];
?>
Produces:
/var/www/test.php
/var/www/test.php

The __FILE__ variable in PHP gives you the file name of whatever script it's called in. So, if you call it from an included file, you'll get the file name of the included file.

  

  test.php:
<?php
echo __FILE__, "\n";
include('lib.php');
?>
lib.php:
<?php
echo __FILE__;
?>
Produces:
/var/www/test.php
/var/www/lib.php

 

The bizarre behavior comes with symlinks. On my workstation, I had a symlink for /var/www that pointed to a folder in my home directory. This caused some very bizarre behavior: 

  test.php:
<?php
echo __FILE__, "\n",
$_SERVER['SCRIPT_FILENAME'], "\n\n";
include('lib.php');
?>
lib.php:
<?php
echo __FILE__, "\n",
$_SERVER['SCRIPT_FILENAME'], "\n\n";
?>
Produces:
/home/windigo/test/test.php
/var/www/test.php
/home/windigo/test/lib.php
/var/www/test.php

 

Well, that was unexpected! Apparently the $_SERVER variables report the path that I would expect, where the magic constant seems to dereference (?) the symlink and point directly at the target file.

This caused some strange behavior in the pages I was working on, so I thought I should shed some light on things and write it down in case I ran into it again later. Hope this helps somebody out - otherwise, carry on. :)

Note: Formatting kinda jacked up, will work on that once I get my blog moved to newer, cooler software.

PHP | Permalink | Comments (1) | Trackbacks (0)

Federation

jacob | 25 November, 2011 15:42

After Identi.ca had a rash of issues shortly following the release of Status.net 1.0, I decided that the only logical solution was to take advantage of the open source nature of Status.net, and set up my own instance. Overall, I'd say this is a success; although there are a couple issues that could be addressed.

Dependence on the Mothership

One of the issues you run into immediately after getting Status.net and OStatus set up is that you're still extremely dependent on Identi.ca. I have over 200 subscriptions, and the vast majority of them are still on Identi.ca. When Identi.ca goes down, your instance may still be up and running - but it's not doing all that much.

Not only do you get an empty timeline, but any posts you make probably won't get through to the majority of your subscribers. The method in which posts are synchronized across instances is beyond me; but messages can be, and have been, lost.

Plugin or Bolt On?

One of the issues I encountered when I first set up my instance involved the OStatus plugin - or lack thereof. OStatus wasn't listed anywhere in the admin section, either...

A quick stop into the Status.net IRC informed me that I needed to add the plugin manually via the config.php file, and then run checkSchema.php from the command line to make sure all of the right database tables are present.

...really? It seems like this could be refined quite a bit. Enabling a plugin shouldn't require hacking in PHP and executing shell scripts.

Overall

Honestly, I've had a pretty good experience overall with my Status.net instance, Micro.FragDev.net. Most of the pain points occurred early in the setup, and the community supporting people who run their own instances has been wonderful. Whenever Identi.ca goes down, there are still a bunch of federated users having discussions in my timeline.

It seems like version 1.0 of Status.net might have better been a beta release, with a bit of more polish applied before it was thrown on a huge production system like Identi.ca.

I'll be sticking with Status.net for the time being - and look forward to further development and improvement from Evan and the team.

Server, Content, troubleshooting | Permalink | Comments (1) | Trackbacks (0)

Office Life

jacob | 10 August, 2011 09:56

I don't always put people as my wallpaper. But when I do, I prefer Jezra.

A picture of Windigo in front of his computer at work, with Jezra's face adorning his dual monitors

Stay happy, my friend.

General | Permalink | Comments (2) | Trackbacks (0)

Sixth Sense; IPv6 Summary, Setup on Linode

jacob | 08 August, 2011 15:38

While I'm primarily a web guy now, I graduated college as a networker. I really dig networking stuff, so the fact that I didn't have anything that supported IPv6 bothered me.

If you haven't heard of IPv6 before, you can go over to the Wikipedia Page on IPv6 for all of the information you could possibly desire. If you have better things to do with your life, I'll do a brutal summary for you.

Computers identify themselves on the Internet by using something called an "IP address". The current set of addresses, specified as part of IPv4, look like this: 1.2.3.4. We have about 4 billion (4,294,967,296) of those addresses, and we just ran out of them. That's a bit of an issue. The rest is invisible, don't worry about it.

IPv6 addresses look like this: fe80::f03c:91ff:fe93:5121. A little bit more confusing, but you don't usually use them directly. As for the number of addresses, IPv6 has 340 septillu-frepto-blarkin (340,282,366,920,938,463,463,374,607,431,768,211,456) available, which is at least twice as many as we have now. Since that number is just astronomically large, let's get astronomical. Let's take the Sun - you know, shiny outside thing, middle of galaxy. The sun is about ~300,000 times the size of planet Earth.

If you chopped the Sun into cubes that weighted one gram, you would have enough addresses to give ~300,000 addresses to each cube. That's how many addresses we're talkin' about.

IPv6 really appeals to me on a very basic geek level, because of stuff like that. So, I went about setting it up on my virtual server, hosted by the good folks at Linode. It's a good thing the IPv6 explanation got to be a bit wordy, because this part won't.

First thing I had to do was log into Linode and click on the "Enable IPv6" link underneath the "Remote Access" tab of the VPS in question. This rebooted my server, which now had a brand spankin' new IPv6 address upon booting. If you buy a new VPS from them, I think it's enabled by default and you can skip this step.

After that, I logged into my registrar and added a "AAAA" record to point to my web server at it's new IPv6 address. Your registrar will have to support IPv6 records, but a lot of the good ones do: Gandi.net and GoDaddy both do.

Then I had to.... wait, no. That was it. That was the only change I had to make.

So, if you're interested in being ahead of the curve, and you have a Linode, do it up. It's easy as hell, and will give you an edge over all of the old crusty IPv4-only people out there. Next up, I'm planning on figuring out how to get a IPv6 tunnel set up so I can visit other web sites with IPv6. Stay tuned!

Linux, Server | Permalink | Comments (1) | Trackbacks (0)

1 2 3 ... 20 21 22  Next»

Search

Calendar

« April 2012 »
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

Recently...

Categories

Fragmented Development, abbreviated FragDev, summarizes to the nature of the web; many disparate technologies make today's web. This variety makes development both challenging and enjoyable.

FragDev is also the technical blog of Jacob Hume, a web developer and Free Software enthusiast. On the internet, he usually uses the username Windigo.