What is Computer Science?

"Computer Science is the Science of Computing Machinery."
When I hear this I want to put a stick in the eye of the person who just said it. That's not a definition, it's a slogan. Yet, this is the definition used in most textbooks that even try to tackle the subject.

Let's sit down and try and break this apart. When do we cross the line from just being a machine and becoming a computing machine? Where is the distinction? Perhaps that will tell us something.

If I take a light bulb and plug it in and it turns on, that's not a computing machine.

If I take a light bulb and plug it in and it flickers... not still not computing since the flicker is random and has nothing to do with anything outside the light bulb.

If I take a light bulb and plug it in and it doesn't light. That's not computing, that's broken.

If I take a light bulb and it has a sensor so that when I plug it in, it doesn't light ... until I darken the room. In the dark it turns on, and in the light it turns off.

This machine has now crossed into the realm of computing. Albeit the simplest possible processing is happening: an outside stimulus is causing a response. We could call this a stimulus-response agent. Even so, this is now a computing machine and what is going inside this simple device is the very smallest beginning of something of interest.

Now, name a system that we can clearly define as a computer that does not exhibit some form of this behavior. Even a batch processing system that starts at a given time takes input or stimulus from outside itself, processes this inside itself, and then produces output.

What is Computer Science? We study something called "Computing" perhaps that should have been the name of the field? Computing is really what I've been working with my entire career and that's really what the degree is all about.


The Life Cycle of Plugins & Addons in the Enterprise

I'm probably one of the few people in the world that has had the opportunity to work with both Grails and Spring Roo on extended projects. In both environments I've discovered a strategy around code reuse that is a bit different from what I normally observe in the Enterprises I consult with.

Both Spring Roo and Grails feature a reusable component system. They are similar enough you can use similar strategies in the enterprise with either Spring Roo or Grails. If you are in an enterprise that uses both Grails and Roo (these companies do in fact exist), I recommend that you develop common functionality in Spring POJO then graft a Grails plugin and/or a Spring Roo addon over the top.

In Grails, plugins are powerful sub-applications. A plugin can provide a command line script to the Grails CLI, a library, a library dependency, to a full set of Model View and Controllers or anywhere in between.

In Spring Roo, we term these reusable components addons because they do not necessarily contribute runtime functionality to the final system. Spring Roo's philosophy of having zero runtime footprint means that you don't have a Roo runtime to hang your hat on. What you do have is a very powerful Command Line Interface (CLI) that you can leverage along with a templating system inside your Roo addon to allow your end-user-developer to generate their own components. Instead of shipping function as you do in Grails, in Roo you provide a mechanism for guiding the developer through generating function.

Whether you are shipping function wholesale, as you do in Grails, or you are providing functional templates as you do in Roo, in an abstract sense I've discovered the same pattern applies to both Roo and Grails. You start with a pilot project for the addon or the plugin and you lift it out of the pilot project allowing it to graduate to a shared enterprise-wide repository.

As time goes by, you work on the addon or plugin as a separate project. Each project that uses the addon/plugin will keep track of its own versions of these addons meaning it is important to keep those old revisions available just in case. You will also want to tag each released revision in the event you need to back port fixes into old releases should a critical project get stuck on an old version of Roo or Grails for some reason.

The advantages to the enterprise would be a single place to revision control the client components of a Single Sign On system, or a single place to revision control and distribute shared client functions, look and feel components, or other commonly reused system components.


The Highly Monitored Grails Application @ SpringOne 2GX 2011

My second talk at SpringOne 2GX was "The Highly Monitored Grails Application" and it had a great turn out from a large and lively audience. This was fantastic especially considering I was presenting as the very last presenter of the conference. This was one of the best received talks I've ever given.

The talk was demo heavy and so, while there's not much in the slides we spent a lot of time in my IDE, at the command line, and running through ways to monitor and work with live Grails applications. We even manipulated the hibernate settings in a running Grails application! Great fun!

Definitely the highlight of my SpringOne 2GX conference!


Performance Tuning Grails applications at SpringOne 2GX 2011

I just got done with my SpringOne 2GX talk on Performance Tuning Grails Applications. When I proposed this talk six months ago there was no material on this subject. Since then a fantastic webinar came out. At the start of the presentation I mentioned this video which I would call the essential resource. And, you can watch it any time.

