Why Debugging is hard...

Groovy Grails and your URL

Getting the URL you are at in Grails is pretty easy. Just use the dependency injected properties inside your controller and some of the nifty Grails built-in helpers.

For example, want to know the application you are running in? Each grails application controller will be able to grab this info from the grailsApplication object magically available to it via the power of dependency injection. That grailsApplication object will hold metadata about the project which is the info stored in the file application.properties...

def warName = grailsApplication.metadata.'app.name'

Want to know your controller? Each controller has the variable "controllerName" already for you to use.

So you could build a back link to your current controller using the request object and metadata like so:

def urlString =  request.scheme + "://" + request.serverName
     + ":" + request.serverPort
     + "/" + grailsApplication.metadata.'app.name' 
     + "/" + controllerName + "/" 

21st Century Network management

Oblong Industries

About once a year I see something like this: http://oblong.com/ and it renews the passion I have for technology changing the way we interact with our machine creations. I only dream that someday I can create a work that is as visceral in its impact. I hope systems like this will one day be everywhere and also not require any UI gadgetry such as VR gloves like the ones shown in the video.

SearchGroovy.org

Just in case you weren't aware. There is a search engine for Groovy Programmers. The GroovySearch.org is a Google custom search engine that is maintained by Jeremy Rayner, Guillaume Laforge and some other guy. (no really... anonymous no idea who it is)

I've been using this search for a while but I've noticed not all Groovy programmers know about it yet. Spread the word!

Fighting Annotation buildup

It was called XML hell. More precisely XML configuration hell. You would spend hours and days fighting with XML configurations that grew in size and complexity until they became a nightmare.

They call it Annotation hell. It is what happens when you get a the same problems as you had in XML hell manifesting in Annotations. The earliest mention of Annotation hell I can find is from 2004 in James Strachan's old weblog where he uses the term "annotation overkill" but is wrongly quoted in other blogs as saying "annotation hell".

There is an Annotation hell. And I've seen it. A good example is here in Eric Redmond's blog Annotation Hell where he posts a method with 10 annotations on one method operating in at least four contexts.

I've seen this before... although admittedly not nearly as bad... and I have called the same thing "Annotation Buildup" it's the cruft you get on a class that you are annotating for too many simultaneous execution contexts. It is a symptom of a design philosophy flaw.

The annotation centric design directly reverses the problem of XML hell by merging everything back into the class. This is good. It centralizes information related to the class into one place. The flaw is that all the configuration piles up in the same places and it isn't clear how the annotations make sense.

Grails solves this problem using Convention over Configuration (CoC) and a GORM Mapping DSL the effect is a much cleaner looking class. GORM can use the JPA if configured properly. And this isn't a bad combination to work in but the real advantage is being able to both centralize configurations for a class and also group them by context.

Convention keeps configuration hell at bay whether it is created by XML or annotations. Allowing a configuration DSL allows you to keep the flexibility of configurations without the XML and by placing the DSL inside the class definition you can keep everything related to a class together. The DSL also have the advantage of keeping related configurations grouped together so that you don't have to stare at a pile of annotations that don't relate to each other.

CoC in combination with in class DSL for configuration can keep annotation buildup at bay and keep away XML and annotation hell.

Groovy is to Java like C++ is to C?

A nearly heretical thought entered my mind. C++ was a proper super set of C. I used to work in C from a C++ compiler for example and the advantage was that I had C with a little bit of syntax freedom. Like the ability to declare variables anywhere in a function. In fact I had forgotten that you couldn't declare variables just anywhere in C during an interview where the interviewer felt like he needed to really grill me on my knowledge of C.

It isn't hard for me to imagine then that Groovy is nearly a proper super-set of Java and is therefore similar in relationship to Java as C++ was to C.

With a little tweaking your tool chain could be set up to see things the same way. It could see Groovy as Java++. The change would aid adoption and aid in developer migration. In fact you can see here (in my own post) that you can write Groovy/Java and not really Groovy/Groovy. Props to Andres pointing out how I'm not really thinking in Groovy yet.

I'm sure I'm not the first person to have this thought but I thought I'd go ahead and voice it here since I've not read anyone else taking this point of view.

Top Ten reasons *not* to buy GroovyMag

Here are some reasons NOT to read GroovyMag...

10. You don't care about the future...
9. Programming is a fad...
8. You fear change...
7. You are a rock, you are an island...
6. The internet is for losers...
5. Nothing will ever top assembly for writing clear and concise code.
4. Bah. Technology.
3. You don't have an email... what is this email thing?
2. The internet is just a series of tubes...
1. You can't read.

Go read GroovyMag!

More fun with Groovy and Reflection API

This time in a TagLib I need to see all the properties of a domain class but I don't want to look at anything that isn't sent to hibernate.

import java.lang.reflect.Modifier
static getFields(obj) {
      def names = []
      def fields = obj.getClass().declaredFields
      fields.each({ field ->
       if(!field.synthetic)
        if(!Modifier.isStatic(field.modifiers))
         if(!Modifier.isTransient(field.modifiers)) {
          names.add(field.name.toString())
                                 }
      })
      return names
    }

