Top Most Problem Resolution

I observed a small team that included a very talented developer. They were asked to solve a very nasty production performance issue.

The developer had a "gut feeling" for the problem and wanted to try his solution.

This approach is akin to picking the low hanging fruit.

To solve this type of issue, it is often wise to attempt to pick the low hanging fruit and hope for a quick resolution.

However you must limit your fruit intake. After a few tries, you need to resort to proper analysis and isolate the problem.

After his initial effort failed, he again had another "gut feeling" and wanted to try for another quick fix. This pattern repeated itself several more times, until he gave up and quietly moved on.

Unfortunately the low hanging fruit was too appealing, and management was easily sold by the quick solution. The proper analysis was never done. The issue was never resolved.

Gut feelings often result in brilliant work. When they fail, there must be proper analysis. The pragmatic programmer must set aside emotionally-driven behaviors and use a more prudent approach.

Top Most Managing Complexity

I was once confronted by a well meaning tech lead who predicted a performance issue and was "enhancing" the design to circumvent the issue.

After many years in this field I find it interesting that even very talented developers feel the need to fall prey to one of the oldest anti-patterns: premature optimization.

When I requested justification I discovered he had a "gut" feel this operation would take too long. No proof of concept had been done, no estimated timings, just the perception it would take "too long".

For all I know he could be correct. But years of development have taught me to resist the urge and keep it simple. Don't complicate designs until you know you have a real problem.

My experience is that the vast majority of perceived performance issues never materialize. Assuming a well-designed architecture, simple designs perform well in the vast majority of cases.

Keeping the design simple and focusing on performance enhancements when they become necessary allows developers to focus their efforts on real problems, rather than perceived issues.

Don't design in complexity. Save it for when you really need it.

Top Most Is Agile Disappointing?

Are you disappointed with your Agile rollout?

Not seeing the benefits the Agile zealots promised?

Don't pay attention to the Agile zealots!

Smart execs leverage empirical evidence. Mediocre managers get sold. Don't be mediocre!

So what is the empirical evidence? As it turns out, some organizations gain significant benefit from Agile. Some do not. Why?

Human nature. People who lack confidence tend to resist change, while confident professionals thrive on change.

