A brief sampling of my work
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
2) Background it
jobs to find the number to …
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 @127.0.0.1. 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
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
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:
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
Verify the setup with
$ exim -bt firstname.lastname@example.org
You should see something like …
email@example.com router = localuser, transport = local_delivery
Now any output from the cron jobs will appear in the mail logs located in
Also note that you can quickly send mail from the command line now without any other tools. Try this:
$ exim -v -odf firstname.lastname@example.org This is a test message.
Just end the message with a newline and then type Ctrl+D. Now check
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?
This portifolio represents a brief sampling. More thorough demonstrations and walk-thrus of my latest and greatest work are available. Just contact me.
You can also find me at StackOverflow where you will find me asking and answering many web development questions.