Ruby in Java with Maven – Part 1

 Programming  No Responses »
Apr 172009
 

Java is a great language. It has many positive attributes, however one thing java is not good for is fast development. Now that I’m older and a little more impatient, I prefer to work in dynamic languages largely because of their short feedback cycle and instant gratification. Over the last few years, there’s been a movement towards the ability to run other languages within the JVM. This makes a lot of sense with the JVM being arguably the best part of Java. It makes it possible to use a dynamic language but still get some of the robustness and scalability of Java. Languages like Jython, Jruby and Jaskel are Java implementations of dynamic and/or functional programming languages that run in the context of a JVM and share a really nifty naming convention.

These languages have been in development for a while but until recently my team has only dabbled with some of them mainly for testing purposes. I haven’t really considered them a viable option for the “if I could only write this in Ruby” problem until recently. Java 6 has made integration of these languages very clean and easy.

The simple scripting inside java is easily demonstrable using javascript since the javascript engine is built into Java 6. 

/* hello_world.js */
println("Hello World, I'm javascript")

I am going to attempt to run this super complex javascript from inside the JVM. The first thing I’m going to do is create a new Java project using Maven. 

mvn archetype:create -DgroupId=com.weromans -DartifactId=scripting

Since the standard maven archetype doesn’t include a place to keep my scripts, I’ll create the directory ./scripting/src/main/javascript, and copy my hello_world.js file into it.

Just because I’m curious, I would like to see what scripting engines my environment currently supports. As I’ve already stated, javascript is supported out of the box, but let’s go ahead and verify that I’m not just lying to you for fun.

Open up the scripting/scr/main/java/com/weromans/App.java file in your favorite editor or IDE (vi if you’re hardcore), and modify it to include the following:

package com.weromans;

import java.util.List;
import javax.script.ScriptEngineManager;
import javax.script.ScriptEngineFactory;

public class App
{
    public static void main( String[] args )
    {
        ScriptEngineManager manager = new ScriptEngineManager();
        List<ScriptEngineFactory> factoryList = manager.getEngineFactories();

        for (ScriptEngineFactory factory : factoryList) {
            System.out.printf("Engine Name: %s, Language: %sn",
                              factory.getEngineName(),
                              factory.getLanguageName());
        }
    }
}

Let’s just give Maven a little more information about our project so we can compile and run it easily from the command line. Edit your pom file to include the maven-compiler-plugin and the exec-maven-plugin. 

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

    <modelVersion>4.0.0</modelVersion>
    <groupId>com.weromans</groupId>
    <artifactId>scripting</artifactId>
    <packaging>jar</packaging>
    <version>1.0-SNAPSHOT</version>
    <name>scripting</name>
    <url>http://maven.apache.org</url>
    <dependencies>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>3.8.1</version>
            <scope>test</scope>
        </dependency>
    </dependencies>
    <build>
        <plugins>
            <plugin>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.0.2</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>exec-maven-plugin</artifactId>
                <version>1.1</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>java</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <mainClass>com.weromans.App</mainClass>
                </configuration>
            </plugin>
        </plugins>
    </build>
</project>

Now just complie and run it:


$ mvn compile exec:java

You should see the following output:
[INFO] Scanning for projects…
[INFO] ————————————————————————
[INFO] Building scripting
[INFO] task-segment: [exec:java]
[INFO] ————————————————————————
[INFO] Preparing exec:java
[INFO] No goals needed for project – skipping
[INFO] [exec:java]
Engine Name: Mozilla Rhino, Language: ECMAScript
[INFO] ————————————————————————
[INFO] BUILD SUCCESSFUL
[INFO] ————————————————————————
[INFO] Total time: < 1 second
[INFO] Finished at: Fri Apr 17 14:14:45 EDT 2009
[INFO] Final Memory: 3M/6M
[INFO] ------------------------------------------------------------------------

the line Engine Name: Mozilla Rhino, Language: ECMAScript is your applications output and it show’s that the only engine name that is currently supported is Mozilla Rhino which is the javascript engine. Now let’s modify this thing to run our super complex hellow world javascript.

Open up the scripting/scr/main/java/com/weromans/App.java file in the hard core editor of your choice and modify it as follows:

package com.weromans;

import java.io.FileReader;
import java.io.FileNotFoundException;
import javax.script.ScriptEngineManager;
import javax.script.ScriptEngine;
import javax.script.ScriptException;

public class App
{
    public static void main( String[] args ) throws
                                             FileNotFoundException,
                                             ScriptException
    {
        ScriptEngineManager manager = new ScriptEngineManager();
        ScriptEngine javascriptEngine = manager.getEngineByName("javascript");
        javascriptEngine.eval(
                         new FileReader("src/main/javascript/hello_world.js"));
    }
}

Execute it again:

$ mvn compile exec:java
[INFO] Scanning for projects…
[INFO] ————————————————————————
[INFO] Building scripting
[INFO] task-segment: [exec:java]
[INFO] ————————————————————————
[INFO] Preparing exec:java
[INFO] No goals needed for project – skipping
[INFO] [exec:java]
This is hello from hello_world.js
[INFO] ————————————————————————
[INFO] BUILD SUCCESSFUL
[INFO] ————————————————————————
[INFO] Total time: < 1 second
[INFO] Finished at: Fri Apr 17 15:27:26 EDT 2009
[INFO] Final Memory: 3M/6M
[INFO] ------------------------------------------------------------------------

You can see the hello world output from your javascript. Congratulations, you've just done some scripting in the JVM. I know the title says Ruby in Java, but it also says part 1, so you'll just have to check out Ruby in Java with Maven – Part 2 for the ruby part.

 Posted by Matt at 11:24 am  Tagged with:

Grasping Freedom – A Code Randori

 Programming, Uncategorized  No Responses »
Mar 162009
 

Sometime last year I came across Dave Thomas’s Code Kata page and I thought, what a great way to learn a new language, or even just shake the rust off. Eventually I learned that some teams practice code kata’s together. This is known as a code dojo. Since I enjoy team building possibly more than I like software building, dojo’s make kata that much more intriguing.

Why dojo’s? Let’s face it, there are some serious limitations to learning on the job. Sure, Apex Tech seems to like the idea, but even they have a standard curriculum you must follow before you graduate with the tools of the trade. The problem with learning software on the job is the occasionality of the problems which catalyze the lessons. Some very important lessons may go unlearned based on how frequently they come up, or based on the level of exposure to the problem your role permits. There are certainly some common skills we must all acquire and some common lessons we can all learn which will help us avoid repeated mistakes in the field of software development.

We software developers have an additional problem, our craft is quite young. It’s only recently that we’ve started to shift away from thinking of it as a field of Engineering, and college programs haven’t even perfected teaching the engineering version of it yet. It will be decades before programming students begin to enter the field with the required skills to hit the ground running. Collectively, we are far too reliant on “on the job training.” Code dojo’s are a great way to start learning those common lessons in a training environment, as well as help unearth some of the team incongruities that go unadressed in our our day to day work and often slip under the radar of our retrospectives.

I have come across 2 types of code dojo’s. A simple kata is a staged execution of a solvable problem. Kata’s allow the group to watch solution performed illustrating good form. A randori dojo is more dynamic and interactive. In a randori the team collectively codes the problems solution.

Wikipedia currently defines a randori as: a term used in Japanese martial arts to describe free-style practice or sparring, sometimes with multiple attackers. The term literally means “chaos taking” or “grasping freedom,” implying a freedom from the structured practice of kata. This definition may be what intrigued me the most. The most effective form of practice resembles reality closely. In a randori the the problem is fairly simple, it should be something that the team can easily get their heads around. The focus shouldn’t be on the problem, but rather the techniques used to solve it, and the problems that arise during the course of the randori. It is not necessary to solve the problem completely. Similarly to rock climbing, it’s about the climb, not the summit.

For our randori’s we have adopted the rules that are very well laid out by Agile Finland on their code dojo page. The rules of the randori like anything else on an agile team are subject to reflection and modification. Each randori ends with a quick retrospective, the output of which helps refine our rules.

  • There is a coding challenge that is announced beforehand.
  • There is a room with one computer attached to video screen and set up as a pairing station (2 keyboards, 2 mice).
  • The presenter explains the coding challenge and starts the Randori with a pair from audience.
  • One half of the pair is changed every 5 minutes.
  • The pair on the keyboard should continuously explain what they are doing.
  • The pair on the keyboard should stop when someone from the audience falls off the sled — and only continue when that someone is back on track again.
  • The audience should give comments on design only when there is green bar. (During red bar audience can only ask questions)
  • The pair should not continue on writing new code if other participants are not happy with the current design (The code should be always well refactored before starting to write new code)
  • The pair will use TDD (Test-Driven Development), preferably employing the ping pong model of writing and passing tests.
  • The programming language to be used is announced in advance per session.
  • The maximum number of participants is limited to 15.
  • The presenter acts as a product owner
  • The actual coding is done in small iterations. There are short planning period before every coding iteration.

Some randori’s end up being clean practice session and a knowledge exchange for best practices and good craftsmanship. They usually start off a little rough but really gain momentum during the second iteration. These randori’s have helped us model good behavior in terms of TDD and pairing. Other times we’ve run into a rut which prevents us from making good progress on the randori problem. We find these randori’s to be even more valuable than the former. They expose the problems that hinder us during our day to day work but are less noticeable in the broader context of an iteration.

 Posted by Matt at 2:15 pm
© 2012 WeRomans Suffusion theme by Sayontan Sinha