Installing Java on Ubuntu 12.x+

I’ve seen a couple of ways to do this on the internet but the easiest is through apt-get and ppa.

The catch with doing anything in Java on Ubuntu is always the same - Ubuntu doesn't ship with Oracle’s Java installed. Instead, Ubuntu ships with Open JDK installed. Open JDK is an open source version of Java. Some may argue that you can develop with and probably run most things Java with Open JDK. That may be the case, but for me I find the Oracle Java to be more trustworthy for production environment so will be using the Oracle bits. This is simply a matter of opinion.

Apt-get needs to be configured to point to a ppa that will take care of the heavy lifting and then install like anything else via apt.

Open a terminal and execute the following:

sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java8-installer

Verify Oracle Java 8 is the default java version, the ‘*’ char notes the selected default:

sudo update-alternatives --config java
There are 2 choices for the alternative java (providing /usr/bin/java).

  Selection    Path                                            Priority   Status
------------------------------------------------------------
* 0            /usr/lib/jvm/java-8-oracle/jre/bin/java          1072      auto mode
  1            /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java   1071      manual mode
  2            /usr/lib/jvm/java-8-oracle/jre/bin/java          1072      manual mode

Press enter to keep the current choice[*], or type selection number:

That's it. All done.

Are Static Methods an Anti-Pattern?

Is using the Static keyword on class members and methods an anti-pattern? I think so and hopefully this post will get you thinking about it. Primarily I see Static abused when programmers do not want to go through the work of instantiating a class. This is in circumstances in which instantiation is not strictly necessary. The problem with Static members is that they get in the way of approaches such as Inversion of Control and Test Driven development.

First, lets take a look at an example that illustrates what I am talking about concerning using Static on class members. For the sake of discussion I will be using java, but the same is true in c#. Here is the main object of discussion, a Sentinel. This implementation uses an object with Static methods as a dependent object.

public class StaticSentinel {
    private AiState aiState = AiState.Scanning;
    private long posX;
    private long posY;
    private long posZ;

    public void live() {
        int threatLevel = 0;

        // unit testing here is problematic because of the dependency upon StaticMutantScanner. Since
        // StaticMutantScanner's implementation is static it cannot be overriden. Therefore, this.live() cannot
        // be unit tested in isolation of the dependency upon StaticMutantScanner. A unit test here is no longer
        // a unit test but is an integration test - testing both StaticSentinel and StaticMutantScanner components.
        Mutant mutant = StaticMutantScanner.detectMutant(this.posX, this.posY, this.posZ);

        if (mutant != null) {
            threatLevel = StaticMutantScanner.assessThreatLevel(mutant);
            // do something here based on the threat level.
            if (threatLevel > 0) {
                this.aiState = aiState.Hunting;
            }
        }

        // some other ai related activities, move, sleep, attack, guard, etc.
        doAi();
    }

    private void doAi() {
        // do something here.
    }

    public AiState getAiState() {
        return this.aiState;
    }
}

And here is the class with the Static methods. Our scanner, it looks for Mutants and assess their threat level.

public class StaticMutantScanner {
    public static Mutant detectMutant(long posx, long posy, long posz) {
        // create a mutant here via factory pattern and return it if nearby
        // instead of newing-up this mutant. newing-up is used here just for illustration.
        return new Mutant();
    }

    public static int assessThreatLevel(Mutant mutant) {
        // do something complicated here
        // and return threat level of the mutant
        return 0;
    }
}

What I’ve outlined above in the Sentinel class is not an uncommon thing to see in legacy code bases. In the case of the StaticMutantScanner - it is an object that does not require instantiation. So, the developer creates some kind of Static implementation. It makes sense, why bother instantiating it and all the irritating work associated with the task? This thought works - until we try to test it.

