Thomas Ferris Nicolaisen's blog

Update: I've moved the list of Google Guava resources to  http://www.tfnico.com/presentations/google-guava . This page won't be updated any more, but I'll leave it the way it was. I recently blogged about the Guava Libraries taking over for Google Collections . I figured I'd add a few more pointers to documentation, as the Guava wiki seem to be a bit empty (feel free to copy in these links). Update: More resources (I think if there are any more updates, I'll move this into an editable page on tfnico.com). A four part quite extensive tutorial from Sezin Karli: http://scaramoche.blogspot.com/search/label/guava Google Guava, the easy parts. A basic tutorial that recently surfaced on DZone: http://www.copperykeenclaws.com/googles-guava-java-the-easy-parts/ Old entries: A collection of short snippets (great mini reference for Google Collections): http://blog.publicobject.com/2007/09/series-recap-coding-in-small-with.html Codemunchies' 4 part series o

Update: There's a full list of Google Guava resources on  http://www.tfnico.com/presentations/google-guava . I recently spent some time gathering documentation for our internal use of Google Collections . No more than a few days after quickly presenting Collections at work last week, Kevin Bourrillion announced Guava Release 05 , urging all users of google-collect to replace it with Guava  ASAP, and spread the news (so here we go). If you don't know Guava or Google Collections, they're basically a nice set of Java util classes that you always wanted. I figured I'd have a look through the library's docs, and as I went along, I coded a few easy examples (mostly from the base package). The code is available as a Maven project on github , and I also made a presentation (PDF) with roughly the same examples, seen here: Google guava presentation on slideshare Feel free to extend the examples by forking them on GitHub!

We recently did an internal knowledge meeting about Distributed Revision Control at work. Rather than post my rugged presentation on SlideShare, I figured I'd rather pull together my notes into a blog-post. In our presentation, we were supposed to go head-on-head with Git vs Mercurial (as these were our DSCM finalists). Most of my notes are pro-Git, although I'm equally fine with adopting Mercurial. So, what's the deal with distributed? Basically, instead of having a single repository on a central server, everyone has their own repository. These repository are the same, because internally they have the same identifier-keys (SHAs) and history. Since all bits and pieces are globally understood in relation to eachother, you can bring together changes from two separate repositories pretty easily. Why would anyone want to distribute their repos? You want to let people work without ruining the main line. Consider feature branches. Remember that feature branch we