The Best Groovy Inspections You’re Not Using

Many, many tools perform static analysis on code. There are all sorts of automated ways to look through your code and tell you if there are likely errors or not. FindBugs, PMD, and CheckStyle are some of the big names from the Java world. On the Groovy side we have two real options: IntelliJ IDEA and CodeNarc.

This post (over on the Canoo Blog) highlights my favorite static analysis rules for Groovy in IDEA that are not enabled by default. Groovy in IDEA 11 has well over 100 rules, but less than half of them are activated when you install the product. To turn these rules on you’ll need to go into Settings (Ctrl+Alt+S) and enable them under Inspections.

So surf over to the main post and check it out. If you want to leave a comment, then do it on the DZone page. I've been turning comments off on the main posts.

If you like this then you might check out some of my other IDEA related posts: The 10 Best Inspections You’re Not Using (in Java), or the IDEA archive on my blog and the Canoo blog.

And remember if you need Groovy and Grails help, then give me a call or drop me an email at hamlet.darcy@canoo.com

Android Testing in IntelliJ IDEA

Google’s Android site has some fairly detailed instructions for testing Android applications… from Eclipse. They were nice enough to supply a “Testing from Other IDEs” page, but that is nothing more than instructions on using Ant and the command line. Well, if you are using IntelliJ IDEA then you already believe the IDE is going to be a better tool than Ant for this. It’s easy to set up a test project in IDEA and get your tests running. Here are some simple instructions.

As usual, the full post is over on the Canoo website. Wanna be cool about it? Upvote it at DZone or Reddit.

Thanks for paying attention.

IntelliJ IDEA 11 for the Groovy Developer

IntelliJ IDEA 11 was released a few weeks ago, and it contains quite a few new features for the Groovy developer. Everything listed in my blog post is in the free and open source Community Edition of IntelliJ IDEA. There are plenty of new Grails features as well, but I wanted to separate out the Ultimate Edition features into a different post.

To read the full post, surf on over to the Canoo Blog: http://www.canoo.com/blog/2011/12/20/intellij-idea-11-for-the-groovy-developer/

And, as usual, you can vote for this thing over at DZone.

Thanks everyone.

The Art of Groovy Command Expressions in DSLs

Domain Specific Languages (DSLs) are often littered with the accidental complexity of the host language. Have you ever seen a supposedly “friendly” language expression like “ride(minutes(10)).on(bus).towards(Basel)”. The newest version of Groovy contains a language feature that aims to eliminate the noise of all those extra periods and parenthesis, so that your DSL looks more like “ride 10.minutes on bus towards Basel”. This article shows you step-by-step how to use Groovy Command Expressions and plain old metaprogramming to write just this DSL, and also offers advice on when, and when not, to use this new language feature.

The full article is available over on the Canoo Blog: http://www.canoo.com/blog/2011/12/08/the-art-of-groovy-command-expressions-in-dsls/

And of course you can upvote in all the usual places.

Until next time...

Global Day of Code Retreat Comes to Switzerland

Next Saturday, 3rd December, Canoo is sponsoring the Swiss installment of the Global Day of Code Retreat. It's being held in Lugano, which is easily reachable from Switzerland or Northern Italy. The event is free, lunch is provided, and you'll get a chance to practice your programming skills while taking part in a world-wide event that criss-crosses the globe. Sound fun? It will be. Here's what you need to know: A code retreat is a day long event where programmers get to practice and hone their craft. The format was created three years ago and has been used and improved regularly since then. During the day we'll use Conway's Game of Life to practice our design, testing, and pair programming skills. The event has a predefined format and will be facilitated by Canooie Hamlet D'Arcy. This is quite different from our Hackergartens, so you may want to read up on the format so you know what to expect. Michael Hunger has an excellent synopsis of Code Retreat up on the InfoQ website. The originator of the idea is Corey Haines and he will be facilitating the first code retreat of the day in Australia and then flying to Hawaii to also facilitate the last retreat of the day. There is most likely a code retreat in your area, just in case you can't make it to Lugano. Check out the map to see where you can go. There are several sponsors for the Code Retreat in Lugano: Canoo, Ex Machina, and JetBrains to name a few. If you show up then expect to leave with some goodies as well as the free lunch. And please, if you plan on coming then be sure to register on the website so we can provide enough food and coffee. See you Saturday!

