Announcing a beta release of the Android SDK

Upgrading the SDK

A first look at the Google Android SDK

Free, and often even free beer (thanks to the sponsors, you can get ripped even if the talk sucks ;)).

---------- Forwarded message ----------
From: Burr Sutter
Date: Tue, Aug 19, 2008 at 9:02 AM
Subject: [ajug-announce] AJUG Tonight: Flex=Java+Flash
To: ajug-announce@ajug.org

When: August 19th at 7:00 PM
Who: James Ward (Adobe)
Where: Holiday Inn Select - Chamblee-Dunwoody http://www.ajug.org/meetings.html#directions
What: Rich Internet Applications with Flex and Java

The Session:
The Web 2.0 crowd has had significant debates about the use of plug-in based solutions to RIA vs JavaScript-based ones and in this presentation you will see how powerful a Flash-based business-focused web application can be. This presentation will include numerous live coding examples and illustrate how a Java developer can add Flex to their development skillset and environment. Bring your hardest questions, James has been all around the globe speaking with developers about the use of Flex/Flash technology in their next generation applications.

Our Speaker:
James Ward is a Technical Evangelist for Flex at Adobe and Adobe's JCP representative to JSRs 286, 299, and 301. Much like his love for climbing mountains he enjoys programming because it provides endless new discoveries, elegant workarounds, summits and valleys. His adventures in climbing have taken him many places. Likewise, technology has brought him many adventures, including: Pascal and Assembly back in the early 90s; Perl, HTML, and JavaScript in the mid 90s; then Java and many of its frameworks beginning in the late 90s. Today he primarily uses Flex to build beautiful front-ends for Java-based back-ends. Prior to Adobe, James built a rich marketing and customer service portal for Pillar Data Systems.

