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.

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”

A friend of mine passed this link on to me from the Wired site - Want to Remember Everything You’ll Ever Learn? Surrender to This Algorithm - which is a very interesting article on a Memory technique (and the man behind it).

After some digging on the corporate Web site I found the “free” version which is actually a pen and paper version that you can use. I also shared this with my friend Kate who told me about a similar method called Pimsleur - but it is only available for languages.

After reading through this I have decided to give it a shot on an upcoming Computer Science course I’m taking this summer on Discrete Structures (basically a math course disguised as a CS course). I’ll continue blogging regularly on this so I can actually track my progress with it. As Kate said “We need a Mac app for this.” Twould be nice but I don’t have time.

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.

So at work I’ve been using Ubuntu on my desktop as my primary computer. I have primarily been a Windows user at work (because I have been forced to) and an OS X user at home because I prefer it. At first I kinda liked it, at least a little better than Windows. Then I began to hate it for the following reasons:

• It works just like Windows (and looks almost like Windows)
• Except when it doesn’t - then it sucks because it doesn’t work in a predictable manner

Here are some key problems I’ve had with Ubuntu:

• It can never quite remember my monitor settings properly - every time I remove a monitor or want to switch a display it loses everything or goes extremely flakey
• We play Unreal here afterhours and the audio just “disappears” - if I futz with the monitor settings then I lose Audio, hunh? Reboot required to get audio back
• No common UI - dialog boxes behave differently, things just feel “off” depending on which program I’m using
• Katapult is a poor replacement for LaunchBar or QuickSilver (which started crashing repeatedly on me on the last update so switched to LaunchBar)
• Installing an application takes command-line work - blech

The are a few good things, but not enough for me to love it:

• Wow, a real terminal - but I have this in OS X
• Updates are painless - again I already have this on OS X
• It’s stable - again I already have this on OS X
• That’s about it - otherwise, eh

This isn’t to say I don’t use Linux, I use it for my server, but I can’t see using it as a desktop replacement, not by a long shot. In order to win me over they have to really be thinking out of the box and not just duplicating what Windows or OS X has done - which they really haven’t yet (yes I know about things like Compiz Fusion - but that isn’t the whole user experience that’s just one small part - yes I said small).

So, I’m using a G4 machine right now to VNC into my work machine for specific apps I can’t install (or don’t want to) and will be upgrading the laptop to either a MacBook or MacBook Pro in the next few months. Then I’ll be really happy.

I’ve been working on a project for a family member and need a good Content Management System for them to use. Here are my requirements:

• Easy to understand interface
• Generates URLs that are human readable - no blah.php?page_id=123 crap
• Easily supports internationalization as the site itself will need to be translated into multiple languages
• Preferrably Java (but open to Rails, and not really interested in PHP)
• Doesn’t take a rocket scientist to create and edit site templates

What I’ve looked at so far has been:

• Radiant CMS - too simple, with code embedded and no Rich Text editor that they won’t understand
• Magnolia - Waaaay too complex, nice for an enterprise solution but not for what they need it for

Just downloaded Liferay and will be taking a look at that, Daisy and JBoss Portal. Another suggestion made to me was to possibly use Contribute, which I think I’ll have them download and try out to see if it works for them (but then I’ll have to do the whole locale thing through Apache).

I’ve looked at the CMSes listed here.

• Jahia - ok, after relooking at it I may download it and try it out
• Magnolia - too complex for my needs
• InfoGlue - looks complex just like Magnolia
• Apache Lenya - had a very bad experience with this in the past and the interface looks just as awkward to use as it did before - pass
• Daisy - looks interesting
• MMBase - no online demo and I wasn’t wild about the screenshots I did see, passing for now

What I’ve found so far with alot of these (just through using their online demo) is that the interfaces are very complex. I don’t know if this is supposed to go along with their “Enterprise” tag or not, and of course a fair number of them tout their JSR-170, 168 compliance. Ok, JSR-168 might be important to know, but do I really care if they are a fully compliant Java Content Repository? Nah, not really, I just want it to work and have a usable interface. Some may care about that but to me it isn’t a selling point. I respect the CMSes who put up an online demo, it gives me a chance to play with it first to see if it’s even close to something I want, those that don’t I look for screenshots, and most likely move on anyways.

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.