It all started when I completely rebuilt my Eclipse environment, using the latest version, Indigo, so that I could install the wonderful PhoneGap plugin. I installed the latest version of all of my plugins, including Subclipse, and I also installed the latest CollabNet subversion binaries. Subclipse's wikipage for JavaHL says that if you install these binaries says that you shouldn't have to do any further configuration to get Subclipse to work, but in my case that turned out to be wildly optimistic, to say the least. Each time I tried to use a Subclipse feature, I was presented with the dialog that I gather all too many people are familiar with: "Unable to load default SVN client". A search across the Googles for this sentence gave me a lot of results, almost all of which referred to confirming the path variables in your .profile file or your eclipse.ini file. I edited, I confirmed, I failed. Again and again. I even tried to install SVNKit, but their subversion client doesn't support the svn client version of 1.7.x that Subclipse was looking for. Aargh.

The binaries that Collabnet installs have version numbers of "1.0" in their filenames, so you really can't tell what version they are. Instead you have to run "svn-javahl --version" to get that information. And what do you know, I had version 1.6.x.

So the final solution?

1. Install MacPorts if you don't have it already.
2. Use MacPorts to install the JavaHL bindings (you'll get the latest version by default):
   sudo port install subversion-javahlbindings

"ClassroomWindow addresses an absolutely critical missing element in education -- understanding what works, and for which kids. Sounds obvious, but it doesn't exist (yet). Our mission is to provide transparency into the effectiveness of educational texts, tools, and resources. It is Yelp + Consumer Reports for education products and services, combining crowd-sourced input from teachers and others on the front-lines of education with expert opinion and student data."

ClassroomWindow is preparing for a private beta later this year. If you or others you know (teachers in particular) would like to have their voices heard on which products work and which don't, please sign up for the beta at www.classroomwindow.com, check them out on Facebook, and follow them on Twitter.

@variables { elementcolor: black; }
#selector1 { color: var(elementcolor); }
#selector2 { color: var(elementcolor); }
#selector3 { color: var(elementcolor); }

I can't believe there are people who say that CSS variables aren't needed or wouldn't be useful. These folks tend to have two arguments:

• Variables make CSS too complex, and more like a programming language.
  I disagree with this one heartily. Variables would only make CSS more like a programming language if the developer felt like using them. If someone didn't want to use variables, the wouldn't need to touch them. And, what's wrong with letting a language evolve? HTML certainly has, and it's gotten more like a programming language since it came into widespread use.
• You don't need variables if you use your selectors correctly.
  This is a better argument. It's the idea that you'd have a bunch of selectors all in one comma-delimited list with one declaration after it-- color, for example, or font-family. But that kind of arrangement seems almost as contrived and complex as the use of variables. Variables, at least, let you organize your declarations where you want them, instead of forcing you to separate them in a predetermined manner.

Just as I anticipated, there was a lot that I could accomplish soley through a browser, some significant things that I can't yet do on a Chromebook, and, notably, some tasks I chose not to do, mostly for security. I think that most of those issues can be overcome in the future. Here's a list of what I could and couldn't do:

What I could do

• Email
• Calendar
• IM
• Writing blog entries
• Salesforce CRM
• Taking notes (Evernote, Scratchpad)
• SSH (aka Telnet)
• Calculator
• Phone calls (Google Talk)
• Video calls (Google Talk)
• Banking

What I chose not to do*

• Code editing
• FTP
• Versioning

What I couldn't do

• Use our FF/IE-only content management system (CMS)
• Perform browser testing (of course)
• Participate in Webex meetings (requires application installation)
• Use our office phone system software (Cisco "CUPs")

* So why did I choose not to edit code or use FTP on my Chromebook? The answer is that to do so, I'd need to have my source files and FTP credentials stored somewhere in the cloud, which is definitely neither good sense nor compliant with our corporate security policy. I'll start using these on my Chromebook once I can run a web-based code editor, FTP client, and SVN client on our own servers so code and credentials never leave our network.

Google's pitch to users is "Chromebooks are built and optimized for the web, where you already spend most of your computing time. So you get a faster, simpler and more secure experience without all the headaches of ordinary computers." I was pretty curious to see whether this premise was true, and now that I've taken delivery of my own Chromebook, I have the perfect chance to find out: just how much of my work can I perform completely through a browser?

I'll report on what I find later today, but my guess is that while I'll be able to spend the bulk of my time on the Chromebook (email, chat, web browsing), my most important tasks (editing code and FTPing files) will still need to happen via applications on my MacBook Pro laptop.