AJUG Sponsors (provide the facilities, web hosting, speakers and equipment):
* 4t Networks, AJUG's hosting provider (www.4tvirtual.com)
* Anteo Group: Your Java Staffing & Placement Specialist (http://www.anteogroup.com/)
* Intercontinental Exchange (ICE): Looking for Atlanta's best IT talent (http://www.theice.com/jobs.jhtml)
* JBoss: The world's most popular enterprise-class Java middleware (http://www.jboss.com/)
* Sun: The Source of Java (www.sun.com)

SDK delays for the general public notwithstanding, its on the way: A ‘Dream’ Come True: U.S. Approves the First Google Phone.

I know they are well aware that people check their feeds, and have manipulated the listings accordingly, but that only makes it a bit more shockingly clear: John McCain is officially way beyond losing his sanity (Drudge, and Fox News), and Barack has a brain (Chicago Sun Times, and The Daily Show).

Explore news sites read by McCain, Obama and political journalists

My DVD broke a while back (first one I have ever had that just stopped working, all the cheap ones over the years were fine, the fancy Toshiba upconverting one dies after a year - I digress). I had a Wii in the same room connected to the same TV, so I just threw out the DVD player thinking to myself - don't need it, will just play em on the Wii (if the need arises).

Later I found out the Wii isn't a DVD player, sorry, no dice. I was literally sitting there one day going with my Wiimote going "you have to be kidding me, right? - this $200+ device that plays all sorts of software on optical discs can't play a DVD movie? WTF!."

So that was a few months back, and today I come across this in my reader feeds (from a knet share) - ta da:
it's a Wii port of MPlayer (problem solved). Props to Team Twiizers, and thanks.

I know they are well aware that people check their feeds, and have manipulated the listings accordingly, but that only makes it a bit more shockingly clear: John McCain is officially way beyond losing his sanity (Drudge, and Fox News), and Barack has a brain (Chicago Sun Times, and The Daily Show).

Explore news sites read by McCain, Obama and political journalists

My DVD broke a while back (first one I have ever had that just stopped working, all the cheap ones over the years were fine, the fancy Toshiba upconverting one dies after a year - I digress). I had a Wii in the same room connected to the same TV, so I just threw out the DVD player thinking to myself - don't need it, will just play em on the Wii (if the need arises).

Later I found out the Wii isn't a DVD player, sorry, no dice. I was literally sitting there one day going with my Wiimote going "you have to be kidding me, right? - this $200+ device that plays all sorts of software on optical discs can't play a DVD movie? WTF!."

So that was a few months back, and today I come across this in my reader feeds (from a knet share) - ta da:
it's a Wii port of MPlayer (problem solved). Props to Team Twiizers, and thanks.

Stevey's Blog Rants - Business requirements are bullshit.

I like the headline too, and the thoroughness of the article, and completely agree - so I thought I would try to do my little part to propagate this knowledge (link it here - etc). Really, I know how hard this is for many PMs and "business analysts" (don't get me started), but it's true.

Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.

Two Georgians Say They Have Bigfoot???s Body

Alternate headline - get yourself in the New York Times by throwing some deer entrails into a cooler on top of a monkey suit.

This article is filed under humor, because these clowns are obviously full of crap, but still, it's a great marketing ploy. One of them just happens to own a *business* that "offers bigfoot tours." The perpetrators of this hoax are going to offer up the "proof," today. But, before that happens, let's take bets on what the excuse will eventually be as to why actual scientists won't be able to examine their "evidence." (Georgia has a great primatalogy institute at Emory university, arguably one of the best in the world, but I guarantee you there will be some reason, or a host of reasons, that no one with any background in real science will be allowed to scrutinize anything.)

As an aside, I live in north Georgia, and mountain bike in many remote areas there often. I haven't personally seen a bigfoot in all my years (imagine that), but this story does scare me. You can never underestimate the stupidity of some rednecks with rifles and a large cooler - mountain bikers and everyone else in the vicinity when there is nothing else to shoot at, beware (and not to mention the stupidity of all the news outlets and bloggers and such that pick up the story just like the clowns want - including me ;)).

. . . stepping up to soap box . . .

I had an opinion or two about the US invading Iraq back in the day. Before the invasion I was concerned about the geopolitical standing of the US if we unilaterally invaded a "sovereign" country. I was also concerned about the actual effect on terrorism (repeatedly, and logically, noting that bombing the crap out of a group of religious zealots might not be the best way to make our country safer - in fact it might have the opposite affect - whereas dealing with the root causes of the ignorance and hatred might be more useful).

I can't help but chuckle (yes chuckle, in order to keep my sanity I have to laugh at the mostly insane world - I certainly do not mean to belittle the situation and the all too real consequences - getting to that) when I hear Condoleeza Rice, and other representatives of the Bush administration, pretend to be outraged at the Russian invasion of Georgia. They even had the balls to teach W the word "sovereign" and put it in the talking points. (And I may have confused the Georgias back in the day, but this time I am sure they are talking about the former Soviet territory ;).)

Yes it's a bullshit move by the dictator they now have in Russia, Mr. Putin. For years he has been destroying democracy there (shutting down the press, murdering journalists, jailing private citizens that disagree with him, stealing businesses from the private sector and taking them for the government, changing the government rules to suit his whims without a democratic process, etc), and for years we have mostly played along without batting an eyelash (an eyelash on the same eyes we used to look into Putin's "soul" to be certain he is a good guy, mind you).

So the move certainly is something the be outraged about, but just where does the US get off in putting anyone on notice about "invading" "sovereign" countries? (And I mean in reference to Iraq for now, let's leave any other US invasions of territory in the past out of the equation for the moment, such as the *democracies* the US pushed out to get in *dictators* they wanted, for example in Central and South America - and let's also ignore the current dictators the US supports in Pakistan, Uzbekistan, and other areas. The Iraq move itself is enough to make such a position by the US laughable.)

Maybe it's just me, but the world not paying any particular attention to the US administration throwing around "strong words" about the Russian invasion just doesn't seem surprising (one of the consequences of the damage done as a result of the Iraq decision). When the kid that steals everyone's lunch money for years finally tells the new bully to cut it out, it just doesn't seem to resonate.

I write, therefore the LHC hasn't destroyed the planet.

I was recently tasked with helping to create a Java class that had the same command line options and operation as a C executable. We already had a Java API that handled the actual work, so the goal was really just to handle the command line options and exit codes, hook into the API correctly for all the options, and output the correct stdout and stderr responses.

Sounds pretty easy at first, but, once you make a few options and then try to write a test for a class that only produces stdout (System.out) and stderr (System.err) output, and then exits the VM every time it does something, you realize there is a bit more to it than first glance reveals.

After I got done doing this for a fairly involved class with a lot of options, I made a small example application - App.java - for future reference of the key points. In this post I will discuss the example application, beginning with the easy stuff, parsing the command line options.

I used commons-cli for the command line option handling. There are other libraries out there that do this too, and it's also not out of the question to just roll your own command line parsing, but I was familiar with CLI from days past, and it has always worked well for me, so I just went back to it. The command line processing looks like the following:

   /**
    * Parse the command line options, and produce usage information - uses Commons-CLI.
    *
    * @param args input
    * @throws ParseException if problem encountered parsing options
    */
   private void parseCommandLine(final String[] args) throws ParseException {

      CommandLineParser parser = new PosixParser();

      // create the boolean options
      Options options = new Options();
      options.addOption("h", "help", false, "print this message");
      options.addOption("v", "version", false, "show version");

      // create the name/value pair options - d,r,l
      options.addOption(OptionBuilder.hasOptionalArg().withArgName("value").withDescription(
         "echo the value passed in (required)").create("e"));

      // parse the options
      CommandLine line = parser.parse(options, args);

      if (line.hasOption("h")) {
         HelpFormatter help = new HelpFormatter();
         help.printHelp(80, "TestMainExample [options]", "demonstrates a Main java class and options handling/testing",
                  options, null);
         System.exit(App.EXIT_NO_ERROR);
      }
      else if (line.hasOption("v")) {
         System.out.println("Version 1.0");
         System.exit(App.EXIT_NO_ERROR);
      }

      // if it's the e option, set the echo instance var value
      if (line.hasOption("e")) {
         String value = line.getOptionValue("e");
         if (value != null) {
            this.echo = value;
         }
      }
      else {
         System.err.println("ERROR: -e option with value is required");
         System.exit(App.EXIT_USAGE_ERROR);
      }
   }

With CLI you have a CommandLineParser, and Option[] array. You may notice that I created a separate method just for the CLI stuff. I didn't start out this way, but in order to make it more testable, as we shall come to, I refactored to avoid stuffing everything into the main method (in addition to being more testable, this also makes the class just easier to read and maintain overall). Also, you can see that when a USAGE_ERROR or other problem occurs, the VM is exited with the corresponding exit code.

Next, after the command line handling was in place, I moved the logic into a "process" method, like so:

   /**
    * Process method to keep logic/etc out of main and help testability. 
    * 
    * @param args
    */
   private void process(String[] args) {

      // first parse command line to set state 
      try {
         this.parseCommandLine(args);
      }
      catch (ParseException e) {
         System.err.println("ERROR processing command line args - " + e.getMessage());
         System.exit(App.EXIT_UNKNOWN_ERROR);
      }

      // normal processing 
      System.out.println("ECHO  . . . " + this.echo);
      System.exit(App.EXIT_NO_ERROR);
   }

The process method invokes the command line parser first, to ensure that instance variables are setup based on the selected options. This is one of the key points. I avoided statics for this stuff, which you often see in "main" method type classes, and just made sure the command line processing was the first step, after which the instance variables are used to "do stuff." (In this case just a simple echo, but whatever you need can be handled at this point.)

After the process method the next few things I needed were the main method itself, and a constructor. These are shown below:

   /**
    * Constructor that requires args, and then invokes process 
    * (guarantees that process occurs). 
    * 
    * @param args
    */
   protected App(String args[]) {
      this.process(args);
   }

   /**
    * Command line main runner, makes an instance.
    * 
    * @param args
    */
   public static void main(String[] args) {
      new App(args);
   }

The main method just makes a new instance of the class, and hands it the command line args[]. The constructor calls the process method (which goes through the command line parsing and then performs the logic, as we saw previously). One thing that may seem curious about this is that the constructor is not private. I did that to help out the testing, which we will look at next.

Changing ANY aspect of your class exclusively to facilitate testing always seems like a bad smell to me. Don't get me wrong, I think testing is very important, essential even, but I also think you should have more than just that in mind when you refactor (or add new dependencies for injection frameworks or such). Usually you can justify changes with enhanced readability, or better decoupling, etc, and not say, well, "it's easier to test" this way (just something to keep in mind, I like to see people justify changes with more than "it's easier to test this way" - well, *why* is it easier to test, there is another benefit right?).

At any rate, I made the constructor protected access, just for the tests. Sure there are a few other ways to create private objects that I could have hooped through, but the simplest way was just make it protected and put the test in the same package (as really should be the case anyway). This leads into the tests themselves, where the real challenges in this project were.

So how well does JUnit work when the VM exits, and when the only output is System.out/err? Out of the box, it really doesn't work. But, after searching around a bit I found a lot of people asking about this (testing a main method class), and only a few helpful responses (no articles though, hence this one ;)). Specifically the most helpful response was Lasse Reichstein Nielsen on a velocityreviews forum.

Nielsen mentioned using a security manager that prevents calling System.exit and then catching SecurityException. I went with that approach, modifying the code supplied in the forum a bit to create an AbstractSecurityTestCase:

package com.totsp.example;
import java.security.Permission;
import junit.framework.TestCase;

public class AbstractSecurityTestCase extends TestCase {

   public AbstractSecurityTestCase(String name) {
      super(name);
   }

   protected static class ExitException extends SecurityException {
      public final int status;
      public ExitException(int status) {
         super("There is no escape!");
         this.status = status;
      }
   }

   private static class NoExitSecurityManager extends SecurityManager {
      @Override
      public void checkPermission(Permission perm) {
         // allow anything.
      }

      @Override
      public void checkPermission(Permission perm, Object context) {
         // allow anything.
      }

      @Override
      public void checkExit(int status) {
         super.checkExit(status);
         throw new ExitException(status);
      }
   }

   @Override
   protected void setUp() throws Exception {
      super.setUp();
      System.setSecurityManager(new NoExitSecurityManager());
   }

   @Override
   protected void tearDown() throws Exception {
      System.setSecurityManager(null); 
      super.tearDown();
   }   
}

With that testing support in place, it then became pretty easy to write tests for a main[] method class, not only checking the exit codes, but also redirecting the System.out and System.err output and asserting against it as well. My AppTest test class demonstrates this:

package com.totsp.example;
import java.io.ByteArrayOutputStream;
import java.io.PrintStream;
import junit.framework.Assert;

public class AppTest extends AbstractSecurityTestCase {

   private ByteArrayOutputStream out;
   private ByteArrayOutputStream err;
   private PrintStream stdout;
   private PrintStream stderr;

   public AppTest(String testName) {
      super(testName);
   }

   public void setUp() throws Exception {
      super.setUp();
      this.stdout = System.out;
      this.stderr = System.err;
      this.out = new ByteArrayOutputStream();
      this.err = new ByteArrayOutputStream();      
      System.setOut(new PrintStream(this.out));
      System.setErr(new PrintStream(this.err));
   }

   public void tearDown() throws Exception {
      super.tearDown();
      System.setOut(this.stdout);
      System.setErr(this.stderr);
   }

   public void testOptionH()  {
      try {
         String[] args = new String[] {"-h"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("usage: TestMainExample [options]") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }
   
   public void testOptionV()  {
      try {
         String[] args = new String[] {"-v"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("Version 1.0") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }

   public void testInvalidCommandLine()  {
      try {
         String[] args = new String[] {"some", "crap", "with", "no", "e", "option"};
         new App(args);
         Assert.fail("should have exited with status 2");
      }

      catch (ExitException e) {         
         Assert.assertEquals("Exit status", 2, e.status);
      }
   }

   public void testProcessE()  {
      try {
         String[] args = new String[] {"-e", "TESTING"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("ECHO  . . . TESTING") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }
}

So, this was a quick example, but has a few pretty key, and handy, points: you can handle command line options easily with CLI, you can refactor to keep things out of main, and you can test classes that exit the VM with the security manager approach.

This full example is available as a Maven project in SVN here: TestMainExample.

Net neutrality, Switzerland, get it.

Yeah it's clever, but it's also very cool. Switzerland, brought to you by the EFF (really, you are a member by now, you have made a donation, right?) is a tool for testing ISPs to determine what kind of packet shaping is going on, if any.

Maximum Transmission Unit(MTU), the largest physical packet size, measured in bytes, that a network can transmit. Any messages larger than the MTU are divided into smaller packets before being sent.By optimizing the MTU setting you can gain substantial network performance increases, especially when using dial-up modem connections.

Full Story

Stevey's Blog Rants - Business requirements are bullshit.

I link the headline too, and the thoroughness of the article, and completely agree - so I thought I would try to do my little part to propagate this knowledge (link it here - etc). Really, I know how hard this is for many PMs and "business analysts" (don't get me started), but it's true.

Call it what you want, but it's a sign of organizational (or individual) cluelessness. If you don't already know exactly what to build, then you're in the wrong business. At the very least, you should hire someone who does know. Don't gather business requirements: hire domain experts.

Two Georgians Say They Have Bigfoot’s Body

Alternate headline - get yourself in the New York Times by throwing some deer entrails into a cooler on top of a monkey suit.

This article is filed under humor, because these clowns are obviously full of crap, but still, it's a great marketing ploy. One of them just happens to own a *business* that "offers bigfoot tours." The perpetrators of this hoax are going to offer up the "proof," today. But, before that happens, let's take bets on what the excuse will eventually be as to why actual scientists won't be able to examine their "evidence." (Georgia has a great primatalogy institute at Emory university, arguably one of the best in the world, but I guarantee you there will be some reason, or a host of reasons, that no one with any background in real science will be allowed to scrutinize anything.)

As an aside, I live in north Georgia, and mountain bike in many remote areas there often. I haven't personally seen a bigfoot in all my years (imagine that), but this story does scare me. You can never underestimate the stupidity of some rednecks with rifles and a large cooler - mountain bikers and everyone else in the vicinity when there is nothing else to shoot at, beware (and not to mention the stupidity of all the news outlets and bloggers and such that pick up the story just like the clowns want - including me ;)).

. . . stepping up to soap box . . .

I had an opinion or two about the US invading Iraq back in the day. Before the invasion I was concerned about the geopolitical standing of the US if we unilaterally invaded a "sovereign" country. I was also concerned about the actual effect on terrorism (repeatedly, and logically, noting that bombing the crap out of a group of religious zealots might not be the best way to make our country safer - in fact it might have the opposite affect - whereas dealing with the root causes of the ignorance and hatred might be more useful).

I can't help but chuckle (yes chuckle, in order to keep my sanity I have to laugh at the mostly insane world - I certainly do not mean to belittle the situation and the all too real consequences - getting to that) when I hear Condoleeza Rice, and other representatives of the Bush administration, pretend to be outraged at the Russian invasion of Georgia. They even had the balls to teach W the word "sovereign" and put it in the talking points. (And I may have confused the Georgias back in the day, but this time I am sure they are talking about the former Soviet territory ;).)

Yes it's a bullshit move by the dictator they now have in Russia, Mr. Putin. For years he has been destroying democracy there (shutting down the press, murdering journalists, jailing private citizens that disagree with him, stealing businesses from the private sector and taking them for the government, changing the government rules to suit his whims without a democratic process, etc), and for years we have mostly played along without batting an eyelash (an eyelash on the same eyes we used to look into Putin's "soul" to be certain he is a good guy, mind you).

So the move certainly is something the be outraged about, but just where does the US get off in putting anyone on notice about "invading" "sovereign" countries? (And I mean in reference to Iraq for now, let's leave any other US invasions of territory in the past out of the equation for the moment, such as the *democracies* the US pushed out to get in *dictators* they wanted, for example in Central and South America - and let's also ignore the current dictators the US supports in Pakistan, Uzbekistan, and other areas. The Iraq move itself is enough to make such a position by the US laughable.)

Maybe it's just me, but the world not paying any particular attention to the US administration throwing around "strong words" about the Russian invasion just doesn't seem surprising (one of the consequences of the damage done as a result of the Iraq decision). When the kid that steals everyone's lunch money for years finally tells the new bully to cut it out, it just doesn't seem to resonate.

I write, therefore the LHC hasn't destroyed the planet.

BitTorrent is a peer-to-peer file sharing protocol used to distribute large amounts of data. The initial distributor of the complete file or collection acts as the first seed. Each peer that downloads the data also uploads it to other peers. Relative to standard internet hosting, this provides a significant reduction in the original distributor's hardware and bandwidth resource costs. It also provides redundancy against system problems and reduces dependence on the original distributor.

A BitTorrent client is a program that manages torrent downloads and uploads using the BitTorrent protocol.

Full Story

I was recently tasked with helping to create a Java class that had the same command line options and operation as a C executable. We already had a Java API that handled the actual work, so the goal was really just to handle the command line options and exit codes, hook into the API correctly for all the options, and output the correct stdout and stderr responses.

Sounds pretty easy at first, but, once you make a few options and then try to write a test for a class that only produces stdout (System.out) and stderr (System.err) output, and then exits the VM every time it does something, you realize there is a bit more to it than first glance reveals.

After I got done doing this for a fairly involved class with a lot of options, I made a small example application - App.java - for future reference of the key points. In this post I will discuss the example application, beginning with the easy stuff, parsing the command line options.

I used commons-cli for the command line option handling. There are other libraries out there that do this too, and it's also not out of the question to just roll your own command line parsing, but I was familiar with CLI from days past, and it has always worked well for me, so I just went back to it. The command line processing looks like the following:

   /**
    * Parse the command line options, and produce usage information - uses Commons-CLI.
    *
    * @param args input
    * @throws ParseException if problem encountered parsing options
    */
   private void parseCommandLine(final String[] args) throws ParseException {

      CommandLineParser parser = new PosixParser();

      // create the boolean options
      Options options = new Options();
      options.addOption("h", "help", false, "print this message");
      options.addOption("v", "version", false, "show version");

      // create the name/value pair options - d,r,l
      options.addOption(OptionBuilder.hasOptionalArg().withArgName("value").withDescription(
         "echo the value passed in (required)").create("e"));

      // parse the options
      CommandLine line = parser.parse(options, args);

      if (line.hasOption("h")) {
         HelpFormatter help = new HelpFormatter();
         help.printHelp(80, "TestMainExample [options]", "demonstrates a Main java class and options handling/testing",
                  options, null);
         System.exit(App.EXIT_NO_ERROR);
      }
      else if (line.hasOption("v")) {
         System.out.println("Version 1.0");
         System.exit(App.EXIT_NO_ERROR);
      }

      // if it's the e option, set the echo instance var value
      if (line.hasOption("e")) {
         String value = line.getOptionValue("e");
         if (value != null) {
            this.echo = value;
         }
      }
      else {
         System.err.println("ERROR: -e option with value is required");
         System.exit(App.EXIT_USAGE_ERROR);
      }
   }

With CLI you have a CommandLineParser, and Option[] array. You may notice that I created a separate method just for the CLI stuff. I didn't start out this way, but in order to make it more testable, as we shall come to, I refactored to avoid stuffing everything into the main method (in addition to being more testable, this also makes the class just easier to read and maintain overall). Also, you can see that when a USAGE_ERROR or other problem occurs, the VM is exited with the corresponding exit code.

Next, after the command line handling was in place, I moved the logic into a "process" method, like so:

   /**
    * Process method to keep logic/etc out of main and help testability. 
    * 
    * @param args
    */
   private void process(String[] args) {

      // first parse command line to set state 
      try {
         this.parseCommandLine(args);
      }
      catch (ParseException e) {
         System.err.println("ERROR processing command line args - " + e.getMessage());
         System.exit(App.EXIT_UNKNOWN_ERROR);
      }

      // normal processing 
      System.out.println("ECHO  . . . " + this.echo);
      System.exit(App.EXIT_NO_ERROR);
   }

The process method invokes the command line parser first, to ensure that instance variables are setup based on the selected options. This is one of the key points. I avoided statics for this stuff, which you often see in "main" method type classes, and just made sure the command line processing was the first step, after which the instance variables are used to "do stuff." (In this case just a simple echo, but whatever you need can be handled at this point.)

After the process method the next few things I needed were the main method itself, and a constructor. These are shown below:

   /**
    * Constructor that requires args, and then invokes process 
    * (guarantees that process occurs). 
    * 
    * @param args
    */
   protected App(String args[]) {
      this.process(args);
   }

   /**
    * Command line main runner, makes an instance.
    * 
    * @param args
    */
   public static void main(String[] args) {
      new App(args);
   }

The main method just makes a new instance of the class, and hands it the command line args[]. The constructor calls the process method (which goes through the command line parsing and then performs the logic, as we saw previously). One thing that may seem curious about this is that the constructor is not private. I did that to help out the testing, which we will look at next.

Changing ANY aspect of your class exclusively to facilitate testing always seems like a bad smell to me. Don't get me wrong, I think testing is very important, essential even, but I also think you should have more than just that in mind when you refactor (or add new dependencies for injection frameworks or such). Usually you can justify changes with enhanced readability, or better decoupling, etc, and not say, well, "it's easier to test" this way (just something to keep in mind, I like to see people justify changes with more than "it's easier to test this way" - well, *why* is it easier to test, there is another benefit right?).

At any rate, I made the constructor protected access, just for the tests. Sure there are a few other ways to create private objects that I could have hooped through, but the simplest way was just make it protected and put the test in the same package (as really should be the case anyway). This leads into the tests themselves, where the real challenges in this project were.

So how well does JUnit work when the VM exits, and when the only output is System.out/err? Out of the box, it really doesn't work. But, after searching around a bit I found a lot of people asking about this (testing a main method class), and only a few helpful responses (no articles though, hence this one ;)). Specifically the most helpful response was Lasse Reichstein Nielsen on a velocityreviews forum.

Nielsen mentioned using a security manager the prevents calling System.exit and then catching SecurityException. I went with that approach, modifying the code supplied in the forum a bit to create an AbstractSecurityTestCase:

package com.totsp.example;
import java.security.Permission;
import junit.framework.TestCase;

public class AbstractSecurityTestCase extends TestCase {

   public AbstractSecurityTestCase(String name) {
      super(name);
   }

   protected static class ExitException extends SecurityException {
      public final int status;
      public ExitException(int status) {
         super("There is no escape!");
         this.status = status;
      }
   }

   private static class NoExitSecurityManager extends SecurityManager {
      @Override
      public void checkPermission(Permission perm) {
         // allow anything.
      }

      @Override
      public void checkPermission(Permission perm, Object context) {
         // allow anything.
      }

      @Override
      public void checkExit(int status) {
         super.checkExit(status);
         throw new ExitException(status);
      }
   }

   @Override
   protected void setUp() throws Exception {
      super.setUp();
      System.setSecurityManager(new NoExitSecurityManager());
   }

   @Override
   protected void tearDown() throws Exception {
      System.setSecurityManager(null); 
      super.tearDown();
   }   
}

With that testing support in place, it then became pretty easy to write tests for a main[] method class, not only checking the exit codes, but also redirecting the System.out and System.err output and asserting against it as well. My AppTest test class demonstrates this:

package com.totsp.example;
import java.io.ByteArrayOutputStream;
import java.io.PrintStream;
import junit.framework.Assert;

public class AppTest extends AbstractSecurityTestCase {

   private ByteArrayOutputStream out;
   private ByteArrayOutputStream err;
   private PrintStream stdout;
   private PrintStream stderr;

   public AppTest(String testName) {
      super(testName);
   }

   public void setUp() throws Exception {
      super.setUp();
      this.stdout = System.out;
      this.stderr = System.err;
      this.out = new ByteArrayOutputStream();
      this.err = new ByteArrayOutputStream();      
      System.setOut(new PrintStream(this.out));
      System.setErr(new PrintStream(this.err));
   }

   public void tearDown() throws Exception {
      super.tearDown();
      System.setOut(this.stdout);
      System.setErr(this.stderr);
   }

   public void testOptionH()  {
      try {
         String[] args = new String[] {"-h"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("usage: TestMainExample [options]") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }
   
   public void testOptionV()  {
      try {
         String[] args = new String[] {"-v"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("Version 1.0") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }

   public void testInvalidCommandLine()  {
      try {
         String[] args = new String[] {"some", "crap", "with", "no", "e", "option"};
         new App(args);
         Assert.fail("should have exited with status 2");
      }

      catch (ExitException e) {         
         Assert.assertEquals("Exit status", 2, e.status);
      }
   }

   public void testProcessE()  {
      try {
         String[] args = new String[] {"-e", "TESTING"};
         new App(args);
         Assert.fail("should have exited with status 0");
      }

      catch (ExitException e) {
         String output = new String(this.out.toByteArray());
         Assert.assertTrue(output.indexOf("ECHO  . . . TESTING") != -1);
         Assert.assertEquals("Exit status", 0, e.status);
      }
   }
}

So, this was a quick example, but has a few pretty key, and handy, points: you can handle command line options easily with CLI, you can refactor to keep things out of main, and you can test classes that exit the VM with the security manager approach.

This full example is available as a Maven project in SVN here: TestMainExample.

Net neutrality, Switzerland, get it.

Yeah it's clever, but it's also very cool. Switzerland, brought to you by the EFF (really, you are a member by now, you have made a donation, right?) is a tool for testing ISPs to determine what kind of packet shaping is going on, if any.

Just how far the US government has gone with its overt destruction of civil liberties is astounding. Not only has habeas corpus been thrown out the window, selectively, but communications are wiretapped illegally, people are rendered to other countries to be tortured (torture itself being something we "don't do," while splitting hairs over the definition), due process in general is pissed on, and all the while the government asserts it has the right to conduct its business - in our names - secretly.

In yet another example of the lunatic bullshit, any electronic device can now be seized at the border by the not-so-secret-yet-still-gestapo federal authorities. They can keep a device for any amount of time, and can seize it without any probable cause.
Travelers' Laptops May Be Detained At Border - no suspicion required under DHS policies.

Of course, the reason for this great power given to the authorities is to protect the people - from the ever present terrorist threat. Yet, when Chertoff testifies what does he proclaim to have found on confiscated laptops to justify the program . . . wait for it . . . child pornography. See how the bait and switch works once again, so long as you play the fear card anything goes. Chertoff also said they have discovered "violent jihadist materials," but, he is not allowed to tell you if that led to any substantive information about a real terrorist group or operation - the old if I tell you I have to kill you trick - "national security" prevents the disclosure. See how convenient and self-fulfilling that is.

Hope it's not the same "national security" set of reasons that put Colin Powell at the UN professing about all kinds of evidence for attacking Iraq - which became, exactly as predicted, a giant clusterfuck costing the lives of hundreds of thousands of people and at the same time inflaming the *reasons* for the terrorism problem around the world. Thanks for "protecting" us citizens US goverment, you're doing a heck of a job.

I have been busting my hump lately, outside of the "day job," to get a few more chapters of Unlocking Android wrapped up. At this point we are entering the final review. If you want to be a reviewer, just ping me, I will send your name to Manning (it's a giant help, and you get some recognition and a free copy of the book, but the pay is lousy [read: zero]).

Also, the book finally made it onto Amazon proper - Unlocking Android. It's pre-release of course, but always good to be there, especially with the gaggle of other Android related books in the same boat (late this year or early next release dates - I believe ours was one of the first projects to start, remains to be seen who will finish first ;)).

I don't know how we will handle the four authors thing in the long run, as 2 authors have done the lion's share of the work (whether we will label the chapters, how much final polishing it will take to make it feel like a book, etc), but all in all we have some good content to be proud of. It's been a challenge to have 4 authors - the mythical author month if you will - but it's getting there.

Lastly, I know I haven't been posting much here lately, about the book or anything else - apologies. I have just been swamped with the book, the travel for work, and real life. Also, I don't know where all the other posters have gone. Hopefully penguin will get more attention when other things calm down - yeah, right.

I still haven't figured out exactly how the pictures get mashed into the search results (most of the pictures are for unrelated things, and when they are related they are maybe the same topic but a different source or item than the text), or how one of their edicts - "popularity is useful but not always but important" - gets applied, but Cuil is here.

Cuil (pronounced "cool"?) is an old Irish word for knowledge, apparently. It's a new twist on search, and it has been founded by a group of ex-Googlers.

(Side note, I am running across a lot of "ex-Googlers" lately, what's the deal with that?)

VirtualBox is a family of powerful x86 virtualization products for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software under the terms of the GNU General Public License (GPL).

Full Story

I haven't posted a decent blog entry, you know the non-personal crapola, in a while - and for that I apologize. Nevertheless, some of these pictures I am proud of (and I don't have a real camera, just a little point and shoot): Argentina_08.

A few of my favorites are the water over the falls, and the old truck.

Obviously some of the shots are of Buenos Aires, and others are in the town of Puerto Iguazu, and or at the falls. My big regret is that I did not take the camera out at night a few times - the night scenes were crazy. Oh well, maybe next time.

And, as soon as I have a bit more bandwidth I will write up some of the trip details, and get back to a few technical posts that are more than pointers ;).

I left Buenos Aires yesterday, at the end of the work week, to head out and be a turista for a few days in the jungle. I am now in Puerto Iguazu, a dusty "frontier" and tourist town on the border of Argentina, Brazil, and Paraguay.

I will head to the national park and falls later today, after shaking off another late night in the bars of South America.

There will be much more to write, and plenty of pictures, as soon as I have a chance, and have a bit of reliable bandwidth. For now, just wanted to ping the "from here" post - it's become a tradicion - ciao.

Joss Whedon's latest work: Dr. Horrible.

This week I am in Buenos Aires Argentina on "business." Tough job, but someone has to do it. I am working with a group that the company I work for currently outsources some parts of projects to, Hexacta. As far as outsourcing goes (which I am not a big fan of, for communication reasons, regardless of the quality of work or anything political) it seems like a very well run operation - but a much bigger shop than I imagined (a real "software factory," in multiple senses).

I will post pictures and and any interesting details later this week, but for now just wanted to post another in the "blogging from here" series.

As Maarten noted recently on his blog, I was asked to hop over the pond and give a talk at Javoxx 08. Woot!

It's about 98% settled at this point, with only a few final details to work out, so it looks like it will actually happen. I am still a bit stunned to have been asked really, and of course honored. Now I just have to do some work and come up with a great presentation (with Maarten's help, and he is a veteran at it BTW - http://www.maartenvolders.com/jazoon08/) so that I can live up to the billing. ;) Our talk will be about GWT, specifically some cool stuff you can do with the compiler (focusing on the heart of the toolkit, the compiler and how it works, rather than widgets, etc.).

I really want to thank both Maarten, and Stephan Janssen - the guy who made all of JavaPolis/Javoxx possible. (I met Stephan at the JavaPosse roundup earlier this year, fantastic guy. I became acquainted with Maarten through GWT groups and message boards, also a great guy.)

I have never done the big presentation thing at a public conference before. I have done a few short talks at large companies, say 100 people tops, and many small presentations, but not JavaOne or Javoxx or so on. Should be interesting, if not too nerve-wracking.

Once I get something closer to ready, I will likely be doing a few JUGs in the area too, so I will let everyone know where to come out and critique the show (AJUG, and got an email from SCJUG the other day, might solicit others).

And, if you want to come along, just let me know, would be great to have a few fellow countrymen travel over there with me - I haven't yet informed Stephan, but of course I need an entourage! Who wants to be my Turtle?

SproutCore, a Cocoa inspired Ajax framework that uses Ruby, is pretty impressive at first glance - and it's apparently Apple's choice for web apps.

I don't know much about it, but I still find it hard to believe that anyone is going to be able to compete with GWT (or more appropriately the GWT approach) in terms of ease of development, re-use capability, and performance.

In an article entitled Rich Internet Applications: VM Runtimes or Browser Standards?, Frank Somers at Artima serves up a nice starting point to what I think is a very important and timely debate.

Among the many advantages that browser based apps provide are the following: easy to distribute, powerful, and run on a wide variety of platforms, etc. For these reasons, and more, many developers are looking at RIAs for their next big app. The lines are blurring daily between what "needs" to be a desktop app, and what doesn't - for instance, it's really no longer true that for file operations you need a desktop based app (have you seen Flickr?).

Once you admit that an RIA might not only fit the bill but have advantages, you then have to think about RIA. The crux of that question is Ajaxy (HTML/JavaScript/CSS) or "Browser Standards" as Frank calls it, versus "VM Runtimes" like Flash or Silverlight.

There are pros and cons to each, but I sure prefer the browser standards approach. Along with the general web app advantages browser standards apps also provide, a non proprietary approach, UI and usage concepts that don't change and are familiar to users (back button, bookmarks, form inputs, buttons), widest variety of platform support (every platform the browser runs on, versus every platform the browser runs on AND the VM has been ported too - think Flash versus Ajax apps on your iPhone), lack of a download/install step, and so on.

Actually, my ultimate preference, for now (until browser runtimes themselves get more powerful), is to use BOTH. Do the UI in standards based stuff (Ajax) and then do computation or operations that are faster/better on a runtime, with said runtime (if it is available - and fall back gracefully). A lot of "frameworks" are starting to explore this approach, use HTML/JavaScript UI, and use Flash runtime for speed, file operations, or specialized network needs, for example.

It's a worthwhile debate no matter which side you stand on, I am glad to see it getting more due.

I don't have any editorial for this one, as if any would matter to the masses *still* driving around with W stickers on their cars, right next to their anti-Darwin "truth" fishes.

Bush Edits Out Jefferson's Religious Views

Bush (4th of July address at Monticello):

Thomas Jefferson understood that these rights do not belong to Americans alone. They belong to all mankind. And he looked to the day when all people could secure them. On the 50th anniversary of America's independence, Thomas Jefferson passed away. But before leaving this world, he explained that the principles of the Declaration of Independence were universal. In one of the final letters of his life, he wrote, "May it be to the world, what I believe it will be -- to some parts sooner, to others later, but finally to all -- the Signal of arousing men to burst the chains, and to assume the blessings and security of self-government."

Jefferson:

May it be to the world, what I believe it will be, (to some parts sooner, to others later, but finally to all,) the signal of arousing men to burst the chains under which monkish ignorance and superstition had persuaded them to bind themselves, and to assume the blessings and security of self-government.

LXDE is a new project aimed to provide a new desktop environment which is lightweight and fast. It’s not designed to be powerful and bloated, but to be usable and slim enough, and keep the resource usage low. Different from other desktop environments, we don’t tightly integrate every component.

Full Story

The work Maarten Volders has done for his Jazoon 08 presentation is fantastic, really. Rarely do I see (or check out later) a presentation that is both really engaging and also informative, but this is just that. (Neal Ford can do it, "tick" and "tap" can do it, Bruce Johnson can do it, Romain Guy can do it, Cooper has some good stuff too - but most people end up with presentations that are way too dry for my taste - whether or not they have solid technical details.)

Also see his write up of the experience, that's very good as well.

At a new gig I started recently one of the tasks I have is hitting the ground running and get familiar with (at least) a lot of code on a lot of projects.

It is my present duty to work on reference implementations and offer feedback and so on for other developers, as well as work on infrastructure projects and write code (I hesitate to call this an "architecture" related job, because of all the negative connotation I personally have for that term from experience over the course of my working life - 95% of the architects I have met were virtually useless, outside of fancy PowerPoint presentations).

My employer, like many companies, is looking to move core functions toward and SOA approach. Designing services, and useful APIs in general, is often different than just working on internal classes and structures. You have to think about how things will be used and how they come across to people just hitting the outside level with no other understanding of internals. One specific item I might note is that you should try to avoid passing in many untyped parameters (Strings) or collections, or collections of collections and so on, because understanding is reduced, usability is hampered, and validation and other aspects are harder (not to mention that you just threw out typing and all that that entails, for no good reason).

I have seen this in a few APIs my new company currently has, and have brought up, tactfully, that I felt it was less than ideal. I made my own blabbering arguments about it, and noted that especially when it comes to exposing services the approach of a lot of untyped parameters is problematic (you then have to include a spreadsheet or some documentation, rather than they typing being part of the API). When my arguments didn't really get a lot of attention, or even drew argument - concerning a topic that I consider the jury to be in on, I decided to poke around and see what the internets thought about this.

I searched for "too many parameters" and other phrases and quickly came across articles from "expert" sites like this and this. Frankly, all the "answers" in those pages were pathetic, I thought. Really, horrible. Not a single person in those responses mentioned using the Builder pattern, or creating a typed parameter object? Rather the suggestions there were to use arrays or collections, or even to use a single String and delimit it somehow. You stepped in what! As Nate might say "go get me a coffee."

So I searched a bit more and came across TooManyParameters at the great C&C site, which led me to an ANTI-PATTERN named MagicContainer. It seems to line up with my sentiment, too many params is a bad smell. I hadn't heard of MagicContainer before, shamefully or not, but it sure might help me to help others in the future.

In summary the answer to "too many parameters" is *NOT* to use an array/collection, but rather to use the improved builder, or for more service friendly APIs (those you plan to expose over the network, so you don't want 10 chained calls to setup) simply use a ParameterObject that makes sense (and by makes sense I mean don't just move the problem by moving Strings or something to a new object, use the type system you have and type things, then create a composite as a parameter object).

Understanding the GWT compiler

This is such a well written and informative article that I had to give it props on the penguin! ;)

Side note, you can get chapters 4 and 6 of the book (GWT in Practice) free now on the Manning site and those have some really useful yet concise info - or at least I'd like to think so - if you want more of an idea of the overall book.

And, if you have already read the book, please give us a review (fair one, not soliciting any particular opinion, just more opinions) on Amazon.