log4p

Peter Maas’s Weblog

Archive for October, 2008

Using Google maps for displaying large images in a page

October 15th, 2008 | Category: diagram, google

Via the Trendmatcher weblog I came across a nifty tool to use the Google Maps viewer for arbitrary images.

The Google Maps Image Cutter, as the application is called. Is a small Java application which cuts a selected image to thousands of small images compatible with the viewer and a working HTML file.

Really useful for embedding your favorite diagrams (this is diagram I generated for a legacy MMBase application) in a blog post:

Now… the only wish I still have is the option to just use .dot (graphviz) files or a vector graphics format directly ;)

1 comment

Running your griffon application in fullscreen mode

October 14th, 2008 | Category: groovy

I've been doing some development using Griffon lately. Griffon is a Grails like application framework for developing desktop applications in Groovy which lets you create Java Webstart applications without the hassle. It takes a clean MVC approach including nifty automatic binding of the model to the view. If you want to give Griffon a go, please have a look at the Quick Start guide.

I was looking for a solution to run the application I wrote in fullscreen mode. It took me a while to figure out how to do this. In the end it was quite simple.

Griffon offers a couple of hooks to execute code on specific states of the application lifecycle. The following hooks are availlable:

  • griffon-app/lifecycle/Initialize.groovy
  • griffon-app/lifecycle/Ready.groovy
  • griffon-app/lifecycle/Shutdown.groovy
  • griffon-app/lifecycle/Startup.groovy
  • griffon-app/lifecycle/Stop.groovy

I added the following code to the 'griffon-app/lifecycle/Ready.groovy' script:

PLAIN TEXT
  1. import java.awt.GraphicsEnvironment
  2.  
  3. def graphicsEnvironment = GraphicsEnvironment.localGraphicsEnvironment
  4. def device = graphicsEnvironment.screenDevices.find{it.fullScreenSupported}
  5.  
  6. device?.setFullScreenWindow(app.appFrames[0])

The 'app' variable in the script is an implicit variable pointing to the actual application. Via this variable one can get access to all parts of the application; since I've just got one frame choosing was easy.

Haven't had the change to test the above on windows... but it works like a charm in OSX.

5 comments

I want closures “bolted on to Java”

October 11th, 2008 | Category: closures, java

After seeing Blochs' session on Javapolis last year and some of the Java 7 sessions at JavaOne this year I gave up on closures in Java. I just didn't believe that they would be part of Java 7 anymore. I also had my doubts on the 'quircks' of the BGGA proposal.

Playing around with the BGGA prototype changed my opinion though. It might not be as concise as closures in Ruby, but it _is_ a really useful extension of the Java language.

The following code I wrote runs fine with the BGGA prototype:

PLAIN TEXT
  1. package com.finalist.closures;
  2.  
  3. import java.util.*;
  4.  
  5. public final class ClosuresExample {
  6.  
  7.     public static void main(String[] args){
  8.         List<String> words = toWords("altijd is kortjakje ziek");
  9.         Collections.sort(words, {String a, String b => b.compareTo(a)});   
  10.         System.out.println(words);
  11.         List<String> wordsContainingK = select(words, {String it => it.contains("k")});
  12.         System.out.println(wordsContainingK);
  13.     }
  14.    
  15.     public static <T> List<T> select(List<T> list, {T=>boolean} filter) {
  16.           List<T> results = new ArrayList<T>();
  17.           for (T t : list){
  18.             if(filter.invoke(t))
  19.               results.add(t);
  20.           }
  21.        return results;
  22.     }
  23.  
  24.     public static List<String> toWords(String input){
  25.         return Arrays.asList(input.split("\\W"));
  26.     }
  27. }

This is just one example, you can do _much_ more with the BGGA proposal. It integrates with the existing API. I like this. I want this. I feel a bit sad about the fact that it might not make it to Java7.

But...

Yesterday @headius / Charles Nutter came up with a very interesting idea on twitter:

@danny_l Gafter made the same mistake; I don't mean a forked Java any more than Groovy is a fork. I want a "mostly Java" with closures.

or the reply by @danny_l / Danny Lagrouw:

@headius or could the BGGA prototype be "bolted on" any future version of Java? That might be useful

That really is what I would like to see as well. Can't we have some sort of bytecode preprocessor to make the BGGA prototype work on any modern Java version? I mean scala, Groovy and JRuby have closures and produce valid bytecode!

I would even like to help and put effort in it. Although I don't really know where to start.

11 comments

Review: “Clean Code: A handbook of agile software craftmanship”

October 10th, 2008 | Category: java


The following product description of Clean Code written by Robert C. Martin managed to trigger my interest:

Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship. Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code on the fly into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it.

A software craftsman. That is what I’d like to be. It is however a fairly bold claim; wasn’t craftsmanship something you learn through experience? After having read Clean Code however, I can tell you that the Robert C. Martin did a really good job at doing just that.

The content

Clean Code is divided into three parts. The first part describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies. The third part is a single chapter containing a list of heuristics and smells gathered while creating the case studies.

In part one Robert explains the fundamentals of good code. Robert introduces some great concepts like “the newspaper metaphor – ‘think of headlines, synopsis, increasing detail as you continue downward’” and “boyscout rule – ‘leave the campground cleaner than you found it’”. He dives into how to do this: meaningful names, what should a good function look like (in terms of abstraction, arguments, error handling), comments in code, formatting, objects and data structures, error handling in general, talking to third party code, unittests, class hierarchy, architectures and concurrency.
The level of detail is spectacular. Robert doesn’t just tell you how it should be, he also explains how to achieve it; with good, modern, Java code. This part also contains excerpts and metrics gathered from different open-source project illustrating his points; a nice touch.

Part two contains two cases where Robert applies his principles, patterns and practices to real-life projects (JUnit and JFree). What I really like about this part is that Robert explains every single refactor he did; even if he decided to revert his changes later on. The JUnit example is great. The JFree example is a bit tougher; mostly due to the fact that the code for this case is not part of the text but located in an appendix; it takes a lot of ‘random access’ to actually read it.

Part three is a concise list of ‘rules’ you should apply to write good code. Really useful as a reference.

The verdict

I think every (Java) programmer should read this book. It will make you a better programmer. Even if you know all the concepts Robert talks about. Seeing the concepts being applied to code from real-life projects by a skilled developer with a complete explanation is really valuable. I’ll be pointing developers in my team and teams to come to this book!

4 comments