Code Beach: Get the Names of the Months in Java

I did not even know about the DateFormatSymbols class.

Code Beach: Get the Names of the Months in Java: "This tutorial shows how to get the month names for the current locale or for a specific locale. Java provides an easy mechanism for getting localized month names. To get the month names, you will use the DateFormatSymbols in the java.text package. By default, the constructor will create a DateFormatSymbols object based on the current locale.

DateFormatSymbols symbols = new DateFormatSymbols();"

Read More

101 Adobe AIR Resources to Add to Your Toolbelt of Awesomeness

I have committed to learning Flex and this looks like a great list of resources to help do that.

101 Adobe AIR Resources to Add to Your Toolbelt of Awesomeness: "The Adobe Integrated Runtime or AIR is a runtime environment for developing rich Internet applications. These applications can be deployed as a desktop applications. AIR applications can operate offline and can take advantage of additional functionality when connected to the Internet."

Read More

InfoQ: Top 10 Mistakes when building Flex Applications

As I am learning flex, it is nice to see what not to do.

InfoQ: Top 10 Mistakes when building Flex Applications: "In this post, Adobe’s James Ward teams up with InfoQ.com to bring you another Flex Top 10 (our most recent Flex Top 10). Flex is an open source application development framework for building rich Internet applications that run in the web with Flash Player, or on the desktop with Adobe AIR. Overall, Flex is a powerful framework that is easy to use, but today let's focus on some of the common mistakes that are made when building Flex applications."

Read More

Flex, Spring and BlazeDS: the full stack! (Part 1)

I've decided that it is time for me to learn a new language and I have decided on Flex. This article looks like a good place to start.

Flex, Spring and BlazeDS: the full stack! (Part 1): "!n this article series, I’ll try to give you a step-by-step process to create an application with Flex/BlazeDS/Spring/Hibernate/MySQL architecture, all of that built with Maven. I’ve been looking for such a tutorial for a long time, but you know what Gandhi said about the change you wish to see in the world, right? So I finally put all the parts together, and with a little help from a Brazilian friend, tadaaaa! Here it comes!"

Read More

Checking for any property in a bean

I came across a situation the other day at work where I needed to know if any property was set on a bean. There are a couple of uses cases that involve checking that a bean being used as a value object or transfer object has at least one property set before doing some heavy lifting based on the contents of the bean. The two use cases involved doing a database query or generating XML based on the bean. If the bean is empty, the query does not need to be performed or the XML does not need to be generated.

The first solution is a simple if-else-if chain:

if(bean.getProp1() != null) {
    return true;
} else if(bean.getProp2() != null) {
    return true;
}  else {
    return false;
}

There are a couple of problems with this approach. First, it is just plain ugly for more than a couple of properties. This ugliness quickly translates into a high cyclomatic complexity for more than a few properties. The code also leads to maintenance bugs as it is easy to forgot to add new properties to the chain.

I took a survey of a few of my coworkers and we came up with several solutions.

hashCode

If hashCode is defined to return zero (0) if none of the properties are set and a standard hash code otherwise, then hashCode makes a good candidate for checking if any property has been set. In practice, simple unit tests proved that the algorithms for setting hashCode do not lend themselves nicely to having a predictable value, like 0, for when none the properties are set. The hashCode ends up being based on the number of properties as well as the content.

Dirty Bit

This solution consists in a adding a boolean flag to the the object, anyValue. The flag is set to false and every setter would set it to true. Then a new method, hasAnyValue would simple return anyValue.

public void setProp1(Prop1 newProp1) {
  prop1 = newProp1;
  if(newProp1 != null ) anyValue = true;
}

public boolean hasAnyValue() {
   return anyValue;
}

We decided against this one for a couple of reasons. While it removes the cycolmatic complexity problem, is fast and is easy to understand, it still has the problem of a maintainer forgetting to add the assignment of anyValue to true in new setters. Also, it does not handle the case where a property is set back to null after having been set to a new value. Using a counter that is incremented and decremented would work around that problem.

This method works well where only a subset of the properties need to be checked. The only the relevant setters need contain the anyValue assignment.

AOP

