3.times { theFun }

How to Interview Developers

2011-05-08T20:47:00.000-05:00

Over the years I have performed many interviews. I’ve also been on the other side of the table and am frequently amazed by the range of quality of interviews. I believe I do an excellent job at interviewing candidates, but then again so do most of the interviewers I’ve met.

The problem of determining how well a candidate will perform in a role is difficult. We look at the past as an indicator of the future, but it is hard to determine past performance when each candidate has learned to show their background in the most positive manner.

There are many techniques to assess a candidate, but I prefer to look at how useful they are. There are no good or bad questions, just degrees of usefulness. Here are some of what I consider "best interview practices".

Repeatability. We frequently interview multiple candidates for a role, and it is critical to be able to compare them. Use a form with interview questions and score them. Include both technical and soft skills, and leave room for comments. Scores are always approximate, but are useful when making comparisons.

Focus on time in your assessment. API's are displayed in an instant with any modern IDE. Any mediocre developer can memorize API's, but do they know how to solve problems? It is far more useful to understand concepts than being able to memorize classes and methods.

Theory versus practice. Yes, there are some folks who excel at theory but have trouble coding. If you need them to code, a take-home coding problem works very well to filter those out. Spend the little time you have in the interview to assess the level of understanding the candidate has.

Gear questions to the role. Ask questions that the candidate needs for the role, then add a few at a level higher. This provides a good indication of of how well suited the candidate is for the role and how close they are for the next step up. If the role is a lead developer, skip the simple questions life "what is the difference between a class and an object" and ask questions that show deeper understanding like" what is the difference between composition and aggregation"?

Avoid hangups. Keep personal bias out of the process. One common anti-pattern is when the candidate reminds one of someone else who did or did not turn out well. It happens with technical questions as well as appearance, previous employers, schooling, etc. And it goes both ways, like the pony-tailed guy who won the job over a short-haired competitor. I've had both short and long hair, but am the same person. And in these days of casual dress, I really do not care if anyone wears a tie or not. As long as they show up on time in clothes that do not offend, I am fine. In fact if I can contact them before the interview I ask them to dress like they would while on the job. Then when they show up in a Cubs jersey, well lets not go there..

Keep it real. An interview is an artificial situation to begin with, so keep the questions clear and realistic. Much has been written about the type of questions with no answer, but how does that translate to work? Questions that are too vague or too hypothetical are simply not predictive about success. Keep the interview realistic; time is short.

Ask about trends. Good developers are often aware of industry trends. When all they know is what they've encountered at work, they could be good at grinding out code but will not succeed as leaders. Do they have at least a high level understanding of trends (e.g. clouds, tdd, ddd, bdd, lean, scrum, esb, soa, etc.)

Ask about objectivity. Can the candidate separate personal from professional opinion? Do they make blanket statements? Do they contradict industry best practices by repeating arguments that were settled years ago? Are they open to other opinions?

Determine rationality. Look for those who are willing to work with your standards but eager to debate. It is OK to engage in a friendly debate to see if they can do so without getting heated and angry.

Sell. Obviously you want to attract good people and the interview is a great place to get candidates excited. Be yourself to allow a natural bonding to occur. Be honest about the job and discuss what others in the role like and dislike. Realistically you both need to determine if you'll work well together.

Economies of Open Source

2011-05-08T20:42:00.000-05:00

Perhaps the most unexpected success story of the last decade is the proliferation of open source software.

When Richard Stallman began touting his ideas regarding free software (free as in free beer) many viewed this as idealistic. Of course Stallman had no issues about getting paid to write software. His assertion was that software represented information that should be shared. It was expected at this time that open source software would play at most a minor role in mainstream development.

Historically software vendors vigorously guarded their source code to maintain competitive advantage. What we know today is availability of source code is an asset to developers, while competitors are only slightly hindered due to modern code dis-assemblers..

Linksys made history by opening their source code, which spawned a mini-industry of firmware upgrades that fueled sales of their hardware. Linksys effectively changed their revenue model from a hardware/firmware offering to a hardware solution with a basic operating system that users can easily upgrade, often for free.

Vendors are exploring other revenue models that, for instance, combine open source software with enhancements (e.g. IBM Websphere) or offer support and consulting (e.g. SpringSource).

