BlackBox

The other big change I’m considering is actually moving away from Subversion. I’ve really enjoyed using it, but a recent discussion on the Groovy Dev list about Distributed Version Control Systems (DVCS) has got me looking at alternatives and why it would be good. I asked my friend Kate if she had any blog posts on why switching to a dvcs is a good idea and she whipped one up for me.

After reading through it I think I’m sold, but now I’m trying to figure out which one to try out first. Git honestly looks like the clear winner here in a number of respects:

• Serious mindshare amongst the OSS projects
• Has a great community committed to pushing the project forward (as Kate suggests )
• Has some really good functionality (even if it is a bit obtuse to get to understand)
• Looks like the beginnings of some plugins
  • Eclipse

But it also has some (current) drawbacks:

• Tools are really only available on Linux - Mac looks like its coming but could be a pain in the ass to build, forget Windows right now
  • No IDEA plugin yet (bummer) - but it does look like IDEA 8 will support it
  • No NetBeans plugin
• It’s a bit obtuse to learn - the commands are not necessarily the easiest to understand but they do have a Subversion -> Git guide online

So, I think I will try Git first, maybe. What about the other two - Bazaar and Mercurial? Bazaar honestly looks like 3rd place contender right now, but it does have some interesting tools available to it. Let’s look at Mercurial next.

• There are some pre-built packages for OS X and Windows - nice
• Again, looks like the beginnings of some plugins
  • Eclipse
  • IDEA
  • NetBeans

Some current drawbacks

• Doesn’t seem to have the same mindshare as Git does (this is my perception not necessarily true)

Now onto Bazaar.

• Binaries available for multiple platforms - OS X, Windows, and Linux
• Patch Queue Manager - very interesting tool
• Bundle Buggy - another interesting tool
• There are again plugins available
  • Eclipse
  • IDEA

Of course after I started this I found this much more in-depth review of the different systems over at InfoQ.

I think after reading a ton more on this (and the InfoQ article) that I’m going to give Mercurial a short first and see how it goes. Kate makes two more points at the end of this blog post on Mercurial vs. Git (which itself was a response to another blog post) - If you need Windows support or documentation are important items then Mercurial may be a better choice. For me, while I don’t need Windows support, it will be nice to understand what I’m trying to do first.

First, let me say, I like Maven - a lot. I’ve liked the idea, if not the execution, since 1.0 (yes, I know there is some serious bad blood for the implementation of 1.0, and yes I still liked it). But I’ve recently run into some irritating problems with Maven that would again, I think, require a major reworking of what it does.

Here is the main issue Maven is designed to handle one language only for its compilation - primarily Java. This is rapidly starting to fall apart now that the JVM has some serious contenders besides Java, namely Groovy, JRuby, Jython, and Scala. There are some hackish things for getting Maven to deal with these, however it still only has one “true” source directory for compilation. A case in point is a mixed Java/Groovy project - trying to get IntelliJ to respect the fact that I want not one, but two main source directories is a pain in the ass as I have to either tell it not to sync everytime I launch or I have to refix the source directories each time I update the project.

This is what triggered this post - what happens when I want to do some Flex programming with some Java, ActionScript and MXML, all of these are true source files (and in Maven specfic directories). I’m sure some Mavenite is going to say that these should be separate projects, but in alot of cases they aren’t and it doesn’t make sense to actually separate them into sub-projects. And I’m equally as sure that some Ant-ite is going to come along and tell me to use Ant - I won’t. Ant is stuck in the past and I won’t use it unless I absolutely have to. I like the “imposed” structure that Maven offers. I can walk up to any project and know where to find stuff instead of blindly hunting around for hours trying to piece it together like some giant source-code jigsaw puzzle, blech.

So, I’m at cross-roads, what should I do? There is Ivy (for dependency management -which they got from Maven natch), but that requires Ant, blech. There’s also Gant, ok, this is better, but still Ant. GMaven, but I’m right back where I started.

