More in-depth training that goes under the hood of an actual application would be great.  And if anyone attends an AWS bootcamp in the meantime, I’d love to hear how it went.

Nearly three hours into the class, we’re still on introductory slides and there’s confusion among attendees about how Elastic Block Storage works.  Also, the network here has slowed to a crawl so even the presenter’s online examples are being impacted.  Usually, at conferences, I forgive the inevitable network issues that arise when a roomful of developers go online at once.  But when you charge for a class focused on Web-based technologies, I think it’s a requirement to be prepared to handle the traffic.

Still, I’m hoping things pick up after lunch and that we actually into the examples.  The goal is to get under the hood of a video sharing application that runs off EC2, S3, and other Amazon Web services. Fingers crossed.

Update: We got a little further after lunch, and finally got a little more hands-on with some of the tools available for administering EC2 and S3.  So we practiced launching Linux and Windows server instances, transferred files to S3 buckets, and mounted EBS volumes.

But we were clearly short on time and had to skip most of the code examples.  In particular, we never got to the video sharing application — which was the entire reason I signed up.  While administering AWS is a necessary step in developing and deploying applications on Amazon’s infrastructure, it’s hard to justify spending $175 and the related costs of an entire day away from the office only to come back with no real insight into the architecture of an AWS application.  The session was touted as a “Developer Bootcamp” after all.

What could the presenters have done differently?  Four things:

1. Skip the 45-minute-long “team building” exercise at the beginning of the day.  For a one-day session during which there is no other group work, there’s no need to “team build.”  If you want to encourage people to meet others, a 10-minute round-robin of people introducing themselves and saying why they are attending would suffice.
2. Don’t switch the software requirements once attendees arrive (as our presenter did.)  We wasted valuable time as everyone tried to download the new code samples and consequently brought the entire network to a halt.  People should arrive at the session with all the necessary software installed and ready to go.   If people need help with configuring the software, maybe ask them to arrive early during the breakfast portion of the day?
3. Ensure that the network can handle the traffic.
4. Don’t spend so much session time answering tangential questions.  The goal of the day is to provide a developer-level look at how one can build an application on AWS.  Attendees who have specific questions about AWS or need clarification on things that aren’t core to the session should be encouraged to re-ask their questions at lunch.

Hopefully the presenters will improve in subsequent bootcamps.  Based on the peformance at this one, however, I can’t recommend it to other developers.

Update 2: Amazon has refunded the $175 I paid to attend the class.

The release builds on the work started by Tao Starbow of Starbow Consulting, which provided regular-expression-based search-and-replace functionality for CCK fields.  Version 2.0 adds an undo option, plain text searching in addition to regular expression searching, whole-word matching, and the ablity to limite searches to certain node types and nodes with certain taxonomy terms, among a half-dozen other features.

Many thanks to Jason Salter of awesome Drupal consulting firm FivePaths for co-writing version 2 with me, and to FivePaths for supporting development.

The module is currently listed as an alpha1 release, but we’ve been testing it heavily and it’s looking pretty solid.  I’m looking forward to seeing others use it and to getting feedback on what works, what doesn’t, and what we should add in future versions.

Without a doubt, Lala has replaced iTunes for managing and playing my music.  Why?

1. Lala lets me listen to any song in its entirety for free the first time I access it.  You can queue up an entire album and listen to it before deciding to buy.  ITunes only lets me listen to 30 seconds of a song.
2. Lala lets me see what other people are listening to, including those who have just listened to the same thing I have.  Chances are, we like the same music.  And if we do, I can choose to “follow” them and listen to new stuff they find.  This is the best use of online social networking I’ve seen so far.  I’ve already discovered five new bands I like.
3. Lala lets me “upload” my entire iTunes library to my Lala collection so I can access it from anywhere on the Web.  (You’re not actually uploading the files, just a list of them — Lala then streams their own copy when you access a particular song.)  ITunes limits the number of computers on which I can listen to my music.
4. If I like a song I find on Lala, I can add it to my Web collection for $0.10 and listen to it in its entirety whenever I want, as many times as I want.
5. If I do want to put a song on my iPod or burn it to disc, the cost is $0.89 — or $0.79 if I already paid the $0.10 to add it to my Web collection.  In comparison, iTunes songs cost $0.99.
6. The songs I buy at full price are totally-DRM-free MP3s.  That means I can burn them to disc as many times as I want, put them on music players other than the iPod, play them on as many computers as I want, and I’m not screwed if the service goes out of business one day.  Apple’s iTunes can’t beat that.

You should check Lala out.  And no, I don’t get any kickbacks for recommending the site.  I just thought you might be interested in what the future of music looks like.

How did the Governor’s office arrive at that figure?  The office figures it’ll take a programmer 6 hours to assemble the emails (presumably recovering them from archives), two hours for “security” checks, and five hours of actually searching through the emails for a given topic.  Multiply that times $73.87 per hour and times the 16,000 full-time state employees in Alaska, and you get $15,364,960.

Hopefully, the AP is pushing back on this, because the number is bullshit.

The Cheaper Way to Do It

First, even if you accept that it takes 6 hours to rebuild archives from backups and various sources, and even if you give the office the benefit of the doubt on the “security” checks (whatever that may entail), it shouldn’t take a programmer 5 hours to run a lexical search.  You start the search and walk away until the results come back.  Perhaps you have to refine the search a few times, but at some point you should have it down pat and the rest should be scripted.