Lip service Agile is a term frequently associated with an IT group who attempts to create the appearance they have adopted Agile yet continues using legacy development practices. A common strategy is to pepper communications with word "Agile" hoping management will confuse that with actual Agile adoption. (I've seen this a number of times.)

Fortunately there are good ways to understand whether your organization is really Agile. Here is a list of some of the most common symptoms:

1. Agile novice syndrome.  Agile can be quite appealing and the IT world is rife with stories of well meaning folks who've read about Agile and talk their boss into letting them try it. However Agile is very difficult to  "get". If your staff is running an Agile project without an experienced coach, it is almost certainly going to fail to realize Agile benefits.
2. Half Agile. When organizations adopt Scrum but retain legacy development practices. Scrum assumes the use of industry best development practices. The safest bet is to adopt Scrum and Extreme Programming.
3. Fragmented Agile. Well meaning managers who do not personally agree with specific Agile practices pull the plug on critical activities. Fortunately identification is simple: quiz the team. They should be doing all of these activities:
   
   
   1. Pairing at least 6 hours per day
   2. Writing unit tests first
   3. Attending no more than one, daily, 10 minute stand-up meeting
   4. Engages at least one full time product owner and acceptance tester
   5. Estimates are expressed in story points, and not associated to an amount of time
   6. Iterations are with 1 or 2 weeks long
   7. Runs ALL the various Scrum meetings (retrospectives, iteration planning, etc.)
   8. Does NOT have status meetings
   9. Maintains a burndown chart
   10. Calculates the velocity each iteration
   11. No one assigns tasks to other people
   12. Performance testing starts early in the project
   13. Requirements are specified by user stories (that fit on an index card)
   14. The continuous integration server runs all day at approximately 20 minute intervals
   15. Delivers user observable results in every iteration for every story
   16. All stories are small enough that they can be completed within an iteration
   17. Stories are not done until the product owner agrees they are done
   18. Detailed requirements are not captured until the associated story is scheduled to be worked on
   19. Technical documentation (other than architecture) exists solely in executable tests
   20. Failing tests receive top priority; 100% of tests generally pass
   21. Test coverage is nearly 100% (some trivial code can be excluded)
   22. Bug detectors (like FindBugs) are run as part of continuous integration
   23. No more than the minimal amount of code needed to complete a story is written
   24. Code is committed to a source code repository daily
   25. Every member of the team takes ownership over the entire code base
   
   
4. Cowboy Developers. Strong willed developers sometimes try to skip specific practices they personally don't agree with. For example, if your architect laments that not everyone is writing tests, you need to fix that.
5. Assertiveness Challenged Leaders. Sometimes leaders decide it's easier to bend to a strong willed developer than enforce standards. You need to fix that ASAP.
6. Unsupported Agile Coaches. Agile coaches must have the final say. 
7. Insufficient Buy-In. Upper management must be 100% behind the Agile effort.
8. IT Isolation. Everyone in the organization associated with the project must agree to Agile processes. Agile is implemented by the entire organization.

Top Most Top 10 JDBC Best Practices for Java Programmer

Java JDBC Best practices

JDBC Best Practices are some coding practices which Java programmer should follow while writing JDBC code. As discussed in how to connect to Oracle database from Java, JDBC API is used to connect and interact with a Database management System.  We have touched some of the JDBC best practices in our last article 4 JDBC Performance tips, On which we have discussed simple tips to improve performance of Java application with database. By using JDBC you can execute DDL, DML and Stored Procedures. JDBC Best practices is probably most significant set of coding practices in Java because it significantly affect performance of Java application. I have seen substantial performance gain by simply following common JDBC best practices like running queries with auto commit mode disable. One of the query which we used in our example of JDBC Batch update was taking almost 30 second to finish with auto commit mode enabled but it just took under one second with auto commit mode disable and using explicit commit. This JDBC tutorial is collection of such practices which help you to write better JDBC code and in most cases result in improved performance.

Read more »

Top Most 10 Exception handling Best Practices in Java Programming

Exception handling is an important part of writing robust Java application. It’s a non functional requirement for any application, to gracefully handle any erroneous condition like resource not available, invalid input, null input and so on. Java provides several exception handling features, in built in language itself in form of try, catch and finally keyword.  Java  programming language also allows you to create new exceptions and throw them using  throw and throws keyword. In reality, Exception handling is more than knowing syntax. Writing a robust code is an art more than science, and here we will discuss few Java best practices related to Exception handling. These Java best practices are followed even in standard JDK libraries, and several open source code to better deal with Errors and Exceptions. This also comes as handy guide of writing robust code for Java programmers.

Read more »

Top Most JAMon plugin for Grails: Part 4 of 4

In this series we completed steps 1-4 of our task list:

1. Add jamon.jar to the application classpath
2. Use JAMon's datasource proxy to monitor SQL
   
3. Implement the JAMonServletFilter to monitor page hits
   
4. Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
5. Add a Spring filter to monitor Grails controllers

Now lets complete step #5: Add a Spring filter to monitor Grails controllers. Spring filters are different than Servlet filters, although the details are beyond the scope of this article. Grails makes it easy to add Spring filters. Read the Grails documention for the details.

Create a package structure under grails-app/conf. I used org/grails/plugins/filters. Create a file named JamonFilters and add the following code:

package org.grails.plugins.filters

import com.jamonapi.MonitorFactory
import com.jamonapi.Monitor
import org.codehaus.groovy.grails.commons.ConfigurationHolder
/**
 * @author eric weimer
 */
 class JamonFilters {
    
    Monitor monitor, viewMonitor, previewMonitor
    def skipControllers = (ConfigurationHolder.config.jamon.controllersToExclude)? ConfigurationHolder.config.jamon.controllersToExclude: []
    def filters = {

         monitorController(controller: "*", action: "*") {
             before = {
                 if (!(controllerName in skipControllers)) {
                     def monName = "Controller.${controllerName}.${actionName}"
                     monitor = MonitorFactory.start("${monName}")
                     previewMonitor = MonitorFactory.start("${monName}.noview")
                 }
                 true
             }
             after = {
                 if (previewMonitor) {
                     previewMonitor.stop()
                     def monName = "Controller.${controllerName}.${actionName}.view"
                     viewMonitor = MonitorFactory.start("${monName}")
                 }
                 true
              }
             afterView = {
                 if (monitor) monitor.stop()
                 if (viewMonitor) viewMonitor.stop()
                 true
              }
         }
     }
}

This code calls JAMon methods to start and stop timings. Note the variable skipControllers. This allows users of the plugin to easily define a list of controllers NOT to monitor by adding the variable
jamon.controllersToExclude to groovy.config.

This is all you need to do! Grails will add this filter to the application when you install the plugin.

To allow users to provide additional customizations to the plugin, we document some configuration settings they can set, and then access those settings in our plugin. For example, in the application's Config.groovy class, let's allow users to specify the following:

jamon.monitorControllers = true
jamon.monitorServices = true
jamon.servicesToExclude = ['consoleService']
jamon.controllersToExclude = []
jamon.additionalBeans = ['com.eweimer.terrapin.util.MediaAccess','com.eweimer.terrapin.util.Key']

These settings will allow users to turn off monitoring for Controllers or Services, and specify services NOT to monitor as well as additional Spring beans classes to include.

To access these values in our JamonGrailsPlugin, we'll import:

import org.codehaus.groovy.grails.commons.ConfigurationHolder

To perform a safe test on a boolean value we can use the following code to default to true when the user does not specify a value:

def skipServices = application.config.jamon.servicesToExclude ?: []

Put together, the code now looks like this:

def monBeanNames = []
def skipServices = application.config.jamon.servicesToExclude ?: []
  
if (application.config.jamon.monitorServices ?: true) {
   monBeanNames = application.serviceClasses.collect{ it.shortName[0].toLowerCase() + it.shortName[1..-1] }
   monBeanNames -= skipServices
}
if (application.config.jamon.additionalBeans) {
   monBeanNames += application.config.jamon.additionalBeans
}

By using this logic we can allow users to easily customize the behavior of our jamon plugin.

The final step is to deploy your plugin. Type "grails package-plugin" in the root of your plugin project and Grails will create a .zip file. Then go to your Grails application and type "grails install-plugin path-to-your-zip-file", and you are ready to go.

Deploy the jamon.war that comes with the JAMon distribution to your web server then point your browser to /jamon/menu.jsp to view the results. Viola!

I hope you enjoyed this series. I'll add one more installment about testing your plugin when I have the chance. Meanwhile, have fun!

Top Most JAMon plugin for Grails: Part 3 of 4

In this series we completed steps 1-3 of:

1. Add jamon.jar to the application classpath
2. Use JAMon's datasource proxy to monitor SQL
   
3. Implement the JAMonServletFilter to monitor page hits
   
4. Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
5. Add a Spring filter to monitor Grails controllers.

Let's move on to step 4 : "Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services."

We'll add this to the doWithSpring closure. First we'll define a jamonInterceptor bean. It accepts a prefix attribute, which can be set to anything you like:

def doWithSpring = {
   jamonInterceptor( org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor, true, true ) {
      prefix="Class."
   }
}

Next we need to get a list of beans to intercept. Service class beans are named by the class name with the first character set to lower case. Grails provides a list of service classes via the application object:

def monBeanNames = application.serviceClasses.collect{ it.shortName[0].toLowerCase() + it.shortName[1..-1] }

Finally we use Springs BeanNameAutoProxyCreator to add the jamon interceptor to the service classes:

if (monBeanNames) {
   autoProxyCreator( org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator ) {
      proxyTargetClass="true"
      interceptorNames=["jamonInterceptor"]
      beanNames=monBeanNames as String[]
   }
}

Put it all together, it looks like this:

def doWithSpring = {
   def monBeanNames = application.serviceClasses.collect{ it.shortName[0].toLowerCase() + it.shortName[1..-1] }

   if (monBeanNames) {
      jamonInterceptor(org.springframework.aop.interceptor.JamonPerformanceMonitorInterceptor, true, true) {
      prefix="Class."
      }

      autoProxyCreator(org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator) { 
      proxyTargetClass="true"
      interceptorNames=["jamonInterceptor"]
      beanNames=monBeanNames as String[]
   }
}

In part 4 of this series, we'll complete task #5 and deploy our JAMon plugin.

Top Most JAMon plugin for Grails: Part 2 of 4

In part 1 we discussed four tasks needed to create a JAMon plugin. The first task was completed simply by adding jamon.jar to our plugin's lib folder. To review, the steps are:

1. Add jamon.jar to the application classpath
2. Use JAMon's datasource proxy to monitor SQL
   
3. Implement the JAMonServletFilter to monitor page hits
   
4. Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
5. Add a Spring filter to monitor Grails controllers.

As I mentioned previously, our plugin project has a file named: JamonGrailsPlugin.groovy. This is where we'll implement steps 2-5.

JamonGrailsPlugin.groovy comes with a series of closures pre-defined. To change the datasource we add code to the doWithSpring closure. This closure allows you to update your Spring configuration.

We need to change the driverClassName to "com.jamonapi.proxy.JAMonDriver" and alter the url by adding "jamon:" after "jdbc:" and appending a parameter named "jamonrealdriver".

First lets add an import:

import javax.sql.DataSource

Then code the closure:

def doWithSpring = {
   def config = application.config
   def orgUrl = config.dataSource.url
   def driverClassName = config.dataSource.driverClassName
   
   String appendUrl = (orgUrl.contains('?')? '&': '?') + 'jamonrealdriver=' + driverClassName
   if (orgUrl.contains("oracle:")) appendUrl = 'jamonrealdriver=' + driverClassName
   def url = orgUrl.replace("jdbc:","jdbc:jamon:") + appendUrl

   config.dataSource.url = url
   config.dataSource.driverClassName = "com.jamonapi.proxy.JAMonDriver"
}

Step 3 is "implement the JAMonServletFilter to monitor page hits."

The doWithWebDescriptor closure will allow us to add our filter to the application. We need to append to both the <filter> and <filter-mapping> sections. Note that this is typical Grails builder code. The 'filter-mapping' node needs to be in quotes due to the hyphen in it's name:

def doWithWebDescriptor = { webXml ->
   def filters = webXml.filter
   filters + {
      filter {
         'filter-name'("jAMonServletFilter")
         'filter-class'("com.jamonapi.http.JAMonServletFilter")
      }
   }

   def filterMappings = webXml.'filter-mapping'
      filterMappings + {
         'filter-mapping' {
            'filter-name'("jAMonServletFilter")
            'url-pattern'("/*")
          }
      }
   }

} 

In part 3 we'll move on to step #4.

Top Most Jamon plugin for Grails: Part 1 of 4

JAMon is a popular, flexible, lightweight open source Java performance monitor. I won't cover all the features here, but in short JAMon can monitor performance, memory, number of users, basically any quantity you can access in Java.

To view the statistics JAMon provides a WAR file that you can deploy to your server along with your application. The war provides a set of JSP pages allowing you to view and export the data you are monitoring.

Another option is to incorporate the WAR into your application. It requires a little more work but you can enhance it to your hearts content.

Adding JAMon to Grails is really quite simple. What required some time was to experiment with the different methods JAMon can be inserted into your application. I prefer automation over hard-coded solutions.

Here are the tasks needed to get JAMon set up with an initial set of monitors:

1. Add jamon.jar to the application classpath
2. Use JAMon's datasource proxy to monitor SQL
   
3. Implement the JAMonServletFilter to monitor page hits
   
4. Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
5. Add a Spring filter to monitor Grails controllers.
   

Ideally it would be nice to separate this code in a way that JAMon could be applied to any Grails project. In fact, I found that to be the simplest approach! This solution just cries out for a Grails plugin.

I won't go into all the details regarding plugins. Good references are available here, here and here.

Fist download the JAMon distribution and unzip it.

Assuming you have a target application, let's assume you'll be creating your plugin in the same workspace (i.e. directory). Open a command prompt in that folder and type:

grails create-plugin jamon

If you've never created a plugin before you'll notice that Grails creates a typical Grails application with one additional file in the top directory: JamonGrailsPlugin.groovy.

This file is where we'll be doing most of the work.

To complete task #1 (add jamon.jar to the classpath), simple copy jamon.jar to jamon/lib. When an application installs the plugin, Grails will add jamon.jar to the classpath. That's all you need to do!

Next time I'll show how to implement the remaining tasks. Stay tuned.

Top Most JAMon

Years ago I discovered a little gem in the world of a free and open source software: JAMon.

Still in use today, JAMon's mind-numbingly simple API provides a wealth of value for minimal effort. JAMon has now spawned competing products, each with its unique pros and cons.

JAMon is called a lightweight monitor. This may disappoint those who prefer large, feature-filled enterprise level commercial products, but the reality is JAMon delivers most of the data you need with minimal impact on performance. I would never consider developing a Java application without JAMon or some other monitoring solution. (JAMon is available for other languages as well.)

Best of all, you can have JAMon up and running in a few hours (or less)!

JAMon excels at timing code execution. Without any code changes you can configure JAMon to monitor SQL, method calls (via Spring AOP), as well as application entry and exit points.

In addition to execution time, JAMon allows you to monitor ANY data that can be expressed numerically. Common usage includes the number of users by hour of the day (to find usage peaks), simultaneous users, memory, heap size, session size, # of active sessions, and so on.

JAMon accumulates statistics rather than details which allows it to minimize its memory footprint. As it turns out, that is an excellent comprimise. JAMon keeps track of the number of invocations, min, max, average and standard deviation, as well as the min, max and average number of simultaneous executions, which is great for bottleneck analysis.

Although criticized for its inability to save statistics to a persistent store, you can do so with a little work if needed. You can persist statistics to a database, log file, expose them via JMX, etc.

You can configure JAMon start and stop monitoring dynamically. JAMon is typically measured at less than one percent overhead while turned on, and much less when turned off.

So if you have no monitoring (or your monitoring solution cannot be run in production), try JAMon or one of it's competitors. Documentation is a bit on the light side but there are plenty of examples on the Web.

And if you are a Grails developer, look for my posts about how to create a simple plugin to enable JAMon in your Grails applications.

Top Most Testing the Grails JAMon Plugin

Previously I wrote about creating a JAMon plugin for Grails. Today I'll add some tests.

Since a plugin is a Grails application, you should add tests to your plugin project. Let's begin with opening a command window in the plugin project (jamon) and creating a test class:

grails create-integration-test JamonGrailsPlugin

Now we edit the class Grails created. We find this class in jamon\test\integration\JamonGrailsPluginTests.groovy.

First we see Grails creates a class that extends GrailsUnitTestCase. Since this is an integration test, we'll change it to extend GroovyTestCase instead. Let's add a few handy imports as well:

import grails.test.*

import org.codehaus.groovy.grails.commons.ApplicationHolder
import org.codehaus.groovy.grails.commons.GrailsApplication
import javax.sql.DataSource

class JamonGrailsPluginTests extends GroovyTestCase {

I'll add a couple variables for brevity sake:

def app = ApplicationHolder.application
def ctx = app.mainContext

Next we'll add the boiler plate setUp and tearDown methods. I like AgileDox naming so I'll override getName() as well:

protected void setUp() {
        super.setUp()
    }

    protected void tearDown() {
        super.tearDown()
    }
    
    public String getName() {
        return super.getName().substring(4).replaceAll("([A-Z])", " \$1").toLowerCase();
    }

This first test will be to verify the dataSources have been updated with the jamon proxy:

void testDataSourcesAreJamonEnabled() {
        ctx.getBeanNamesForType(DataSource).each{ beanName ->
            def bean = ctx.getBean( beanName )
            assertEquals "com.jamonapi.proxy.JAMonDriver", bean.driverClassName
            assert bean.url.startsWith("jdbc:jamon:")
            assert bean.url.contains('jamonrealdriver=')
        }
    }

We make use of the Spring method getBeanNamesForType() to get all beans subclassed from DataSource, then simply test the attributes we attempted to set.

To verify that jamon is configured in the Spring context, we need a class in the plugin, such as a service class, to verify it is included in autoProxyCreatorBean. We can add a service by the grails command 'grails create-service jamonTest'. Of course we do not want the class added to our target applications, so we add the classname to the pluginExcludes variable in JamonGrailsPlugin:

def pluginExcludes = [
     "grails-app/views/error.gsp",
     "grails-app/services/JamonTestService.groovy"
   ]

Now we can code out test:

void testJamonHasSpringAop() {
        assertNotNull ctx.getBean("jamonInterceptor")
        def autoProxyCreatorBean = ctx.getBean("autoProxyCreator")
        assertNotNull autoProxyCreatorBean
        assertArrayEquals (["jamonTestService"].toArray(), autoProxyCreatorBean.beanNames.toArray()) 
    }

The remaining tests can be coded in a similar fashion. It is a good idea to include tests for all the plugin behaviours as well as any bugs that creep up over time.

That is it for the JAMon series. Hope these articles saved you some time. Your comments are encouraged!

Top Most Java Architect Interview Questions and Answers **Updated for Java 7!**

Who are you?

I am a IT veteran and consultant with 20+ years of experience leading Full Life Cycle Application Development, from startup to the enterprise, in the Chicago-land area. (Note, Chicago no longer has gangsters. It is perfectly safe to raise your kids here. Just avoid the areas controlled by the mafia.)

CORRECTION: There is no mafia in Chicago or it's surrounding suburbs, except for ...(edited).

NEW CORRECTION: There is no mafia in Chicago or it's surrounding suburbs. PERIOD.

My apologies. So I claim to be a computer veteran. This is only because my first three dreams: Rock Star, Baseball Player and Novelist, didn't quite pan out.

(AND movie producer, almost forgot that one. But if I get a camcorder, write a script, and coerce dome gullible, wannabe actors and actresses...)

Humor in the Workplace

Anyway, I digress. And now that I've diverged this far, I may as well explain. I do not think I'm funny, nor am I trying to be. This is just how it comes out when I write. If you ever hire me, please know I clean up my writing and make it professional. But I'll happily supply the first draft for your amusement. (It makes great ammunition when you have to cut costs.)

However I've had requests to leave the alleged humor in my documents because "IT is so dry". Take that as you will.

Getting on track...

Semi-Qualifications

I have both given and been the recipient of many Java Architect interviews. (This is true, I'm afraid.) I've fielded questions that include "what is the difference between a class and an object", and even more challenging ones. (Also true, "you know who you are....")

Service to the Community (i.e Complaints)

But first, I must do service to the IT community and complain about three things:

1. The interviewer asks a question looking for agreement with their opinion, despite the fact the industry is still debating the question, and the company would be better served with a diversity of opinion.
2. Does any organization bother to train it's IT employees how to interview? I've had a single client that did, and the training was optional and the approach was never used
3. Studies show the majority of Americans believe they are better than average drivers, LOL. My personal observation is most IT interviewers believe they are uniquely good interviewers.

Interview Best Practices

It's productive to have an informal chat with a prospect. But if I can get a client to use a lightweight process that quantifies results, they are, in most cases, SOLD!

Case Study

At a client I interviewed candidates with two team leads. To prepare, I simply threw together a spreadsheet with around 5 questions for each job requirement (it's all we had time to ask).

The questions ranged from simple to very advanced. Each questioned had a 'value' assigned, the simple questions having the highest, the advanced the lowest. I added simple formulas to sum results and copied the original tab for each interview.

We ended with a short list of two candidates, who seemed to be roughly equal. However I preferred the woman and my two male team leads preferred the man.

To resolve the impasse, I opened the spreadsheet and compared results. Within a minute we realized the woman answered one more question in each and every category! So we agreed to hire her, and she performed well.

The morale of the story is, with a trivial amount of extra effort, we made a better choice, because we used objective measures.

I always recommend you tech your prospective architect. In fact I've been paid to tech Java architects and developers as a part time job.

Think about it, someone decided to pay ME to interview their Java candidates.Wonders never cease.

Interview Questions

Here are some questions any good architect should know. Pains have been taken to avoid ambiguous answers, but YMMV.

Select the BEST answer...

Simple Questions (15 points each)

1. xUnit is a family of frameworks that can be used for:
    a. Unit tests
    b. Integration tests
    c. Both unit and integration tests
    d. xUnit has nothing to do with testing

2. TDD stands for:
     a. Temporal Date Design patterns
     b. Test Driven Development
     c. Test Driven Design
     d. Both b and c

3. One object oriented design technique is:
     a. Noun Harvesting
     b. Design Patterns
     c. UML
     d. BREAD

4. A UML Class Diagram does not sufficiently describe an OO system because:
     a. It does not show interfaces
     b. It does not show composition
     c. It does not show class relationships
     d. It is a static diagram

5. The difference between aggregation and composition is:
     a. They are both the same
     b. Composition is an "owning" relationship
     c. Aggregation is an "owning" relationship
     d. Composition groups like objects, aggregation groups family's of objects

Medium Difficulty (10 points each)

6. A domain model is:
    a. The entire application
    b. An object oriented model that represents user interactions
    c. An object oriented model of the business that the application is automating
    d. An object oriented model containing the business rules

7. The difference between "rich" and "anemic" domain models is:
     a. A rich model has business logic
     b. A rich model has Design Patterns
     c. An anemic model has no Design Patterns
     d. Both b and c

8. Refactoring is:
     a. A process to fix bugs introduced by programmers
     b. Any general bug fix
     c. A re-architecture of the code that does not change it's behavior
     d. A re-architecture of the code to make it more efficient

9. Scrum is:
     a. An Agile methodology
     b. All you need to be "Agile"
     c. Assumes developers use best development practices
     d. a and c

10. Which of the following is NOT a common architectural application tier:
     a. Presentation tier
     b. Persistence tier
     c. Object Orientated tier
     d. Both a and b

Advanced Questions (5 points each)

11. The expression "favor composition over inheritance":
     a. Is stated in the "Gang of Four" Design Patterns book
     b. Appeared after the "Gang of Four" Design Patterns book
     c. Is based on the idea that inheritance is more tightly coupled than composition. 
     d. Is based on the idea that composition is more tightly coupled than inheritance.
     e. Both A and D
     f. Both A and C

12. The Liskov substitution principle:
     a. Is required to support class inheritance
     b. Is a mathematical model for the facade Design Pattern
     c. Is a mathematical principle that has nothing to so with programming
     d. Makes all computer languages work

13. GRASP is:
     a. An acronym for a set of practices that lead to good UI design
     b. Is Craig Larman's learning aid to help in the design of object-oriented software
     c. Is Peter Coad's learning aid to help in the design of User Interfaces
     d. A trick question, there is no reference to GRASP in computer literature

14. Design Patterns are:
     a. Common object orientated solutions
     b. New objected oriented solutions
     c. Created by Java experts to teach good design
     d. Only useful to architects

15. Agile methods are:
     a. An example of "Waterfall" methodologies
     b. A fad no longer recommended by industry leaders
     c. No different than development techniques of the last 30 years
     d. Considered a current industry best practice

Java version 5-7 questions (5 points each)

16. Java 5 Generics:
     a. Ensure compile-time type safety
     b. Ensure compile and runtime type safety
     c. Have nothing to do with type safety
     d. Are useful only for Java collections

17. What is the most significant cause of concern for Java Annotations?
     a. You cannot create your own annotations
     b. They cause additional classes to be loaded, slowing performance
     c. The represent a tight coupling
     d. There are no significant drawbacks

18. Regarding CMP and JPA:
     a. JPA and CMP are designed to work together, but CMP is optional
     b. JPA and CMP are designed to work together, and CMP is required
     c. JPA without CMP requires a JTA transaction controller
     d. JPA replaces CMP

19. Advantages of the Spring Framework over JPA:
     a. JPA is a standard
     b. Spring supports Dependency Injection
     c. JPA uses annotations that couple domain classes to the framework
     d. Spring is free

20. Advantages of JPA over the Spring Framework:
     a. None. The advantages are part of CMP
     b. JPA is implemented by Hibernate "under the covers"
     c. JPA provides vendor independence
     d. Spring uses more libraries

New Technology

21. What is the biggest difference between Ruby and Groovy?
     a. Groovy uses the familiar C-based syntax while Ruby does not
     b. Ruby supports runtime code compilation.
     c. Groovy is meant for scripting
     d. Ruby executes faster because it's written in C.

22 Grails is considered scalable:
     a. Because it supports static classes
     b. Because it supports multithreading while Rails does not
     c. Because it is based on Spring and Hibernate
     d. Grails has not been shown to scale.

23 Which is easier to learn: Grails or Rails?
     a. Rails, because Ruby has a simpler syntax.
     b. Rails, because it uses more common Design Patterns
     c. For Java developers, Rails, because Ruby is simpler than Java.
     d. For Java developers, Grails, because Groovy is mostly Java compatible.

24 NoSql database performance can be restricted by:
     a. Access via services, which are slower than direct calls .
     b. The CAP theorum
     c. The DAP theorum
     d. Both c and d.

25 Cloud computing:
     a. is always hosted by a third party like Amazon, Google or Rackspace
     b. requires NoSQL databases
     c. cannot be used to host Java Web Applications
     d. achieves economy of scale



-
-
-
F
I
L
L
E
R
-
-
-
A
N
S
W
E
R
S

B
E
L
O
W
-
-
-

Answers:

1. xUnit is a family of frameworks that can be used for:
• Answer:c. Both unit and integration tests
• Note:jUnit, like other xUnit variations, can drive both unit and integration tests, as well as others.
2. TDD stands for:
• Answer: d: Both b and c
• Note:TDD is alternatively called Test Driven Design or Test Driven Development
3. One object oriented design technique is:
• Answer: a. Noun Harvesting
• Note:Noun harvesting is a classic OOD technique
• Note:None of the others are OOD techniques
4. A UML Class Diagram does not sufficiently describe an OO system because:
• Answer:d. It is a static diagram
• Note:Class diagrams do not document object interactions
• Note:Other diagrams like sequence and activity diagrams capture dynamic interactions
5. The difference between aggregation and composition is:
• Answer: Composition is an "owning" relationship
• Note:In composition, if an object is removed, it's related objects are also removed
• Note:In aggregations, related objects can exist on their own
6. A domain model is:
• Answer: c. An object oriented model of the business that the application is automating
• Note:The term "domain" refers to the business domain being automated by the application
7. The difference between "rich" and "anemic" domain models is:
• Answer: a. A rich model has business logic
• Note: According to Martin Fowler, a rich model contains business logic
• Note: According to Martin Fowler, an anemic model contains POJO)'s (properties, getters, setters, equals() and HashCode()).
8. Refactoring is:
• Answer: c. A re-architecture of the code that does not change it's behavior
• Note: Martin Fowler wrote the refactoring "bible".
9. Scrum is:
• Answer: d. a and c
• Note: Scrum is considered an Agile Methodology
• Note: Scrum assumes developers use best development practices, like Extreme Programming
• Note: A project with Scrum and traditional engineering practices is not considered "Agile".
10. Which of the following is NOT a common architectural application tier:
• Answer:  c. Object Orientated tier
• Note: Presentation and Persistence are common architectural tiers managing the User Interface and data persistence respectively. The "middle" tier has various names, or is sometimes just called the "middle tier".
11. The expression "favor composition over inheritance":
• Answer:  f. Both A and C
• Note: This advice appeared as early as the 1995 GOF Design Patterns book
• Note: We favor composition because it is more loosely coupled than inheritance
12. The Liskov substitution principle:
• Answer: a. Is required to support class inheritance
• Note: The Liskov substitution principle defines how sub-types work.
• Note:It applies only to OO languages.
13. GRASP is:
• Answer:b. Is Craig Larman's learning aid to help in the design of object-oriented software
• Note: Craig Larman wrote the classic book Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process
14. Design Patterns are:
• Answer: a. Common object orientated solutions
• Note: Curiously the Java folks created a number of "patterns" intended to be used in web applications, which contradicts the definitions of "well known".
• Note: Most Java architects tried, then abandoned, most of the Java patterns, especially after Martin Fowler's classic PofEAA book was published.
15. Agile methods are:
• Answer: d. Considered a current industry best practice
• Note:The debate has ended some time ago.
16. Java 5 Generics:
• Answer:  a. Ensure compile-time type safety
• Note: Generics are a compile-time only feature
• Note: IMHO, after a decade of code reviews, I have yet to see a bug that generics would have prevented. 
• Note: Generics make Java code even more verbose (see Groovy)
• Note: Most IT shops I know have added generics as a coding requirement
17. What is the most significant cause of concern for Java Annotations?
• Answer: C: The represent a tight coupling
• Note: (A) is not true
• Note: The overhead referred to in (B) is trivial.
• Note: Annotations represent a tight coupling to a specific framework. 
• Note: Tight coupling has historically been considered a significant negative. However many Java folks are embracing annotations for code reduction. This trade-off is still being debated. However it can be confidently stated that the tight coupling annotations represent is their major concern.
18. Regarding CMP and JPA:
• Answer: d. JPA replaces CMP
19. Advantages of the Spring Framework over JPA:
• Answer: c. JPA uses annotations that couple domain classes to the framework
• (A) is commonly used to cite advantage for JPA, not Spring.
• (B) Both solutions support DI.
• (D) Both solutions can be obtained free of charge.
• Note: Java annotations, like any direct class reference, represents a tight coupling.
• Note: Tight coupling makes changing the dependent framework more expensive.
20. Advantages of JPA over the Spring Framework:
• Answer: c. JPA provides vendor independence
• Note: (A) JPA deprecates CMP
• Note: (B) This is irrevelant to the question.
• Note: (D) The fact Spring uses more libraries is not considered an issue.
21. What is the biggest difference between Ruby and Groovy?
• Answer: a. Groovy uses the familiar C-based syntax while Ruby does not
• Note: Both languages tend to keep up with each others features
• Note: Both Java and Groovy use "C" syntax, while Ruby does not
22. Grails is considered scalable
• Answer: c. Because it is based on Spring and Hibernate
• Note: Grails began as an API over Spring and Hibernate, both known to scale.
• Note: At that time Rails did not support multi-threading and was restricted to small web applications.
• Note: Rails scales quite well now.
23. Which is easier to learn: Grails or Rails?
• Answer: d. For Java developers, Grails, because Groovy is mostly Java compatible.
• Note: (A-C) are incorrect
24. NoSql database performance can be restricted by:
• Answer: b. The CAP theorum
25. Cloud computing:
• Answer: d. achieves economy of scale
• Note:(A-C) are not true

If anyone has opinions or facts that are pertinent to this posting, I'd love to hear about them.

Thanks, and have a pleasant tomorrow.

Top Most Java Best Practices to Follow while Overloading Method and Constructor

Method overloading in Java needs to be use carefully. Poorly overloaded method add not only add confusions among developers who use that but also they are error prone and leaves your program on compiler's mercy to select proper method. It's best to avoid issues related to method overloading in Java by following some Java best practices. For those who doesn’t know What is method overloading in Java, method overloading means declaring two method with same name but different method signatures. This is generally done to create method which operates on different data types e.g. System.out.println() which is overloaded to accept different types of parameters like String, double, int etc, see this Java tutorial on method overloading and static vs dynamic binding for more details. By the way all of these Java best practices which are explained in context of method overloading are equally applicable to constructor overloading in Java, because in terms of overloading method and constructors are almost same.

Read more »

Top Most Java Mistake 3 - Using "==" instead of equals() to compare Objects in Java

In this part of Java programming mistakes, we will take a look on another common pattern, where programmers tend to use "==" operator to compare Objects, similar to comparing primitives. Since equality of object can be very different in physical and logical sense, and in case of domain objects it's mostly driven by business rules, comparing objects with "==" operator, introduces subtle bugs, which are hard to find. Difference between equals() and == operator,  one of the Java classics is also asked to find out if developer is familiar with this important concept or not. Using == operator only make sense when comparing primitives like int, or final constants like Enum. Though there is more involve in comparing two Enum, which you learn by following that link. One of the most common pattern of this mistake is is comparing two Strings with == operator, which we will see in this article. By the way this is third in series of common Java programming mistakes, and if you haven't read the previous two, you can read them here :

• Java Mistake 1 : Using double and Float for monetary Calculation
• Java Mistake 2 : Mixing up static and non static synchronized methods

Read more »

Top Most Why getter and setter are better than public fields in Java

public modifier vs getter and setter method in Java

Providing getter and setter method for accessing any field of class in Java may look unnecessary and trivial at first place, simply because you can make field publicand it’s accessible from everywhere in Java program. In fact many programmers do this in there early days but once you start thinking in terms of enterprise application or production code, you will start seeing how much trouble it can create in terms of maintenance. Since as per SDLC process, software spends more time in maintenance than development, it’s worth keeping ease of maintenance as one of goal in development. In reality using getter and setter method in Java is one of the Java coding best practice much like using @Override annotation while overriding method in Java. Main problem with making field public instead of getter and setter is that it violates Encapsulationby exposing internals of a class. Once you exposed internals of class  you can not change internal representation or make it better until making change in all client code. Since every code change comes with risk and cost of regression testing is high during maintenance, its not a good idea to make field public in Java.  In this Java tutorial we will see some more benefits getter and setter offers over public fields in Java.

Read more »

Top Most How to create Immutable Class and Object in Java - Tutorial Example

Writing or creating immutable classes in Java is becoming popular day by day, because of concurrency and multithreading advantage provided by immutable objects. Immutable objects offers several benefits over conventional mutable object, especially while creating concurrent Java application. Immutable object not only guarantees safe publication of object’s state, but also can be shared among other threads without any external synchronization. In fact JDK itself contains several immutable classes like String, Integer and other wrapper classes. For those, who doesn’t know what is immutable class or object, Immutable objects are those, whose state can not be changed once created e.g. java.lang.String, once created can not be modified e.g. trim, uppercase, lowercase. All modification in String result in new object, see why String is immutable in Javafor more details. In this Java programming tutorial, we will learn, how to write immutable class in Java or how to make a class immutable. By the way making a class immutable is not difficult on code level, but its the decision to make, which class mutable or immutable which makes difference. I also suggest reading, Java Concurrency in Practiceto learn more about concurrency benefit offered by Immutable object.

Read more »

Top Most Grails Logging

I am in the middle of a Grails/Flex project. One of the criteria involved with the selection of Grails was the large number of blogs, articles and documentation available.

The other criteria was, of course, improved productivity.

We have an aggressive deadline of eight weeks. Our customer chose the Drupal CMS for the site, but we had concerns about it's suitability and scalability. We ended up using Drupal for it's strengths, like FAQ's, blogs, etc. We selected Grails for the bulk of data handling and Flex for the front end. (No one does "eye candy" as well as Flex. Perhaps JavaFX some day, but today it is Flex.)

For the most part, Grails has grown so popular it has been easy finding solutions to common problems. However, one area lacking in advice is, oddly enough, basic logging.

So here is our logging configuration. We use four appenders, the console and three rolling files. The console is designed to make watching the application as painless as possible. Besides the usual Grails output, it displays only error level logging.

The three rolling file appendars contain error, debug and trace level logging respectively. The error log is great for quickly determining if any errors have occurred.

The debug log is excellent for researching issues not made obvious by the error log. The trace log adds Hibernate data values to the queries if you really need that level of detail.

So here it is, a working Grails 1.1 version logging configuration, straight from Config.groovy. As it turns out, the best source for learning about this is the documentation from the Grails web site.

I hope you find this useful:

log4j = {

 appenders {
  console name:'console', threshold:Level.ERROR,layout:pattern(conversionPattern: '%p %d{ISO8601} %c{4} %m%n')
  rollingFile name:"rollingFileTrace", threshold:Level?TRACE, maxFileSize:1048576,  file:logFile+'Trace?log', ayout:pattern(conversionPattern: '%p %d{ISO8601} %c{5} %m%n')
  rollingFile name:"rollingFileDebug", threshold:Level?DEBUG, axFileSize:1048576,file:logFile+'Debug.log', layout:pattern(conversionPattern: '%p %d{ISO8601} %c{5} %m%n')
  rollingFile name:"rollingFileError", threshold:Level.ERROR, axFileSize:1048576,file:logFile+'Error.log', layout:pattern(conversionPattern: '%p %d{ISO8601} %c{5} %m%n')
 }

  error console, rollingFileDebug, rollingFileError, rollingFileTrace:
   'org.codehaus.groovy.grails.web.servlet',  //  controllers
   'org.codehaus.groovy.grails.web.pages', //  GSP
   'org.codehaus.groovy.grails.web.sitemesh', //  layouts
   'org.codehaus.groovy.grails."web.mapping.filter', // URL mapping
   'org.codehaus.groovy.grails."web.mapping', // URL mapping
   'org.codehaus.groovy.grails.commons', // core / classloading
   'org.codehaus.groovy.grails.plugins', // plugins
   'org.codehaus.groovy.grails.orm.hibernate', // hibernate integration
   'org.springframework'

  debug rollingFileDebug, rollingFileTrace:'org.hibernate',
   'com.britetab',
   'BootStrap',
   'org.apache.ddlutils'

  trace rollingFileTrace:'org.hibernate.SQL',
   'org.hibernate.type',
   'flex.messaging.services'

  warn  console,rollingFileDebug,rollingFileTrace:'org.mortbay.log',
   'org.hibernate.tool.hbm2ddl'

 root {
  error 'console','rollingFileError','rollingFileDebug','rollingFileTrace'
  additivity = true
 }
}

Top Most Why use @Override annotation in Java - Coding Best Practice

@Override annotation was added in JDK 1.5 and it is used to instruct compiler that method annotated with @Override 

is an overridden method from super classor interface. Though it may look trivial @Override is particularly useful while

overriding methods which accept Object as parameter just like equals, compareToor compare() method of Comparator 

interface. @Override is one of the three built in annotation provided by Java 1.5, other two are @SuppressWarnings and @Deprecated. Out of these three @Override is most used because of its general nature, while @SuppressWarnings is also used while using Generics, @Deprecated is mostly for API and library. If you have read my article common errors while overriding equals method than you have see that one of the mistake Java programmer makes it,  write equals method with non object argument type as shown in below example:

Read more »