Dienstag, 30. Juni 2009

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

Sonntag, 24. Mai 2009

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

Mittwoch, 20. Mai 2009

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...

Dienstag, 12. Mai 2009

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

Samstag, 25. April 2009

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....

Samstag, 18. April 2009

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.

Donnerstag, 12. März 2009

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

Samstag, 28. Februar 2009

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...