If we don’t care about good software quality and highly testable software, we don’t really need to care that we have a Static member. Some organizations out there still test by releasing or through manual and labor intensive processes. For the rest of us though, we want to know quickly and reliably - if and when we break our software by making inevitable changes. So we test. For us, Unit Testing is not an academic exercise.

Here is the test of the StaticSentintel:

    @Test
    public void liveTest(){
        StaticSentinel sentinel = new StaticSentinel();
        sentinel.live();
        Assert.assertTrue(sentinel.getAiState() == AiState.Scanning);
    }

Unit Testing is where Static methods and members make things go wrong. If I try to Unit Test Sentinel.live() in its current state, I cannot do so without exercising the code that lives in StaticMutantScanner.detectMutant() and StaticMutantScanner.accessThreat(). That is, I test live() by settings the a Sentinel’s coordinates and based on whether or not a Mutant is nearby get some kind of AiState property value to Assert against. So this means I have to guess or know in advance the values that would make StaticMutantScanner behave the way we need it to to cover bother branches of the “ if (threatLevel > 0) {“ statement. Some of you at this point are saying, ‘yes, that is Unit Testing.’

No it isn’t. It is an Integration Testing of the Sentinel and MutantScanner objects and how they work in tandem. In a Unit Test - a test of Sentinel.live() should be done by not actually descending into the the logic exposed by sub-components; thereby ‘testing the smallest unit of code’, a.k.a., Unit Test. Integration Testing is perfectly valid and should be done along side Unit Testing, but this is probably the job a QA person, not a Dev. Regardless of the ‘who’ both Integration and Unit tests should exist and serve distinctly different purposes.

In this scenario, Inversion of Control (IoC), also known as Dependency Injection (DI), becomes extremely important and is one reason why DI has emerged as a best practice. In the case of Unit Testing, DI lets us inject an implementation of a dependent child object to explicitly cause a state to exist in the child component that will cause one branch of code to behave in an expected manner.

For this discussion I implement DI this through an overloaded constructor and without some kind of IoC container. I have created a new Sentinel object named TestableSentinel. This object has an overloaded constructor and now acts more like a true composite object with an instantiated MutantScanner member. Note that the calls to the MutantScanner Interface are now through an instantiated object, not a class with Static members.

public class TestableSentinel {
    private MutantScanner mutantScanner;
    private AiState aiState = AiState.Scanning;
    private long posX;
    private long posY;
    private long posZ;

    /**
     * Overloaded constructor. Ultimately for use with Inversion of Control/Dependency Injection.
     * We can inject an implementation of MutantScanner at run time to properly Unit Test
     * TestableSentinel
     *
     * @param mutantScanner This is an implementation of an interface.
     */
    public TestableSentinel(MutantScanner mutantScanner){
        this.mutantScanner = mutantScanner;
    }

    public void live() {
        int threatLevel = 0;
        // The problem with the dependency upon mutantScanner's implementations are solved here by passing in
        // a new implementation during testing that returns the expected result for each test. This ensures that
        // TestableSentinel.live() is being tested in isolation of the mutantScanner object.
        Mutant mutant = this.mutantScanner.detectMutant(this.posX, this.posY, this.posZ);

        if (mutant != null) {
            threatLevel = this.mutantScanner.assessThreatLevel(mutant);
            // do something here based on the threat level.
            if (threatLevel > 0) {
                this.aiState = aiState.Hunting;
            }
        }
        // some other ai related activities, move, sleep, attack, guard, etc.
        doAi();
    }

    private void doAi() {
        // do something here.
    }

    public AiState getAiState() {
        return this.aiState;
    }

Here is the MutantScanner Interface:

public interface MutantScanner {
    Mutant detectMutant(long posx, long posy, long posz);
    int assessThreatLevel(Mutant mutant);
}

Note that we don’t know what the implementation of MutantScanner does. We just know that if it returns a Mutant and returns a threatLevel > 0 that the Sentinel will start Hunting. This is all we need to know and should know for the purpose of Unit Testing TestableSentinel.live().

The tests are a bit more interesting. I’ve deliberately not supplied an implementation of MutantScanner in the main branch of the source. This is to illustrate that one of the purposes behind the DI in the overloaded constructor of TestableSentinel is that we can supply an implementation specific to our test’s needs.

Here is the first test:

    @Test
    public void liveTest_ExpectThreatLevelHunting(){
        int threatLevel = 1;
        MutantScanner mutantScanner = new TestMutantScanner(threatLevel);
        TestableSentinel sentinel = new TestableSentinel(mutantScanner);
        sentinel.live();
        Assert.assertTrue(sentinel.getAiState() == AiState.Hunting);
    }

Here we set the threatLevel as a parameter in the TestMutantScanner’s constructor. TestMutantScanner is an implemetnation of MutantScanner created solely for the purpose of Unit Testing the Sentinel’s live() method. In this implementation, assessThreatLevel() simply returns the value supplied to the constructor when the TestMutantScanner is instantiated. When the test is run, the branch of code is executed that sets the sentinel’s AiState to Hunting and the test verifies this.

public class TestMutantScanner implements MutantScanner {
    int threatLevel;

    /**
     * For the purpose of discussion here and the associated test,
     * this implementation simply returns the threatLevel that is set in the constructor.
     * This is to give a point in which I can control the branch of code to unit test in
     * TestableSentinel via this implementation.
     * @param threatLevel
     */
    public TestMutantScanner(int threatLevel){
        this.threatLevel = threatLevel;
    }
    public Mutant detectMutant(long posx, long posy, long posz){
        return new Mutant();
    }

    public int assessThreatLevel(Mutant mutant){
        return threatLevel;
    }
}

We test the other branch, the branch that sets the Sentinel’s AiMode to Scanning, just by changing the parameter passed to TestMutantScanner to 0. This gets complete coverage of both branches of code associated with the if (threatLevel > 0) line of code. See the second test:

    @Test
    public void liveTest_ExpectThreatLevelScanning(){
        int threatLevel = 0;
        MutantScanner mutantScanner = new TestMutantScanner(threatLevel);
        TestableSentinel sentinel = new TestableSentinel(mutantScanner);
        sentinel.live();
        Assert.assertTrue(sentinel.getAiState() == AiState.Scanning);
    }

That’s how we get great Unit Test coverage. Unit Testing takes work, but it reduces delivered bugs. It also reveals flaws in design as in the case of Static methods. Some tools and frameworks exist to make this easier - MOQ http://code.google.com/p/moq/in the .Net site of things and Mockito http://code.google.com/p/mockito/ on the java side of things are two examples. The topic of mocking gets pretty big. Essentially, I created a manual mock when I implemented MutantScanner for the purpose of testing.

To reiterate - the problem with Static members lie in inability to test them. We can’t change the implementation. This creates untestable software when the Static members are in a class that is used by another. None of the testing strategies outlined above work for static methods.

Other strategies besides DI/IoC exist for dealing with Static methods, such as wrapper classes. But if we can, we should refactor and eliminate these legacy artifacts. We certainly should not inject Static methods into new code bases without compelling reasons to do so. Using Test Driven Development will reveal the pain associated with Static methods and the need to avoid them.

Publishing Java to Heroku Cloud Service

Heroku is a jvm-based cloud service. They have scaling appliations and many of the features you expect to see in the cloud. The big thing for me is that it is simple setup, simple to understand, simple billing and lastly - simple to deploy to. Since I am very big on minimalism - Heroku is a huge win in the jvm based cloud arena.

You actually publish to the Heroku Cloud using git with just a handful of commands once you get the initial setup out of the way. Since the modern jvm culture loves git, using git to publish is very natural for jvm development.

Prerequisites

1. Your project must be built via mvn. This can be done outside your ide of choice so won’t impact any notion of project files your ide may have.
2. You need git. git is a version control system and has versions for all the major operating systems..  If you are running linux you probably already have it. If you need to install it, go here. http://git-scm.com/downloads
3. You need a heroku account. http://heroku.com

Setup

1. Install heroku Toolbelt to get Foreman, the Heroku command line client.
1. https://toolbelt.heroku.com/
2. Create a .Procfile.
1. This file contains the command you want Heroku to execute immediately after the deploy is complete. So this is your java -jar command. Be sure to include any required parameters. This file has a single line:
1. web: java -jar target/sebsApi-1.0.jar server configuration.yaml
2. Heroku uses the Celadon Ceadar stack to manage jvm polyglot apps. That’s what the ‘web:’ flag is. Find more info here: https://devcenter.heroku.com/articles/cedar
3. This file should be in your application’s root along side the pom.
3. Create a system.properties file.
1. This file is a a typical java properties file that describes unique config information for your app. This is where you can specify the java version:
1. java.runtime.version=1.7
2. This file should be in your application’s root, along side the pom.
4. Store the app in locally in Git (if not done already).
1. git init
2. git add .
3. git commit -m “some message”
5. Add the Git remote for Heroku
1. If you do not already have a heroku app, you need to create it.
1. heroku create
2. git remote -v
2. If you already have the app created (available in the Heroku app dashboard) and you need to add a your Git local to the Heroku remote:
1. heroku git:remote -a <app name>

Publish

1. git push heroku master
2. If you are new to git, be sure to commit before pushing. Any changes to local files must be committed to the local git repository before they can be pushed to the remote.

Verify

1. Scale up a single web process (Dyno).
2. Heroku calls their processes Dynos. You must have at least one running for your app to be available.
1. heroku ps:scale web=1
3. Check the status of the running Dyno:
1. heroku ps
4. View the website in a browser:
1. heroku open

Other useful infos

Viewing the logs: heroku logs

Heroku assigns a port to the app. I don’t know the logic behind how it selects the port, but it is likely that it will be different every time you deploy. This makes sense when you think about scaling and multiple Dynos to support your app. So you will need to pass in an environment variable for the port as parameter in the Procfile if your app supports it:

In my case, for DropWizard:
web: java $JAVA_OPTS -Ddw.http.port=$PORT -Ddw.http.adminPort=$PORT -jar -jar target/sebsApi-1.0.jar server configuration.yaml

References

https://devcenter.heroku.com/articles/java#deploy-your-application-to-heroku
https://devcenter.heroku.com/articles/cedar
http://gary-rowe.com/agilestack/2012/10/09/how-to-deploy-a-dropwizard-project-to-heroku/

Getting Started w/ Mongo DB in Linux using Java

The url below contains the information for installing mongo. The steps outline configuring apt to install the package. Following these steps will get mongo running and the ability to do CRUD via command line. You have to get a driver for the language of choice in order to do CRUD via code.

Installation Steps:

http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/

Command Line Interface

Mongo’s commands and the like can be found here. The command line interface is pretty straight forward:
http://docs.mongodb.org/manual/crud/

Starting mongo:

sudo service mongodb start

Stopping mongo:

sudo service mongodb stop

Restarting mongo:

sudo service mongodb restart

Connecting to mongo:

mogo

Java Driver

You will need a driver to access MongoDB programmatically. Drivers exist for most languages. The tutorial on Mongo's website has some of this information. Note that the tutorial looks dated. It looks to be using objects that no longer exist in the current version of the driver. This adds confusion so best to avoid the tutorial to get started. I have included some brief code to setup a connection and do some simple CRUD in Mongo. Note that it is not production ready.

http://www.mongodb.org/display/DOCS/Java+Language+Center#JavaLanguageCenter-Basics

Adding the Java Driver with Maven

Just add the dependency below to your Maven file. Maven will take care of getting the jar in. This url will tell you the latest version Maven supports: http://mvnrepository.com/artifact/org.mongodb/mongo-java-driver

<dependency>
     <groupId>org.mongodb</groupId>
     <artifactId>mongo-java-driver</artifactId>
     <version>2.9.1</version>
</dependency>

Code Example

import com.mongodb.*;  
 public class MongoUserDataAdapter {  
   private Mongo mongo = null;  
   private DB db = null;  
   private String serverAddress;  
   private int port;  
   private String databaseName;  
   private String collectionName;  
   /***  
   * this should be handled via config.  
   */  
   public MongoUserDataAdapter(){  
     this.serverAddress = "localhost";  
     this.port = 27017;  
     this.databaseName = "sebsTestDb";  
     this.collectionName = "users";  
   }  
   /***  
    * inserts the user into the collection in mongodb.  
    * @param user  
    * @return a user.  
    */  
   public User createUser(User user) {  
     User result = null;  
     try{  
       // mongo will create this if it doesn't exist.  
       DBCollection collection = db.getCollection(this.collectionName);  
       BasicDBObject document = this.createBasicUserDBObject(user);  
       WriteResult writeResult = collection.insert(WriteConcern.SAFE, document);  
       String error = writeResult.getError();  
       if(error.isEmpty()){  
         result = user;  
       }  
       // ToDo: have mongo set the Id.  
     }  
     catch (Exception ex){  
                //ToDo: log this  
     }  
     return result;  
   }  
   /***  
    * creates a DB document representation of user.  
    * @param user  
    * @return  
    */  
   private BasicDBObject createBasicUserDBObject(User user){  
     BasicDBObject document = new BasicDBObject();  
     document.put("id", user.getId());  
     document.put("email", user.getEmailAddress());  
     document.put("password", user.getPassword());  
     document.put("firstName", user.getFirstName());  
     document.put("lastName", user.getLastName());  
     return document;  
   }  
   public User getUser(String email) {  
     DBObject result = null;  
     DBCursor cursor = null;  
     try{  
       DBCollection collection = db.getCollection(this.collectionName);  
       BasicDBObject query = new BasicDBObject("email", email);  
       cursor = collection.find(query);  
       while(cursor.hasNext()){  
         result = cursor.next();  
       }  
     }  
     catch(Exception ex){  
          // todo: log this  
     }  
     finally{  
       cursor.close();  
     }  
     User user = null;  
     if(result != null){  
       Long id = (Long)result.get("id");  
       String address = (String)result.get("email");  
       String password = (String)result.get("password");  
       String firstName = (String)result.get("firstName");  
       String lastName = (String)result.get("lastName");  
       user = new User(id, address, password, firstName, lastName);  
     }  
     return user;  
   }  
   /***  
    * Connects to the monogdb  
    * @return false if some kind of exception.  
    */  
   public boolean connect(){  
     // this needs to be refactored out into properties where appropriate.  
     boolean success = true;  
     try{  
       // this opens the connection  
       this.mongo = new Mongo(this.serverAddress, this.port);  
       // mongo will create the database if it doesn't exist.  
       this.db = mongo.getDB(this.databaseName);  
     }  
     catch(Exception ex){  
       //ToDo: Log  
     }  
     return success;  
   }  
   public boolean close(){  
     boolean success = true;  
     try{  
       if(this.mongo != null){  
         this.mongo.close();  
       }  
     }  
     catch(Exception ex){  
       // ToDo: log  
       success = false;  
     }  
     return success;  
   }  
 }

References

http://docs.mongodb.org/manual/tutorial/install-mongodb-on-ubuntu/

http://www.mkyong.com/mongodb/java-mongodb-hello-world-example/

http://www.mongodb.org/display/DOCS/Java+Language+Center#JavaLanguageCenter-Basics

http://mvnrepository.com/artifact/org.mongodb/mongo-java-driver

http://docs.mongodb.org/manual/crud/