Open Source

Time to come back to Firefox? Maybe… just maybe…

I posted this in the Open Source LA meetup too, but I thought it was worth repeating here:

new-firefox-versionFull confession: I’ve been on Chrome basically since it came out. I abandoned Firefox years ago because it was slow, bloated, etc… In fact, in even fuller, richer, Technicolor confession: I even started the Open Source LA Meetup group using Chrome.

But I think it’s kind of serendipitous that on roughly the same day that I got the group launched, Firefox released a fantastic new version of the browser. And I don’t need to confess anything to tell you that I’m using it now.

I know all the blah, blah, blah with Mozilla and some guy named Brandon and so on… but maybe those just dark days for Mozilla’s and in a era of you-as-a-product-because-you-use-Chrome and a new era of conscientiousness around things like open source… maybe Mozilla’s (and Firefox’s) very best days are ahead.

In a bold move for me, I already made it my default browser.

Open Source

Building an open source community

group-photoToday I created a new Meetup group called Open Source LA. I don’t know if it will go anywhere, but I think there’s room for this kind of group.

And I posted a message to the group, which currently consists of just me, paraphrasing David Hurley’s recent post:

(1) You are still on the hook for support: just because you open source the project doesn’t mean that any developers are going to jump out there and answer support questions.

(2) You need to be the innovator: just because other people can fork and enhance your code doesn’t mean they will; your codebase will likely stagnate without your heavy involvement.

(3) Nurture your contributors: why should anyone help you? If you were building a community playground together, how would you encourage people to help? (Actually, Mr. Hurley put this point quite differently, but this is my post so I get to paraphrase.)

(4) Explain your mission, make it transparent, and stick to it closely.

(5) Fail fast: this is kind of obvious to me at a product level, but I think the idea of “failing” in front of a whole community by writing crappy code or making shoddy architectural choices is something a lot of coders — including me — fear. Don’t.

I hope you’ll consider joining my little Meetup group — or at least tell me why I should fail fast! The group is here: Open Source LA.


Cecil the caterpillar

We adopted this caterpillar from Kidspace in Pasadena a while ago. I swear I never seem to get over the whole metamorphosis thing. Why is it so complex for something than only lives a few months??





Getting started with JBoss AS 7 and OpenShift — the absolute minimum

tweet-openshitStep one: First of all, do yourself a huge favor and take advantage of RedHat’s free giveaway for Getting Started With OpenShift.

openshift-getting-startThe O’Reilly edited free ebook doesn’t cover Java or JBoss or enterprise stuff specifically, but it’s generally written at just the right level to get you started as a developer. Honestly, I played around with Heroku and a few other PaaS services, and I struggled a little until I found OpenShift and the book. Do it!

Step two: sign up for an OpenShift account. You’re a developer, you’re smart enough to figure this one out.


Step three: download and install the OpenShift RHC Client tools so that you can interact with the OpenShift server through the command line. Are you assuming you’d rather work with GUI? I get it, but the command line tools are more powerful. Just take it on faith for now.

openshiftTo install the RHC Client Tools, you actually need to install Ruby first to get access to the gem package management service, but don’t worry too much about it; the process is pretty straight forward. The documentation explains it well, and it’s easy.

Step three: deploy a fresh JBoss AS 7 instance (cartridge on a fresh gear, in OpenShift lingo) in less than a minute by typing the following:

[code lang=”java”]
rhc create-app test jbossas-7

You’ll see something like this:


Nicely done. You’ve just deployed a JBoss AS 7 instance. Point your browser at the URL listed and you’ll see something line this.


Pretty amazing considering how much work used to go into setting up a new application server on the ‘net.

I’ll do some more posts to go into more detail later, but I hope this gives you the confidence to go forward. The OpenShift service is pretty amazing.


Los Angeles

Sushi for dinner; barbeque for lunch



Los Angeles

Easter eggs



Maven Surefire + Failsafe, the easiest way

Tell me I’m not the only one. Your web application has a bunch of unit tests, and Cobertura says all kinds of nice things about your coverage. But every now and then you check something in and the build breaks. But it worked locally, so what the hell?

mavenThen you realize that one of the tests depends on a REST call to some other system, and they changed their data. In other words, you realize that you, my friend, have a mix of unit tests and integration tests.

Don’t panic. Just add the Maven Failsafe plugin to your build. Failsafe is similar to the default testing plugin that you already know and love: Surefire. But it’s specifically made to run integration tests. There’s a lot of great documentation, but I hope this example will get you up and running faster than I did.

Step one: add the Failsafe plugin to your pom

[code lang=”xml”]

Unfortunately, the Failsafe plugin doesn’t come out of the box like Surefire does so you have to explicitly add it to your build.

Step two: separate your unit and integration tests by convention

By default, the Surefire plugin will pick up any classes named * or * By contrast, Failsafe picks up any classes named * That’s nice because you can let them coexist in the same src/test/java folder.


Just for reference, here’s my “code” for the Demo tests:

