Top Most What is Groovy?

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:

1. Groovy is backward-compatible with Java, which translates to real business value.
2. Groovy is designed to allow developers to be more productive, which also adds real business value.
   
3. 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.
   
4. 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.
5. 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.
   
6. Groovy implements all the popular language constructs from Ruby, Smalltalk, Python and others, making it an excellent choice for the enterprise.
7. New features that show up in Ruby or Groovy are quickly implemented in each other language.
   
8. Java is widely perceived to be near sunsetting. Any language can tolerate only so many enhancements until it acquires a reputation of feature bloat.
9. Groovy improves on Java. Syntactically, Groovy is clearer and more concise. And Groovy eliminates some of the the most common Java bugs.
   
10. Grails, a popular application framework for Groovy, leverages RoR's "convention over configuration" approach, which further reduces the code developers need to write.
11. During the last 12 months, downloads of Grails have grown from 7,000 to 70,000 per month.
12. Groovy is 100% object-orientated, leaving Java compromises in the past forever.
13. 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.

Top Most Syntactic Sugar

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.

Top Most Architecture in the Enterprise

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.