Enter, Gradle, a new Groovy-based build system that offers alot of the benefits of Maven without locking you in and the flexibility of Ant. I’m not 100% sold on it yet, but I’m going to give it a shot for a relatively complex project that will have a fair amount of Java, Groovy and other fun resource files. It looks interesting in that all the build files are actually Groovy scripts that are a DSL (like Gant files). Here’s a short example with some dependencies (taken directly from their examples in the download).

import org.gradle.api.tasks.util.FileSet

usePlugin('groovy')

group = 'org.gradle'
version = '1.0'

sourceCompatibility = 1.5
targetCompatibility = 1.5

dependencies {
   clientModule(['groovy'], ":groovy-all:1.6-beta-1") {
       dependency(":commons-cli:1.0")
   }
   compile project(':groovycDetector')
   testCompile ":junit:4.4"
}

compile {
   exclude('**/Exclude.java')
   groovyExclude('**/ExcludeGroovy.groovy')
   groovyJavaExclude('**/ExcludeGroovyJava.java')
}

manifest.mainAttributes(myprop: 'myvalue')
metaInf << new FileSet(new File(srcRoot, 'metaInfFiles'))

test.options.systemProperties['org.gradle.integtest.buildDir'] = buildDir.absolutePath

I will try and keep everyone up to date as I continue to investigate this new build system. They also state that they are going to be supporting polyglot programming in the near future which I’m looking forward to.

Last night I presented part 2 of a 2-part series looking at Flex and OpenLaszlo at the Tucson JUG. Here are my final thoughts on the two (given a brief introduction to each):

• Both are good platforms for RIA
• I really like the fact that you can compile Flex apps in either XML or in ActionScript
• I like OpenLaszlo’s xpath notation for connecting to XML datasources
• I feel that Flex has really gained the mind-share of the Open-Source community. I found many more tools available to me in Flex-land than in OpenLaszlo
  • See BlazeDS, GraniteDS for some excellent Open-Source data and messaging providers for Flex
  • Maven and Ant(included with the Flex SDK) tools for Flex
  • Unfortunately the Eclipse plugin for OpenLaszlo appears to be gone, gone, gone.
  • Both have Unit testing frameworks available - ASUnit, FlexUnit, and LzUnit
• I like the fact that OpenLaszlo supports additional run-times through the new “legals” initiative (DHTML and others are in the pipeline through a partnership with Sun)
• I couldn’t find an easy way to setup a project for OpenLaszlo through Ant or Maven. I’m sure they exist but nothing turned up in a cursory search
  • I take it back, I finally found this on the OpenLaszlo wiki for ant tasks included with the source. But not packaged up all nice and clean like the ones for Flex. Blech.
• I also like how easy it is to create and modify components for Laszlo. I don’t know how easy it is to do this in Flex.
• The docs for OpenLaszlo are somewhat scattered and some are sorely out of date. Several examples on their own site didn’t work at all with 4.0.12

Overall I think I will be focusing my future efforts on Flex/ActionScript 3.0 and unfortunately leaving Laszlo behind. I have been a fan of it for quite a while but I don’t think it has kept up at all with Flex and is starting to lose mind-share amongst the Open-Source community.

Last night I presented part 2 of a 2-part series looking at Flex and OpenLaszlo at the Tucson JUG. Here are my final thoughts on the two (given a brief introduction to each):

• Both are good platforms for RIA
• I really like the fact that you can compile Flex apps in either XML or in ActionScript
• I like OpenLaszlo’s xpath notation for connecting to XML datasources
• I feel that Flex has really gained the mind-share of the Open-Source community. I found many more tools available to me in Flex-land than in OpenLaszlo
  • See BlazeDS, GraniteDS for some excellent Open-Source data and messaging providers for Flex
  • Maven and Ant(included with the Flex SDK) tools for Flex
  • Unfortunately the Eclipse plugin for OpenLaszlo appears to be gone, gone, gone.
  • Both have Unit testing frameworks available - ASUnit, FlexUnit, and LzUnit