... in another method I'll filter out the Closures by checking against Closure.class and the property's class.

Top Ten ways to spot a Groovy Programmer

10. Still addicted to Java but doesn't complain about getters and setters
9. Sunglasses. Really. Sunglasses.
8. More productive and lest angsty
7. Not worried about Java 7
6. Breezes through XML and JSON work
5. not afraid of FP or currying
4. pals around with GinA and likes DSL
3. asks did you mean the BGG, DGG or DGG2?
2. still has lots of boats because the boats are not burned... (ask Scott Davis)
1. reads GroovyMag!

It's Programmable... It's configurable...

How much difference is there between a program and a configuration?

Consider that a program is a set of instructions for a universal Turing machine. If a configuration determines how a program does something... if the configuration becomes sophisticated enough so that it even includes a DSL when does it cross the line from merely a configuration into a programming language.

When does a program become configuration? When does a configuration become a program? What is the difference?

GroovyMag

I'm very happy to see the first edition of GroovyMag published. Please go out and support the Groovy Magazine for Groovy and Grails developers. I'd love to see this magazine get some good circulation! I'm thankful to Michael Kimsal the GroovyMag crew for helping me launch my career in writing!

Get the word out and start getting Groovy today.

It is all UI even API

It is all UI and UI leads us down certain paths.

This is an idea I've had for a long time but it hasn't been posted here before so let me lay down for you the why behind the tag line of this blog: "The power of software is the power of thoughts and ideas."

These are important concepts: The purpose of the UI is to aid the user in thinking about what they are doing inside their machine. The UI should match what they are thinking about as closely as possible.

This is all well and good for users. It gives them pretty looking sites that are easy to use and understand. It leads to ideas about making user customization of content a certain flavor of easy that involves allowing for graphical interaction with the system.

But, the programming language is UI too.

I have recently graduated into a tier of programmers that write programs for other programmers to use. But, I have always known that unless you are building the system from nothing then you are the user of another person's UI. It may be called an API but it is still UI.

Programming languages are UI too, they are UI with a limited audience, developers. Just as EE folks design CPU with a "programmer's model" in mind so too should library developers develop software with application developers in mind.

The best way to do this is through "dog-fooding" which is to say that a developer should be forced to eat their own dog-food. When you develop something you should have to use it. If you can't use it you can't really make well informed decisions about how that product should work.

As a developer I try to get inside the minds of the people who use my products. I try to anticipate what they will do, how they will do it, and what ways they may want to do things differently. I can operate this way because after nearly two decades of working with computers in one fashion or another I am convinced there is no right or wrong intrinsic in the machines themselves.

Any meaning, purpose, or sense of working or brokenness is determined by the user. To make a system that is bug free you have to know the user. The technology therefore must be designed from the user back to the machine.

The problem is compounded by the fact that there are multiple types of users. You can build classifications for each of them profiling what their expectations are and building their view of the system around that. Working for one user is broken for another. To design a truly beautiful system you need to account for as many of your user classes as possible.

Often what system designers and developers leave out of their design consideration is themselves. Developers are users too. The must live with their own design choices over time and are prone to the same flaws that other user classifications are prone to as well.

The reasons technologies succeed and fail are tied up in the intersections of actual functionality and perceived function and value. These are emotional decisions as much as logical ones. Very technically speaking any Turing complete language is capable of any task that any other Turing complete language can do.

So the power we find in expressive software is actually the ability to cleanly express some thought or idea. We are attempting to communicate both to the machine and the user some expression of action, computation, art, or logic that will achieve the goal of the user. The software is most effective when the developer and the user understand each other through the lens of the software.

This is true for your web application, mobile application, programming language, or your developer API.

The web framework developer is working for their user which is the web application developer. The persistence layer developer is working for their user which is both the framework developer and the application developer. The application developer is working for the end users of their system.

The most effective developers will be the ones that realize this and deliberately cross as many disciplines as appropriate for their application space. This kind of renaissance developer will be most effective at knowing how what they will write will be received. This kind of developer will know implicitly that it is all about user interface and developers are users too.

Just as architects have known for generations that a building must be beautiful both on the outside and the inside yet still respect the laws of nature so too must computing grow up. So in my phrase "the power of software is the power of thoughts and ideas" is nestled the concept that not only power but beauty and value of software is the beauty and value of thoughts and ideas.

The metrics of our beauty in software is the cognitive dissonance we create in attempting to enable our users to create their art with our tools. When you create software you are implicitly directing the thoughts of another person or machine. Just as an Orwellian language could forbade certain thoughts your API could forbid a design or direct users down a path. The challenge is to match your design to the users' thoughts and direct them toward good solutions without imposing a mental fascism.

The converse is side of this is that you want to direct your users toward maintainable and workable designs. The goal should be to guide not to force. So working out an good design is a balancing act.

Just some thoughts that I've had while looking at possible improvements to an existing development framework.

Edit: Oh yes, I saw this shiny "follow" gadget and added it to the upper right hand corner. Won't you do me a favor and click it a few dozen times so I don't feel too bad about having "0" followers. Thanks.