Saint Louis, Technology City Extraordinaire

Saint Louis is a sweet spot to be a developer right now because there are tons of jobs.

Saint Louis is a sweet spot to be a passionate developer because we have an amazing user group community. There are active user groups for Java (two), Ruby, JavaScript, and .NET (two). There’s user groups for mobile, AppleHadoop, vim, and Perl. Then there’s Lambda Lounge for the really interesting stuff that you won’t use in your day job.  If you want to skip the talking and just code, you can’t beat Code Til Dawn!

All of these groups are friendly to attendees and speakers. We have many great recruiting firms that sponsor food and space, sometimes even flying speakers in from out of town.


Now here’s the real skinny – the user groups that I attend regularly ranked according to alcohol content:

1. STLJS – it’s above a bar. The bar has scotch. It closes at midnight, but we’re still drinking and talking about code past that. Food: sandwiches
2. Lambda Lounge – we bring beer, and go to the Hive (nearest bar) for more drinks afterward. Food: pizza
3. ALT.NET – some of us bring beer, and at least once the speaker brought vodka. Food: snacks at best
4. JUG – no beer. No bar. Only technical. But – Ted Neward in July! Food: pizza

Special kudos to ALT.NET, because Nick recruits some of the best speakers: Steve F-in Bohlen, Ken Sipe, me. It is a more intimate user group than the others, with a smaller venue and great discussions, and beer. The topics are technical and a good depth. Now if only I could get those guys to the bar afterward, it’d be perfect.

IntelliJ IDEA 11

The new version of IntelliJ IDEA is out, and I’m liking it.

Gradle integration: creating a new project from a build.gradle was smooth and easy. Then when dependencies were added to the gradle file, the gradle plugin came in handy. One line added to build.gradle

apply plugin: 'idea'

and then one execution of

gradle idea

updated the dependencies without losing my other settings.

Git integration: it’s built-in, but I haven’t tried it yet. I’m still making friends with git at the command line. in the meantime, I added .idea, *.ipr and *.iws to the .gitignore list.

Android integration: this is smooth. It was a little rough in the last version. In 11, it’s slick so far. Clicking on an R.id.viewName takes me directly to the definition of that layout element in the XML. The IDE also has a GUI editor for creating layouts — priceless. (I do have an issue with the resources not being regenerated and packaged correctly on changes to layouts. I haven’t yet narrowed it down closely enough to report a bug. Rebuilding the project fixes it.)

Final variables: Type an expression, then press ctrl-alt-v for “create a local variable to store the results of this expression.” A little thought bubble appears containing a checkbox for “Declare final.” Having checked that once, my created variables are now final by default. Hurray!

JetBrains supports the local user group community by giving free licenses to attendees (one random giveaway at each meeting of the St. Louis JUG when at least thirty people show up, which is most of the time). JetBrains also supplies licenses to leaders of the JUG. This is a great reason to be active in the local user group community!

Spring configuration returns home

Remember the early days of XML, when people were all excited about using it to wire up applications? “You can change which implementation is used without changing any code!”

Sure, right, XML isn’t code. It gets packaged in your jar files, with the code. It controls how your application works, like the code. It breaks shit when it is wrong, like the code. Difference is, it’s a lot easier to test the code.

I’m happy to see that Spring is coming full circle and moving configuration back to the code. Not to application code (in-bean annotations), but to separate configuration classes. This keeps the wiring isolated from the application code, while keeping the configuration readable, refactorable, and more testable.

Instead place of XML, we get something like this:


@Configuration
public void ZooConfig {

@Bean
public Goat goat() {
return new GoatImpl();
}

@Bean
public PettingZoo pettingZoo() {
PettingZoo p = new PettingZooImpl(goat(), goat());
p.openForBusiness();
return p;
}

}

Yes, this is a trivial made-up example. What is exciting about it?
– The compiler finds the typos in your class names.
– The IDE (without any special plugins) links between the application code and configuration. I can get from here to the implementation class quickly. The configuration will show up in a “Find Usages” search. If I rename GoatImpl to AnatolianBlackGoat, the configuration will change, because the configuration is code!
– Integration tests instantiate a fully populated PettingZoo without loading Spring, and without duplicating the logic of how to create one.


@Test
public void animalsLikeItWhenIPetThem() {
PettingZoo p = new ZooConfig().pettingZoo();

String result = p.getAnimal().pet();

assertThat(result, is("Maaaaaaaa."));
}

(Caveat: this isn’t a perfect test. In real life, Spring will proxy the ZooConfig and wrap the goat() call to return one singleton Goat every time. The Spring-created PettingZoo has the same Goat twice. My test PettingZoo has two different Goats.)

This new method of Spring config is a welcome admission that XML is code. If it lives with the code, integrates with the code, and can break the application, then the configuration is code. Pointy braces or curly braces, it’s all code. It might as well be in Java. Putting all this glue and wiring in one place is good, decoupling our application classes is good, and the beautiful part is we can have all this and compile-time type checking too. Mmm, cake.

The phrase “configuration classes” has a lovely ring to it. I hope to hear more of it in the future.

Credit to: St Louis JUG and Chris Hardin of OCI, presenter.