Android and IDEA for the Eclipse Refugee

For the full article jump to: http://www.canoo.com/blog

Earlier this month I switched from writing my Android projects in Eclipse to writing them in IntelliJ IDEA. Overall the experience has been great, and I much prefer using IDEA to Eclipse for Android development. And now that IntelliJ IDEA 11 EAP (Early Access) has a visual layout window, there is almost no reason for me to write my Android apps in anything else. I wrote this post to help other users along their way when converting between the IDEs.

The full article with all the screenshot glory is over on the Canoo Blog

If you want to be a bro and slip me an upvote, then please do: Hackernews, Reddit, or DZone

Should Static Type-Checked Compilation Come to Groovy?

Please note: As always, I speak for myself alone and not as a representative for any project or company. These are my opinions and reading of an ever-changing situation.

Update: This was a pretty stupid thing to post, because everything is in flux and these are just some thoughts.

Why Should Groovy have a Static Mode?

There were some internal discussions about "Grumpy mode" among some of the Groovy committers. I had a lot of reservations about introducing static-typing or static-mode into Groovy. When I thought about the idea I come up with many unanswerable questions. Is it a good idea or not? Only time will tell. Here are some of the questions that I wish I had answers to.

What exactly do users want?

Do people want a static language with a dynamic backdoor, such as the way C#/.NET has a dynamic keyword or the way you can use Groovy++ by default with the .gpp file extension and then sprinkle in @Dynamic annotations? This is one approach, where the core of your language is statically typed but you have an option to escape into dynamic-land. Or do people want a dynamic language with a static backdoor, which Groovy will be (as far as I know) one of the few examples of. This use case is the same as adding an @Typed keyword to your Groovy code to enable static compilation, or adding an @Grumpy keyword. Or do people just want better performance from Groovy, end of story?

If you want a statically typed language without the verbosity of Java then use Scala. Yes, Scala is complex. But Groovy is just as complex. Does anyone really know Groovy without reading a few books? Yes you can get things done, but understanding metaprogramming, understanding method dispatch, and understanding all the closure options (delegates, delegate-first, trampoline) is just as complex. I am excited about Kotlin and think it looks like a great statically-typed language, but at this point it is nothing more than a slidedeck and a wiki for anyone that isn't on the IntelliJ IDEA development team. It's not available to anyone.

I honestly don't think a Grumpy mode will boost my productivity much. Will it aide in language adoption? I say probably not. In my opinion there are three large barriers to Groovy adoption in the mainstream: performance, tooling, and bugs. Not being statically typed is a connoisseurs criticism, and connoisseurs generally chase after things that are interesting rather than good (it's been said about me as well). Groovy is a language that appeals to people that just want to get something done; it's about productivity not about programming language theory. Adding static typing might please some high-end connoisseurs if it is done in a good way, but I have trouble believing it will please many real users. Search the web for "Groovy sucks". You won't find pages about dynamic type systems, you'll find performance benchmarks. In my personal experience, people I talk to about Groovy++ are asking about performance. Sure, traits are clever. Sure, the type-checking is an interesting idea. But the interest is in performance. Alex's blog posts are mostly about x-thousand transactions per second, or beating Scala performance. I think the number 1 priority of Groovy++ is performance, and type checking is a 2nd nice to have benefit.

And what about people that want a static language with a dynamic backdoor (for builder objects perhaps)? Other languages have this. C# has a "dynamic" variable, right? Boo has a dynamic variable as well, and even lowly Flex has dynamic XML support. This is useful and valuable. I would love to see an @Groovy annotation in Java, where you escape from Java into Groovy, rather than an @Grumpy annotation for Groovy. The benefit of @Groovy for Java is that tool support is the best in the world (without a doubt) and the language has a specification, is well known, and is well tested. Of course, an @Groovy annotation would only ever work with core Java language grammar changes or very ugly hacks.

