Here is what I publish through this blog's RSS feed. It's not bound to what I actually write...
This was created using Wordle and is licensed under a Creative Commons By Attribution License.

Generated by Wordle and published under a Creative Common "By Attribution" license.

I have been back at Sun for almost a year now. Still, there are a few things that I have yet to take care of. Things like unsubscribing from the Sun Alumni Yahoo! group. Or moving my RSS feed back to blogs.sun.com.

Well, one of these things have been taken care of since I am now syndicated on blogs.sun.com instead of alumni.sun.com. It will be interesting to see how this affects my FeedBurner numbers...

I just pushed REm 1.5.0 for NetBeans 6.x. This releases adds the following features:

• Bundles ZK 3.0.5
• Provides basic syntax highlighting for ZHTML files.
• Provides basic syntax highlighting for DSP files.

You can download the plugin from Sourceforge.net.

Many Java projects accumulate Jar files. Their numbers just grow until you are not exactly sure why or whether a Jar file is still in use. Traditionally, you answer the question of whether you still need a specific file by removing it from the class path, attempting to build your project, deploying it and seeing whether the application works or not.

Kyrill Alyoshin has released a beta version of his loosejar project. The goal is to determine what jar files are not being used by your application. It does so by analyzing what classes are loaded by which class loader. The result is a report that is presented via JMX or through the console (once the VM is shutdown).

The project is hosted on Google Code and it is released under the Apache Software License v2.0.

The FizzBuzz programming interview question raised it's head again. I've managed to resist the temptation to implement it in any languages so far. Until this morning that is...

So I fired up the Groovy Console and played a little. A nice feature of the console is that it displays a history of the scripts it ran. This allows me to present an evolution of my FizzBuzz program.

I first started with a rather naive implementation:

              (1..100).each { 
                def out = "" 
                if ((it % 3) == 0) { out += "Fizz" } 
                if ((it % 5) == 0) { out += "Buzz" } 
                if (out == "" ) { out = it } 
                println out
              }
              

Not bad for something that I came up with in about 10 minutes. It doesn't really take advantage of Groovy's features though. So I refined it a bit by using the ternary operator:

              (1..100).each {
                def out = (it % 3) == 0 ? "Fizz" : ""
                out += (it % 5) == 0 ? "Buzz" : ""
                println (out == "" ? it : out)
              }
              

This is a slight improvement over the first version. I still didn't feel that this was Groovy enough for me. I decided to play with the List collect method. This applies a closure to all items in a collection. The first pass was the following code segment:

              println ((1..100).collect {
                def out = (it % 3) == 0 ? "Fizz" : ""
                out += (it % 5) == 0 ? "Buzz" : ""
                out == "" ? it : out
              })
              

This ended up printing the list returned by the collect method. Really close, but not quite what I was hoping for. After all, the challenge is to print the results, not quite a string representation of a list. It was easy then to go from the code above to the code below:

              (1..100).collect {
                def out = (it % 3) == 0 ? "Fizz" : ""
                out += (it % 5) == 0 ? "Buzz" : ""
                out ?: it
              }.each { println it }
              

This printed the list just like the first pass. It's definitively Groovier (in my opinion) than the original implementation. It still does fall short of the capabilities of Groovy.

So here's my final implementation:

              (1..100).collect {
                   ((it % 3) == 0 ? "Fizz" : "") << ((it % 5) == 0 ? "Buzz" : "") ?: it
              }.each { println it }
              

This takes full advantage of Groovy's power. It is a little harder to read, which is a downside. It does take full advantage of many of Groovy's powerful features:

1. A range to generate the list of numbers to process. Ranges return an iterator that iterates from the start of the range to the end of the range.
2. The collect method which applies a closure to each item in the collection (or iterator) and returns the results as a list.
3. The each method, which iterates through a list and applies a closure to it. It returns the collection that it iterated through.
4. Closures, which are implemented quite well in Groovy.
5. Operator overloading. The << operator is overloaded on the String class to concatenate two Strings together.
6. The brand new Elvis operator (?:) which returns the alternate value if the expression evaluates to false.
7. Groovy returns the last expression of a block as the result of the block. This includes closures and methods.

I do think that I'll incorporate this question in future interviews. It has quite a few interesting subtleties and implementations that are only rivaled by the Singleton pattern. I guess that the last group of interviewees got it a little easier...