Next, you don’t need to search the emails of 16,000 employees.  Assuming the office’s IT staff kept their SMTP log files, one could run a search on them to develop a list of people who traded emails with Todd — all without having to go through the emails first.

But realistically, you don’t even need to do that.  Though Todd Palin spent “about 50 percent of his time” in the Governor’s office, it’s not likely that he emailed the majority of those employees.  More likely, he traded most of his emails with Sarah Palin’s staff, the public safety commissioner, and other key state officials.  Provide the office with a list of, say, 200 officials who likely received emails from Todd Palin or sent some to him, and you’ve suddenly cut the cost to under $200,000.

Push the office’s IT staff to admit that they don’t need 5 hours of search time per email account and you can lower the costs even further — to about $120,000.

That the Governor’s office quoted $15 million is either a sign that its IT staff is incompetent and wasting state resources, or that the office staff is trying its damndest to foil legitimate public requests to find out exactly what role Todd Palin played in state affairs.

It’s also a sign that it’s time to bring government into the modern era.  Increasingly, requests to view the emails of politicians in office will be the way to provide transparency into our government.  It’s time to demand that government offices put in place systems that make it easy to recover and search emails — and that officials be prosecuted for circumventing these systems by using non-government accounts for official business.

I guess they figured the system wouldn’t be abused because only the staff members would know the phone number.  What they didn’t plan for, however, was telemarketers accidentally stumbling across the system as their auto-dialers try every possible phone number.

So imagine my surprise — and everyone else’s there at the pool the other day — when in the middle of the usual lap swim time a pitch for carpet cleaning services suddenly blasted out from the speakers.

Moral of the story? Just beause you think you’ve hidden some technical feature where no one will find it doesn’t mean they won’t.  If it’s important to you to hide something, use real security measures like a password.

The session is on Saturday at 11am.  Drop by and check it out if you’re attending.  For those who can’t make it or didn’t register before alll the spots were gone, I’ll post my notes here.

It’s unclear if it’s a Comcast problem, a Facebook problem, or something else.  But Facebook does plan to get rid of the .new. subdomain now that the new profiles are rolled out, which would require some DNS modifications. And given the company’s track record, I’m not entirely ready to give Facebook the benefit of the doubt.

1. The Governor of Alaska uses the free Yahoo email service for work-related emails; and that
2. Yahoo uses really bad security practices for its password recovery system.

Indeed, it’s the latter point that makes the former all the worse.

If the so-called hacker who accessed Palin’s emails is to be believed, Yahoo allowed the intruder to reset the password on Palin’s account simply by answering some security questions.  And sure enough, that’s exactly how Yahoo’s password recovery system works: You answer some simple questions like “Where did you meet your spouse?” and Yahoo checks to make sure your responses match up with the answers you provided when you first created your account.  In other words, these questions serve as a secondary, “backup password.”

The problem with security questions like these is that they’re all too easy for almost anyone to answer.  This is especially true if you have information about your life published on the Web (as Palin found out) — or, more likely, if you publish that information yourself on blogs, social networks, profile pages, and so on.

So what should Yahoo have done instead?  Or, more importantly, if you’re developing a Web site that needs a password recovery feature, what should you do?

The Better Way to Do It

The best option: Don’t allow users to change their passwords online after answering the security questions, but rather send an email containing an password change alert and instructions to the user’s alternate email address.

This is more secure because any attempt to change your password results in you receiving notice of it — via a method only you have access to.

Second best: Send the alert and instructions to the user’s cell phone via text message or voicemail.

This is handy in a case like Yahoo’s, where the company is providing email accounts to users who often don’t have existing accounts that they can list as an “alternate.” (Although, it looks like the current iteration of Yahoo Mail does ask for an alternate address upon registration.)

If you just can’t ask your users for an alternate means of notification: At the least, you could ask more personal backup questions that can’t simply be looked up online.  For instance:

• In three words, what’s your biggest fear?
• In three words, what is your earliest memory?
• What’s your favorite word and least favorite word?

These don’t sound as nice as “What’s your ZIP code?” but unless you’re a no-holds-barred blogger who has published a post containing the words “my worst fear is…”, most other people truly won’t know the answers.

And even if they do know you well enough to have an inkling, they’re still not likely to phrase the answer in the same way.  After all, “Big hairy spiders” is not the same as “big scary spiders.”

String a few of these questions  together and you’ve got a much higher barrier in place — one that’s less likely to lead to an embarrassing break-in when your site’s users are running for the second highest office in the land.

A Footnote (Helping Users Choose More Secure Answers)

Bizarrely, Yahoo’s only public response so far to the Palin break-in has been to repost an item to the Yahoo Mail Blog about choosing secure passwords.  It doesn’t address the problem, since reports so far say that Palin’s password was just fine — it was the backup security questions that were breached.

So what might Yahoo do instead (until it rolls out a more secure password recovery feature)?

Advise users to choose the most difficult backup security questions available and to pay attention to how easily others might be able to find the answers.  Your “favorite sports team” is too easy to guess — the answer usually has to do with where you live, lived, or went to college.  However, the “make of your first car or bike” is harder for others to know.

And finally, advise users to lie. That’s right.  You don’t have to answer the backup security questions truthfully.  No one’s checking up on your responses.  If you must use “favorite sports team” as a question, then respond with the name of the coach of that team.  Do that consistently whenever you see that question on other sites and you’ll have a good chance of thwarting most would-be intruders.