We are always developing web applications for clients or for ourselves – and sometimes some sort of combination of the two as we are doing with SMBLive and the CloudProfile platform we have been working on much of the year. It has been great but the work has afforded us precious little time to devote to Lean-to, our project tracking application, and a little something new on which we have been working.

So when Jesse asked if I was planning to bring the Wii into the office during the traditionally slow time week between Christmas and New Year’s I didn’t even pause before I said, “If I can get free to play Wii I would rather use that time to work on Lean-to or MileMarker” an innovation management app debuting today. And it was true we love building web apps and we hope that love comes through in the interactions, features, and concepts of our products.

Over the next few weeks we’re going to highlight some of the features of MileMarker and the improvements being made to Lean-to. Maybe we’ll even be able to throw in some of the exciting news on the CloudProfile front such as a partnership with a Minnesota-based electronics retailer.

Ok, so we didn’t stop signing non-disclosure agreements entirely, but what we have done is, postpone the signing of NDA’s until after we have spoken with and know the folks with the idea. All too often these days it seems people are overly protective of their ideas and want to discuss them with us before we know anything about them. From a legal standpoint, our hands could be tied if we are under NDA and non-compete agreements for every idea under the sun. But in a very practical way, it just does not make sense to treat your ideas with such secrecy.

Chances are, y/our idea isn’t even very good. Techcrunch had a post on Saturday about startups being afraid to tell “their secrets”. And it’s true. Most of the time the ideas aren’t good, or certainly are not unique. And startups and entrepreneurs are actually doing themselves a disservice by holding their product ideas close to the vest. They lose out on the important process of vetting their ideas to collegues and friends to determine how much merit it has; and on the feedback and critique that coud make the idea better. But most of the time, the folks who are so guarded of their ideas simply don’t act on them, so a product never emerges.

So, don’t be offended if we say we want to wait to sign your NDA. Come talk to us anyway. If we end up working together we’ll get all the contracts and legal stuff taken care of, but in the meantime you can be sure we’ll be open and honest with you about your idea, and its merits, feasibility, and you’ll likely come out of our discussion with an even better concept.

We’d love to see some Groovy/Grails/Agile sessions at Minnesota’s barcamp, MinneBar. Jesse, Scott, and I are a bit too harried at the moment to lead too many sessions so we are calling on the community to take the baton. We’d love to participate in discussions about agile development, web application design, Groovy/Grails, iPhone and mobile development, and entrepreneurism and startups in general.

Please take a look at the existing sessions and sign up to lead a discussion. We’ll even help if you like.

I finally got around to upgrading our WordPress install tonight. It actually went very smoothly, but the amount of fear that I feel when upgrading should tell me something.

Let us know if you experience any problems!

2GX is only 5 weeks away: October 19th – 22nd in New Orleans.

There’s a great speaker line-up with some great sessions … oh, and I’ll be speaking too.

The Groovy Users of Minnesota are represented well at this conference: Hamlet D’Arcy has four sessions, Robert Fischer (GUM alum) has two sessions, and I have two sessions. We’re pulling in 3 of 19 speakers for 8 of the 50 Groovy/Grails presentations. If you’re planning to be there, let me know. I’d love to meet in person and grab a beer.

If you haven’t already registered, the early bird discount ends this Friday, September 18th, so get to it. And, you can use the promo code SPRINGONE2GX75 for an additional $75 off! You can register here.

SpringOne & 2GX are running concurrently, so there are eight tracks and over 100 sessions to choose from. A little something for everyone.

Too funny (and sad): If architects had to work like software developers

I advise you to run up and look at my neighbor’s house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

Via: Big Contrarian

So the big news in the Groovy/Grails arena is the pending purchase of SpringSource by VMware. I’m not really sure how I feel about this. On the one hand, you have to expect some pretty cool cloud tech to come out of an acquisition like this. I’m sure VMware is looking to have a nice tech stack that can easily be deployed in their virtualization environment. On the other hand, I’m not totally sure what this buys SpringSource other than a cash infusion and I, as a consumer of Spring through Grails, am a bit worried about attention being paid to VMware to the detriment of other cloud providers. Hopefully this will end up being a non-issue and there will be great stuff to come, but my initial feelings are largely negative, or neutral at best.

The changes in this release consist mainly of exposing the internals of each Circuit Breaker to developers, ops, or anyone that might care.

At Tuesday night’s GUM meeting, I presented my experiences with AOP in Grails and we discussed the Circuit Breaker Plugin for most of the meeting. As part of that discussion, I talked about things that I would like to add to the plugin in the near future.

The main thing on my list was to expose the information about each Circuit Breaker via JMX. To make this happen, I first submitted a patch for the JMX Grails Plugin to allow any Spring bean to be exposed, rather than just Grails Services. Many thanks to Ken Sipe for committing my patch and releasing a new version of the plugin the same evening I submitted the patch!

