BlackBox

I’ve been working on Chama recently and have been making some good progress. One of the last big hurdles before getting all of the Model, View, Controller generation working has been:

1. Connecting to a database and gathering metadata – 90% complete (just have the relationship, primary key, foreign key stuff to work out)
2. Getting Chama packaged up as a real distributable app that you can download and get up and going quickly

Rather than go through a whole bunch of Ant copy scripts and integrating that with my Maven build I decided to write a plugin that would copy everything over into a specific directory structure and zip up for me (and I can also add in the tar.gz stuff real easy now too). I gotta say it wasn’t too difficult, although the docs leave a lot to be desired in this department. With all the plugins out there you would think this would be more fleshed out, especially since they want everyone to move away from the old Jelly scripts that people wrote in Maven 1. Anyways, it’s fairly simple to do with some caveats.

• There appear to be no docs on what all the custom expressions are such as:
  • expression="${project}"
  • expression="${project.build.directory}"
  • expression="${component.org.codehaus.plexus.archiver.manager.ArchiverManager}"
• Or if you can actually use expressions like these when setting default values of properties (you can, at least that’s what I’ve gathered by looking at other plugins)
• And if you do or do not need to have getters and setters for your variables that you’ve “annotated” (I say that in quotes because it doesn’t act like true annotations, or at least there isn’t a package in Maven called annotations where you can find docs on all of these)
  • My assumption is that at least the setters are necessary so that it can use those to populate the variables you want Maven to populate your plugin with)

