Ted Naleid is a well known member of the Grails community. He has authored a couple plugins and submitted valuable feedback and patches across the years. He also has a nack for automating tasks via scripts which can be downloaded from his blog. Enjoy!
Andres Almiray: Could you please introduce yourself
Ted Naleid: I currently live in Minneapolis, Minnesota and have spent most of the last decade working for health care and semantic web startups. Prior to that, I was an "enterprise" developer for a number of large companies but I've since sworn off working for companies with that much red tape.
I've spent most of my professional career in the midwest, but also lived in Seattle and Colorado Springs for a few years each.
I'm currently the Technical Architect at a VC funded startup called Bloom Health in downtown Minneapolis. At Bloom, I work with half a dozen other developers (we're currently hiring BTW :). I'm responsible for the technology choices, so of course I picked Grails as our main framework. We're also using Redis and MySQL to store and cache data. Our entire IT infrastructure (other than our laptops) is deployed on Amazon's EC2 platform.
Andres: What drove you into Groovy?
Ted: I was a Java developer for a number of years, but in 2005 I saw the productivity advantages of dynamic languages when I saw some of the early stuff that David Heinemeier Hansson was doing with Ruby on Rails. I was living in Seattle at the time where there was a really strong RoR community.
In 2007, my wife and I decided to move back to Minnesota to start a family. There wasn't much of a Rails community here at that time, but I was lucky enough to get hired by a startup that was taking a chance on Groovy and Grails (starting with Grails 0.4.2). I haven't looked back and I'm now on my third startup using Grails.
Minneapolis is also home to one of the strongest Groovy user groups in the world, the Groovy Users of Minnesota. It's been great to see the continued growth of Groovy and Grails. Unlike my experience in some other tech communities, I've always found people working with Groovy to be helpful and welcoming.
Andres: Please tell us more about GUM! How do you guys keep the momentum going?
Ted: We’ve got a good group of core people who show up just about every month. We’ve also got a nice meeting place at the Refactr offices, a local Groovy and Grails shop. The hardest part of user groups can be finding a topic that someone is willing to present on every month, but luckily the Groovy ecosystem is vibrant and there’s a ton of new stuff coming up every year worth diving into.
Andres: I believe I’m not the only one that consults your blog regularly to learn useful Groovy tricks, like the handling of regexes. What keeps you busy in the Groovy space these days?
Ted: The posts on my blog are almost always borne out of some real world problem that I've hit. Right now, I'm in the process of making a Groovy script that leverages HTTPClient to let me execute code on a remote grails instance running the console plugin (even behind spring security auth). I've always found the Groovy console/shell to be a little lacking as an editor. This script will allow me to write Groovy in my editor of choice (Vim) [Ed: as if there were really any other editor real developers would pick ;-)] and execute the code within the Grails context with a single keystroke.
Andres: You’re also the author of the build-test-data Grails plugin, a very handy one for assembling quick tests. What moved you to start the project? What can we expect in future releases?
Ted: I'm a big proponent of test driven development and I think it's especially important in a dynamic language like Groovy. Good tests give you the courage to change the code to make it better, but TDD also leads to having lots and lots of tests that you need to maintain. After building up a library of tests, I was finding that any time I'd make a change to one of my domain classes, that I'd end up breaking 10+ tests that had nothing to do with the change. They just broke because the fixture data needed to get the test to run with valid data had every minute field specified to pass the domain constraints.
The constraints were getting in my way by making my test data more fragile, but then I realized that they could also help guide me in automating the creation of test data; that leveraging the constraints to automatically walk the domain model and populate any required fields with default values could massively cut down on test maintenance.
I'm really happy with where the build-test-data plugin is right now and I don't have any major features planned, other than continuing to ensure that it works with grails 1.4 and 2.0. I think the current API is clean and easy for users to understand and that adding more features to it would likely add more complication than it'd be worth.
Andres: It is my understanding that custom validators were not supported in earlier versions of the plugin. Is this still true? If so, are there any workarounds for it?
Ted: Yep, that’s sort of true. Because custom validators can be any crazy piece of groovy code that you want it to be, without limits or guidelines, there’s no way for the plugin to interrogate the validation closure to determine what a valid response is. Build test data does attempt a simple value of the appropriate type for the field to see if it passes. If it passes, everything progresses as normal and the building of the domain object succeeds. If it fails, it lets you know about it.
The workaround is that build-test-data also lets you define a config file called TestDataConfig.groovy. In it, you can override the default values that build-test-data will attempt to use. This allows you to provide a value that will pass your custom validation in most cases.
Andres: What about the markdown and Jasypt plugins? What’s the scoop on each one?
Ted: The markdown plugin lets people write using the markdown "wiki-like" syntax created by John Gruber of daringfireball.net. It is a fairly lightweight plugin, but I get a lot of use out of it for letting users quickly create human readable content that displays nicely without having to write HTML.
The Jasypt encryption plugin came from a desire to protect the HIPAA protected information of our users. It enables field-level encryption of data within a database, and it leverages the Jasypt library to integrate with Hibernate. In-memory the values are decrypted, but when they're at rest in the database, they're strongly encrypted with AES.
Someone could get a full dump of our production database, but be unable to do anything malicious with it because all of the protected data (name, address, SSN, etc) is encrypted.
It was developed for our application at Bloom Health and we use it in production, but I was able to release it to the community.
Andres: Apparently you’re also into Redis. Any tips you can share to get started? What are in your opinion the common pitfalls when making your first steps into Redis?
Ted: Redis is the swiss army knife of persistence, it's lightning fast, but has a variety of . It's been called a "data structures server" and I think that's an apt description. It's similar to a key/value store like memcached, but the values that it stores are things like Lists, Maps, Sorted Sets, etc. These are the same structures that you manipulate in code so it naturally lends itself to things like blocking queues, publish/subscribe, pagination of items, and caching.
It's also financially supported by the same company that funds the Groovy and Grails core team, VMWare. Their recently released cloud storage platform, Cloud Foundry, comes with Redis as a built-in feature.
Starting out with Redis is easy as it doesn't have any external dependencies, just download the latest stable version, run it, and start playing with it in an interactive session. There's even a web based demo that you can try out without installing anything.
For Groovy specific information, I wrote up a blog post on using Redis with Groovy recently. The documentation on the main redis site is also quite good and I think browsing the command reference to be a good way to get a feel for what it can do.
I'll also be giving a presentation on using Groovy and Grails with Redis at the US GR8 conference at the end of June.
Andres: How do you keep in touch with Groovy news and community?
Ted: I follow a number of grails developers twitter (I'm @tednaleid). I also monitor the "groovy" and "grails" tags on stackoverflow. Many times, a question that someone asks there turns into an idea for a blog post or a groovy/grails patch. Glen Smith's groovyblogs.org is also something I read daily in Google Reader.
Andres: What's on your reading table right now?
Ted: Right now I'm reading "Effective Java (2nd edition)" by Joshua Bloch. There are a lot of great tips in there that are still pertinent to groovy developers.
I'm also reading the EAP of the second edition of "Groovy in Action", mostly focusing on all of the cool things you can do with AST transformations in Hamlet D'Arcy's chapter that was recently released.
Once I'm done with those, I plan on going back and re-reading Uncle Bob's "Clean Code", which has been one of the most influential books on me in the last decade. Lots of great information in there and it's been over a year since I last read it.
Andres: Any parting thoughts you may want to share?
Ted: I’m very excited about some of the stuff on the horizon for Groovy and Grails, but the thing I’m looking forward to the most in Grails 2.0 is the build script migration from Gant over to Gradle. I think the existing Gant scripts have gone about as far as they can be taken and are starting to show weaknesses in testing, modularity, and packaging. I think Gradle is well positioned to enable things in Grails that are difficult to impossible with the current system, including parallelization of tests, a more robust grails “interactive” mode and better classpath handling.
Thank you Ted!