As I sat through the interview, I went through the usual motions of answering their questions about my background, listened to their marketing talk about how great their company is, and I chatted a bit about my hobbyist programming I did in my free time. Then came the bad news…. the interviewer smiled as he mulled over my resume, and he said he noticed that I didn’t have any COBOL experience. He asked me if I had ever taken any COBOL classes at the college, and I told him no… as far as I know they don’t even have it in the curriculum anymore.

“Really?” he replied, with a slight look of shock on his face. “Well, all of our systems are written in COBOL here, so that’s what you’d be developing in. We really need someone with COBOL experience.”

“Well, I pick up languages pretty quick… I just learned python last week and was able to do all kinds of things with it… I probably wouldn’t have any problems learning COBOL and actually using it.” I replied.

He smiled. “Well, that’s great James. I’ll tell you what, I’ll talk with the rest of my staff and I’ll try and get back with you by the end of the week to let you know if you made it in.”

And I never ever heard from them again. Another guy at my university, who had made straight As in CompSci and double majored in Mathematics got hired out there the following week, so I guessed maybe I just didn’t have a high enough GPA to meet their standards. I remember wondering what was so special about the language… I looked around online and the examples I found were pretty ugly and I remember wondering if it was some kind of joke? But I did hear from the guy who got the job out there that yes… all they programmed in was COBOL.

Looking back, I’m damn happy I never got the job. A large part of my growth was working for a small start up firm and getting the chance to work with all kinds of languages as well as do a lot of reading online to self-teach myself (I didn’t have any senior developers to work with… just me at first) that led me to read books like Design Patterns, Patterns of Enterprise Application Architecture, Refactoring, and even Extreme Programming Explained as I searched for a methodology to manage our projects. With no one to turn to, I often sought help in online forums, mailing lists, and usergroups in St.Louis. I think all of that played a large part in growing as a developer and evolving my thinking.

If I had gotten that job, I probably would have done my best to excel at it… and perhaps by now I would have been promoted to the position Programmer Analyst II.

I decided to use it to build the kind of project that enterprise architects go ga-ga over: a multi module project that contains a shared module with an interface (containing JAXWS annotations), a services war module to create a service implementation, and a client implementation to call it. It was a breeze and I finished it in a couple hours.

For starters, I created a root directory and created the following build.gradle and settings.gradle file in it:
build.gradle:

subprojects {
        usePlugin 'java'

        repositories {
                mavenCentral()
        }
        dependencies {
                testCompile 'junit:junit:4.7'
        }

        group = 'org.jamescarr'
        version = '1.0'
        sourceCompatibility=1.6
}

dependsOnChildren()

settings.gradle:

include "shared", "api", "services"

Running gradle build from this directory will auto-create your directories for you. I went ahead and created the source directories and build.gradle for each module myself, but there are ways to make your script do that too, more on that in another post.

In our shared project, there’s really no dependencies, so the build.gradle file is left blank. We just create the following interface under src/main/java:

package org.jamescarr;
import javax.jws.WebService;
import javax.jws.WebParam;
import javax.jws.WebMethod;

@WebService
public interface Greeter{
        String getGreetingFor(@WebParam(name="greetee") String greetee);
}

Nothing fancy. Now let’s make the service. Foremost, it’ll need to depend on shared since it’s going to have the actual implementation in it. We’ll also depend on CXF to setup the cxf servlet as well as use the war and jetty plugins so we can produce a war artifact and the jetty plugin for running it locally.

services/build.gradle:

usePlugin 'war'
usePlugin 'jetty'

dependencies {
        compile project(':shared')
        compile 'org.apache.cxf:cxf-bundle-minimal:2.2.6'
}

At this point, doing a gradle build will auto generate your src/main/webapp directory, and if you throw an index.html file in there and run gradle jettyRun your server will start up and you can navigate to http://localhost:8080 to see it.

Now let’s write our Greeter implementation.
src/main/java/org/jamescarr/EnglishGreeter.java:

package org.jamescarr;
import javax.jws.WebService;

@WebService(endpointInterface="org.jamescarr.Greeter", serviceName="GreetingService")
public class EnglishGreeter implements Greeter{
        @Override
        public String getGreetingFor(String greetee){
                return "Hello " + greetee;
        }
}

Next we need to add a web.xml to src/main/webapp/WEB-INF and an application-context.xml file under src/main/resource. Since this is the part where it get’s ugly, I’m simply going to link to them on github… you can see them here and here.

Now if we go the root of the services directory and run gradle jettyRun our server will be up and running and if you navigate to http://localhost:8080/services/services (if I had named the module something else it wouldn’t look so silly) you should see the generated CXF page listing the available services, and Greeter -> getGreetingFor will be listed. Now let’s create the client and start communicating with the service!