• I like the fact that OpenLaszlo supports additional run-times through the new “legals” initiative (DHTML and others are in the pipeline through a partnership with Sun)
• I couldn’t find an easy way to setup a project for OpenLaszlo through Ant or Maven. I’m sure they exist but nothing turned up in a cursory search
  • I take it back, I finally found this on the OpenLaszlo wiki for ant tasks included with the source. But not packaged up all nice and clean like the ones for Flex. Blech.
• I also like how easy it is to create and modify components for Laszlo. I don’t know how easy it is to do this in Flex.
• The docs for OpenLaszlo are somewhat scattered and some are sorely out of date. Several examples on their own site didn’t work at all with 4.0.12

Overall I think I will be focusing my future efforts on Flex/ActionScript 3.0 and unfortunately leaving Laszlo behind. I have been a fan of it for quite a while but I don’t think it has kept up at all with Flex and is starting to lose mind-share amongst the Open-Source community.

Last night I presented part 2 of a 2-part series looking at Flex and OpenLaszlo at the Tucson JUG. Here are my final thoughts on the two (given a brief introduction to each):

• Both are good platforms for RIA
• I really like the fact that you can compile Flex apps in either XML or in ActionScript
• I like OpenLaszlo’s xpath notation for connecting to XML datasources
• I feel that Flex has really gained the mind-share of the Open-Source community. I found many more tools available to me in Flex-land than in OpenLaszlo
  • See BlazeDS, GraniteDS for some excellent Open-Source data and messaging providers for Flex
  • Maven and Ant(included with the Flex SDK) tools for Flex
  • Unfortunately the Eclipse plugin for OpenLaszlo appears to be gone, gone, gone.
  • Both have Unit testing frameworks available - ASUnit, FlexUnit, and LzUnit
• I like the fact that OpenLaszlo supports additional run-times through the new “legals” initiative (DHTML and others are in the pipeline through a partnership with Sun)
• I couldn’t find an easy way to setup a project for OpenLaszlo through Ant or Maven. I’m sure they exist but nothing turned up in a cursory search
  • I take it back, I finally found this on the OpenLaszlo wiki for ant tasks included with the source. But not packaged up all nice and clean like the ones for Flex. Blech.
• I also like how easy it is to create and modify components for Laszlo. I don’t know how easy it is to do this in Flex.
• The docs for OpenLaszlo are somewhat scattered and some are sorely out of date. Several examples on their own site didn’t work at all with 4.0.12

Overall I think I will be focusing my future efforts on Flex/ActionScript 3.0 and unfortunately leaving Laszlo behind. I have been a fan of it for quite a while but I don’t think it has kept up at all with Flex and is starting to lose mind-share amongst the Open-Source community.

Periodically I will do small consulting gigs and recently had a client who wanted to know if there was a way that they could improve their development experience with Tapestry 4. Their specific problem lied in the fact that when they initially pulled up any Tapestry page it was incredibly slow to render that first time. They were not using the property org.apache.tapestry.disable-caching so that definitely wasn’t the issue.

The solutions that I came up with after doing some research and looking at their code were these:

• Use Jetty for development
• Convert as much of their pages (and components) to be “spec-less” as possible

Two primary reasons to use Jetty are that it allows you to more easily reload HTML changes and in general is a much more lightweight container than Tomcat, therefore getting an overall faster startup time and increasing development time. One of their own developers was already using Jetty and was seeing speed increases.

The primary reason to convert your HTML pages to be ”spec-less” (in other words no *.page file to bother with) is that reduces the overhead that Tapestry 4 puts into place to parse the XML file and figure out how all the components are wired together. Instead it puts this in either the HTML template, which it is already parsing, or in the Java class as an Annotation.

This also has the side benefit of prepping your code for converting up to Tapestry 5 as it uses no *.page files whatsoever.

This is my first attempt at categorizing some of the DSLs I’ve run across into some kind of logical grouping. First I’ll list out some Groovy DSL examples (sound off in the comments for those I’m not aware of, the more the better). I’ll go through the DSLs first and then look at the possible categories after the break. And the first two are mine that I created

