Monday, July 30, 2007

We are all familiar with hardcoding values when programming; mostly out of laziness or we are just not aware of potential solutions based on industries best practices and experience. There are infinite ways to hardcode values. Some are temporarily acceptable based on the cost it would take to change it. However, the majority of hardcoded values should be avoided as it makes your class less reusable, brittle, and the other 500 obvious bad reasons.

A few common examples to make my point:URI uri = new URI("http://jlorenzen.blogspot.com");File file = new File("/home/jlorenzen/glassfish.log");

The problem with my first two examples, is that when defined in another class as say instance variables, everyone who uses that class is now forced to those specific values. Some typical solutions include putting values in a database, properties file, var args (main), or System Properties (-D). For my HTML <a> example, always use relative paths: <a href="../downloads/download.htm">Downloads</a&gtl. Keep in mind that when you use a String and it's not a constant, more than likely you are hardcoding some value.

Now for all you experienced Java programmers, you may not be aware that you are hardcoding values everytime you use the Java keyword "new". When instantiating a new class, you are basically forcing users of your class (most importantly your unit tests) to use that implementation. This is what makes the Factory Pattern so useful and common. But we don't need a factory everytime we need to create a new object. An alternative is practicing Dependency Injection (Inversion of Control). DI is a way to inject an object into a class, passing the control of creating a class to someone else. An easy way to explain DI is its similar to Java's terms IS-A and HAS-A, but instead I refer to it as GETS-A. For me the most important advantage of DI is it easily allows you to write unit tests using mocks objects. Some popular DI containers are Spring,Google Guice, and PicoContainer.

Here is a naive example of code you might write today:

public class MovieManager { MovieFinder finder = new MovieFinder();

public Movie findMovie(String zip) { return finder.get(zip); }}

Now anyone wanting to use MovieManager is forced to use the MovieFinder class. This makes unit testing this class difficult without using reflection (no thanks). The alternatives are using constructor or setter injection, or passing it as a variable into the findMovie method.

In summary, anytime you instantiate a new object, think about whether or not you want to limit users of your class to that implementation. DI has revolutionized my programming and if you practice it enough your code consequently gets cleaner and more usable.

Tuesday, July 24, 2007

When writing unit tests for java, its extremely valuable to view the log statements produced by your unit tests and java code. The following is a brief introduction on how to configure maven1 and maven2 projects to capture logs.

Maven1
The maven-test-plugin is used for running unit tests in maven1 projects. It is best to configure this plugin at a global level in your build.properties file located under your $USER_HOME.

Second add a log4j.properties file under your $USER_HOME directory. Mostly likely this will include a ConsoleAppender. By using a ConsoleAppender the maven-test-plugin will capture the logs and write them to the console. However its cleaner if you set the property maven.junit.usefile=true in your build.properties file. This will put all your logs in the .txt test report file.

Next you need to define the value for the variable ${logging.location}. You do this in your settings.xml file which is located under $USER_HOME/.m2. If you do not already have a settings.xml file you can get an empty one under your maven2 install in the directory $M2_HOME/conf. To define the value for ${logging.location} create a profile in your $USER_HOME/.m2/settings.xml file like the following:

<profiles>
<profile>
<id>configure.logging.location.profile</id>
<properties>
<logging.location>${user.home}/.m2/logging.properties</logging.location>
</properties>
</profile>
</profiles>
Next you need to activate the profile by adding the following in your settings.xml:
<activeprofiles>
<activeprofile>configure.logging.location.profile</activeprofile>
</activeprofiles>

Since the surefire plugin does not put log statements in the output file when using the redirectTestOutputToFile, viewing the log statements in the console can be a bit overwhelming. To make this easier consider using the test single goal: mvn -Dtest=ClassName test

One way to populate this list is to use the UDDI Binding Component, which returns an EndpointReferenceList containing multiple addresses. However, if you want something simpler without the burden of setting up a UDDI Server ,you can also use a BPEL String literal to specify XML fragments directly in a BPEL Process using Netbeans/OpenESB.

The key is to use the Source View verses the Design View because is not currently supported in the Design View (I am using Netbeans 6.0 20070622). After creating a new BPEL Module, process, and adding a sequence, go ahead and view the process in the Source View. Now a typical Assignment in BPEL looks like the following:

The goal of this entry was to quickly explain how you can use the BPEL editor in Source View to assign XML fragments for whatever purpose you may require. Obviously it's not the best long-term solution because this is no different than hardcoding file paths in a java program. But is very useful for quick testing.

