When developing a web application and quickly iterating, it’s imperative that you can quickly test changes on a multitude of browsers and platforms. If you want coverage on IE6-9, the latest Chrome, the latest Safari, the latest Firefox, and maybe the FF 3.6+ branch, you will need several machines. Fortunately, they can be virtual, and those machines can run more than one browser.

With all of this in mind, I set out to set up the following automated, distributed testing grid on one decent physical machine running off a external drive.

So what’s the set up and why?

Virtual Machine 1: Win7
IE9, latest Chrome, latest Firefox
Running as both the hub with multiple web drivers

Virtual Machine 2: XP SP3
IE8, FF 3.6

Virtual Machine 3:

Virtual Machine 4:

Physical Host Machine: Mac OS X 10.6.8, Quad Core, 8 GB
Mac Browsers (obviously):
latest Safari, latest Chrome, latest Firefox, Firefox 3.6+

More notes to come …

I was recently copying some very large files from one remote machine to another. However, I had forgotten to use the nohup command and would need to leave before the transfer finished. Simple solution:

1) Suspend the process Ctrl+z
2) Background it bg
3) jobs to find the number to …
4) disown

Another problem that I ran up against was transferring large files and being disconnected. Since scp does not support resume, you have to use it in conjunction with rsync. Furthermore, the problem seemed to be an overload of a home router, so I needed to rate limit it. The final cmd:

rsync --partial --progress --bwlimit=500 --rsh=ssh orig_file user@host:~/dest_file

I love the command line especially when working remotely. Yes, logmein, vnc, teamview, etc. are useful, but when you need quick access or powerful command-line tools, nothing beats the shell.

The problem is what to do when it fails. Diagnosing connection problems over hostile networks with firewalls, packet filtering, and more can be a pain. I recently discovered 2 useful tips when trying to diagnose the client and server interactions. First, run ssh with -vvv. Second, run sshd with -Dddde. This gives you all the debugging info you need.

In this particular case, sshd appeared to starting correctly, and I could ssh @localhost but not @ The culprit turned out to be FreeSSHD had already bound port 22. Starting sshd with -Dddde revealed this problem. Then I simply found the guilty process by netstat -ab. When I had run netstat -an before and saw the system listening on port 22, I had incorrectly assumed it was sshd. =P

I was recently watching a Goggle Tech Talk titled How To Design A Good API and Why it Matters. Joshua Block had this great summary that I wanted to share …

Characteristics of a Good API
- Easy to learn
- Easy to use even w/o docs
- Hard to misuse
- Easy to read and maintain code that uses it
- Sufficiently powerful to satisfy reqs
- Easy to evolve
- Appropiate to audience

Recently, I’ve had innumerable decision points for a library that I’m working on. I’m hoping that turning these characteristics into questions will help me improve the code.

So cygwin allows you to port all the great *nix utilities to a Windows environment, and that’s useful because 1) there are some many handy tools and 2) you can write scripts or tasks once and use them everywhere (Unix, Linux, OS X, Windows).

Today, let’s discover how you can get two of the most useful tools (automated tasks and mail notification) installed in less than 5 min.

Since the typical Windows box was not designed as a server, scheduled services/tasks and mail transfer agents are not commonly implemented/installed, but we can quickly fix that.

First, install the exim and cron cygwin package and then run exim-config. You can accept most of the defaults. The only change that you might want to make is to set up a primary hostname. I use “mail.local”. Be sure to add that to your hosts file (%WINDIR%\system32\drivers\etc\hosts), too: mail.local

Next since you want mail to be deliverable for users without accounts, we need to disable the check_local_user option under the localuser router in /etc/exim.conf.

Verify the setup with

$ exim -bt test@mail.local

You should see something like …

   router = localuser, transport = local_delivery

Now any output from the cron jobs will appear in the mail logs located in /var/spool/mail.

Also note that you can quickly send mail from the command line now without any other tools. Try this:

$ exim -v -odf test@mail.local
This is a test message.

Just end the message with a newline and then type Ctrl+D. Now check /var/spool/mail/test.

Now for cron. Run cron-config accepting the defaults as needed. You can quickly test the setup afterward by editing your crontab.

echo '* * * * * echo hi' | crontab -

In less than a minute (and every minute thereafter until you change it), you should see the output in your mail spool.

And we’re done. Now just set up whatever cron jobs you want on whatever schedule you want. That wasn’t so bad, was it?