Lastly, do users just want static compile-time typing for tooling support to catch silly errors as early as possible? Well yes they want that. Who wouldn't? But who is writing Groovy code without testing it? And we already do a great job of recommending suggestions when methods fail ("hashode not found. Did you mean hashcode()"). And the tools exist to do this. IntelliJ IDEA is very reliable in this regard and GroovyLint does the same thing on a limited scale. These features exist today but since they aren't in Eclipse by default then I suspect they are underused. Catching silly errors is entirely possible without the burden of static typing. In fact, some might say that the majority of CodeNarc errors fall into the silly category!

Can Groovy Afford the Complexity?

The Java world talks about a "complexity budget" where a language can only absorb so much complexity before developers leave for something simpler. The term "complexity budget" is poorly defined and often used as a scare tactic in hyperbolic arguments, but I often fear that Groovy could become the next C++ and overrun this arbitrary "complexity budget". C is a good and simple language. Java is a good and simple language. Neither C nor Java are good for all tasks, but they are both successful and capable of having system written in them. C++ started building on C and had every feature known to man added. Nowadays the criticism of C++ is that only 20% is safe to use, but no two C++ programmers can agree on which 20%. Groovy is a multi-paradigm language. You can script, you can OO, and you can FP. Already I am advising teams to find their standard. If you like FP then embrace curry, trampoline, and functions. If you don't then steer clear of those features. Adding a static mode is going to make Groovy more complex. The same code will most likely behave differently between Grumpy mode and not Gumpy. This is one more thing to think about when programming, even if we work to minimize the differences.

Looking at Groovy++, they have done some very cool things. But sometimes the basic features of Groovy++ and Groovy differ, and this cannot be allowed to happen because it is too complex. Already Groovy developers need to know Java and the JVM. I don't know how you could us Groovy outside of Grails without knowing Java. Introducing a new mode that is subtly different could be too much complexity.

Time and Budget Trade-offs

Adding static-mode seems to me like a big undertaking in terms of developer hours. Groovy++ is a good proof of concept for the idea, but the implementation won't be merged into core-groovy. The approach used by Groovy++ is to subclass ASTNodes with AST Transformations and then write out different bytecode for the node, fighting with groovyc to make sure the correct node is invoked. It is better to implement this feature as a part of the core compiler than as an AST transformation, and that is the route the team are currently taking.

It is wonderful that VMWare supports Groovy financially by giving several people jobs. But remember there are finite resources for the project. Any time spent on static-mode means there is less time spent on other features. There aren't enough hours in the day to do everything. So developing a high-performing and well-behaving @Grumpy mode means there are less resources to solve the performance problems of plain old Groovy. I already asserted that performance was a big barrier to wider adoption. Optimized ints are good for benchmarks and came out in Groovy 1.8, but I reckon most method calls are on user defined objects. How many ints are used in a Grails app? Maybe there is a way to do everything at once, but I'm a little sad to see performance improvements not come faster to the language.

My Wishlist

Here is my wishlist of what @Grumpy would do for me and how the feature should roll out.

Some social wishes...

* GEP - The GEP process for Groovy enhancements is supposed to help us formalize features and provide feedback, but it's underused. Please, let's start a GEP as soon as possible and move this big change into the public debate.

* Dev-List Discussion - The dev-list exists to give developers a forum to communicate with each other. There will always be internal conference calls and IM Chats as well, but please lets move more discussion back into the public domain.

* Research - Are there any other dynamic languages with Static backdoor that we learn from them? I don't know of one, but would love to see more examples of what works and what doesn't

Some type inference and static typing wishes...

* Closure Return Type Type-Inference - Closures should have their return type inferred. This is non trivial, and you can have closures that return the values of closure.apply(). At some point type inference breaks. Where will Groovy's fail? How far will the type inferrer go? And how will you specify a return type on a closure when it does fail?