When working with the Sun BPEL SE in Netbeans, sometimes you might have the requirement of defining a WSDL Port Type with two operations and then reference that WSDL in two different BPEL Processes.It turns out this currently is not supported and if you try to attempt it you will receive the following exception from the BPEL SE:

java.lang.RuntimeException: Could not find a business process providing service for the endpoint specified in the message exchange.

Here is the bug related to this issue and the conversation over the mailing list discussing this issue with the OpenESB dev mailing list.

The solution that worked for us was using the BPEL Pick activity the single BPEL Process to support the second operation. Alternatively we could have created a second WSDL, which doesn't scale very well. Also as Murali points out here, you could also make the targetNamespace the same in both BPEL Processes.

Monday, July 16, 2007

Today I participated in an enjoyable training session on presentation skills. And although I would have preferred programming, I did learn several new helpful techniques that I would like to share.

When in doubt, close your mouthTo avoid saying fillers (umm, so, and, etc) just close your mouth. There is nothing wrong with silence and a pause. It beats saying um a hundred times in 5 minutes.

Proper stanceWhen standing in front of an audience your arms should be at your side, not behind or in front of you. While at your side it can help if you make a circle with your thumb and pointer finger (this helped me a lot when practicing). If you have to put your hands in front of you, create a steeple/triangle (hard to explain verbally).

Be PreparedTo avoid nervousness be prepared. A good idea on how to prepare is to type your speech up, word for word. Then record yourself giving that speech by not referencing the paper and then compare the differences.

First ImpressionThe average person makes a first impression in 7 seconds. 55% comes visually, 38% vocally, and the remaining 7% verbally. It's very important to connect with your audience and create a good first impression.

Be PassionateNobody cares what you know, until they know you care.PowerPoint SuggestionsYou want your audience to be focused on you, not your powerpoint. Therefore use the b and w buttons to blackout or whiteout your screen. This helps in the beginning of a presentation before being introduced. Actually ironic that a non-technical person was giving a room full of technical people suggestions on keyboard shortcuts.

This obviously isn't everything that I learned and doesn't even come close to the multitude of skills necessary to deliver a successful presentation. These are just the ones that made the most impact one me.

Sunday, July 15, 2007

What is pluging: knowledge gained while learning/using maven2 plugins? I call it this because my fingers always put an extra 'g' on the end when I type the word plugin. To me pluging is fun. It's like reading a keyboard shortcut list for an IDE; you can just feel yourself being more productive. So while reading "Maven: The Definitive Guide" I naturally felt excited to learn more about maven2.

Currently I am only on the second chapter and the author points out an uncommon plugin (uncommon to me anyways) that seems pretty handy. Check out the help plugin and run this goal: mvn help:describe -Dplugin=jar -Dfull. The describe goal prints out the plugin's goals and properties. The output is the same information you can get by browsing the plugin's home page. If the information is too much, the help plugin also supports an output property: mvn help:describe -Dplugin=jar -Dfull -Doutput=jar.goals. Nothing super fancy but saves you the step of googling for the plugins site and also gives you the opportunity to explore possible options.

I would also highly recommend viewing the other maven2 plugins. Some of the plugins I would like to get to know are:

Thursday, July 12, 2007

Here is some interesting Sailfin documentation. Project SailFin is based on robust and scalable SIP Servlets Technology contributed by Ericsson and was announced at JavaOne 2007. This currently implements JSR 116 (SIP Servlet API 1.0). They are currently working towards achieving JSR 289 (SIP Servlet API 1.1) compatibility, adding high availability and clustering features and integrating with the existing GlassFish services.

What I found most interesting was the Click to Dial example and its accompanying architectural diagram.

For those not aware, we are developing a SIP JBI Binding Component to provide SIP capabilities to an ESB. Currently the SIP BC supports messaging and we are currently working on adding the ability to establish sessions.

Tuesday, July 10, 2007

Does your church have a library but doesn't have any software to keep track of its inventory? Or perhaps, like me, you have several DVDs and Books that you loan out and you forget who has what.

Then take a look at Evergreen (http://www.open-ils.org), an enterprise-class Integrated Library System (ILS). It is licensed under the GPL, and is open-source software and can be downloaded for free. It's currently in use by Georgia Library PINES, a consortium of 265 public libraries. Additionally, libraries in British Columbia and University of Windsor have committed to migrating to Evergreen.

I found out about Evergreen when reading this article about OSS use in the Government. The author mentions that in some cases U.S. governments have even started whole OSS projects when it was in their best interest; examples include OpenVista, Expect, and EXRO. In fact the reason the state of Georgia started Evergreen was because they found existing commerical products were grossly inadequate.