Fresh out of its beta period we are proud to show off our innovation acceleration, idea management, task prioritization system, MileMarker. We’re still working on some walk-through videos and some updates to the public site.

Screenshots

Release Notes:

• Added filtering, sorting and pagination options to lists of ideas and projects.
• Added ability to save sorting, filtering, and pagination preferences.
• Archive views for projects and ideas were added.
• Added the ability delete groups, projects, and ideas (in addition to archiving them).
• Simplified the account management section where groups, projects and people are managed.
• Improved idea search functionality and added it to all pages.
• Descriptions and comments now retain carriage returns.
• Increased character limits in a number of places.
• Fixed some issues surrounding importing and exporting projects.
• Numerous formatting and style tweaks.
• Added the ability to change plans and pay us actual money. :)
• Killed over 100 bugs (and most assuredly added a few new secret ones).

We’re excited about the prospects this app holds for organizations looking to get their ideas “under control”. Hopefully we can roll out some other great features soon. On the docket are:

• Public community site
• Public idea list and voting widget
• Facebook widgets
• API hooks into some complimentary products
• Our own API to allow others to riff on our work
• Adding project packs that can be purchased without upgrading to next plan level

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.

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.

Today is a big day for everyone interested in Groovy and Grails. Following quickly on the release of Groovy 1.6, today Grails 1.1 has been released. This is a major milestone for the framework and I can’t wait to get my hands dirty trying out the new features.

Happy? Sad? Disgusted?

Nat Pryce wrote a program to find out how developers feel about their projects. He extracts code comments and feeds them into Synesketch. Nat has even posted results from a number of different open source (and a couple nameless closed source) projects.

I find it really interesting. I wonder if it truly correlates to the health of the project or the morale of the project team.

I have been a big fan of the PNG image format for several years, or I should really say I am a fan of the alpha-transparency* you can achieve with the 24 and 32-bit versions of the format (you get the more GIF-like transparency with the 8-bit PNGs). Not only that but the use of PNG files as backgrounds for divs and such allow me to better cut up and position elements using CSS in semantic ways that allows for more flexibility in the future as well as each component is self-contained.

The thing is, aside from all the benefits, I could only use PNGs sparingly because I would feel guilty about the large file sizes that result. Until now that is! I am not sure when it was implemented but using Adobe Fireworks you can export 8-bit PNG files with alpha transparency! This is a huge file-size savings and in most cases there isn’t a noticeable degradation in image quality.

* Alpha-transparency is the ability to show multiple levels of transparency/opacity instead of the GIF format’s simple transparent or not, resulting in much better looking transparent transitions and less “choppiness” around the edges.

About six months ago, Jesse and I were talking about how much Javascript code we had been writing and how it would be nice to have better (or any) test coverage of that code.

I had used Selenium a little bit and I spent a little time writing some jsUnit tests, but what we really wanted was to be able to run the javascript tests along with the other test cases in our Grails project. We figured that with Rhino, there should be no reason that you couldn’t use Groovy to write jUnit tests to test our javascript code.

And so Sumatra* was born. With a little invokeMethod goodness, I wrapped the Rhino api, making it more usable and readable. At the June GUM meeting, I did a little show and tell of some working examples and I finally just got around to creating a project home for it.

Give Sumatra a try and let me know what you think. And if anyone is interested in spending time adding to it and enhancing it, join the project!

* I started calling it RhinoUnit and found that there was already another project by that name. Hamlet suggested Sumatra because of the allusions to both the rhinoceros and Java (via the coffee bean).

There is plenty to be said for (and against) the new iPhone and all the new apps flooding to our screens but aside from the sluggish response times and occasional crashes, the biggest problem I have is keeping track of and organizing all these apps.

Applications of all types are now spread across multiple screens as I try, mostly in vain, to come up with a strategy that doesn’t leave me needlessly flipping through 3 to 5 pages just to find the thing I want. I have tried to organize them by grouping like apps together on screen but I don’t really want a whole screen for music-related apps or games. Then I tried by frequency of use with the most frequently used apps on the first couple screens and then those I rarely use on the last few. This too was less than ideal as it isn’t readily apparent when I am search for something how many times I really use it. I guess I could try alphabetical.

How about adding folders?

The folder is a simple organizational mechanism that could help keep my applications in order: Creating and naming folders and then dragging apps into them could work nicely. (like shown above)

Double tapping the folders brings up a radial menu of its contents – app icons – that can be clicked. I have mocked up how that may look (see below). A simple, dark overlay similar to a lightbox effect to represent the mode change would work well.

This example only shows a folder with six applications in it and I am uncertain how to deal with folders containing more than eight. Perhaps there would be a number on the the folder and then single tapping would tab through them.

Until I get something like this the number off application I will be downloading will be significantly restrained.

Bonus gripes to Apple:

1. Please let us delete (or at least hide) those app you included on the phone that we do not use. I don’t need stock quotes and notes.

2. When updating an app, don’t move its position. This is very annoying.

3. Get the stability and fluidity of the interface back to the point where it was when the phone first launched. I don’t think you can totally blame the apps being installed, but if you can, then be more stringent on the apps you let in the store.

4. For next iPhone INCREASE THE RAM!

Lean-to is live! We haven’t done a great job of keeping the work we have been doing under wraps but we haven’t been promoting it either. Since we gave a demo of our agile project tracking application, Lean-to, at minnebar in May, we have been adding features and tweaking it until we were ready to start talking about it.

We wanted to let everyone know that we have pushed out some significant updates to Lean-to that we hope will get people excited. Here are a few of the highlights:

• Add people to your account and manage settings
• View plan and backlog views for your stories/bugs
• Track team progress with report views
• Get more info on list views with new context menus
• Add tests to stories in improved ways
• Assign stories or bugs to iterations from the backlog view
• Filter lists to show only those stories or bugs assigned to you
• More invite and project options
• Various interface improvements

We hope that you enjoy the new changes in this release and we ask that you don’t hesitate to use the feedback link to let us know what you like and don’t like about Lean-to.  We’ve got lots more on our own backlog, but we’d love to hear what you want from Lean-to.

(more…)