bryandunn.com Excelling in excellence since 2001

It turns out the folks at Spin Magazine did NOT want the words “test blah blah” to appear on their RSS feed page. Go figure….

I had to log into a Windows box for the first time in a long time this week and somehow I like it even less than the last time I had to do so. The reason? As always, since MS never complies to anyone’s standards but it’s own, some of my javascript code was not working (in IE7). Of course it was previously tested in Firefox, Seamonkey, and Opera.

Anyway, like everything MS makes, it is nearly impossible to derive any debugging information from. After trying to duplicate the issue one of my users was having, I noticed that a small dialog box in the lower left hand corner of IE was telling me there was an error. Clicking on the box even gave me a line number, great. Viewing the source code and going to that line number however was a different story as the line number being shown relates to the source code in no way. In my search for a javascript debugger for IE7, I found these hideous instructions on how to enable debugging:

1. Run C:\\Program Files\Microsoft Office\OFFICE11\MSE7.exe
2. Wait for MS Script Editor to run and click Debug and install the debugger
3. Close the MS Script Editor when debugger installation has finished
4. In IE->Internet Options, click on the ‘Advanced’ tab and uncheck  “Disable Script Debugging (other)” and “Disable Script Debugging (Internet Explorer)”.
5. Restart IE

The next time you encounter the error, you will get a dialog box asking if you want to debug. Choosing ‘yes’ and ‘MS Script Editor’ for your debugger will give you some debugging ability (it actually shows you the line where the error occurs). Certainly much more complicated than it should be, but anyone who writes javascript has to use it. On a better note, I have an even greater appreciation for firebug.

Note to self: write all your web apps using Google Web Toolkit from now on so you don’t have to worry about browser incompatibilities.

There are a lot of reasons you may want to host your own web site. I have learned a lot about the way the internet works over the years by hosting sites from home. I also like to be able to control every aspect of the site down to the OS level, a benefit you will not get with using a hosting service. I make the assumption in this article that you already have a working webserver you plan to use. If you don’t have that working yet, this will still give you the process and background you need to get going. Here’s what you are going to have to do:

1. Register a domain name
If you are going to host a site, need a name. There are plenty of sites that allow you to register your domain name such as register.com, godaddy.com, etc. One thing you may want to do is create an account with the Dynamic DNS site of your choosing first and see if you can register a domain name through them. You may get a discount if you are also signing up for their services.

2. Sign up for Dynamic DNS (DDNS)
Like registering a domain name, there are also plenty of choices for DDNS services. I use dyndns.com. A couple of sites I have registered were done when it was a free service and I’ve never had a problem. dyndns.com is no longer free, but there are plenty of free ones out there. Once you get an account you will have to add your domain(s). Your DDNS provider will give you some DNS servers that you must assign to your domain. The reason for this is that each DNS entry has a Time To Live (TTL) associated with it. Because you do not have a static IP address and DHCP addresses may change often, the DDNS servers set the TTL for your domain to something much smaller than your typical DNS services do. Each time someone types in http://yourdomain.com, if the TTL has expired since the last time your address was looked up in DNS, your DDNS servers will be asked again for the address instead of using a cached value.

Anyway, long story short, you will have to take the DDNS services specified DNS servers and assign them to your domain via the site you registered your domain at. For example, if you register your domain name at register.com, you will have to log into your account there and edit the settings for your domain. Part of those settings will include primary, secondary and tertiary DNS servers. This is where you will enter the IP addresses or hostnames associated with your DDNS provider.

3. Account for your changing IP
Now that you have a domain name and a DDNS service, you need a way to tell your DDNS provider what your IP address is. Since the IP address given out by your ISP may change often, you will want to install something on your web server that constantly monitors your IP address and automatically tells DDNS when it changes. I prefer to use ddclient, but there are many out there and your DDNS provider probably has some recommendations. The goal of any of these apps is to poll your server/router to get the IP address assigned by your ISP and update the entry for your domain(s) via your DDNS service.

4. Port Forwarding
Most people these days have a router at the heart of their home network. By default, your router isn’t going to know what to do with requests made to http://yourdomain.com. The default http port is port 80. What you need to tell your router to do is forward any request it sees for port 80 to your webserver. You probably want to use static IP addresses for anything on your home network you want to get to from outside so you know they won’t be changing. Most routers have some sort of port forwarding configuration page/file. The syntax will differ, but you want to tell your router that any request it receives on port 80 (you may add others if you want) should be forwarded to the IP address of your webserver.

In the event that your ISP blocks port 80 in an attempt to force it’s customers to discontinue hosting a web page, your DDNS service likely has a port forwarding option as well. This way you can run a webserver on a nonstandard port (not 80) without having to ask your users to type http://yourdomain.com:8080.