In the client, we’re just going to create a quick client using JaxWsProxyFactory directly, but in most projects you might configure this in spring and inject it using the service interface. So we’ll need to depend on our shared project for the interface and cxf for the proxy factory. We’ll also setup a task named “run” to simply run this from the commandline and see the output.

api/bild.gradle:

dependencies {
        compile project(':shared')
        compile "org.apache.cxf:cxf-bundle-minimal:2.2.6"
}
task run(dependsOn:'build') <<{
        ant.java(classname: 'org.jamescarr.Main', fork: false,
        classpath: "${sourceSets.main.runtimeClasspath.asPath}")
}

The run task depends on the build task, so we can ensure it builds the project before trying to run it. We also set fork to false on the ant.java task so we can see the System.out.println I’ll put in the main class to print the result out. Okay, now let’s whip the java class real quick:

api/src/main/java/org/jamescarr/Main.java

package org.jamescarr;
import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
import org.jamescarr.Greeter;

public class Main{
        public static void main(String... args){
                JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
                factory.setAddress("http://localhost:8080/services/services/english");
                factory.setServiceClass(Greeter.class);

                Greeter client = (Greeter)factory.create();
                System.out.println(client.getGreetingFor("James"));
        }
}

I don’t want to get too deep into the intricacies of CXF, but all this does is create a proxy factory for our endpoint and generates a client object that we can use to call it.

Now to finally see all this work, drop down to the commandline in the api directory and type gradle -q run. If everything works well, you should see “Hello James” printed to the console. A perfect Hello World example bringing together SOA and the pure awesomeness of gradle.

Hope you enjoyed it, if you want to take a look at the code and tinker with it hands on, feel free to clone it from github.

Luckily, gradle includes practically all the ant tasks so you can simply use ant.java:

task run(dependsOn:'build') <<{
        ant.java(classname: 'org.jamescarr.Main', fork: true,
        classpath: "${sourceSets.main.runtimeClasspath.asPath}")
}

We want it to depend on the build task so it will compile our classes and dependencies, then it’ll work as expected.

The symptoms are quite visible in any organization… different values, practices, and concepts that we use in the agile world for improving our teams are bastardized and turned against the team in the form of forced metrics that are required to be met. This doesn’t help the team one bit and honestly will simply cause the team much grief and do diddly squat to improve anything.

Four years ago I listened to Dave Thomas give a pretty good presentation on Cargo Cults and I’m now realizing something… most companies continue to use the cargo cult approach to adopting agile. They’ve bought into the silly idea that if you do X, Y and Z software will get released faster with zero defects. We’re better than that, and our industry deserves better than that.

Let’s drop this idea of agile being “a set of practices” to be strictly followed. If we really want to succeed at agile we first need to empower our teams to succeed.

Luckily, after some searching, I found this solution in the FAQ:

$ export GDK_NATIVE_WINDOWS=true
$ ./eclipse

That seems to have fixed the problem for me… but according to the FAQ “Your Mileage May Vary”. Good luck!

Yes it’s true… there in is a framework that acts just like mockito for javascript: jsMockito!

The stubbing action looks pretty cool, and I’ll try in depth later when I’m home. But here’s a quick sample to whet your appetite:

    var mockedObject = mock(Array);

    when(mockedObject).get(1).thenReturn("hello world");

Today I did something that made me step back and recall a time long long ago when I was working with SOAP on a project. See, I had to integrate a PHP application with a SOAP service and used a utility to generate all the client objects and stubs I needed, then ran into a weird problem. One of the fields in the response object contained a string… of xml. This meant I had to go and parse data manually out of that field by hand rather than having a nice object model created by the utility I used.

“Those stupid morons! Why can’t they learn to embrace the technology they’re using!”

Why did they have to go and embed xml inside a cdata tag!? Why couldn’t they just import the namespace for it (it was schema-less anyway) and include it in the SOAP body??

Anyway, what triggered this recollection? I was working on a SOAP service that returns, in addition to some information used by the application, a binary attachment that is read into a 3rd party library on the client side. Let’s say it’s a PNG or something. Anyway, we decided to try out some different image adapters on the server end and I discovered that I could change the format to SVG and not only would the 3rd party library used on the client be able to parse it… I wouldn’t even have to change ANYTHING on the client side because the 3rd party library automatically detected the type. So I switched the output to SVG and reran the client app… perfect! It worked fine. Then I looked at the raw soap packets it produced while testing it with SoapUI:

<image><!CDATA[[<?xml version="1.0">
<svg width="100%" height="100%" version="1.1"
xmlns="http://www.w3.org/2000/svg">
...]]></image>

*Facepalm*

I suppose to my credit, it’s not as if the client app itself is meant to parse the SVG data itself anyway.