What is your LOCBUT?

How many lines of code do you write before having the urge to test if it is working? Does this count go up or down when you know that there are solid tests backing it?

For me personally, it is about 5, and going down if tests are around.

I have of course no metrics, but I have the feeling that this is not depending on the programming language. Which leads to some interesting conclusions:

• strive for fast round-trip cycles in your development process
  
• prefer expressive languages which allow to more in less LOC

Checking the Radar

Well, about time this blog gets some content added.

Quick check on my radar: what technologies am I watching, where they are heading, what else I would like to have a look at etc.

Tapestry:
Wasn't able to play around with it. Currently V5.0, looks very very good, but I will take it off the radar, since I do not see an opportunity to test it out.

Grails:
About same as Tapestry. I personally would choose one of those two as Web Framework.

Groovy:
This has become my home language. Just makes sense. Just good. Use it. Will be on Main Road by 2011 (and might get boring then :))

Sling (and Jackrabbit):
Still much work going on there. Sling (and Jackrabbit) are not only superb technologies, but more than that, have become inspiration for modeling content and thinking about data and their respective handling.

Griffon:
Everyone and their mum does that AJAX-Flex-JavaFX-RIA-thingie. Everyone? No, there are some stubborn, backward-oriented guys (did not spot any ladies up to now), which, basically, say, screw it: we are doing SWING! Yeah baby. Do it right by using Groovy, be inspired by Grails, and well, use some major brain power. This one is hot, mark my words...

What are possible new candidates for the Radar?
Well, there is Clojure, but I do not yet have any use case for it at the moment. I will first read the book. Suggestions welcome...

Apache Jackrabbit 1.5

Apache Jackrabbit was just released in version 1.5.

It looks that this is the "yes, we heard you" release, and is a huge jump forward for straightforward usage:
1) grab the jar-file
2) java -jar jackrabbit-....jar

And... there is no step 3 :).

I can't stress out enough the importance of such easy usage. While it already has been more or less simple to use Jackrabbit in, say, semi-professional setups, it now has the chance to hit the Main Street. "Want webdav? Well, you'd better use that jackrabbit thingie".

Ok, there may be some steps 3, but I will write about those later

Fun with annotations in Groovy/Griffon

The 1.6 version of Groovy seems to have full-fledged annotation support.

I took the occasion to finally learn to create some annotations on my own, and wrote an annotation which can be used in a Griffon model to give the controller some hints about how to best display its data.

I might have taken this a little bit too far, but it is also possible to declare strings in annotations which can later be evaluated.

Take this annotation as an example:


package annotations

import java.lang.annotation.*

@Retention(RetentionPolicy.RUNTIME)
public @interface TableModelInformation {
boolean displayed() default true
String displayName() default ""
String displayValue() default ""
}


This can be used in the model like this:


...
@TableModelInformation(displayValue='"Total Subprocesses: ${object.subprocesses.size()}"')
List subprocesses = []
...

