DZone continues a series of interviews with members of the Groovy community. Today is the turn for Tim Berglund to answer our questions. Tim is an international speaker and a familiar face in Denver Java user groups. He's no stranger to Groovy and Grails, and as you'll soon discover, to other technologies that can help you increase your productivity. Enjoy!
Andres Almiray: Could you please introduce yourself?
Tim Berglund: I'm Tim Berglund, the owner and principal software developer of the August Technology Group, a consultancy based in Denver, Colorado, the United States. I do most of my work as a consultant, developer, and trainer, and I also spend a fair amount of time writing and speaking on various topics that interest me. (And, I hope, my audiences as well!) My wife and I have three children, ages 12, 14, and 16.
Andres: What drove you into Groovy?
Tim: It was the advocacy of guys like Scott Davis and Venkat Subramaniam back around 2007 that got my interest. By about 2008, it was no longer all that avant-garde of a thing to be using Groovy--Scala was just about to become the belle of the ball by then--so I jumped on Groovy just as soon as my technological circumstances permitted. (It's worth noting that I basically had to go into business for myself to make this possible.) Ultimately, two arguments sold me: first, that the future of the JVM was fundamentally polyglot, and second, that Groovy was a more productive application programming language than Java. It was not an option for me not to explore something other than Java, and Groovy was a good for for the kind of work I was doing.
As I've used Groovy more and more, I've had to continue to defend it as my first choice of JVM language in the face of increasing competition in that space. For example, I'm very excited about Clojure, but I think Groovy maintains a respectable place in the JVM language pantheon because of its broad integration into many places as a scripting language, its painless migration path from Java, and of course because of the success of Grails.
Andres: Polyglot programming? A topic that has entered the spotlight in the latest years. Do you have any tips for introducing PP into teams and organizations?
Tim: I think very few teams indeed will be good enough at several JVM languages to realize the vision of polyglot programming in the way it is commonly discussed. Not many teams will opt to write their highly concurrent code in Clojure, their type-obsessive back-end services in Scala, and their web app in Groovy. I think a more modest vision is to pick a second language other than Java for your team to learn. Decide whether you want this to be Scala, Clojure or Groovy, and go for it. This is a strategic investment, so you’re not ultimately going to get it done with guerrilla warfare tactics. You’re going to need to convince the political leaders in your organization that it’s a good idea.
These arguments are never won on the merits, because the merits are too hard to prove. Is Groovy going to make you a more productive web app developer? That’s great. Now we need some measurements to compare. How are you being measured right now? You’re not? Well, let’s institute some metrics so we can be objective about all of this.
You can see how Taylorist assumptions are going to drive this argument deeply into the nettles.
Instead of talking about productivity, I prefer to describe polyglot choices as a strategic recruiting and retention advantage. It’s a common lament among Java thought leaders that Java Itself is no longer where the cool kids hang out. Whether this is true or not doesn’t matter, since the coolness of the cool kids is rarely grounded in fact anyway. However, if the brightest and most productive developers perceive that non-Java JVM languages are where good things are happening right now, then you’re going to able to recruit and retain those people more easily if you use non-Java JVM languages. A reactionary embrace of Java doesn’t actually reduce staffing risk; it increases it.
[Ed: Tim co-authored the Clojure DZone Refcard]
Andres: Can you tell us more about your Grails experience?
Tim: Certainly. I started building Grails apps late in 2008, working with a client who was replatforming a deeply disturbed legacy system onto the JVM. That ended up being a long engagement, with lots and lots of real-life app development and deployment activities in the mix. I've also helped a number of small teams get started with Grails, I've spoken on Grails at user groups and conferences, and I deliver Grails training with ThirstyHead.com. At this point, I am settled in my opinion that Grails is the right default web framework for the JVM. I'm sure there will come a time when this will not be true anymore, but right now, I can't imagine beginning a web app targeted for the JVM and not building it with Grails.
Andres: What about Gaelyk?
Tim: Ah, good question. I say I can't imagine beginning a JVM web app without Grails, but a more complete answer is that I might want to use Gaelyk for certain kinds of apps. Gaelyk is a lightweight, Groovy-based framework for the Google App Engine. It's a really clever, impressively simple piece of code by Guillaume Laforge. Basically what it does is wrap all of the Java APIs on the GAE--which are characteristically pedantic, wordy Java APIs, just like Ruby people like to make fun of us for--with nice Groovy idioms. So what you have is the fairly impressive stack of services in the GAE wrapped with an extremely lightweight web framework, plus it feels very Groovy. Who doesn't want that?
In reality, there are many applications for which the GAE is not suited, but what excites me about Gaelyk is the kind of applications it enables in an economic sense. In the Java space, our most successful frameworks have evolved as very serious, well-ordered, rigorous things, which are good at being deployed in the enterprise and supporting lots of complex functionality. I think this description includes Grails. But this set of sensibilities comes at the cost of a certain amount of heft: we just don't write quick, tiny, but useful apps the way that, say, PHP developers do. Gaelyk helps bring us the best parts of the PHP development and deployment story for low-mass applications, without marching us off of JVM-controlled territory and into a language and platform that wants to injure us.
Andres: Are you saying PHP wants to injure us?
Tim: I think if you run with scissors, eventually you get cut.
Andres: What would you like to see in a future release of the Groovy language?
Tim: I think much of my use of Groovy has been relatively simplistic: just building workable applications with it, exploring its idioms, and helping Java developers to get to know it for the great application language that it is. The downside of this is that I haven't spent much time exploring the fringes of language, which as you know are a very exciting place indeed. So I think my answer to this question is not very well-informed, but probably what would serve Groovy best would be fist-class, idiomatic concurrency support. Groovy has never tried to get people to think about it as a language for concurrency, but to be taken seriously over the next five years, lacking a bulletproof concurrency story is just not an option. I think GPars is probably a good answer to this challenge, so the more that it is seen as a part of Groovy, the better.
Andres: How do you keep in touch with Groovy news and community?
Tim: I follow you on Twitter, of course! [Ed: Andres is at @aalmiray.] I also follow @glaforge, @hamletdrc, @shemnon, and @paulk_asert. DZone is a great place for Groovy news, but if I miss an important article in the RSS feed, chances are one of you guys (or the prolific and Groovy-loving @fifthposition) will tweet a link to it. I should put in a plug for the SpringOne/2GX conference in the fall, too. That show is definitely a good nexus of Groovy leaders and important announcements.
Andres: What's on your reading table right now?
Tim: For my tech reading, I'm trying to digest as much as I can in the NoSQL space. I'm giving a couple of talks on that topic this year, and doing some NoSQL video training for O'Reilly with my friend, Matthew McCullough. I'm generally just excited about it as an area of research and application for the next decade. Also on the list for the year are a very geeky alt-history novel by Harry Turtledove, the novel Daemon by Daniel Suarez, The Fatal Conceit by F.A. Hayek, and King's Cross by Tim Keller. I'm also reading (through secondary sources) some family systems theory by a 20th-century psychologist named Murray Bowen, which is giving me awesome insights into how teams and organizations—generalizations of families, I think—behave. And I doubt I'll get to it in 2011, but I'd really like to do some reading on how railroad emerged in the 19th century United States. I think there are important economic lessons to be learned there, with direction application to technology issues we're passionate about today. I just don't know the right titles for that topic yet.
Andres: NoSQL is also another hot topic these days. Any preference on a particular datastore?
Tim: Yes and no. I think the basic lesson NoSQL is forcing us to learn is that we actually have to think about the way we store and retrieve data—that there isn’t just one data model or query idiom or scaling paradigm to rule them all. We now have a healthy set of options available to us whose different characteristics will be more suitable or less suitable to different applications. This makes it hard (and probably wrongheaded) to pick a favorite.
That said, I’ve been concentrating the most on Cassandra. I’m giving a deep dive talk on it at No Fluff, Just Stuff and other conferences this year. I’m really pleased with the elegance and simplicity of its architecture, and I’m also impressed with the innovation DataStax is producing around it. A good example is their Brisk project, which replaces Hadoop’s HDFS with Cassandra for data storage, which opens up Hadoop to a whole new class of low-latency, high-reliability applications. There is no “right” NoSQL database, but Cassandra definitely has my attention right now.
Andres: What would be the common pitfalls a developer may encounter when jumping into NoSQL?
Tim: The most obvious are the resume-driven motivations we all have to select NoSQL databases right now. It’s a technology in its hype phase, so everybody wants on the bandwagon so they can talk about their Real Production Experience with a particular product. This is going to cause project failures over the next couple of years, just like it does with every other hyped technology before we discover how to use them properly.
When I talk about NoSQL, one of the biggest points I try to make to my students is that we don’t really know yet as a community what’s right about this space, or what’s going to go wrong it. Relational databases have existed since before I was born, and have been the dominant data storage choice since before I entered this profession. We mostly know what works with them and what doesn’t. Now that we’re collectively deciding to branch out into other data storage paradigms, I expect it to take at least five or ten years to discover how not to do NoSQL. I don’t think we’ve even discovered the important pitfalls yet. And by the time we get that figured out we won’t be calling it “NoSQL” anymore; we’ll just be talking about data.
Andres: What about Polyglot Persistence? Are we there yet?
Tim: I think it’s technologically possible, but it’s clearly not a cultural reality yet. I talk to more developers who say, “I don’t really know what NoSQL is all about” than I do developers who are trying to make decisions about how to store their data. This will probably change on the same five- to ten-year time frame that it will take us to learn how not to use the various NoSQL products.
Andres: What are your favorite development tools?
Tim: If I had to pick a single favorite, it would clearly be Git. The more I use it, the more I understand it to be a revolutionary change in the way we think about version control. It’s one thing for it to be better at branching and merging than Subversion, or for it to offer disconnected operation for people who spent lots of time on airplanes, but beyond that, I’m constantly impressed with how it excels in small ways in everything a VCS is supposed to do. It’s also functioning as a platform for innovation slightly outside the VCS space, through social sites like GitHub.com or a publishing system like git-scribe.
Matthew McCullough and I recently put his Git training materials on video as a part of O’Reilly’s Master Class series. If you want an easy way to learn Git, you can’t go wrong: http://bit.ly/ogitvid. Of course my view of this is not entirely impartial.
Andres: Any parting thoughts you might want to share?
Tim: I would encourage Java developers to work as hard as they can to explore alternate JVM languages. Java itself remains quite a viable choice for all kinds of work, but you don't know what other options might be more suitable if you don't know the landscape. Groovy is definitely the easiest language to migrate to for the sort of work most of us do, but Scala and Clojure would be incredibly fruitful ways for many of us to spend our time as well. Try hard to get these languages adopted at work. If that doesn't work, invest your own time in learning them. The JVM is too valuable for us not to innovate on it, and the success of our innovation depends on developers actually using the languages. So get to it!
Thank you Tim!