However, debugging JavaScript in IE requires that you be able to switch the JavaScript engine between different versions of IE. Many of the IE debugging tools (including Developer Tools) doesn’t replicate the old JavaScript engines. Luckily there’s a tool called IETester that lets you test both the rendering engine and the JavaScript engine of IE 5.5 all the way to the latest version of IE.

IETester is really easy and intuitive to use and lets you test any number of sites and any number of versions at the same time. It also has a feature to disable caching like any good debugging tool should.

Most of the time, all those connections are probably legitimate, in which case, you probably shouldn’t be doing what I’m about to tell you. However, in some cases, sessions just aren’t killed properly giving you a valid reason to use this trick.

To see what active sessions are currently running on the remote computer, open a command prompt and type:

qwinsta /SERVER:<IP_ADDRESS_OF_REMOTE_COMPUTER>


You might get something like below:

Look for those sessions with the type “rdpwd”. At this point, you’re just going to have to pick a session to kill. Once you’re made your decision, run:

rwinsta /SERVER:<IP_ADDRESS_OF_REMOTE_COMPUTER> <ID_OF_SESSION_TO_KILL>


These commands require you already be authenticated to the computer you’re trying to log on to. If you’re not, the commands will fail. Just open a UNC path to the computer and authenticate through that. Then you can run the commands again.

And that’s it, you should be able to remote in without exceeding the maximum connections now.

Enjoy and use wisely. Remember, with great power comes great responsibility.

Personally I’ve never really used Winamp (having an iPod, I mostly use iTunes). However the wireless syncing service it offers is too appealing. After all, who doesn’t hate having to go hunt down that USB cord every time and go through the hassle of mounting, etc., etc. Especially because I have the Samsung Vibrant, and silly Samsung, thought they could kill two birds with one stone by giving you a wall adapter that you plug the USB cord into in order to charge your phone. Of course this means I have to walk all the way into my room, grab the cord from off my wall, and walk all the way back to my computer just to hook it up. Painful I know.

Anyway, just a word of warning for whoever’s using the Winamp Android Beta and have wireless sync enabled. The sync service, called “WifiSyncService”, is a huge battery killer. My phone pretty much died within half a day with that service enabled. So if your phone is suddenly dying quicker than usual, check to see if that service is running and kill it. If you’re using a Task Killer, be careful, sometimes it doesn’t kill the service.

Otherwise, it’s an awesome app and I really look forward to the next version.

A cover letter is nothing more than a way to sell yourself to your potential employer. Why should this be difficult? After all, if you’re applying for a job, you obviously think you can do it. There must be something that you possess that brought you to think that you can do the job. Whether it be a skill, a quality, a trait, anything. You know better than anyone what you’re capable of. You know better than anyone why you think you can do the job. If you can explain that in your cover letter, you’re good to go. I mean, if you can’t explain why you think you can do the job in a cover letter… how do you expect to explain it in an interview? On the other hand, if you don’t think you can do the job, don’t bother applying. If you’re not convinced that you can do the job, how are you going to convince your employer?

Hope that helps.

*UPDATE*
Just found a cover letter done by somebody for a job at Penny Arcade. Chances are you’re not gonna do anything like this but still fun to look at.

Now Google has some pretty good tutorials so I’ll mostly use their material but I’ll make sure to make comment on where I ran into problems.

NOTE: I am using Windows 7 Ultimate 64-bit with a 64bit JDK so all the instructions here will be for Windows 64bit.

If you haven’t already, you’ll need the Sun Java JDK, download it here. I am using the 64bit Java SE JDK 6.

To start off, you’ll need to download the Android SDK. Note that you can also follow the instructions on that page to get your environment set up.

Next you’ll need Eclipse and the Android Development Tools plugin for it. If you already have Eclipse, click here to figure out how to install the plugin. If you need Eclipse, you can download it here. I think they recommend using the Eclipse for Java or Eclipse for RCP/Plug-in but since I’m using 64bit Windows AND 64bit JDK, I had to download the 64bit version of Eclipse Classic (you may have to do the same if you’re using a 64bit OS).

After you have Eclipse, follow the instructions from the link above to get the ADT plugin.

Once you get Eclipse running, you’ll need to download some extra SDK components (for sure at least one Android Platform). You can go here to find out more.

Once you have a platform, you’ll need to create an Android Virtual Device. You can do this from the Eclipse “Android SDK and AVD Manager” (From Eclipse, Window > Android SDK and AVD Manager).

Once everything is set up, follow this tutorial to get started with an Android Project. Note that the tutorial tells you how to create a Virtual Device from the command line.

Here’s where it got tricky for me. After following the “Hello, Android” tutorial and clicking “Run”, nothing happened. No emulator, no nothing. If you look at the console, you may get an error like “emulator: could not find virtual device named <DeviceName>”. After some time on Google, I was able to figure out the problem. What’s happening is that Eclipse is looking for the Virtual Devices to be in the “C:Users<User>.android” folder but for whatever reason, it may not have gotten created in that folder. A solution is to create a symlink. First find out where the Devices got created. You can do this by opening the Android SDK and AVD Manager, clicking on the Virtual Device and click “Details” (for example mine was “G:.android”). Once you get the path, open up a command prompt, cd into “C:Users<User>” and run the command “mklink /J .android G:.android” (except changing the second path to whatever yours is). Then if you try to run the application again, it should work.

And there ya go, Android environment set up and good to go (hopefully anyway, I stopped everything I did once I got things working to write this post).

If you’re a web developer then chances are, you have to debug sites in Internet Explorer. However, if you’re running Windows 7 (or even just Internet Explorer 8), you probably have some sort of separate test environment set up so you can debug in IE7 (at least I did). Well let me tell you, that’s not necessary.

IE8 comes packaged with something called Developer Tools, which is similar to Firebug for Firefox but no where near as good. However Developer Tools does come with one handy feature: the ability to switch your browser mode to IE7.

All you have to do is open IE8, open Developer Tools (Tools > Developer Tools or hit F12), and from the menu bar, you can select your Browser Mode (IE7, IE8, and IE8 Compatibility) as well as your Document Mode (IE7 Standards, IE8 Standards, and Quirks Mode).

Voila! Goodbye separate test environment. Of course, you’ll still need some other method if you’re debugging for IE6. If you are debugging for IE6 however, well, I just feel sorry for you.

My job is to cover student startups, mostly from within the University of Minnesota-Twin Cities area. I have a few leads that I’ll be working the next few weeks but if you are a local student Minnesota startup or if you know of one that would want to get their name out, contact me and I’ll be glad to talk to you.