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()andsiglongjmp()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 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.
I had a chance to play around with Capistrano this weekend. It's a cool little tool and it works very well.
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.
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.
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!
This morning I woke up to an email from Amazon. I finally have my EC2 account! Hooray for me. Now I just need to find out why making a large (greater than 60GB) S3FS freezes my machine.
Cross posted from Today in Brief.
Ars Technica has a chilling summary of the current problems with electronic voting.
As the article states, even if we assume there is no willful tampering being done with these electronic voting machines, we’re in for a terribly shitty midterm election in those states/precincts using the machines. Poll workers are poorly trained, procedures for making sure the correct votes are recorded and counted are not in place, the machines can easily and undetectably tampered with, there is no dependable audit trail.
Electronic voting is not a panacea for the problems we saw in 2000. Voting problems are addressed with procedure, including auditing (paper trails) and vote verification (preferably at the polling place AND after you’ve gone home). As we see in too many places these days the focus of current voting system work is on presenting a facade to make it appear that our votes are secure and will be counted correctly. Unfortunately it seems that, in many places, that facade will break down when it is least convenient for the electorate.
A side note: the eminent cryptographer Ron Rivest proposed a damned good verifiable voting system, the best part of which is that it uses no fancy math and no computers to cast the votes. Read the paper, as much as you can, it’s an incredibly simple scheme that would work very well.
Amazon announced the beta of Amazon Elastic Compute Cloud (EC2) today; it’s pretty exciting. The basic premise of the service is that you can get any number of virtual machines and pay for what you use as far as the number of machines, disk space and bandwith go. I’m absolutely bursting with different ways to use this technology, from web hosting to streaming radio to batch processing to QA.
I signed up for an Amazon Web Services account today, hoping to play, even if only a little, with EC2, but the beta is full already. I am, however, on the list of people waiting for spots, and I’ll still have a chance to play with S3 (which I wrote about, if a bit tangentially, in the context of JungleDisk) in the mean time. Cool stuff is coming out of Amazon, cool stuff.