(Note the weird string syntax: only double quotes (i.e. GString) are rightfully not interpreted as Strings. Furthermore it expects to receive an instance of the object in a variable named (tadaaa) "object".

This can be evaluated later in the controller:

return new GroovyShell(new Binding([object:object])).evaluate(object.class.getDeclaredField(field).getAnnotation(annotations.TableModelInformation).displayValue())

("object" and "field" are available in the context of the controller)

I am not sure how to optimize this code, especially the verbosity of annotation retrieval. It nevertheless is kind of funny to see groovy behavior in an (at least from me) unexpected way...

Using ocmgroovy as Persistance Layer for Griffon

Griffon is a very interessting approach to create an agile and fun framework for building Swing applications. Currently a very shy version numeration is used (0.0.1 is current), but the whole package is built using large know-how.

One thing missing is the persistance layer. It is planned to use GORM, the hibernate-based layer of Grails.

This situation is an opportunity for ocmgroovy, my "framework"(*) for persisting Groovy objects into a JCR. While beeing a little ugly hack atm, the basic things like save() and get() seem to work, at least for my basic test cases.

Using ocmgroovy in grails is one annoying and 2 easy steps

1. download ocmgroovy (either create the project via pom.xml or download all dependencies manually, which basically means to download all jackrabbit dependencies and xstream with its dependencies) and install it into {griffon_project}/lib directory
2. declare the class to be persisted in {griffon_project/lifecycle}/Startup.groovy
3. use it in your Griffon mvc
   

Step 2 looks like this

TransientRepository repository = new TransientRepository()
def session = repository.login(
new SimpleCredentials("threatmanagment", "password".toCharArray()))
JcrPersister strategy = new JcrPersister()
strategy.session = session
strategy.instanceRoot ="threatmanagment"

strategy.instrumentate(ThreatModel, "name")
strategy.instrumentate(Dataflow,"id")

This makes model classes ThreatModel and Dataflow persistable, i.e. currently mostly adds save() and get() methods to instance and class, respectively

And Step 3: about as easy

ThreatModel model = new ThreatModel("name": "TestModel")
model.save()
...
ThreatModel model2 = ThreatModel.get("TestModel")

Please note that this is all very shaky at the moment (and therefore will create a black hole if you try it at home ;)), but might prove usable in the future.

I probably will release a PoC-project in the near future.

===
(*): ocmgroovy is very alpha and only used by myself. Therefore I do not consider this to be a framework

Ditching Flex ... for now

Well, killing another fairie: I am dissing Flex for my pet project. There are several reasons:

1. not too good Flex-Support in IDEA
   
2. roundtrips are slow (create compile load)
   
3. open source built on closed source doesn't work
4. mxml: simply don't like those
5. actionscript will not be the next ecmascript
6. verbosity: too much to write while using MVC frameworks. Convention over Configuration is not there yet (?)
   
7. HTTP support is kind of crippled
   

There are very good reasons to love Flex:

1. the looks: I am no expert, but I got the feeling Flex just looks great out of the box
2. components: component based UIs are great.
   
3. event models
   
4. ubiquity

I am sure that some of the points are due to the fact that I am a novice. I might come back to it, but now it is time to move on...

An "in between" review of Sling

Now that I have been using Apache Sling for a pet project for some weeks now, I thought I could share some insights on it. The spaghetti western way, of course :). And all utterly subjective.

The Good

• java -jar sling.jar -> http://localhost:8080 and dav://localhost:8080. This is fantastic.
• Scripting support
  
• REST: learn it the Sling way
  
• webdav-support
  
• A good community
  
• best-of-breed technologies: OSGI (with Felix), JCR (with Jackrabbit)
• JCR muscle flexing included: query, hierarchies, versioning
• semi-structured data approach
  
• it's fun
  

The Bad

Nothing bad, just great stuff with some edges:

The Ugly

• Docu. Yeah I know. Is getting better, but should be more (please kill those "out of sync" pages)
  
• After a fast start, there still is a learning curve (OSGI, REST, JCR, Maven, ...). Since these are hot topics anyway, this is no big deal, expect when you want something fast and nownownow :)
  
• bootstrapping problem: despite the available help, I still did struggle with the question whether controls (scripts) or data should be created first. But this is just me, I guess :)
  
• JCR Editor support: Days eclipse plugin is great, but unfortunately doesn't work on my Ubuntu-system
• No out-of-the-box solution for rich applications (Except dojo, which is a beast on its own...)
  

All in all, Sling holds its head up high in a tight, competitive market. I am looking forward to do more stuff with it. The rough spots are being addressed, therefore I am positive and quite impressed. Most important thing now would be to flesh out the documentation....

update 13th Sept: The JCR Plugin for eclipse works after a fresh install, using Eclipse Ganymede and JCR Plugin version 3.6.6. Nice thing is, that Eclipse editors seem to work, e.g. when editing a HTML file. Have to check if this works with the groovy editor too ...