Whether you like the idea of Open Source or not, odds are that just about any modern application makes use of some Open Source software. .NET developers are adopting open source tools like nHibernate and Spring.net. Look under the wraps at IBM's Websphere and you will find it is largely based on Open Source solutions.

The reason is that in many domains, Open Source solutions now offer industry best solutions. This seems to be a contradiction to all things we learned about free market economics. How can free software compete with commercial solutions?

The answer is quite simple: marketing. We take for granted that a vendor needs to peddle their wares. Competition results in better products for the consumer, however sales teams skew the picture to gain competitive advantage.

In general Open Source solutions have no marketing, no sales teams, no slick presentations. The community vets these solutions, allowing the best to bubble to the top. It is the lack of marketeers that allow Open Source solutions to compete on merit alone, and that has resulted in today's plethora of high quality Open Source options.

Perhaps the most common misunderstanding is about how Open Source solutions as funded. Certainly some are created out of passion, career enhancement or ego fulfillment. However Microsoft has performed so well that competitors now fund the Open Source community. In fact most large vendors have paid positions that contribute either part or full time to the community.

It will be interesting to see what the future holds for the Open Source community. In the meantime, enjoy the riches available now, and contribute back to the community if you have the chance.

Architecture in the Enterprise

2010-07-03T15:14:00.002-05:00

Recently I heard about a consulting company that sent a prospect to interview for an Enterprise Architect role. The interviewer, resume in hand, zeroed in on the lack of EA experience. Unfortunately the folks who set this up never identified this as an Enterprise Architect role. The prospect was a software architect, not an Enterprise Architect.

Unfortunately some managers in recent years have appropriated the term 'architect' after running out of titles for the senior developers. Senior-senior developer? Master developer? Guru developer? I must admit, 'architect' sounds better.

In reality architecture is a set of disciplines, each unique and specific. Beware of the unmodified term "architect", it has no meaning without context.

In my experience, I have seen the following architecture roles:

Enterprise Architect
Enterprise architecture is performed at the strategic level. Typically EA's plan future-state architectures for the enterprise. They do no development at all and actual development experience is helpful but not necessary. EA's can provide competitive advantage over the long run. They can also bring an enterprise to it's knees.

Technical (or Solution) Architect
This is a project-level position that recommends the hardware best suited for an application or system of applications. Actual development experience is helpful but not necessary.

Chief Architect
In the mid-late 1990's architects were seen as overhead, but motivation existed for CIO's to have an architect. This would be a very senior person, essentially the only named architect in the enterprise. Nowadays Chief Architect is sometimes used to designate the top architect, or can be just a ceremonial title.

Application Architect
Works at the project level, typically overseeing all technical aspects of the project. This is the original "architect", responsible for frameworks and design, aka "software architecture". Typically promoted from Technical Lead, the best AA's have been know to improve developer productivity by 2 times or more.

Network, Security, Data, Infrastructure, etc. Architects
These are technology-specific professionals who create enterprise standards, assist development teams and provide governance. They are responsible for their specific technical space, ensuring it meets project and enterprise requirements.

Summary
Each architecture role aligns with Enterprise Architecture and strategic business initiatives. For example, years before the current services trend, good application architects would design to support services, since future state architectures were likely to move to a Services Orientated Architecture.

Each architecture role is fairly specific with little overlap. They are specialists who help tame the complexity required of enterprise solutions through standards, governance and best practices. Some can play multiple roles with training and experience, but they are generally not interchangeable.

Chicago Groovy User Group - March 2010

2010-03-09T14:42:00.002-06:00

I am giving a talk on "recipes" at the March 9, 2010 Chicago Groovy User Group (www.cgug.org).

The Powerpoint may be found here.

Testing the Grails JAMon Plugin

2009-12-14T11:22:00.001-06:00

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!

JAMon plugin for Grails: Part 4 of 4

2009-11-22T14:33:00.082-06:00

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

Add jamon.jar to the application classpath
Use JAMon's datasource proxy to monitor SQL
Implement the JAMonServletFilter to monitor page hits
Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
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!

JAMon plugin for Grails: Part 3 of 4

2009-11-22T14:01:00.050-06:00

In this series we completed steps 1-3 of:

Add jamon.jar to the application classpath
Use JAMon's datasource proxy to monitor SQL
Implement the JAMonServletFilter to monitor page hits
Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
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.