* Closure Arity - The type checker should check the number of parameters a closure has. You should not be able to pass a one method closure to something like Collection.inject() that requires two parameters. All closures need to specify at their type declaration how many parameters it takes.

* Closure Parameter Types - The parameter types of a closure should be type checked. You shouldn't be able to pass a closure that takes a String argument to something that requires a closure that takes an Event argument.

* Closure casting to interfaces - When you cast a Closure into a Single-Method-Interface then the arity, return type, and parameter types should all be checked and verified.

* Interfaces Implemented as a Map - When you implement an interface using the Map notation [ methodName: { /* body */ } ] then the closure arity, parameter types, and return type should be checked, and the compiler should make sure all interface methods are implemented.

* curry/ncurry type issues- Functions like curry, lCurry, rCurry, and nCurry should work in a correct, statically-typed way. For example, if you curry of a 2-arg closure then you're returned a 1-arg closure. Curry a 4-arg closure and you're returned a 3-arg closure. This is a fun edge case that can't be implemented with just overloaded methods!

* Calling groovy from Java - The semantics for calling Grumpy Groovy from Java must remain sane. I'm interested to see some examples of what the APIs look like once all the new types are added. For instance, what is the Closure class hierarchy? Will there be Closure0, Closure1, Closure2 types to model the arity of closures?

* A Grumpy GDK - All of the libraries that ship with Groovy should be as Grumpy as possible. That way a Grumpy developer never has a problem just because a Groovy GDK method was not Grumpy as well. For instance, you should be able to easily make a Grumpy subclass of GroovyTestCase, so any dynamic method on GroovyTestCase should be updated to be as static as possible. Only really use dynamic features when they are necessary.

* Generic by Default - The type inference mechanism should create the correct generics for methods, similar to how F#/Ocaml creates generic methods by default. For instance, the closure: def wrap = { println "logging..."; it() } should have a generic type signature that returns the same type that the 'it' parameter returns.

* AST Transforms Can Read Types - Transforms should be easily able to read the type information out of the AST, and it should be there as early as possible in the compilation process. So the type inference should happen early. The types don't need to be checked early, but they need to be inferred early. Also, when the type of an object is unknown then an AST transformation should be able to read this. Currently, an unknown type is Object to Groovy, but there should be a difference between Object and Unknown.

* AST Transforms Can Write Types - Transforms should be able to write type information. Transforms should be able to participate fully in this process if they are to remain powerful and flexible.

* Type Verification Happens at the End - Type checking and verification should occur at the end of all the compiler phases. This enables AST transforms to actively participate in the type inferring and type specifying process. If type verification runs and fails too early then transforms that could fix the problem won't have a chance to run

So that is my wishlist, perhaps it is a connoisseur's wishlist. What is it that you want to see in Grumpy mode? What do you not want to see?

You can leave feedback here are on the Groovy dev mailing list. We'll see where this goes!

Java 7 Small Language Changes Screencast

This screencast demonstrates the small language changes that are part of Open JDK 7, which is available from the Open JDK website. It demonstrates multi-catch, try with resources, strings in switch statements, underscores in literals, and the diamond operator.

If you have any issues watching the video below, then you may have better luck viewing it on the JetBrains.tv site.

I've made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I've done: 

• My main blog: http://hamletdarcy.blogspot.com
• My other JetBrains.tv posts: http://tv.jetbrains.net/tags/hamlet
• IDEA related posts on my blog: http://hamletdarcy.blogspot.com/search/label/IDEA
• My screencasts on YouTube: http://www.youtube.com/user/HamletDRC
• IDEA related Posts on my work blog: http://www.canoo.com/blog/tag/idea/
• Or follow me on Twitter: @HamletDRC

The screencast was created with Ubuntu 10.04, PiTiVi, Audicity, gtk-RecordMyDesktop, IntelliJ IDEA, and LibreOffice. OS from top to bottom.

Thanks for watching, leave a comment, or upvote it at your favorite link site!