I deliberately cut out of my talk much of the subject matter there, why present the same information in a talk that you can download at any time? Wanting to present new and original material at SpringOne 2GX I rewrote my own talk from scratch. This time focused on the performance tuning of the server side code itself.

I decided to focus on real world performance metrics associated with Groovy Code itself. In the talk I demonstrated four implementations of a service three in Groovy and one in Java. The result is a bit surprising. Restructuring your Groovy code yields order-of-magnitude greater performance improvement than simply shedding Groovy in favor of Java.

The lesson to be learned is that the largest expenses your application will pay are in data marshalling, unmarshalling, network transmission time, and database querying. The Groovy itself can be restructured to be more performant without resorting to pure Java. Pure Java is there for us if we really need it but the majority of its benefit is not in that it is Java but in that it removes the most elegant features of functional programming and dynamic type systems from our pallet. I ask if the trade-off is really worth the small difference we see when simple Groovy code restructuring can give us five times better performance.




Speaking at Milwaukee Java User's Group

I'm honored to be speaking at the Milwaukee Java User Group coming up on September 27th. If you are in the area, I'd be glad to see you and hear your input on the topic. I'm leaving my normal fare of talks on Groovy and Grails and speaking on the topic of cloud computing and Java. Many of my engagements revolve around tuning Java in cloud computing platforms for use in high volume websites. This talk is about my reflections on travelling from mere virtualization to three variations on cloud computing that I've used.

Hope to see you there.


Software Development versus Software Engineering

One of the most useful things that I have gotten from studying things that I call "Demingesque " is the idea of Kanban. Kanban means "sign board" and is a way for projects to display information about themselves.

In its simplest form the Kanban idea is simply to keep track of things I need to do, things that I am doing, and things that I have done. In addition, because the board is placed in a location that is easy for management to see it can't help but communicate the status of the project or work area associated with the Kanban.

This idea is so simple it hardly seems like it is worth the effort of naming it. It is so engrained in the idea of a productive work team that I can't fathom needing to have a "methodology" associated with it. Yet I see amazingly complex ideas built up around this very simple tool.

Ironically, developers tend to like over complicated things in place of simple things. I suspect that it is because we are smart people and we don't like things that are too "simple" challenge us. Instead we want something hard that forces us to really stretch. So, I'd like to challenge people who think like that: don't think like that.

Instead, we should relish the idea of doing amazingly complex things with the simplest tools possible. In the places I've worked, the Kanban is most frequently implemented using a simple white sheet and a simple "sticky note" approach. I've seen many variations but ultimately you are just capturing the following information:

1. What do you need to do?
2. What are you doing?
3. What have you done?

Anything beyond this is probably a waste of time. This information recorded regularly can give you an idea of how long a project will take (based on the velocity of movement of items from "need to do" over to "have done") and how many "are doing" things are happening at the same time. The manager's job now becomes tracking this information and predicting that if fewer "are doing" things are happening then the "have done" pile grows more slowly.

You can formalize this as much as you feel like, put pretty math on it, or give it buzzword names, but really this is the basis for all software development project management... also sometimes known as "software engineering."


Washington DC Area Groovy User Group

I'm honored to be presenting at the Washington DC Area Groovy User Group this Wednesday. If you are going to be in DC I would encourage you to come out.


good code, great code, and really great code

There's great software, and there's really great software. The stuff that's great is the stuff that works well and is well documented. Ever need to figure out something? Go read the docs, if you screw up then the software tells you exactly how you messed up and didn't follow the documentation. That's great software.

The best software (the really great stuff) doesn't require documentation. You can play with it and discover how to make it do what you want. You just have to poke about with it a little bit and it will guide you to a working use case. You don't have to read a book, understand a theory (beyond basic computer sciencey things) and you can get to work almost immediately.

This is accomplished through really good failure modes and support tools that help you figure out how to use the system. It's 100 time the work of documentation but it is 100 times better. The best form of this is really great test coverage. You need to have really great test coverage to show you the use cases the system designers were thinking of. That is the best documentation because if a developer changes their minds the tests must reflect the change in paradigm.

Then there's stuff like this:

This is from the Sonatype Blog. On its own this is a tiny mistake. A blog has had the POM XML fragment stripped out of it. A bit of spelunking on the web produces this link as the definitive documentation for the plugin. Let's go and read the code for the plugin and see if we can't figure out what the missing tags are.