All that said it was mostly easy to write my little packaging plugin as I was willing to dig through the source code of some of the existing plugins that were doing similar things (maven-assembly-plugin and maven-war-plugin). That isn’t to say that I’m 100% sure I understand exactly how everything works (good idea but not 100% .

If I get a chance I’ll see if I can contribute something a little more to the plugin docs than what is there currently because others shouldn’t have to do what I did to get through this and it isn’t that difficult once you know the secret handshake.

This post started as a seed from interviews that we are holding for the project I’m working on for my day job (Kuali). The vast majority of the programmers that are working on this project are the cream of the crop from each institution. That isn’t to say that I’m one of those or that the rest of the programmers are not excellent, they are, but it’s a higher standard. This standard makes us that more critical when we choose new programmers that are going to come on to the project.

One of the qualities that I tend to look for (without really knowing it until recently) is passion. When someone comes in and just does the bare minimum or a little above that to get the job done it tells me that they have no passion for what they do. All of the good or excellent developers that I know all have a passion for programming. To them it isn’t just a job, it’s something they enjoy doing and they enjoy expanding their horizons, not because it is a part of their job, but because they truly enjoy it.

I think that this passion extends further than just this though, most of the good programmers that I know are passionate about other things and aren’t afraid to share their passion with other people. This of course can lead to either a healthy discourse or heated debate in the office or elsewhere , this is what happens when you get passionate people together. Of course one of the tricks of a truly good developer is to know when to put your passion (and your ego) on the shelf for the betterment of the project or task at hand.

Further along this line of thinking lies creativity, in his piece ”Hackers and Painters”, Paul Graham describes the commonality between hackers and painters

What hackers and painters have in common is that they’re both makers. Along with composers, architects, and writers, what hackers and painters are trying to do is make good things. They’re not doing research per se, though if in the course of trying to make good things they discover some new technique, so much the better.

And honestly I couldn’t have said it better myself, but I’ll elaborate on this idea a little further based on my personal experience. Every really good programmer that I’ve met has had some other creative bent, most of them have been musicians of one form or another, or they have really been into photography, painting, etc. I think that this derives from the desire to create, to make. One of the reasons why I like programming is because I like to make stuff, for me this has also extended to music, film, and writing (in fact I started out writing fiction way back in grade school). But it is the act of making, the act of getting something to work that fascinates me still. Whenever I hear a problem that needs a solution my mind immediately shifts into “maker” mode and I start thinking about how I could so do that – if only there were like 20 of me all of the cool ideas I’d ever had would be done .

This all leads back to passion, if you are truly passionate about what you do then you will do better at it, it really is that simple. But that doesn’t mean that that is where your passion has to end, I would say that if you are currently playing around with the idea of learning how to draw, or learn how to play an instrument, do it, don’t wait.

So, I was more than a little disappointed to discover that the Grails developers are using Ant for most of the command-line stuff (partly because I was hoping to learn some cool tricks for starting up HSQLDB and Jetty for Chama). It just seems a little weird to me to rely on Ant tasks to do something that in my mind should be handled as part of the class (or Groovy file in this case).

Here are some examples of what I’m talking about:

    <target name="run-app:impl">
        <basename property="project.dir" file="."/>

        <groovy>
            import org.mortbay.jetty.*
            import org.mortbay.http.*

            System.setProperty('org.mortbay.xml.XmlParser.NotValidating', 'true')
            def server = new Server()
            project.addReference('server', server)
            try {
                def listener = new SocketListener()
                listener.setPort(properties.'server.port'.toInteger())
                server.addListener(listener)
                server.addWebApplication("/" + properties."project.dir", 'tmp/war')
                server.start()
            } catch(Throwable t) {
                t.printStackTrace()
            }
        </groovy>
    </target>

I can understand, to a certain degree, why one would do something like this, but this seems like a bit overkill. I have a real problem with adding scripting into Ant files, it just seems like you are really pushing Ant to do something that it was never meant to do, but that’s just my opinion.

Also, to be fair, the Grails developers seem to have realized this and are now moving towards a true command line interface with the GrailsScriptRunner.groovy. Again though they are tying themselves to Ant unnecessarily. My personal preference is to create a true standalone command line interface (which is what I’m doing with Chama).

These are, of course, my opinions but I thought that others not familiar with Grails might be interested. And also note that I loathe Ant , I’m a true Maven convert.

Ok, if you haven’t heard of Krugle yet and you do any kind of programming you should read this.

No, I don’t work for them (although they seem like a cool company for sure), but I have been using their service for a little while and have been very impressed. So what is Krugle anyways? Krugle is an online index of Open Source Software source code that is searchable.

How is this different from just plain google? First, it has indexed the source by language and by project so if you know what language you are searching for that eliminates a lot right off the bat, plus if you know the project (or projects) you expect to find your source in then that narrows it down quite a bit more. Plus you can also choose whether you want to search just class files or other files within a given project (very handy for html templates and the like).

Alright, but how is this different from Google’s Code Search? Google’s Code Search also allows you to search via language type, but not really project. Additionally Krugle’s search interface is more geared towards exploration, with all of the class files listed cleanly and once you drill down you haven’t lost your search results and can easily build up a shopping cart of classes you are investigating. Another cool thing they did is to actually show you the tree of the project that you are in once you are viewing the class file so you can navigate around the rest of the project easily.

About the only thing I would like to see them add would be a source cross-reference so that I could easily navigate to other classes defined within a class-file. But I could see how that type of thing would get tricky very quickly with all of the different languages they are supporting.

So far I’ve had Krugle save me 3 or 4 times and Google’s Code Search only once, so I’ll definitely head back to Krugle first (now if I could only remember the name .

So, I decided to use Yaml for all of my configuration needs, in order to use this I needed a library to interface with it, I found JYaml which seems to fit the bill nicely. Here’s a short example of what I’ve used it for in Chama.

--- !org.chama.db.DBConfiguration
dev: !org.chama.db.DBConnection
  dbName: chama_dev
  driver: org.hsqldb.jdbcDriver
  url: "jdbc:hsqldb:mem:"
  username: sa
production: !org.chama.db.DBConnection
  dbName: chama_production
  driver: org.hsqldb.jdbcDriver
  url: "jdbc:hsqldb:mem:"
  username: sa
test: !org.chama.db.DBConnection
  dbName: chama_test
  driver: org.hsqldb.jdbcDriver
  url: "jdbc:hsqldb:mem:"
  username: sa

DBConfigurationTest.groovy
class DBConfigurationTest extends GroovyTestCase {

    void testReadConfigFile() {
        DBConfiguration config = Yaml.load(new File("src/test/conf/db.yml"))
            assert config.test.dbName == "chama_test"
            assert config.dev.dbName == "chama_dev"
            assert config.production.dbName = "chama_production"
    }

}

I also found another package when I was having some difficulty with JYaml called JvYaml, but when I tried to save my configuration class it gave me a nested object exception telling me that I couldn’t save nested objects into my Yaml file. That seemed kinda stupid to me so perhaps I was doing something wrong, but I didn’t have time to try and figure out what it was and went back to JYaml.

I first read about Processing in an old Wired issue (wow, finally found it, do you know how hard it is to search on “processing” on the Web? Uggh). When I first found Processing I wasn’t even thinking about DSLs (this was 3 years ago), but I know that one of my first thoughts was “Why not just use Java directly?”, but now I definitely see the light. I’ve been following the amazing work that others have been doing with Processing who have very little Java programming experience, but they know 2d and 3d graphics.

The cool thing is, is that while Processing is a DSL it is built on top of Java and can leverage any of the packages that Java has (much like Groovy can) which leads to some very interesting hardware projects. And of course, I’m also interested in Processing because I love 2d and 3d graphics and finding interesting ways to interact with them.

In short, I guess, I just wanted to point out that DSLs are everywhere, even if we didn’t see them at first, they aren’t a new idea, they’ve just been given power by naming them (much in the way that Ajax was).

Anyone have some other interesting DSLs that they’ve found?

Guillame Laforge (one of the Groovy programmers) posted his thoughts on using Groovy as a DSL.

With the help of closures, methods, operator overloading, adding
properties & methods to classes, with named parameters and so on, you
can quickly come up with a language of your own, a DSL, targeted at
the subject you’re dealing with.

This was in response to an article that ran on Artima “Creating DSLs with Ruby”, of which most of the examples could be easily modified to Groovy code.

The Groovy team has created a page, “Writing Domain-Specific Languages”, to showcase some of the examples of using Groovy as a DSL, which I will probably be committing more to as the Chama project continues.

So, where has all this DSL stuff been leading? One of my projects that has been sitting on the back-burner for a while has been Chama. Chama was born out of the frustration of writing the same boiler-plate code over and over for database-backed sites that are run on Tapestry. While you can certainly use something like Trails I was not happy with the additional amount of configuration I needed to do in order to get the forms to look and behave the way I wanted them to.

Why not use Ruby on Rails then, or even Grails if I want to stick with the Java theme?

A variety of reasons:

• I’m familiar with Tapestry, Hibernate, etc.
• I’m very familiar with Java
• I want to learn Groovy as a language
• I don’t want to switch out my deployment options to have to deal with deploying my apps to a new server and having to configure it all over again so that it’ll run RoR
• I like generators , no really this is an exercise that I want to undertake and if others find value in it that’s great
• Mostly to make it easier for me to get some app ideas I’ve had off of the ground

What will Chama use:

• Groovy as the primary language, with some Java thrown in where needed
• Most likely Yaml for configuration with JYaml for dealing with it
• Quite possibly several DSLs for each area (Model, View, Controller)

I don’t know yet exactly how far I’m going to take Chama, mostly I just want to get a tool together that will help me build stuff. If others find value in it and it gets extended from there and heads in a direction I never thought about, great! All the code will be available under an Apache License once I start working on stuff. I have some tentative dates setup in my Trac instance (what?! using Python for a Java app?). Comments are welcome, and I will use this blog to announce releases as they happen, the first milestone is set for 12/22/06 (oops was tomorrow, moving to two weeks, wow it’s been two weeks since I first set this up already).