Unless you've been living under a rock, you have heard that last week Google demonstrated their Chrome OS for the first time in public. They also open-sourced what they have so far as the Chromium OS project. You can watch an overview video here: I followed the event, watched the YouTube videos and even played with a copy of Chromium OS via gdgt . So here are my thoughts on my limited experience so far. It seems like a perfect fit for the netbook market. "Living in the cloud" seems like a great idea for the ability to access your data anywhere. A verified boot system will be a godsend to anyone who has ever had reinstall an OS because it just got 'crufty'. But I don't understand why they have, so far, omitted the concept of a desktop. One of the coolest features of Chrome is its ability to turn a web app into a 'desktop' app , which prompted me to to find Fluid for the Mac . Why force new users of Chrome OS to live in a browser when they could

Recently I've been helping a colleague introduce a dependency on a legacy project that hasn't been "Maven-ized". Often the "easy way" to add a legacy dependency is to throw the JAR into our Nexus repository and be done with it. But this legacy project was a little trickier and is my new poster child for why taking the easy way can lead to headaches and frustration. Your legacy project might have compile-time dependencies you need. Maybe your legacy project implements an external API, or maybe it uses a library and exposes that usage in its API. "So what", you say? "I'll find it at compile-time for my project and I'll add the dependency." Well, now every project that wants to use your legacy project is going to go through the same discovery and embed the dependency in their POM. The right way is to define this dependency in the pom.xml for your legacy project so all dependent projects retrieve it transitively. Your legacy pro

I think its undeniable that one of the hottest topic of this year is health care. While I've been casually following the political discourse, its far from my inspiration for today's post. My one year old son, Wally, had a reaction to penicillin this week and I question why current medicine is still so reactive rather than proactive. Since allergies are something that can change and fluctuate, that led me to also wonder why we don't have more frequent testing too. Standardized testing I'm looking forward to the day when there is a standard battery of tests for allergies and conditions. It's beginning with the prenatal screenings available during both of my wife's pregnancies, but why, for instance, is there no standard allergy testing post-birth? From the perspective of a patient, current medicine waits for a reaction to an allergen which seems so dangerous to me. Continuous diagnostics When can I get my little implant that continuously monitors my blood-wor

In a surprising update to my post earlier this week about what REST is NOT , I just spoke with Rooly Eliezerov , the President and co-founder of Gigya. We had a nice conversation about the goals of Gigya, primarily that they want to aggregate these other social web services and their design philosophy is to mimic Facebook and Twitter's API. I expressed that using GET to change a resource isn't a REST principle either company's API breaks. He was surprised to hear it and said he'd follow-up with his team to validate that and get back to me. Whatever the outcome, I really appreciate that a company with their goals and reach is interested in what little ol' me has to say. It speaks volumes to their passion and customer support.

When I got 'Wanted' on DVD as a gift, it was the first movie on disc (DVD or Blu-ray) that included a Digital Copy. Since my home media setup is all iTunes/Apple-based I easily popped in the extra disc, entered the included key and added the "Wanted" to my media collection in less than 5 minutes. It was beautiful and enlightening. I'm on the side of the fence that copying a movie onto a private home media network is an ethical, though not currently legal, fair use of copyrighted works. Usually ripping a DVD for me is a 'set it and forget' operation using Handbrake that takes several elapsed hours but little interaction. But with the latest copy-protection features of DVDs it can be a hit-or-miss prospect which has caused me to add a few corrupted movies to my collection. And if I want to take the time to attempt to circumvent the copy-protection using Mac the Ripper or RipIt , it's again hit-or-miss and makes the process that much more labor-inten

Update : I spoke with the president of Gigya . Having only familiarized myself with REST a few months ago, I still struggle to explain to colleagues what REST is. My best one sentence summary so far is that it's "using HTTP as it was designed". Not a perfect or even complete summary, but I think it covers the highlights. This week I've been reviewing Gigya's REST APIs for an upcoming project at work. And I've found it to be a shining example of designing an API incorrectly and calling it RESTful. It solidified a couple of REST anti-patterns for me and I wanted to capture them: REST is not RPC, though RPC can be done RESTfully. GET is not for state changes. If you're operation has side effects, don't use GET. The response body is not the only way to send the client information. Don't duplicate information in the HTTP headers in the response body. Authentication is not part of your resource. Don't create a query parameter to do authen