• Groovy Higher Order Messaging (HOM)
• Math DSL Part 1 and Part 2
• GroovyLab
• Json-lib with Groovy
• Grails’ Spring Bean DSL
• Grails’ Dynamic Finders
• Grails’ Criteria DSL
• Grails’ Domain Class Validation DSL
• JParsec’s Groovy interface
• Guillaume’s Unit Manipulation DSL
• AntBuilder (as well as XMLBuilder, SwingBuilder, etc. - builders, essentially)
• Ken Barclay’s GParsec
• Human readable date manipulation such as in Guillaume’s example
• Tiago Antão’s Malaria Drug DSL
• GSpec Behavior Driven Development

I know there are more out there but this is a good starting point for sure.

Now, on to the actual categories of DSL “types”

So I thought I’d update everyone on my progress so far with the Portal/Portlet component I’ve been working on, as well as some of the issues I’ve run into.

Normally I would have posted this to my Tapestry 101 blog but I’m going to try and consolidate my blogs together and I’m extremely tired of JRoller’s broken Textile formatting, such a pain in the ass (I have fallen in love with Markdown and code markup, it rocks!). I’ll be crossposting this, but soon I will stop updating the JRoller blog.

I now have a basic implementation of the Portal component complete and it consists of the following classes:

• Portal.java - Stores a TreeSet of columns
• Portal.html - Adds in the portlet controls div and some custom CSS stuff (which I’ll talk about shortly)
• PortalColumn - Stores a TreeSet of Portlets plus some configuration for viewing (width and background color)
• Portlet - Stores the Portlet title, content and it’s location
• portal/scripts/
  • Portal.script - includes all the JavaScript files and does some dynamic stuff (coming up shortly)
  • prototype/scriptaculous scripts
  • portal_hooks.js - the hooks for the portal actions (close, move, etc.)
  • portal.js - the actual JavaScript for the portal functionality that can be called by the portal_hooks.js file
• portal/css - portal.css
• portal/images - all the images for the portal controls and rendering (rounded corners)

Ok, so that’s the basics here are some of the specifics.

Portal.script

<input-symbol key="columns" required="yes" />
<initialization>
 function init() {    
 portal = new Xilinus.Portal("#portal div", {onOverWidget: onOverWidget, onOutWidget: onOutWidget, onChange: onChange, onUpdate: onUpdate, removeEffect: Effect.SwitchOff}); 
   <foreach key="column" expression="columns">
    <foreach key="portlet" expression="column.portlets">
    portal.add(new Xilinus.Widget().setTitle('${portlet.title}').setContent('${portlet.content}'), ${column.index});
    </foreach>
   </foreach> 
   // Add controls buttons
   portal.addWidgetControls("control_buttons");
 }
 Event.observe(window, "load", init);
</initialization>

What I’m doing here is creating a new Portal (from Xilinus) and then I’m looping through each column and then each portlet inside of the column to add it’s content.

I dive into the hackish parts after the break.

Portal.html

This part contains some of the CSS hackish-ness I was hoping to avoid.

<span jwcid="@Script" script="Portal.script" columns="ognl:columns"/>
<div id="portal">
<div jwcid="@For" value="ognl:column" source="ognl:columns">

    <div jwcid="@Any" id="ognl:'widget_col_' + column.index" />
</div>
</div>

This first part just adds in the Portal.script and then declares the html div element we want to use (this element is used throughout the CSS and JavaScript files. The next piece loops over the TreeSet of columns and outputs one specially-named div for each column.

This just creates the HTML for the portlet controls (don’t know how customizable I’m going to make this yet).

Now comes the hack.

<style type="text/css">
<span jwcid="@For" value="ognl:column" source="ognl:columns" renderTag="false">
#widget_col_<span jwcid="@Insert" value="ognl:column.index"/> { 
  float:left;
  width: <span jwcid="@Insert" value="ognl:column.width"/>;  
  background:<span jwcid="@Insert" value="ognl:column.backgroundColor"/>;
}
</span>
#edit_button {
  background: url(<span jwcid="@Insert" value="ognl:editButton.buildURL()"/>);
}
#delete_button {
  background: url(<span jwcid="@Insert" value="ognl:removeButton.buildURL()"/>);
}
</style>