Using aspects to make the assignment to anyValue removes the maintenance problem of forgetting to make the assignment by adding another level of complexity to the application. If an application already makes use of aspects, this would make sense. Adding aspects for just this use case would have been swatting mosquitoes with sledge hammers.

Reflection

Another approach would be to remove the anyValue field and change the method hasAnyValue to use reflection to introspect the properties and return true if any of them is non-null. While this would work, reflection code is ugly and hard to understand.

BeanUtils

Fortunately, the nice folks at Jakarta have a Commons BeanUtils package that performs operations on beans. While I couldn't find a method that checks for any value being set, there is a method that retrieves all the properties of a bean into a map: PropertyUtils.describe
Using this, the hasAnyValue method becomes:

    public static boolean hasValue(Object object) {
        Map describe;
        try {
            describe = BeanUtils.describe(object);
            for (Iterator iterator = describe.entrySet().iterator(); iterator.hasNext();) {
                Map.Entry entry = (Map.Entry) iterator.next();
                if (!"class".equals(entry.getKey()) && entry.getValue() != null) {
                    return true;
                }
            }
        } catch (IllegalAccessException e) {
            LOG.error("Failed to check hasValue 1", e);
        } catch (InvocationTargetException e) {
            LOG.error("Failed to check hasValue 2", e);
        } catch (NoSuchMethodException e) {
            LOG.error("Failed to check hasValue 3", e);
        }
        return false;
    }

This solution provided the flexibility of the reflection solution without having to maintain the reflection code. Note: I have not checked this with primitive properties. One drawback is that this solution is slower than any of the others because it reads all properties, even if all of them are non-null. If more speed is needed or if only a subset of properties need be checked, consider using the dirty bit solution.

Read More

Internet Explorer 8 proposed 'features'

Over at Not Dead Yet is a list of proposed features for the upcoming Internet Explorer 8 including:

#8: "You have not installed Vista, therefore I cannot render this page."

#9: "You have installed Vista, therefore I cannot render this page."

Check out the rest of the list

Read More

Code Buddy: The Art of the Weekly Code Review

As a software engineer for Intermountain Healthcare, I have been tasked with implementing a plan for code reviews on our team. After thinking about it for some time, I have decided to implement weekly code reviews as a nice balance of achieving the goals for having code reviews while overcoming some of the problems involved with more formal code reviews that happen at the end of the project.

A code review that happens at the end of a project has limited usefulness for the project itself. The later in the project life cycle the review is held, the harder it is to act on the issues. It is often too late in the project schedule to do anything about issues identified as part of the code review. The decision to meet the schedule versus fixing the code will always lean toward the schedule. Holding code reviews earlier in the project allows issues to be corrected with less impact to schedule.

On the other extreme is pair programming where code is continuously reviewed. While there is a lot to be said for this concept, there is a lot of drawback as well. One of the most important characteristics of an effective reviewer is being dispassionate. A person involved on a continuous basis with the code will tend to have a motivation to let things slide to meet the schedule. A person who is not so involved in the project can review the code with a more objective eye.

Code Buddy
Somewhere in-between the extremes of pair programming and end-of-projects code reviews is the code buddy. A code buddy is some one who reviews the code on a regular, in our case weekly, basis. To ensure objectivity, the code buddy does not work on the code base being reviewed. Instead, the code buddy is assigned from the people working on a different project or a different part of the same project.

To see why the code buddy works, a review of why code reviews are needed is helpful. As a team, we talked about what we wanted out of a code review. Those items follow with how a code buddy will or will not achieve that goal. Also, how we can measure the outcome for continuous improvement.

Produce higher quality products

This is one of those nebulous goals that is hard to measure. What this really needs is a definition of what is meant by higher quality code.

Find more bugs

There are several good static code analyzers like Checkstyle and FindBugs. which can identify bugs that are commonly overlooked. In addition to these tools, an effective code reviewer will identify bugs and potential bugs that are overlooked by the developer. The earlier in the process a bug is identified and corrected, the less costly the bug is to the project in time and money. Bugs can be caught throughout the process in roughly these steps, in order of increasing cost:

• not written - the cheapest bug to fix is the one never written
• caught by the developer during coding, by running unit tests or through continuous integration - these bugs are quickly addressed and cost very little
  