All you have to do is install the JMX plugin and you can now view the current state of each Circuit Breaker via the JMX Console. In addition to viewing the current breaker state, failure threshold, current failure count, and open-state timeout, you can also manually trip or reset the breaker.

As part of the discussion around JMX on Tuesday, Brian mentioned that often he would prefer to use something quicker and more lightweight than JMX to get a snapshot of the current application state. Whether for easy scripting purposes or just to provide developers with easier access to the data, he thought a simple controller would be more beneficial than JMX integration. That’s now in the plugin as well.

Run grails install-circuit-breaker-controller after the plugin is installed to add CircuitBreakerController.groovy to your project. The controller displays the current state of each Circuit Breaker that has been configured in the application.

Hopefully more updates will come in the not-too-distant future, but before I get too deep I want to make sure I know what would be useful to add. Until I use it more, or get feedback from others, it’s hard to say what would actually add value (and not just clutter). My short list of next potential updates are:

• Additional metrics to expose via JMX and the Controller
  • e.g. number of requests, average response time, number of good responses, number of errors, current number of concurrent requests, concurrent request high-water mark, etc
• Allow configuration of timeout & failureThreshold by exception type. From Release It!:
  

  For example, you may choose to have a lower threshold for “timeout calling remote system” failures than “connection refused” errors.

In addition to my own usage, I definitely appreciate any feedback that you might have if you have a need to use the plugin.

I just released the CircuitBreaker Plugin for Grails.

I recently read Michael Nygard’s book Release It, which is based on his experiences from the trenches in tracking down the causes of large system failures. He relates a number of his experiences and then discusses the patterns and antipatterns that he’s distilled after seeing the same causes of failure over and over. It changed how I think about certain aspects of designing and developing inter-related systems. I highly recommend the book. Though it doesn’t get into implementation details, it’s one of the most interesting (and applicable) technical books I’ve read in a while.

The two things that stick with me the most are both from the section on stability. The first is the effective use of timeouts – especially when integrating with other systems. This can be done in Grails/Groovy/Java/etc by using HttpClient from Apache commons.

The second thing that I can’t stop thinking about is the CircuitBreaker Pattern. Like an electrical circuit breaker in a house, the idea is to recognize a problem and fail first, thereby controlling the overall failure mode. When integrating your app with an external system, this means you stop calling it when it continues to fail over and over and over again.

From Release It!:

…the circuit breaker exists to allow one subsystem (an electrical circuit) to fail (excessive current draw, possibly from a short-circuit) without destroying the entire system (the house). Furthermore, once the danger has passed, the circuit breaker can be reset to restore full function to the system.

You can apply the same technique to software by wrapping dangerous operations with a component that can circumvent calls when the system is not healthy. This differs from retries, in that circuit breakers exist to prevent operations rather than reexecute them.

Whether these are calls to an external system, or even internal operations that could fail repeatedly and need time to recover, the Circuit Breaker pattern guards against cascading failures, so that failures in one area don’t bring down the entire application.

This led me down the path of looking into AOP in Grails because I wanted to reduce the impact on my application codebase. And for the very same reason, creating a Grails plugin seemed like the obvious way to implement it. Many thanks to Ken DeLong because his post Circuit Breaker in Java from last year was very helpful in getting the groundwork set for the plugin. In addition to the tests included in the plugin, I’ve created an example application to show how to use the plugin.

Check out the plugin and let me know what you think.

Success! After playing around with a few things, I got AOP working in Grails this weekend and I’ve checked in the changes to my example app. I’ve also added a test that more clearly shows aop in action.

I made a few changes inspired by Graeme’s comment on my earlier post on AOP in Grails. Graeme pointed me to BeanBuilderTests and both testSpringAOPSupport() and testUseSpringNamespaceAsMethod() were very helpful.

I also took a deeper look at the Spring docs on AOP – specifically around advice and advice params.

Looking at the changes I made, the first change clearly make some sense in retrospect. The second is a little confusing to me and I’m guessing that I’m doing something wrong.

1. In my Aspects, I switched from using the aopalliance classes to aspectj classes. This meant instead of using org.aopalliance.intercept.MethodInvocation & MethodInterceptor classes, I used to org.aspectj.lang.ProceedingJoinPoint. That makes sense and I was just wrong before (not sure where I saw examples of this).
2. The second set of changes I made were in the aop bean definition in resources.groovy.
   1. First, I needed to make sure that I was proxying the target class (proxy-target-class=true).
   2. Second, I had to define my execution point without explicit parameters. As in Service.method(..) vs. Service.method(Integer) && args(i) (which I used with 'arg-names':'i').

The last changes are what confuse me. I tried a number of different things, but could not get explicit parameters to work. Apparently, I need read through the Spring docs on advice params again.

One new wrinkle is that when running the app, my around advice seems to be invoked twice. I wrote the test (inspired by BeanBuilderTests), but I don’t see the same problem when executing the test. Maybe it still has something to do with the pointcut execution declaration. My quest continues….