DZone interviews: Ken Kousen on Making Java Groovy
DZone interviews: Ken Kousen on Making Java Groovy
Join the DZone community and get the full member experience.Join For Free
Learn how to stop testing everything every sprint and only test the code you’ve changed. Brought to you by Parasoft.
Welcome to another installment of DZone Interviews here at Groovy Zone. On this occassion we interviewed Kenneth Kousen, a name that should be familiar to people browsing the Groovy User mailing lists as Ken is quite active there. I won't spoil the contents of the interview with this introduction but let me tell you Ken is one of those people that put a smile on your face every time you have a chance to chat with him. Enjoy!
Andres Almiray: Could you please introduce yourself
Kenneth Kousen: My name is Ken Kousen. My last name is actually pronounced “cousin”, like the relative. My primary job is teaching technical training courses in areas related to Java and XML, including open source projects like Spring, Hibernate, and of course Groovy and Grails.
I’m run a one-person company called Kousen IT, Inc. When I say the company name out loud, I spell out IT, but my wife always says Cousin Itt like the character on the Addams Family. Hey, it was her idea. I travel a lot for my job, but I’m based in Connecticut, in a small town southeast of Hartford. Think Red Sox, not Yankees.
Like many people in IT, I was a career changer. My career started as a research scientist working for United Technologies. I used to investigate the unsteady aerodynamics and aeroacoustics of axial turbomachinery, which is a fancy way of saying I studied noise in jet engines. That itself is a fancy way of saying I did lots of math and lots of Fortran (the nightmares have ended, but it took a while). That’s why I have all those academic degrees (BS in Mathematics and BS in Mechanical Engineering from M.I.T., MA and Ph.D. in Aerospace Engineering from Princeton, MS in Computer Science from R.P.I.). Research was fun when it worked, but I really hated the “begging for funds” part. I knew I was in the wrong field when Fortran 90 came out and I was excited about it (oooo, encapsulation!) and all the engineers around me still thought arithmetic if statements were fine. I do remember during the recession in the early 90’s making a sign that said, “Will Numerically Integrate Partial Differential Equations for Food,” but my company didn’t think it was funny.
I eventually moved into an Artificial Intelligence group, where I got to play with genetic algorithms and neural networks. It took me about two months to realize that ten years of coding in Fortran hadn’t taught me anything about software development, which is why I went back to school and got the MS degree in CS. After completing it I left and joined a training company. Five years later I went out on my own.
In 11 years as a trainer, I’ve never missed a training day. If, as the saying goes, half of life is just showing up, I’ve got that part covered.
Andres: What drove you into Groovy?
Ken: Like many developers, I got caught up in the Ruby on Rails comet that soared across the development sky in 2005. I had many years of Java experience at that time, but I found RoR dazzling. I remember watching Dave Thomas (the Ruby guy, not the Wendy’s owner) doing a RoR demo and hearing audible gasps in the room as he added more and more features. Now it’s fun to watch Jeff Brown do the same thing with Grails and get a similar reaction.
I quickly realized that I couldn’t make any real progress with RoR unless I learned Ruby, but despite what the books said I found it a difficult transition. At the time I was probably too heavily invested in the Java world to really “get” Ruby, though I keep meaning to go back. I’m sure it would make much more sense now. As a trainer, my job is very sensitive to market conditions, and back then I couldn’t get a lot of RoR training work. Since I never really felt competent doing RoR anyway, I stopped working on it a few months later.
Late in 2006, though, I happened to be in Philadelphia teaching a Spring framework class when I noticed the local Spring users group was hosting Jason Rudolph, who was doing a presentation about Grails. Since I was already comfortable with Spring and Hibernate and I was familiar with DRY and Convention over Configuration from RoR, I was the perfect target audience. He was great, of course. If you get a chance to see him, don’t miss the opportunity.
I immediately bought the first editions of “Definitive Guide to Grails” (DGG) and “Groovy in Action” (GinA, still my all-time favorite technical book) and never looked back. Groovy makes development fun again.
Andres: It’s true. When the topic of Grails is brought forward in a conversation with Java developers some will still refer to it as “Groovy on Rails” or brand it as a Rails clone. From your experience, what can you tell us about the similarities and differences between RoR and Grails?
Ken: Grails has a lot of advantages over RoR, especially from a business point of view. Grails is built on Hibernate, and Hibernate works with practically anything. That means Grails can work with existing databases. That leads to one of the Grails sweet spots, building simple applications that maintain a set of database tables inside a company.
Grails is also built on Spring, which I like to call a Swiss Army Chainsaw because it touches on nearly every aspect of enterprise Java development. Anything that can be done with Spring eventually makes its way into Grails, usually through a plugin. The vast set of available plugins is a great asset for Grails development. One demo I like to do for students is to build a quick Grails application, then add the Searchable, Quartz, Email, and RichUI plugins. Then I’ll throw in either Apache Shiro or Spring Security. I wind up with a very powerful application with lots of features in very little time.
I have to say, though, that if you really want a great demonstration of Grails, you need to watch Jeff Brown’s “Build Twitter in 90 Minutes with Grails” video at http://www.youtube.com/watch?v=8d1hp8n1stA.
Sometimes the part that impresses people the most, though, is when you just type “grails war” and deploy the resulting war file in one step.
Seriously, if your shop has any Java experience, you owe it to yourself to look at Grails for your next application.
With all that said, I still spend much more time using Groovy than I do with Grails. I like Grails and prefer it for web applications, but I use Groovy for everything.
Andres: What do you consider to be the killer feature for Groovy?
Ken: That’s a hard question, because I like so many features. Probably the most useful one, though, is its XML parsing (and slurping) and generation capabilities. Whenever I have a task to do in a Java application that need to work with XML, I always add a Groovy class to handle that. Of course, I like using Groovy collections, and closures, and all the methods added by the GDK, and so on.
Andres: Is it true you teach Groovy for a living? How's the experience so far?
Ken: I wish I could say I spend all my time teaching Groovy and/or Grails, but for me at least the market doesn’t support that. I get the impression that the situation may be different in Europe, where open source seems to be more popular. Here in the U.S. I’ve only taught a handful of Grails courses and even fewer straight Groovy courses over the past few years. I normally operate as a sub-contractor to training companies, though I occasionally work with companies directly. I’ve been telling my clients that this is the year Groovy finally breaks through to the mainstream. Of course, I’ve been saying that for the last four years.
I will say, though, that I’ve definitely seen a transition. A few years ago, when I mentioned Groovy or Grails, the reaction was, “you mean Ruby on Rails?” In the last two years the reactions changed to, “yeah, I’ve heard of them but don’t know much about them.” Now we’re in the “well, we have a few developers working on a pilot project that we don’t talk about to upper management” stage.
On my web site (http://www.kousenit.com), I have a graph from the job search site Indeed.com, which lets you search on keywords in job descriptions. It shows Ruby on Rails as a rocket that took off in 2005 that has been slowly descending ever since. On the same historical graph, Grails is like the tide coming in, slow and steady. More and more people are using it, but at the moment not quite enough to keep me busy full time. I think that’s going to change this year, though. In the meantime, I’ve been teaching lots of courses on Spring, Hibernate, Java web services, web security, Ajax, EJB3, and related topics.
Adopting a new web framework is a significant decision companies don’t make lightly. I try to tell them that you can add Groovy, though, without disrupting your current Java development processes too much. Plus, you can start with tools, like Spock for testing or Gradle for builds, that let you use excellent Groovy projects without adding Groovy to your production code. That message is always well received. Of course, I’m not really being honest. Adding Groovy really will be disruptive, but in a good way.
My calendar tends to fill roughly two months ahead of time. At the moment I’m booking classes into June, and my schedule does include a (private) Grails class. I strongly suspect there will be more as the year goes on.
Andres: Your website mentions you're writing a book about Java and Groovy. What's the scoop?
Ken: The book is called “Making Java Groovy”, and is available at http://manning.com/kousen through the Manning Early Access Program. I just turned in a new chapter on using Groovy with the Spring framework, which should be added to the MEAP soon. The book is currently past its “first ⅓” review.
Here’s the “elevator pitch” for the book: Groovy is not intended to replace Java -- it makes Java better by doing well what Java does poorly. Adding Groovy to Java means you don’t lose anything, but you gain a great deal. The goal of the book is to examine all the tasks a typical Java developer faces (working with databases, building web applications, creating and running web services, and so on) and seeing how sprinkling in some Groovy in the right spots can make your job as a developer much easier. The basic theme of the book is:
Java is great for tools, libraries, and infrastructure. Groovy is great for everything else.
In case you’re interested, let me tell you a bit about how the book’s history. Ultimately, it’s all Scott Davis’s fault. Scott is the indefatigable speaker, trainer, developer, and author of several books, including “Groovy Recipes”. I was a tech editor on that book (which is another way I learned Groovy) and on his GIS book as well. I also knew Scott as a speaker in the No Fluff Just Stuff series of conferences (NFJS, http://www.nofluffjuststuff.com), which I used to attend on my own dime. Now I’m a speaker on the tour, which is really fun. I love being on the tour and speaking about Groovy related topics, from basic Groovy/Java integration to Spock to Gradle.
Anyway, I met Scott at an NFJS conference back in 2007. I’m also an adjunct professor at R.P.I. in Hartford, CT (http://www.rh.edu), where I teach a graduate class on developing enterprise applications. I wanted to use Scott’s “JBoss at Work” book in my class, which is how I go to know him. Like everybody else in the Groovy and Grails communities, he was extremely kind and helpful about it.
By the late summer of 2008, I’d been a tech editor for Pragmatic Programmers for several books and had proposed a couple of my own, both of which got turned down. Then I got contacted by an editor at O’Reilly who said that they had a Groovy book being developed but that the author was having trouble finding time to make progress, and was I willing to help out as a co-author? Once I found out that the author was Scott, I jumped at the chance.
It turned out, however, that Scott was living the wild, exciting life of an international Java superstar. I imagine you’re familiar with that, too, being a Java rock star yourself. The price of fame, I guess. As a result, though, I wound up working on the book a lot more than he did, and eventually he gave the contract to me alone shortly after the SpringOne2GX conference in New Orleans. While that was an acknowledgement of his time pressure reality, he gave me this opportunity, and for that I’ll always be grateful. Just don’t tell him I said so. I plan to give him a hard time about it into perpetuity.
The thing is, early in 2010, O’Reilly did a review of their upcoming catalog and decided to cancel several of their upcoming books, including mine. They claimed there wasn’t a sufficient market for Groovy books. Seeing as how Forbes had just published an article about web development in Grails, that seemed a bit of a stretch, but so be it. My plan is for the sales of my book to dazzle them so much they regret ever questioning the market. If my book is the first Java/Groovy integration book to make the NY Times best seller list, so much the better. :)
That might be getting a bit ahead of myself, though. One day a couple months ago I was sitting at the dining room table reading an email from Amazon.com listing their highlighted books of the month. I wondered (out loud, unfortunately) how I could get my book on that list, at which point my wife rolled her eyes and said, “Write it!” Sigh.
After the book was cancelled, I moped around for a month or so, then tried marketing it to other publishers. Somebody (oh yeah, it was some guy named Andres Almiray) gave me the name of an editor at Manning, and the rest, shall we say, is history. I’m very happy to be a Manning author. The early MEAP sales are very encouraging, too, which is more evidence that this is the right topic at the right time for a lot of developers.
Andres: How do you keep in touch with Groovy news and community?
Ken: Once I found out that most of the members of the core Groovy and Grails teams were on Twitter, I started following them all. That’s been very helpful. I follow several blogs, too, but I find that Twitter has really reduced the quantity of blog posts for most people. It certainly has for me. I like Burt Beckwith’s weekly post on developments in the Grails community, and GroovyMag (another great resource, btw) is now doing the same thing for Groovy. Of course, I try not to miss Glen and Sven on the Grails podcast. There’s also this DZone thing, too.
Paul King (one of the Groovy in Action co-authors) tends to add fantastic presentations to his slideshare.net account on a regular basis. Just assume everything Paul King writes is good and you’ll learn plenty.
Whenever I have questions on any API in the Groovy ecosystem, I find the associated mailing lists to be invaluable. I’ve posted lots of questions on the lists for Groovy users, Grails users, Gradle users, and even Spock users, and I always get excellent answers within hours. It’s such a joy working with the people in this community. That’s half the fun for me, actually.
Incidentally, that attitude flows from the top down. Graeme Rocher (head of the Grails project) and Guillaume Laforge (head of the Groovy project) are two of the most impressive developers I’ve ever met, and yet they’re both warm and friendly, with a great willingness to help newbies. I’m sure it’s not a coincidence that the rest of the community is that way, too.
Andres: What would you like to see in a future release of the Groovy language?
Ken: Generally the Groovy core team members are better at coming up with ideas than I am at asking for them. I really liked the AST transformations, like @Singleton and @Delegate, that were added in 1.6, for example. So I’m sure whatever they’re planning will be cool. I’m much more of a Groovy user than someone who works on the language itself, though I like to learn about how it’s done. Jeff Brown (wicked cool co-author of the second edition of “The Definitive Guide to Grails”) was kind enough to help me make what is probably the tiniest possible commit to the Grails codebase, which was great, but I’m mostly content to learn about the new capabilities as they come along. That’s why I like being an instructor. I really enjoy learning about new things, then helping other people understand and use them.
Andres: What's on your reading table right now?
Ken: Now that the Spring chapter in my book is done, I’m back to working on the chapter on RESTful web services and Groovy. That’s a chapter I’ve had to rewrite from scratch twice, and now I have to do it again. Hopefully the third time will be a charm. Every time I think I understand REST, I find I’m not quite there yet. So right now I have both “REST in Practice” and “RESTful Java with JAX-RS” handy.
Incidentally, Scott Davis gave me a good piece of advice on writing. When I was writing my first chapter, I mentioned in passing that I thought I’d accidentally picked the hardest chapter to work on. He told me, “they’re all the hardest chapter.” :)
Speaking of books I’m planning to read, rumor has it that there’s a good book on Griffon coming out soon (called “Griffon in Action”, or something like that). I intend to really dig into that when I get to my chapter on Desktop Groovy. I also have to find time to read Venkat Subramaniam’s new book on currency on the JVM. I’m also eager to read each new chapter in the “Groovy in Action” second edition. I know Hamlet D’Arcy just added a chapter to that book about AST transformations, which sounds cool.
Andres: Any parting thoughts you might want to share?
Ken: I really like technologies where tasks that used to be hard suddenly become simple. With Groovy I’ve had that experience over and over again. Groovy is full of “afterthought” innovations that seem blindingly obvious in retrospect (like the safe dereference operator -- obj?.name returns null if obj is null without throwing a NullPointerException), as well as powerful capabilities like metaprogramming that express themselves in extremely simple ways, like builders and GORM.
If you’re faced with a complicated Java development task, consider adding Groovy to make the job easier. You don’t have to do much to get a great benefit, and at deploy time, it’s just another jar file.
Most of all, if you have a problem, feel free to ask. For a cutting-edge technology representing the combined efforts of some of the greatest developers in the world, Groovy is awfully easy to learn, and the people involved are willing to help. Feel free to ask me all your hard, multithreaded desktop Java questions. I can forward them to Andres as easily as the next person.
Thank you Ken!
Opinions expressed by DZone contributors are their own.