Mock Objects with Spock Screencast

This screencast demonstrates how to use Spock testing specifications and Groovy for mocking and stubbing behavior in unit tests. It covers creating the mock object syntax, setting expectations, verifying and spying on results, and argument matchers.

If you have any issues with video playback, then trying viewing it from the JBrains.tv website

Here are some useful links to read for this webcast:

• Spock Framework - http://code.google.com/p/spock/
• Spock Basics Screencast: http://tv.jetbrains.net/videocontent/ffff
• Mocks and Stubs aren't Spies: http://hamletdarcy.blogspot.com/2007/10/mocks-and-stubs-arent-spies.html
• Mocking with Spocks: http://www.canoo.com/blog/2010/04/20/spock-and-test-spies-a-logical-choice/

I've made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I've done:

• My main blog: http://hamletdarcy.blogspot.com
• My other JetBrains.tv posts: http://tv.jetbrains.net/tags/hamlet
• IDEA related posts on my blog: http://hamletdarcy.blogspot.com/search/label/IDEA
• My screencasts on YouTube: http://www.youtube.com/user/HamletDRC
• IDEA related Posts on my work blog: http://www.canoo.com/blog/tag/idea/
• Or follow me on Twitter: @HamletDRC

Phew, that's a lot of self-promotion :)

The screencast was created with Ubuntu 10.04, PiTiVi, Audicity, gtk-RecordMyDesktop, IntelliJ IDEA, and LibreOffice. OS from top to bottom.

Thanks for watching, and leave a comment!

Grails Podcast Interview with Hamlet D'Arcy

Last week I sat down with the gang at the Grails Podcast and talked shop for about 45 minutes. We talked about a lot of different topics such as Groovy, Lean software, Spock, Groovy in Action, and of course Hackergarten. Check out the full audio and shownotes over at Grails Podcast Episode 125.

IntelliJ IDEA 10.5 for the Groovy and Grails Developer

The formal release of IntelliJ IDEA 10.5 came out this month, and the new Groovy features are all part of the free and open source Community Edition, and the Grails features are part of the Ultimate Edition. IDEA X (or 10 to you non-Romans) was a larger release of the product, and I already blogged about IDEA X for Groovy and IDEA X for Grails. There’s still plenty of nice features in 10.5 though. The prices for IDEA recently dropped between $100 and $50, and anyone purchasing IDEA since last November gets 10.5 as a free upgrade.

You can read the full article detailing my overview of the features over on the Canoo blog.

There is also a whole bunch of other IDEA related content on my own blog and on the Canoo blog. And if you're feeling promotional, you can always upvote at DZone. Enjoy.

IntelliJ IDEA Keyboard Stickers

They finally arrived: IntelliJ IDEA keyboard stickers!

Inspired by the Vi Keyboard Stickers, I've been working with JetBrains over the last couple weeks to create keyboard stickers to remind users (and myself) of the most common IDE shortcuts. Here are the stickers applied to my keyboard:

Do you see the subliminal advertising? No really, my business card always sits by my monitor like that.

Anyway, the keys and modifiers are color coded. Blue is control, red underline is Shift. So then the F9 key has the word "Compile" with a blue background and a red underline, it means that Ctrl+Shift+F9 is the shortcut for Compile.

I had to trim a few of the stickers for my Swiss keyboard (the Shift key is much smaller for instance), but otherwise the stickers adhere well and don't come up. I hand wrote all the Shift-values for the numbers, so that I can remember that Shift-3 is the * character (again, good for non-US keyboards). Also, there are one or two stickers that may not apply to non-US keyboards (I can't type Shift+[ for instance).

Remember to be extra careful when applying the stickers. Overlapping on the upper edge tends to catch your fingers, so either center them exactly or err on the side of bottom edge overlaps. And one last errata: the sticker for space is labeled "Backspace". This was my fault, but you can take a pen and scratch out the work "back". Viola, fixed.

Would you like a copy of the stickers for yourself? I have a giant stack of them and so does JetBrains. Here are some ideas on getting them from me, based on location:

• Near Switzerland? Come to a Hackergarten in Basel or just DM me (@HamletDRC)
• Denmark? I'll be at GR8 Conf May 17th to 19th
• Poland? I'll be at GeeCON in Krakow next week
• In the US? I'll soon be in New York and Salt Lake City for No Fluff, Denver for ÜberConf, and Minneapolis for GR8 in the US
• Spain? I'll be at Greach in Madrid in November
• Anywhere else in Europe?
Invite me to give a talk at your company! I am happy to jump on a plane and visit almost* anywhere. I can do IntelliJ IDEA specific talks and training, as well as any of the Java, Groovy, or Agile talks listed here. Invite me, and I'll see what I can do.

* I am no longer legally able to visit Barneveld in the Netherlands.

Getting Started with Spock and Groovy

This screencast demonstrates how to create Spock testing specifications. It covers creating basic when/then blocks, given/when/then blocks, expect/where blocks, and data tables. It explains how to create Spock file templates and Spock Live Templates for IDEA.

If there are any playback issues then you might try watching it from the JetBrains.tv site.

Here are some useful links to read for this webcast:

• Spock Framework - http://code.google.com/p/spock/
• IDEA File Templates - http://www.jetbrains.com/idea/webhelp/file-templates.html
• IDEA Live Templates - http://www.jetbrains.com/idea/webhelp/live-templates.html

To work with Spock, I use one file template and three live templates.

My file template creates a Spock Specification with the correct java package and javadoc:

The text of the template is:

#if (${PACKAGE_NAME} != "")package ${PACKAGE_NAME};#end

import spock.lang.Specification

#parse("File Header.java")
class ${NAME} extends Specification {

}

My first Live Template is the when-then template:

The text of the template is:

def "$NAME$"() {
  when:
  $END$

  then:
  true
}

The second template is the given/when/then template:

The text of the template is:

def "$NAME$"() {
  given:
  $END$

  when:
  // TODO: add when

  then:
  true
}

The last template is the expect/where template:

The text of the template is:

def "$NAME$"() {
  expect:
  $END$

  where:
  // TODO add where block
}

I've made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I've done:

• My main blog: http://hamletdarcy.blogspot.com
• My other JetBrains.tv posts: http://tv.jetbrains.net/tags/hamlet
• IDEA related posts on my blog: http://hamletdarcy.blogspot.com/search/label/IDEA
• My screencasts on YouTube: http://www.youtube.com/user/HamletDRC
• IDEA related Posts on my work blog: http://www.canoo.com/blog/tag/idea/
• Or follow me on Twitter: @HamletDRC

Phew, that's a lot of self-promotion :)

Thanks for watching, and leave a comment!

New in IntelliJ IDEA 10.5: Less Clutter

Interview with Antonio Goncalves about the past, present, and future of Java EE

I got a chance to sit down and talk to Java Champion Antonio Goncalves about the past, present, and future of Java EE. I've been working for the last six months in a heavy EE/SOA stack, and it's been interesting to see the advantages and disadvantages. I definitely come from the other side of the world where specifications aren't seen as an inherent sign of quality, and frameworks not sanctioned by Sun/Oracle are not to be feared. It was fun to get his opinions about this stuff.

The full interview is on the JetBrains Zone at DZone. We're both JetBrains Academy Members and we're slowly interviewing each other.

P.S. This is the first post I've ever made that mentioned Java Enterprise Edition. I suspect the next time EE is mentioned will be in another few years :)

IntelliJ IDEA Static Analysis: Custom Rules with Structural Search & Replace

Well, well, I made another screencast. This time I'm taking on IntelliJ IDEA code inspections, and writing your own static code analysis rule (and quick fix!) using Structural Search & Replace. Not bad for under 5 minutes.

If you have any trouble viewing the video then perhaps you should watch it directly on the JetBrains site. And if you're feeling generous, then clicky clicky to upvote at DZone.

Check out these pages for more information on IDEA inspections:

• JetBrains' Code Inspection page
  
• IDEA's Webhelp for inspections

Read these pages to learn more about Structural Search and Replace:

• JetBrains' Structural Search and Replace Documentation
• IDEA's Webhelp for Structural Search and Replace

I've made a lot of screencasts and blog posts over the years. If you like this, then there are many ways to see the other stuff I've done:

• My main blog: http://hamletdarcy.blogspot.com
• My other JetBrains.tv posts: http://tv.jetbrains.net/tags/hamlet
• IDEA related posts on my blog: http://hamletdarcy.blogspot.com/search/label/IDEA
• My screencasts on YouTube: http://www.youtube.com/user/HamletDRC
• IDEA related Posts on my work blog: http://www.canoo.com/blog/tag/idea/
• Or follow me on Twitter: @HamletDRC

Phew, that's a lot of self-promotion :)

Thanks for watching, and leave a comment!

Waste!

In our industry no one recommends increasing waste, there are no waste evangelists, and no pro-waste lobby. So why is there so much of it? As we scramble frantically through the day to please our customers we are often not even aware of the pointless trail of half done work and unwanted features we leave in our wake. This article helps you understand what waste is, where it comes from, and what you can do about it by mapping the seven wastes of Lean Manufacturing into the software development field. If you want both better software and happier customers then quit wasting time and read this article.

This article originally appeared in the October issue of No Fluff Just Stuff magazine. The full article is available on the Canoo blog. As always, you can upvote at DZone.

Thanks for bearing with the teaser/redirect thing I keep having to do.

Griffon MVC Groups and Event System

Griffon has a strong MVC focus, and functionality is built using MVC groups. This is not a screen or a form, an MVC group is a piece of functionality, and a single form is made of MVC groups composed together. The way MVC groups talk to each other is through an event bus, rather than being coupled directly to each other.

I created a screencast that demonstrates these concepts in just under 7 minutes. In the video, I create an app, create several MVC groups, and then wire them together with the event bus.

If the video doesn't play correctly, you may want to launch it from the JetBrains.tv site. Also, if you want to be nice then you can upvote this at DZone.



Boom. Winning.

If you like this, you can check out my other screencasts on YouTube (http://www.youtube.com/user/HamletDRC) or JetBrains.tv (http://tv.jetbrains.net/tags/hamlet)

If you want written documentation on these topics, then please read:
* The Griffon RefCard - http://refcardz.dzone.com/refcardz/getting-started-griffon
* The Griffon User Guide - http://dist.codehaus.org/griffon/guide/index.html
* The Griffon Main Site - http://griffon.codehaus.org/

CDI Event Bus Basics Screencast

Another day another screencast. This one's about the Event Bus that is part of CDI. Contexts and Dependency Injection is part of Java EE but available in SE using the Weld framework. This screencast shows you how to use CDI events and the event system, which is just one part of the larger CDI feature set. The screencast briefly explains the benefits of an event system and then shows how easy it is to use it from CDI.

If it doesn't play correctly, you may want to launch it from the JetBrains.tv site.



You could do worse with 5 minutes of your time.

If you like this, you can check out my other screencasts on YouTube (http://www.youtube.com/user/HamletDRC) or JetBrains.tv (http://tv.jetbrains.net/tags/hamlet)

Lean Groovy 7 - Optimize the Whole

The successful software project is dependent on more than just the proper functioning of each part of the life-cycle: coding, testing, analysis, and deployment. Success hinges on how well all of these pieces fit together. Optimizing the Whole in Lean refers to making sure you always measure up. Improving your business is too often an exercise in sub-optimization: you may spend all your effort on improving the unit testing experience without realizing that it’s your interactions with operations that are derailing the project, or you may perfect your team’s delivery process while the rest of the company continues behaving wastefully...

Yep, it happened again. I put a two sentence teaser here only to redirect you to the full article over on the Canoo web site. That's just how I roll. I've got tiger blood from a different terrestrial plane. Or something.

Anyway, check out the full article and vote at DZone!