Go Terk Yourself

Intriguing:

Airlock allows your Mac to lock itself, plain and simple. Using your iPhone or iPod Touch, Bluetooth, and a smidgen of pixie dust, Airlock determines whether you're near your computer.

If, like me, you work in the software world, you will like the following from Joel Spolsky's article on software engineering and schedules at Inc.com:

Software development takes immense intellectual effort. Even the best programmers can rarely sustain that level of effort for more than a few hours a day. Beyond that, they need to rest their brains a bit, which is why they always seem to be surfing the Internet or playing games when you barge in on them.

Jeff Atwood of Coding Horror is the most prolific of the programmer bloggers that I read on a regular basis. His content is hit or miss but today's article, Everything's Fast For Small n, is worth it for this little animated sorting algorithm comparison:

From the GNU Coding Standards:

If you do support Windows, please do not abbreviate it as “win”. In hacker terminology, calling something a “win” is a form of praise. You're free to praise Microsoft Windows on your own if you want, but please don't do this in GNU packages. Instead of abbreviating “Windows” to “un” [sic], you can write it in full or abbreviate it to “woe” or “w”.

On another note, I need to stop suffixing all of my post titles with "Of The Day."

At work I'm doing some old school C programming, which made me think of the OS class I took at BU. Just for shits and giggles I looked up the man page for longjmp(). The best part of the page, by far, is the NOTES section:

longjmp() and siglongjmp() make programs hard to understand and maintain. If possible an alternative should be used.

Understatement of the millennium (and the last millennium too).

There are a couple of cool new technology releases today:

Google Gears is a browser extension providing a set of Javascript APIs for offline web applications.

Review Board is a web based code review application from the folks at VMWare. No CVS support (yet), sadly.

I've been sitting on this for a little while, but Ankit Solanki wrote an Emacs Markdown mode, which includes syntax highlighting, a while back. He even used my buffer preview function!

I got an email today from Amazon Web Services saying that the S3 (Simple Storage Service) prices will change on June first. Now S3 will be even cheaper:

Storage

$0.15 per GB-Month of storage used

Data Transfer

$0.10 per GB - all data uploaded

$0.18 per GB - first 10 TB / month data downloaded

$0.16 per GB - next 40 TB / month data downloaded

$0.13 per GB - data downloaded / month over 50 TB

Data transferred between Amazon S3 and Amazon EC2 is free of charge

Requests

$0.01 per 1,000 PUT or LIST requests

$0.01 per 10,000 GET and all other requests*

*No charge for delete requests

Storage and bandwidth size includes all file overhead

I really need to stop dragging my heels and start backing up my backup server to S3.

