Archaic Soubriquet

Having used Markdown styles at both GitHub and StackOverflow , I really like this idea : I propose that Stack Exchange, GitHub, Meteor, Reddit, and any other company with lots of traffic and a strategic investment in Markdown, all work together to come up with an official Markdown specification, and standard test suites to validate Markdown implementations. We've all been working at cross purposes for too long, accidentally fragmenting Markdown while popularizing it.

Many Java developers have had to build a command line app for one reason or another over the years, and there are many(!) ways to do it.  There are a bevy of command line libraries, some people roll their own when they get to this point (which is one reason why there are so many command line libraries!), and others just pull in the arguments simply and directly, eschewing a library. However, writing a tool, a developer should just focus on the meat of the problem rather than having to worry about the enabling functionality that allows it to work.  The Spring Framework very much supports this approach to development with its inversion of control (IoC) container and a myriad of other features. To support that approach for command line applications, the spring-cmdline library provides a bridge between the Spring framework and the JOpt Simple command line library. This tutorial will show how to leverage the spring-cmdline library to stand up a very simple command line ap...

Trying to convert a Java/EasyMock based JUnit test to Groovy in the last couple days led me to find what I think is a bug in Groovy's MockFor class . The documentation for MockFor says to use the proxyDelegateInstance method when testing Java classes, but unfortunately the delegate proxy obtained using that method is type-incompatible with the Java class you're trying to mock if that class is concrete.  It works for Groovy classes, all abstract classes, and all interfaces, but it appears to fall down when given a plain, concrete Java class.

Though I've recently come to love working with Groovy, I'm deep enough where I'm starting to see some of its warts. The one that hit me nearly right away was the nastiness about groovy.lang.GString not extending java.lang.String .  This is mainly the fault of the latter being final and not extendable, but it mea ns that GString in stances aren't automatically comparable with plain Java strings. In Groovy, string literals can be quoted using both single and double-quotes.  GString appears when you use double-quotes around a string and expand variables into it.  See " Strings and GStrings " for more information.