[code lang=”java”]
public class DemoTest {
public void test() {
System.out.println("Hi. I’m a unit test.");


[code lang=”java”]
public class DemoIT {
public void test() {
System.out.println("And I’m an integration test. Can’t you tell?");

Step three: run mvn verify and check the output

The verify life cycle runs both test and the integration tests (check the documentation for a lot of important detail):


You’ll see it run the normal unit tests:


And then it runs again for the integration tests:


As to how you’re going to integrate this life cycle into Jenkins, Bamboo, or whatever — I’ll leave that up to you! Good luck out there and let me know how it goes.


“Imperative code should be your default, your first choice as of Java 7”

Let’s say you’re not at Java 8 yet, you’re still learning how to spell l-a-m-b-d-a (see? I did it), and yet you still want to get into this functional programming “thing.” But let’s also stipulate that you know and love Guava.

Even though the Guava team cautions that “functional programming in Java can only be approximated through awkward and verbose use of anonymous classes,” you know that the Guava folks have also tempted and taunted you by creating a number of classes and interfaces that look an awful lot like Java 8’s new functional interfaces (see, e.g., Predicate and Function). Resistance is futile, you remind yourself.

So you create something like this:

[code lang=”java”]
public void whatever() {
class Student {
final String firstName;
final String lastName;
public Student(String firstName, String lastName) {
ImmutableSet<Student> students = ImmutableSet.of(
new Student("James", "Jones"),
new Student("Neil", "Sanders"),
new Student("Michael", "Rice"),
new Student("Michael", "Shore"));
Iterable<Student> michaels = Iterables.filter(students, new Predicate<Student>() {
@Override public boolean apply(Student input) {
return StringUtils.equalsIgnoreCase(input.firstName, "michael");
for (Student michael : michaels) {

Looks kind of slick and kind of functional, huh? Looks like it gets you a few steps closer to Java 8, right? But then you’ve got a comment something like the following from the Guava team: why don’t you just loop through them? That’s easier to read, isn’t it? They say the following is more virtuous (at least for Java 7 and older) — largely because it takes fewer lines of code and because it’s more readable:

[code lang=”java”]
// …
Set<Student> michaels = new HashSet<Student>();
for (Student candidate : students) {
if (StringUtils.equalsIgnoreCase(candidate.lastName, "rice"))
// …

In fact, the Guava folks go so far as to say:

Please be sure, when using Guava’s functional utilities, that the traditional imperative way of doing things isn’t more readable. Try writing it out. Was that so bad? Was that more readable than the preposterously awkward functional approach you were about to try?

The Guava folks are really thoughtful about the code, so I have no issue with their comment except that they’ve missed an important psychological component. They missed the fact that it’s so much fun.


The simplest Gradle example I can come up with

gradleI’m just now getting into Gradle, and I had a little trouble just Googling a simple build script that would get me up and running with a basic Spring MVC web application quickly.

In case you’re looking for the same, here’s what I came up with:

[code lang=”groovy”]
apply plugin: ‘war’
apply plugin: ‘jetty’

sourceCompatibility = 1.6
version = ‘1.0’

repositories {

dependencies {
providedCompile ‘javax.servlet:servlet-api:2.5’
compile (‘org.springframework:spring-webmvc:3.2.2.RELEASE’,’javax.servlet:jstl:1.2′)
testCompile (‘junit:junit:4.11’, ‘org.springframework:spring-test:3.2.2.RELEASE’)

jettyRunWar.contextPath = ”

For the record, I’m only focusing on Spring because that’s what I work on most of the time these days.

  • The first section declares plugins. I think this declaration block is quite a bit more expressive than Maven, where you have to declare plugins at various points in the pom.xml in a really verbose way. With Gradle, it’s pretty simple (query if I’m losing power?): you can quickly tell from my script that I want to package the project as a war (for Tomcat/servlet container deployment) and that I want to be able to run Jetty locally to test it.
  • Next, similar to Maven, Gradle needs access to a repository of artifacts. Gradle gives you access to the Maven Central Repository by declaring mavenCentral() as a repository. It’s definitely easier to read than a pom, but again, query whether I’m losing some configuration power here.
  • Finally, we need to declare our dependencies. If you understand the Maven coordinate scheme, then Gradle is a little easier than the verbose pom.xml. Plus it’s easier to see what dependencies go into what build cycle. For example, I’m declaring the servlet API at compile time, but I’m not declaring JSTL or Spring MVC until the actual compilation (yes, yes, I know my Spring MVC is a little out of date). NOTE: it seems like Intellij got the dependency wrong when it created my initial gradle file. The JSTL dependency actually needs to be bundled into the WAR to get the “newer” JSTL syntax.

So there you go, it’s not that different from Maven:

  1. Tell Gradle what plugins you want to run.
  2. Tell it where to get its artifacts.
  3. Tell it what artifacts you want.
  4. Save it as build.gradle and then run gradle tasks to see what you can do with it.

Good luck out there.


Finally, a Java enterprise podcast

I still love the Java Posse, but this is the Java enterprise podcast I’ve been looking for. Great job guys!!