It looks like these prices will lower the overall cost for transferring large files (I'm not sure yet what "large" means in this context). Transferring a lot of small files will increase the overall cost.

I just upgraded to version 1.99 of Capistrano, the remote deployment tool most commonly used for Rails projects. This is a prerelease of Capistrano 2.0 and installed easily with the following commands:

sudo gem install highline
sudo gem install -s http://gems.rubyonrails.com capistrano

Highline is a new (at least on my machine) dependency for Capistrano and needs to be installed separately because it isn't present in the gems.rubyonrails.org repository. Following the upgrade instructions I ran capify . in my local working copy to upgrade my recipe setup. I then ran cap -f upgrade upgrade:revisions to upgrade the remote revision tracking files. Sadly, that didn't work very well and I was greeted with a mostly unhelpful little error:

* executing `upgrade:revisions'
/usr/local/lib/ruby/gems/1.8/gems/capistrano-1.99.0/lib/capistrano/configuration/namespaces.rb:175:in `method_missing': undefined local variable or method `deploy_to' for #<Capistrano::Configuration::Namespaces::Namespace:0x69e8a8> (NameError)

It took a little looking about, but I figured out how to fix it: just run this command:

cap -f upgrade -f Capfile upgrade:revisions

All better.

Now, this is interesting.

I had a chance to play around with Capistrano this weekend. It's a cool little tool and it works very well.

This is nice to know: Subversion's default keyword substitution setting is exactly opposite of CVS'.

Subversion will never attempt to perform textual substitutions on your file contents unless explicitly asked to do so.

So that's why -kb isn't ever necessary when svning.

Discovered via. Dr. Nic: ZenTest.

ZenTest scans your target and unit-test code and writes your missing code based on simple naming rules, enabling XP at a much quicker pace. ZenTest only works with Ruby and Test::Unit.

autotest is a continous testing facility meant to be used during development. As soon as you save a file, autotest will run the corresponding dependent tests.

I really should start using Mauricio Fernandez' rcov code coverage tool for ruby.

Over the past, oh, year and a half or so, I've followed the rapid ascension of Ruby on Rails to the top of the web development heap. In the process I read a lot of blog entries, a lot of "Hello World!" introductory articles and a lot of best practice documents. A big part of the thinking behind Rails is Test Driven Development (TDD) - the idea that you should write automated tests before writing code to make sure that a) you know what the code is supposed to do before you write it and b) once the code is working there is a quick, easy way to make sure it keeps working as you further develop your application.

I never really had a chance to try TDD until recently. I started working on a project at work that isn't part of any of our old projects - I got to start something brand new. So I set out to use TDD from the start and I must say that it's going quite well. Writing the tests is forcing me to think carefully about the interfaces of my classes and to separate the project into more atomic parts than I might otherwise.

I'm using JUnit and have an Ant build file set up so that the default target depends on my unit tests. I can see very quickly if a change I make to the code makes things work or not. I don't have to mash together a driver program to exercise my work and then throw it away once it finally works. Sure, I write code to test, and that's analogous to a driver program, but the key is that the test will stick around after I'm finished with it for the time being and the work that I do to test my work for correctness won't need to be repeated by someone else when the program needs to evolve. The tests make nice example usages too.

I'm a convert.

Typo supports Markdown, which is super sweet. I far prefer it to Textile. The only problem with Typo is that I have yet to find a good Emacs XML-RPC mode/library that work with Typo, so I've decided to compose my blog entries in Emacs as Markdown and then add them to the blog when I'm done. This may have the added effect of making me think more about what I'm writing.

I didn't find a good Markdown tool that works with Emacs, and all I really care about is being able to preview the HTML that it will output. The following will do just that:

(defun markdown-preview-buffer ()
  "Preview the current buffer as it will look when run through
markdown."
  (interactive)
  (let ((buf (get-buffer-create "*markdown-preview*")))
    (clear-buffer buf)
    (call-process-region (point-min) (point-max) "~/bin/markdown" nil buf nil)
    (browse-url-of-buffer buf)))

(defun clear-buffer (buf)
  "Clear a buffer"
  (save-excursion
    (set-buffer buf)
    (kill-region (point-min) (point-max))))

M-x markdown-preview-buffer will run the current buffer through markdown (assuming it's installed in ~/bin/markdown and is executable) and open the resulting HTML in your default browser.

Edit: That's much nicer with save-excursion and bare references to point-min and point-max.

There's a whole lot of very cool web music technology in the works right now. Services are popping up to facilitate tour tracking, music blog tracking and seamless music experiences. I don't really have much to say (for now) but here's a good list of some cool stuff.

• Hype Machine - See what music all the cool kids are blogging about.
• Tour Filter - Track the latest and greatest live shows in your area.
• Archive.org Live Music Archive - Descended from the venerable etree, it seems these guys have something new every time I visit the site and an ever expanding hard drive.
• XSPF Music Player - Not so much a web site as a tool used on music sites. Build a play list, point the player at it, listen.

Know of any other cool sites and tools? Toss 'em in the comments.

I've switched this blog to Typo. this is exciting and fun and it means that you can comment without waiting for me to read your email and add it to the post. It only took one day of that for me to get tired of it. All the old content is still here except for the few comments that were left; for that I apologize. But I won't apologize for anything else! Ever!

At my office we do a lot of functional testing – interacting with our software as an end user would. This, in itself, is enough of a problem: much of what we do would be better tested with unit tests or automated functional tests (see Selenium for example). But it’s hard to retrofit comprehensive unit tests into a large, established code base (that wasn’t created with unit testing in mind) and it takes time to convert from written functional tests to automated functional tests. With all the test writing, editing and performing I’ve done, I have a few notes on what you should (and should not) do with your written functional tests.

Please, for your sanity, use a text based file format for your tests. If you don’t, version control (CVS, Subversion, etc.) won’t work for your tests. It’s a good thing to be able to see what changed between revisions of a test and you simply can’t do that if your version control system can’t do a meaningful diff of two versions of a file. Even more importantly, if you use a text based file format, your version control software can merge differences when you update your working copy. With a binary format, only one person can edit a file at once. This means no Word tests!

Use a source format that uses cross referencing and handles (nested) lists automatically. I like LaTeX, but as long as the software takes care of lists and cross referencing for you, you’ll be happy. I’ve spent a lot of time renumbering tests and updating references; it just isn’t a sensible use of anyone’s time.

Make your tests compartmentalized. It’s OK to have a set of setup steps for a set of tests, but if a test changes anything so that it’s different from that base line it should change things back when it’s done. It might take a little longer to run a test that cleans up properly but there is no reason that you should have to track down what the test you ran half an hour ago did to sabotage the test you’re running now.

Ultimately, don’t depend too much on human executed functional testing. It’s useful for end-user facing interfaces but it is too prone to human error to use on a very large scale. Automated tests and unit tests – those where the instructions can’t be misread or steps can’t be forgotten – are easier to maintain, faster and, because of their speed, can be run more often (which will shorten your development cycle and catch bugs sooner rather than later).