Over on github we find the emma4it plugin's source code. Diving this code we find that the project is actually pretty darn thin... and that's good because it is easy to understand. What does the JavaDoc say about how to configure this plugin? Thankfully there is at least documentation telling us what each of the Java files are for in the Maven lifecycle.

Does any of this include an example like the one Sonatype accidentally destroyed the only canonical example of in their blog? Sadly, no.

So my best guess is the first "report" word shown is a "report" id for the execution since we have more than one execution. My next guess is the phase we use in the documentation from the blog is different from the phase shown in the JavaDoc. The phase here is the "post-integration-test" phase by my guess. Next I have to take a wild leap. My guess is "project.build.sourcesDirectory" is the value set in the sourcesDirectory tag.

This is my best guess at the missing POM fragment:


So by my estimation this is good code, that is on the cusp of being great code. That is still a ways from being really great code which wouldn't require you to dig around for documentation to begin with.


The seven stages of dealing with PMD rule violation

Is your build broken from a PMD rule violation? Has your project has been set up so that a PMD rule violation breaks the build? On occasion even the best developers slip and push code that is in violation of the PMD rules they themselves agreed to.

I have been observing developers under these severe conditions for some time now and I've identified seven emotional stages that every developer who breaks the build due to PMD rule violations goes through. I am cataloging these here in the hope that it helps some developer cope with their broken build and move on in their project.
  1. Shock and denial

    You will probably react to learning that your code does not conform to your project's PMD rules with numbed disbelief. You may deny the reality of this PMD rule violation at some level in order to avoid the pain. Shock provides an emotional protection from being overwhelmed all at once.

  2. Pain and Guilt

    As the shock wears off it is replaced with suffering. Although it is excruciating, it is important that you experience this pain fully and not avoid it or escape it with //NOPMD comments or by the use of alcohol or drugs.

    You may have guilty feelings or remorse for the things you did or didn't do with your code. Life feels scary and chaotic during this phase.

  3. Anger and Bargaining

    Frustration gives way to anger. You lash out and lay unwarranted blame for the rule violation on someone else. You may blame PMD itself. You may blame the authors of the rules. You may rail against fate questioning "Why me?" and you may also try to bargain in vain with PMD saying things like: "I will never drink while coding again if you will just accept my patch"

  4. Depression, reflection, loneliness

    Just when other developers think you should be getting on with your project, a long period of sad reflection will likely overtake you. This is a normal stage of resolving breaking a build due to a PMD rules violation.

    During this time you will finally realize the full magnitude of your rule violation. You may isolate yourself from other developers on purpose to reflect on things you did in the code-base and focus on your memories of past times before you violated the PMD rule.

  5. The upward turn

    As you start to adjust to life after a PMD rule violation has occurred, you become calmer, your thoughts organize. Your physical symptoms (these range from mild stomach cramps and headaches to full blown cold-sweats and involuntary spasms) lessen your depression lifts and you begin to formulate a plan.

  6. Reconstruction and working through.

    As your mind becomes more functional, you find yourself seeking realistic code changes to be made to resolve the PMD rule violation. You start to work on restructuring your code around the PMD rule violation.

  7. Acceptance and hope

    During this last stage you learn to accept and deal with the reality of using PMD on your project. Acceptance of PMD does not necessarily mean happiness. Given the pain and turmoil you have experienced you may never return to a care-free and untroubled code base that existed before you broke the build. But, you will find a way forward in your project.

    You will start to look positively on your project again as a whole and actually plan things for future releases. You will once again anticipate writing good code and may even find joy in writing software again.

Rest assured, you can recover from a PMD rule violation. You can put your project back on track. There will be joy in coding again someday.


The one about scope. And tacos.

Consider the following paragraph.

Mary and Sally are friends. Mary gives Sally a gift for her birthday. Mary hangs up the telephone.

Are there any syntax problems in the above paragraph? Are there any grammar problems? What is wrong with this paragraph exactly? The problem is non-technical in nature. The paragraph references a relationship between Mary and Sally and then describes an interaction that occurs between them. Finally it describes Mary ending a phone conversation. However, we have no idea when or how Mary began talking on the phone. We don't even have a prior reference to a phone conversation.

Consider the following code:

def exchangeIfRelated(def mary, def sally) {
  if( canRelate(mary,sally) ) {

What is wrong here? The isn't anything technically wrong provided whatever connection we just closed was not in use after this method finishes. What is the likely hood this call is made from a different part of the program like this?

public void friends(FooService mary, BarService sally) {

Anything wrong here? No. Not really. It will compile, it will run. In this method we have implicitly taken responsibility for opening and closing whatever these connection things are. In a more concrete example, we might be opening and closing a database connection. In that kind of example, we are allowing concerns to bleed between methods. Ideally, I want one unit of code to be concerned with one thing. That thing (whatever it is) is hopefully easily abstracted for use by other units of code without their having to become experts in that other abstract thing (whatever that is). The following code is better and will likely lead to fewer misunderstandings.
public void friends(FooService mary, BarService sally) {

Knowing how an ignition system works does not aid my ability to drive a car in rush hour traffic. When I start my car I do not need to have knowledge of what happens when in my car's engine, nor do I need to know how a camshaft functions in order to drive my car down the road. The driver is insulated from these automotive inner workings. In the same way when we build software we want to insulate the layer above us from details about the layer beneath us.

Mixing the scope of when and where you do things is like changing the subject of a paragraph. There are fish in the sea. Nothing is really wrong with it from the stand point of the compiler which really only understands the mechanics of phrases in the programming language. There are tacos in a truck. However, just as properly formed sentences that have little to do with the core thought of a paragraph are disruptive and confusing. I like kites. Similarly, such disruptive code phrases in our code leads to confusion and in a program that kind of thing leads to bugs. And tacos.



I'm very pleased to be speaking at GR8Conf this year. I'll be covering two topics. I hope the Groovy communities find them interesting.

The first up, how to use Domain Specific Languages in order to reduce accidental complexity. I have a very long post that I'm holding on to based on this topic (inspired by my trip to Manhattan and Google NYC earlier this year). In this talk I'll really take time to explore this idea practically. I will create a Domain Specific Language before your eyes as I do live coding with Test Driven Development. It's performance art with Unit Tests!

The second topic is on Grails and the JPA. I'm currently working on a lab for this topic. We'll explore some of the nastier Object Relational Mapping problems I've encountered working with Grails and with JPA in isolation and together. If time permits I'll work in some performance troubleshooting in this lab too. In this format we'll have the chance to work together and really get a deep understanding of what's going on with Grails persistence and how you can use GORM and/or the JPA in places you may have thought were impossible. I really enjoy the lab format and I hope to see a good turnout.

For me, getting the opportunity to speak at the GR8Conf is a major milestone and I'm very pleased that Open Software Integrators is allowing me to participate. The fine folks at Open Software Integrators have an experienced consulting staff that can help you with all things JVM related. I've had a great time working with the other consultants here over the last few months learning a great deal about performance tuning and scalability.

So please check me out at GR8Conf and I look forward to seeing you there!


Groovy/Grails: How to disable a controller

Let's say you have a plugin. That plugin includes a controller. You don't want to use the controller provided by the plugin (for whatever reason) but instead you want use your own controller.

What do you do?

Filters my friend. Filters.

Next to your Config.groovy file in the grails-app/conf directory create for your self a file called DisableFilters.groovy and then add a class definition. Here's a filter definition that disables everything in the application... (making your grails application headless).

class DisableFilters {

def filters = {
all(controller:'*', action:'*') {
before = {
// return false
after = {
afterView = {

Now you'll notice there is a before closure and it returns false. This closure fires before the request is passed to its destined controller/action. The * means match all. So if you had a specific controller name or specific controller name pattern you wanted to disable you could easily disable all these by matching the name here.

Notice the nifty after which would execute after the controller and action complete. Finally you have the afterView closure which would execute after the entire call chain was done and the browser has left. I'll leave the uses for these up to your imagination.

In the filter body you have access to everything you have in a grails controller so you have a great deal of flexibility here with what you can do. You could look at usernames, session data, whatever your heart desires. You can even redirect the request to another URL using the same conventions as you would have in a controller. So have at it!


double entendre

I have said "The Future of Java is Groovy" and I meant it deliberately as a double entendre. The future of Java is indeed groovy and is indeed Groovy. This does not mean Java will be supplanted by Groovy, or some other language. Instead, the future of the JVM and the technology stack that calls the JVM home is tied more to technological off-shoots like Groovy than it is to any other purist re-engineering of the JVM or the core Java language.

Java is what it is at this point. Tools like Groovy give developers the chance to get a gentle introduction to new techniques such as Functional Programming, Parallel Computing, Domain Specific Langauges, Runtime Metaprogramming, and Compiletime Metaprogramming, as well as a whole host of other techniques and technologies.

The beauty of Groovy as a programming language is how accessible it makes all these advanced techniques to a beginner and how readily it will get out of the way of an expert. This is a beautiful balance of the elegant and the ugly that few other languages manage to pull off well.

Do I think Groovy will supplant Java on the JVM? No, not really. Do I think any other language will make that claim? I seriously doubt it. Do I think Java needs a successor? No. No I do not.

The closest ecosystems that we can draw analogies to for the modern JVM are the .Net ecosystem and the C/C++ ecosystem. The C/C++ ecosystem is probably a better environment to draw lessons from since C/C++ long ago shed its lock-in with a single vendor (that being AT&T long long ago).

I think Java is growing up the same way the C/C++ ecosystem did and C hasn't really changed much over the years. I think Java needs to become the same kind of solid foundation. If other languages come and go on the JVM that needs to be groovy with everyone.

I don't steer any ships in the Groovy navy, I don't direct any plans or strategies, so what I say here is just what I say, and what I say is:
Groovy allows rapid access to advanced computing concepts with a minimum extraneous cognitive load.
This is the Groovy language's strength. It is immediately accessible to anyone with any programming background. This accessibility is the vital engine for the success we are seeing in Groovy adoption. It is also the weakness of the language. It means that Groovy must necessarily avoid the traps of becoming too "beautiful" of a language forcing people into certain forms steepening its learning curve too sharply.

That's my opinion anyway. I happen to be one those kinds of guys who likes what I can do with a language. I tend to not get hung up on whether it is pretty, or if it is pure. It's all groovy man.


A late New Year's post.

tl;dr I am a consultant now.

It's a quite late, but I did make some new year's resolutions. One was a personal fitness resolution to run a mile every workday. The other was a professional resolution to "get out there" more and contribute more to the Groovy/Grails community. For most of 2010 I felt as if I were under a rock and not able to contribute to the community more and so I've made a couple of drastic moves.

My first drastic move was to step-up my fitness routine. I have been working out 3 times a week now for a few years. This year I have stepped it up to 5 times a week. Yes. 5 times a week. My warm up is a 1 mile run.

So far this year I've managed to run one mile every weekday (I give myself Saturday and Sunday off from running). So far, I haven't missed a day. I was inspired by my son's devotion to his Cross Country training and I have set myself some small goals for my running to try and achieve over the next few years. My big goal is to eventually run a Marathon. This seems utterly absurd to say, I have so very far to go before I can do something like that. Barring any medical reasons I fully intend to achieve that goal.

My results this last month are encouraging. I started the year with a mile time of 15:44 (fifteen minutes and forty-four seconds) and I've managed to bring this down to 11:24 or so on my best day. I typically complete the mile now between 11:30 and 12:30 now. My goal is to make a 12 minute mile an easy run for me. If I can do that then I will begin increasing my mileage over time.

The other one of those drastic moves was quitting my job at a company I dearly loved working at and really respected. It was a very hard decision to make but I decided that I wanted to invest more directly in the Open Source community and open source efforts. I believe strongly in the cause of Open Software and if I believe in it I should put my whole being behind what I say. So I've joined forces with Open Software Integrators which is a young Open Software consultancy based here in the Research Triangle area of North Carolina. We have a strong match for vision and attitude toward software development and I look forward to working with the team here to help companies reap benefits from Open Source software and toward making solid contributions back to the Open Source community.

There have been a lot of preparations going on in making these transitions so I've not been as active here in this blog as I intended. I have made a resolution to also post more regularly here. It was this blog that enabled me to get published in GroovyMag, create the plugins that have taught me so much about living with open source software projects, and introduced me to so many of you.

I hope that I can find a way in my new role to make a real positive impact on the open source community and fill a need that is currently under served. As always I'm open to your feedback and I find your comments valuable. I am currently looking for conferences that would be open to me speaking so your pointers will be welcome. Obviously, I can't attend them all but I will make a real effort this year.

Thank you for reading and I hope I get meet some of you in person this year too!