JAMon plugin for Grails: Part 2 of 4

2009-11-22T13:45:00.004-06:00

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:

Add jamon.jar to the application classpath
Use JAMon's datasource proxy to monitor SQL
Implement the JAMonServletFilter to monitor page hits
Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
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.

Jamon plugin for Grails: Part 1 of 4

2009-11-22T12:01:00.006-06:00

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:

Add jamon.jar to the application classpath
Use JAMon's datasource proxy to monitor SQL
Implement the JAMonServletFilter to monitor page hits
Leverage Spring AOP via Spring's JamonPerformanceMonitorInterceptor class to monitor services
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.

JAMon

2009-11-20T22:44:00.012-06:00

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.

Grails Tweets

2009-09-25T01:06:00.004-05:00

Sven Haiges of grails podcast fame has created a Groovy/Grails/Griffon tweet aggregator that allows users to "re-tweet" important tweets, providing a community-based, self-organizing tweet prioritizing tweeting community (Getting dizzy. I should tweet about that.)

Check out http://www.groovytweets.org/.

Not satisfied with this, Sven created a nice "Headline Animator" that you can place on any html page to view the "important" tweets. This is one of three variations:

↑ Grab this Headline Animator

Danke

The Business of IT - ROI and CBA

2009-09-24T21:10:00.006-05:00

Two common tools businesses use to aid decision making are Return on Investment (ROI) and Cost Benefit Analysis (CBA). Use these tools to help sell your ideas to your management.

ROI is used when "spending money to save money". The analysis is simple and the result is a period of time, often expressed in months.

Simply start with the amount you spend, add up your savings over time, and see when they net out. That will be your ROI. Everything after the ROI is savings, so the analysis typically presents a few years into the future to highlight how much money you'll be ahead (and how clever you are).

Depending on your management, a simple analysis may be close enough, or they may want a more thorough analysis that includes the time-value of money (i.e. the investment income you'll lose by spending it), tax ramifications and other costs expressed as "present value".

In that case, delegate to that staffer who whines when they do not get promoted each and every review.

Cost Benefit Analysis (CBA) is when you weigh expected costs versus expected benefits of one or more options to choose the best one. Both costs and benefits are expressed in money and may be a simple calculation or may include the time value of money expressed as "present value".

With a CBA benefits need not be restricted to typical expense and revenue concerns such as staff reduction. CBA's can include myriad benefits such as market presence, public relations, recruiting, industry and financial analysts, community contributions, carbon footprint, green initiatives, etc. etc.

Here it pays to include all realistic benefits.

Any business analysis must be compelling to be useful, and must be clearly communicated to be compelling. Back up your analysis with industry accepted measures and you'll earn a reputation for "doing your homework" before presenting to management.

Cheers

Grails Logging

2009-05-04T00:31:00.009-05:00

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
 }
}

Problem Resolution

2009-03-31T01:45:00.001-05:00

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.

Managing Complexity

2009-03-31T01:00:00.001-05:00

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.

Chicago Groovy User Group

2009-03-09T20:38:00.001-05:00

Tomorrow I am presenting an intro to Groovy and Grails at the Chicago Groovy User Group monthly meeting.

As usual I have a bad cold and am dead tired. However I'll give it my best effort since the organizers are all great guys and have put a lot of effort into getting this group off the ground.

There will be free pizza and drinks. Best of all, raffle prizes!

Slides of the talk are available in pptx format as well as pdf.

Syntactic Sugar

2009-03-07T23:31:00.001-06:00

Syntactic sugar is a colorful expression that has been popping up in tech circles for the last few years. There is even a Wikipedia page for it.

Java contains a bit of syntactic sugar. All objects in Java are created through calls to the object model except one: String. Strings can be created directly through Java syntax.

In Java we can create a String through the object model by calling a constructor:

String name = new String ("eduardo");

Or we can use this bit of "syntactic sugar":

String name = "eduardo";

As you can see, syntactic sugar gives us two things: clarity and conciseness. It usually does not add any new functionality.

Groovy expands on syntactic sugar. This allows Groovy code to be expressive and concise. Multiply that by the thousands of lines of code a developer reads and it adds up to real productivity. (Of course, the time saved usually gets blown on things like writing blogs, etc.)

Take the following Groovy syntax:

(0..9).times {...}

Even if you've never seen Groovy syntax it is quite obvious this is iterating from o..9. This is arguably clearer than the Java alternative:

for (int i = 0; i < 10; i++) { ... } Groovy makes great use of Syntactic sugar, allowing developers to express their intentions in a more concise and clear manner then legacy Java. Java simply cannot add many next generation features. Java is hampered by the need to be backwards compatible and it's lack of full object orientation. To remain competitive in the future we need to turn to a new language. My money is on Groovy.

What is Groovy?

2009-02-22T17:08:00.001-06:00

What is Groovy? Besides being music-inspired slang from the 1960's, Groovy is, in my view, the "next big thing" for the Java platform.

Why, you may ask? Here are a few reasons:

Groovy is backward-compatible with Java, which translates to real business value.
Groovy is designed to allow developers to be more productive, which also adds real business value.
Groovy has become wildly popular in the recent past.Recent polls I've seen place Groovy as the most desired language by developers. In the open source world this fact is highly predictive.
Ruby in the lead if you go by job postings, and Ruby is an excellent language. However Java developers must learn an entirely new syntax. Groovy is based on Java syntax, making it an easier transition for legacy Java developers.
JRuby can run on the Java platform. However Groovy is built on top of Java and provides access to all the familiar Java api's. In fact Groovy enhances the Java object model, so in reality you are running not only on the Java platform, but you are running on Java standard classes.
Groovy implements all the popular language constructs from Ruby, Smalltalk, Python and others, making it an excellent choice for the enterprise.
New features that show up in Ruby or Groovy are quickly implemented in each other language.
Java is widely perceived to be near sunsetting. Any language can tolerate only so many enhancements until it acquires a reputation of feature bloat.
Groovy improves on Java. Syntactically, Groovy is clearer and more concise. And Groovy eliminates some of the the most common Java bugs.
Grails, a popular application framework for Groovy, leverages RoR's "convention over configuration" approach, which further reduces the code developers need to write.
During the last 12 months, downloads of Grails have grown from 7,000 to 70,000 per month.
Groovy is 100% object-orientated, leaving Java compromises in the past forever.
Groovy and Grails are production ready now, and are showing up in more and more web sites.

Whether you manage or work in a Java shop, you should be watching Groovy's progress very carefully. Your competition may already be making the jump.

At this point, Groovy and Grails look like excellent bets for future development.

The problem with Java Primitives

2009-02-16T20:04:00.001-06:00

As a long time Java user I have developed a love for the language.

At least until I found Groovy. Let me explain...

Smalltalk enjoyed a surge of popularity in the early 1990's when the "deep thinkers" of the industry proclaimed OO as the next big thing. However Smalltalk got stuck with a reputation of being "too slow".

When Java was designed in the mid 1990's it utilized primitives like int, char, float, etc. for performance. But if you think about it, here we have a mostly object-orientated language, where all comparison operators (>, <, ==, etc.) make sense with primitives, not objects!

Groovy designers, on the other hand, realized compiler technology and modern hardware utilize objects with excellent performance. However that leads to a quandary: how do we include operators in a way that makes sense?

The answer is operator overloading. But isn't operator overloading a bad thing? Didn't we learn that from C++?

Well, operator overloading can certainly be abused, but it is a natural way to allow operators to work in a fully object-orientated language.

Examine the following Groovy code:

public Boolean max(Integer i1, Integer i1) {
(i1 > i2)? i1 : i2
}

Even though i1 and i2 are objects of type Integer, this code works as expected. Why? Groovy overloads the '>' operator to call the compareTo() method. For integers, this works since Groovy has added the compareTo method to make Integers work as expected.

You see this all over the Groovy language. Instead of having to memorize Java's idiosynchronicies, Groovy works in an intuitive manner. Much like the Unix's RLS (Rule of Least Surprise), Groovy does what you expect.

Now take what is agruably the most common Java bug: comparing two String objects with '=='. Not only does it compile cleanly but it fails intermittenly, which is the hardest type of failure to cure. Yet it looks fine, passes code reviews, and makes it to production systems all too often. Even experienced Java developers miss it.

In Groovy, it just works. Groovy calls equals() when you use the '==' syntax. So now we have a language that not only is backward compatible with Java, but fixes common Java bugs!

All I can say is "Groovy".