• caught by a code buddy - only slightly more costly than a unit test
  
• caught by QA - now the bug will need to be reviewed and possibly effects the schedule
• caught by a formal code review at the end of the project - might slip the schedule or may never be addressed
  
• caught by a user - the most costly in time, money and reputation

By identifying issues earlier in the process, a code buddy who reviews the code weekly helps meet deadlines and keep costs down.

Follow standards and best practices

Each organization identifies its own standards and best practices. Using automated tools as part of the continuous integration process will ensure adherence to some the standards. Others cannot be automated and it takes a human looking at the code to ensure that the standards are being met. The sooner a deviation from the standard is identified, to easier it is to correct. Looking at the code weekly ensures that the code does not deviate too far before being corrected.

Code buddies will also need on-going training in the standards and what to look for while reviewing. This will reinforce the standards for the whole team.

Identify security threats

In this day and age, security needs to be part of every project. However, security concerns are often separate from the business logic the developer is seeking to implement. By taking a regular step back for the business logic and looking at the code as a objective third party, the code buddy can help see security issues that a developer will overlook.

There are all sorts of security issues and a weekly code review of a snapshot will only be able to identify a subset of the issues. For example, the code buddy will not be able to see how seemingly in secure components interact in insecure ways. For this reason, a thorough security audit of the whole project should be conducted at certain milestones.

Find common solutions

Sometimes a developer write from scratch something that has already been written, reinventing the wheel. There are high quality libraries available both internal to an organization as well as from third parties. A code buddy can help reduce the overall code base by identifying these reinvented wheels and suggesting better solutions.

Makes it maintainable

The first question a reviewer should ask is would I want to maintain this code? If the answer is no, then the reviewer should identify the specific issues and bring them to the attention of the developer. It is important not to criticize the developer, but focus on the code.


Mentor and cross-train each other

As people review each other's code, they naturally learn things they can use in their own code.

Prevents the silo effect

The silo effect is what happens when a developer works under time constraints without anyone looking at the code. Corners get cuts, short cuts taken and really strange things happen in the dark. A regular review sheds needed light on the code and encourages developers to write it right the first time.

Improve performance

Like security, performance happens a many levels. A code review can identify some obvious problems, however any issues identified in a code review should be reviewed by a profiler to ensure that there really is a performance issue. Sometimes efforts to improve performance have the opposite effect.

Verify unit tests are being written

Unit tests are most effective when written early in the project. A weekly code buddy can verify that code has corresponding unit test.

Code buddy process
Each week the developer will create a code review in Crucible, which is a code review tool that integrates with source control like subversion and cvs. The code review consists of all code committed in the last 7 days. The members of the team, a code buddy and a code captain, either a team lead or other who helps facilitate the review, are invited to the review. Using crucible, the code review can be setup in a matter of moments.

The reviewer is notified by email and logs into the crucible server and does the review. Crucible shows the reviewer only the code that has actually changed, think diff. This allows the reviewers to keep up on the changes without having to dredge through lots of code that has not changed. Also, if the committer attached the Jira issues, the reviewer can easily see the motivation for the change.

The reviewer can make make comments online. There is no need for a formal meeting. Instead, each logs into the tools and make comments. The other reviewers are notified by email when comments have been made, allowing them to respond in a timely manner.

Once all the reviewers have finished, the code either passes or the developer agrees to make the suggested changes. This may involve making new Jira issues to track the changes. The changes will naturally be reviewed in the following weeks as they are made and committed.


Encouraging effective code buddies
Some steps to ensure that the reviewers are being effective

• on-going training on standards, security, etc.
• switch code buddies every few months - codes people from getting too comfortable
• provide a checklist of things to look for - one follows

Code Buddy Checklist

• Would you want to maintain this code?
• Is the intent of the changes in the code readily understood either from the code itself, the comment changes, the JIRA referenced or other supporting documentation?
• Are there any security flaws?
• Are there easy better ways of doing this? Things like: use standard libraries, a simpler algorithm, reduce complexity.
• If a complex solution is required, is it properly documented in the code or the javadoc?
• Does the code meet standards?
• Are there unit tests for the public methods of public classes?
  

Read More