Playing a website with JFugue

Ok, had to do this:



import org.jfugue.*

def munge(s) {
s.findAll { it ==~ /[A-Ga-g]/ }.join(' ')
}

String.metaClass.play = { new Player().play(new Pattern(munge(delegate.toString()))) }

"http://www.google.com".toURL().getText().play()



All credits go to transentia

Sling/Groovy Development with OSGI

After having evaded this whole OSGI/Maven topic, I think it is time that I delve into the whole issue. Lars Trieloff and other helpful people alredy gave me a hint about when to change from webdav/scripting mode to OSGI/Maven bundles.

After several hours and reading several blogs and webpages, I came up with the following pom.xml:



<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>SlingControlmanagement</groupId>
<artifactId>SlingControlmanagement</artifactId>
<version>1.0</version>
<packaging>bundle</packaging>
<build>
<plugins>
<!--
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-scr-plugin</artifactId>
<version>1.0.8</version>
</plugin>
-->
<plugin>
<groupId>org.apache.felix</groupId>
<artifactId>maven-bundle-plugin</artifactId>
<extensions>true</extensions>
<configuration>
<instructions>
<Export-Package>
test;version=1.0.0
</Export-Package>
<Bundle-SymbolicName>controlmanagement</Bundle-SymbolicName>
<Bundle-Name>controlmanagement</Bundle-Name>
<Import-Package>
org.osgi.framework;version="1.3.0",groovy.lang;version=1.6.0,org.codehaus.groovy.reflection;version=1.6.0,org.codehaus.groovy.runtime;version=1.6.0,org.codehaus.groovy.runtime.callsite;version=1.6.0
</Import-Package>
<Sling-Initial-Content>
SLING-INF/initial-content/libs/myapp;overwrite:=true;path:=/libs/myapp
</Sling-Initial-Content>
</instructions>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.sling</groupId>
<artifactId>maven-sling-plugin</artifactId>
<executions>
<execution>
<id>install-bundle</id>
<goals>
<goal>validate</goal>
<goal>install</goal>
</goals>
<configuration>
<mountByFS>true</mountByFS>
</configuration>
</execution>
</executions>
</plugin>
<plugin>
<groupId>org.codehaus.groovy.maven</groupId>
<artifactId>gmaven-plugin</artifactId>
<executions>
<execution>
<goals>
<goal>generateStubs</goal>
<goal>compile</goal>
<goal>generateTestStubs</goal>
<goal>testCompile</goal>
</goals>
</execution>
</executions>
</plugin>

</plugins>
</build>
<repositories>
<repository>
<id>apache.incubating</id>
<name>Apache Incubating Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository</url>
</repository>
</repositories>
<pluginRepositories>
<pluginRepository>
<id>apache.incubating.plugins</id>
<name>Apache Incubating Plugin Repository</name>
<url>http://people.apache.org/repo/m2-incubating-repository</url>
</pluginRepository>
</pluginRepositories>
<dependencies>
<dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>1.6.3</version>
</dependency>
</dependencies>
</project>


There are several things to point out:

1. I am by no means a OSGI/Maven expert, so consider this to be a first draft
2. the commented out scr plugin is used for declarative OSGI services, details here.
3. the groovy version used for compilation (1.6.3) and within OSGI (1.6.0) are different. This might lead to problem. Best thing to do would be to reinstall groovy-all.jar into the OSGI environment
4. the "Sling-Inital-Content" tag is a convenience used to supply initial content to sling
5. the <mountByFS>true</mountByFS> tag should theoretically allow to have all changes done within the filesystem be propagated to sling. Doesn't work atm, although, unsure why
   
   

So where in REST is the MVC?

Still trying to get my head around REST. Looking at sling, I do see two different approaches:

• view/model combined: a resource is represented by a markup (html), which contains both view and model information. The controller (browser) is responsible for the correct representation and the hypermedia functionality (hyperlinks, forms), which allows navigation and manipulation of the represented data
  
• model exclusively: the resource is represented by a data structure (json), which is both rendered to the controllers (browser) taste as view

Now, from a design point of view, the second one seems cleaner, and very compatible with the MVC pattern. But the first approach is the one the web is build upon, soooo there has to be something about it ...

The idea spinning around in my head is to implement the first approach with Griffon and Sling: Sling will deliver SwingBuilder fragments which then will be interpreted by Griffon. Stay tuned...

Apache's mime-type list

Just stumbled on this while reading the sling mailing list:

Apache's web server default mime-type list, together with associated extensions: might come handy, includes the relevant RFCs in the comment

This must be the quote of the week

Having read the (german) news post on heise.de
regarding the issue of prodcut piratry one quote struck me:
According to the article (no source is quoted there!), Peer Laslo of SAP is supposed to have made this statement:
" ...
Wir sind nicht betroffen. Unseres Software ist so kompliziert, dass man sie schlecht fälschen kann.
..."

eng:

"...
We are not affected. Our software is that complicated that it hardly can be imitated.
..."

Now, I do not have any context information for this statement. Put like this, it sounds really weird. And wrong too: A software can simply be pirated by copy and paste, or reverse engineering.

So the only thing protecting this particular product is the complexity to enhance/change and lastly to use it. Looks like not only security but whole businesses can be built with obscurity in mind....

Deploying a Groovlet Application to the AppEngine with AntBuilder

Just a quick & dirty info: you can easily use the already defined tasks for Google AppEngine with your Groovlet-based application (as described by Guillaume Laforge on his SpringSource blog)



def ant = new AntBuilder()
def webinf = "war/WEB-INF"
def aesdk = "appengine" //change this to the location of AppEngine SDK

ant."import" (file: "${aesdk}/config/user/ant-macros.xml")
ant.sequential() {
taskdef name: "groovyc", classname: "org.codehaus.groovy.ant.Groovyc"
groovyc srcdir: "src", destdir: "${webinf}/classes", {
classpath {
fileset dir: "${webinf}/lib", {
include name: "*.jar"
}
pathelement path: "${webinf}/classes"
}
javac source: "1.5", target: "1.5", debug: "on"
}
copy toDir: "${webinf}/groovy", {
fileset dir:"groovlets"
}
if(args.find{it.startsWith("-u")}) {
appcfg action:"update", war:"war"
}
}


Please note that appcfg is a task defined in the GAE SDK. By importing the relevant xml file (and having the respective jar files on classpath), this and all other ant tasks become available to groovy scripts.

If you run this script with "groovy build -u" 3 things will happen:

1. all stuff in "src" will get compiled
2. all stuff in "groovlets" will get copied over to the appropriate directory (no need to compile those, if you follow Guillaume's hints regarding web.xml configuration
   
3. all stuff will get pushed to the AppEngine

If you use strictly Groovlets, nothing needs to be compiled and step 1 might become obsolete.

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