Here you see I had to do some inline styles so that I could add in some new attributes for the columns, as well as images for the control buttons. I posted a query to the mailing list about 2 weeks ago, asking if there was anything like RCSS (Ruby CSS) where you could actually use Ruby to generate CSS stylesheets - which is exactly what I need here.

After talking with Howard there did not appear to be any good way of going about doing this. One solution discussed was to let the user drop in a replacement stylesheet, but to me this seems silly, they don’t need to recreate the whole style sheet.

Another solution was to create a Tapestry page that acted like a CSS file. This still holds some promise, but is technically going to be a bear to implement due to the fact that we have to change the mime-type. The kicker in all of this though is that this isn’t going to be easier in Tapestry 5, at least not right away.

The other issue that I have with implementing this is what a pain it is to work with JavaScript in this environment and now I completely understand why it wasn’t really worked with before. Customizing the JavaScript that I need to output is a truly a pain, using XML to do my looping for me feels…wrong. If there are two areas I would like to contribute to these are it - making JavaScript and CSS more first-class citizens. Outputting HTML isn’t everything you do in a Web application.

What’s left?

Not quite done with this yet. I still have the following items to clear up:

• Need to make the Portal, Portlet, and PortalColumn classes persistable
• Once that’s done I need to modify the JavaScript hooks so that some kind of Ajax call happens whenever a user moves a portlet, adds or removes a portlet so that their selected portlets are saved in the database
• Need a new Page so that a user can see all possible portlets to add to their custom page
  • For this page was kind of thinking of doing a slick sliding door effect, dunno yet
• Add in some further customizations
• Replace default button images with ones that are easier to read/understand and fit with our internal scheme a bit better (these are customizable)

I’m trying to get this code Open-Sourced, so it may take a little bit to get this code available but it shouldn’t be too much of a problem (and we have some other cool little items we’re going to release as well - just need to clean them up).

Have you ever wondered how to find the Class that has just called your class? Well, now you can (or rather you always could) by using this little trick that I got from my friend and former co-worker Leo.

Class.forName(new Throwable().getStackTrace()[2].getClassName()));

This will retrieve the caller name from the stacktrace and then you can get the actual class using Class.forName(). He uses this in an interesting way for logging.

private static final Log getLog() {
    try {
        return LogFactory.getLog(Class.forName(new Throwable().getStackTrace()[2].getClassName()));
    }
    catch (Exception e) {
        return LogFactory.getLog(FormattedLogger.class);
    }
}

Which he then imports as static methods so that he can just do:

info("Some intereting INFO logging going on here");

Pretty slick and an interesting use of the Java libraries.

But before I do I thought I’d ask everyone out there (who are interested in such a book), what would you like to see in it?

One possibility I’ve been tossing around is to turn it into a techniques or cookbook-style book. I’ve been reading through “Designing Interfaces” by Jennifer Tidwell. In this book she organizes the interface solutions into different sections and goes through each one with an example and what it solves and when to use it. I really like this idea (but others might not). Originally my book was a “How do I get started designing DSLs?” and “What in the world are they and why should I care?”.

Another thing I’ve been thinking about is ditching the Java part and making it Groovy only. This appeals to me because I feel that Groovy is much cleaner to implement an Internal DSL than Java is. Can you do DSLs in Java? Of course you can, but I’m not sure that I can give it the best treatment because it isn’t what I’m passionate about.

So, sound off in the comments, let me know what topics you’d like to see covered, what challenges have you faced in writing a DSL (or API/Framework) that you would have liked someone to trailblaze for you to show the dead-ends first?