Our old countertops where in really bad shape, and it was driving my wife to insanity (or so she claims). We had done everything we could think of to extend their life. We painted them, we glued the old formica in place. But the paint started to chip and the formica didn't stay glued on very long. So we decided that we had to address the countertop situation.

We remembered passing by a booth at the Flatiron Mall advertising an engineered granite solution by Granite Transformations. It happens that I occasionally drive by their local franchise. We stopped by on a Saturday afternoon, got some information and scheduled an estimate. We did have a little sticker shock at first so we decided to compare other options before going ahead. It turns out that they were competitive with other options from Lowes and Home Depots.

I had to take out the sink before the installation could occur, so we decided to upgrade the sink at the same time.

The installation itself is a two step process. First, a template is built to facilitate the fabrication process. The team showed up right on time for the appointment and created the template. Three days later, they showed up for the installation proper. There was very little demolition involved. The old countertops didn't need to be ripped out since this is an overlay product. They were done right on time for lunch.

I decided to install the sink myself. It did turn into a bit of a saga, like any home improvement projects that I take on. It was promptly resolved once I found the right feed lines for the sink. Within a few hours the sink and new faucets were installed and tested.

My lovely wife is simply in love with the new kitchen and raves about it. I love it too and feel a lot of pride in having installed the sink myself. We are already compiling a list of projects to do next. It never really stops...

I wanted to play with the metaprogramming abilities of Groovy. So I started a new project in NetBeans and created a Mercurial repository to version it. I had a few files committed eventually.

I am really nervous about keeping code in a single location. This is why I do Time Machine backups on my mac. This is also why I keep a clone of Mercurial repositories on my workstation at work. Well, except for my personal projects. I keep a clone on the same server that is hosting this blog. I decided that this new project was worth cloning remotely.

It turns out that you can clone a repository to a remote system just as easily that you can clone a repository from a remote system. The syntax is simply:

hg clone [local-repo] [remote-repo]

This even works over ssh. It also leads to a little more peace of mind on my part.

I pushed REM 1.3.0 for NetBeans to SourceForge earlier today. This release addresses the following issues:

1. Upgrades the ZK libraries to 3.0.1
2. Updated the internal DTD to match ZK's XML Schema
3. Include support for the zkforge components.
4. Registers ZK's XML schema with NetBeans 6.0 so it can be used for syntax highlighting and code completion.

The project can be found at http://www.sourceforge.net/projects/rem1 .

We use the ZK web application framework on our project at work. It was selected before I came back to Sun. ZK in itself is a pretty decent web framework that would allow JavaScript averse Java developers to write an Ajax-like dynamic web application without having to worry about the details of the browser. We've done some pretty amazing things with it.

But this is not a post about ZK.

Most of the team also uses NetBeans as our IDE. NetBeans has improved a lot over the last couple years. I even switched back to it when I was still at TransZap and used it a few times at OpenLogic for it's profiler. NetBeans 6.0 is really an amazing environment to code in Java, has great support for Ruby and has a community of plugin developers who are at work adding support for Groovy, Scala and other languages.

This post is only partially about NetBeans though.

I was pointed to the REM plugin when I came back to Sun. This plugin adds support for ZK to NetBeans. It was created as part of a school project and was posted on SourceForge. It was supporting ZK 2.3.0 and we were using ZK 2.3.0. This plugin made it much easier to learn ZK and write the pages themselves.

Then we upgraded to ZK 2.4.1. The plugin didn't though. But it was still useful, so we kept using it.

Work on NetBeans 6.0 was moving along quite nicely. I downloaded NetBeans 6.0 beta 2 to test it. I started installing my collection of plugins only to discover that REM wouldn't load. I posted a note on the forums asking about support for NetBeans 6 but didn't hear anything. So I downloaded the source code for the plugin, found the area of code that wouldn't work with NetBeans 6.0 and commented it out. It was still usable, but it wouldn't quite do for production work.

I decided to contact the project owner and offered to help. That was the beginning of my official involvement with the REM plugin. In a few weeks, I upgraded the plugin to support ZK 2.4.1 and then ported it to NetBeans 6.0. This was done just in time for Sun's IT to upgrade the default IDE to NetBeans 6.0.

This wouldn't have been possible if REM was a closed source product. We would have been either stuck on NetBeans 5.5 or we would have had to abandon the plugin. The open source nature of the project means that not only can we keep using the plugin moving forward but that we can contribute back to it and make it more valuable to people outside of Sun. This in turn helps the ZK community by adding value to it by integrating it with another IDE and helping it grow.