5 minute intro to parsing command line arguments with jopts simple

Maven:

net.sf.jopt-simple jopt-simple 2.4-rc2          

First you create an OptionParser object 

For example:

OptionParser parser = new OptionParser() {
{
accepts("file").withRequiredArg().ofType(File.class)
.describedAs("nput file");
accepts("date")
.withRequiredArg()
.ofType(Date.class)
.withValuesConvertedBy(
DateConverter
.datePattern("yyyy-MM-dd HH:mm:ss"))
};

    

As you can see, the option argument can be any object that has a string constructor. 

You can print a handy usage via the method

parser.printHelpOn(System.out);

(annoyingly, it throws an IOException). 

Once initialized, you can invoke your OptionsParser on a list of arguments thus:

OptionSet options = parser.parse(args);

Beware, this throws a  runtime exception if unrecognized arguments are passed - you should wrap it in a try catch block.

You can then check if your options are present by invoking

options.has("file")

if this returns true, go ahead and get the argument:

(File) options.valueOf("file")); 

As you specified the argument as a file, it will be retrieved as a file object, the only caveat being that you need to cast it to the right type.

Very useful overall. One thing to note is that the project requires absolutely no dependencies whatsoever (except for those scoped as test). So unlike the bloaty apache type of "utilities" which pull in 5 dozen other dependencies with them, this library is super lightweight.

Link to project page here

Of chickens and pigs

Can I just say how much agile sucks? Our starting point was a team of developers (all developers, mind you, not a single non-coder in sight - even our QA could code) who would meet for 2 minutes in the morning by rolling their chairs over in a common direction and know what they had to do for the rest of the day. The more we worked together, the better we got at it. Apparently this is known as "cowboy coding" and is frowned upon.

Somebody thought we weren't high performing enough so they combined us with another team and now we are doing agile. That means we spend 20% of our time in meetings where we are speculating about the complexity of issues that we aren't allowed to work on yet. The rest of the time we are explaining what we are doing with every hour of our day while scrambling to compensate for our earlier erroneous estimates.

We don't have time to think, let alone think out of the box. There is always the looming deadline of the next morning when you will have to explain how far along you are on a task and cross out some hours on a post it note.

See, to the me the biggest issue is that the gods of agile believe that estimation is a skill that most developers suck at because they haven't practiced enough. They don't realize that estimation is always a crapshoot because you can't know in advance how long a task is going to take and certainly not to the hour the way that we are expected to. Programming is an art, it's not data entry.