DZone interviews: Shawn Hartsock on Gr8 stuff
DZone interviews: Shawn Hartsock on Gr8 stuff
Join the DZone community and get the full member experience.Join For Free
"I love writing authentication and authorization code." ~ No Developer Ever. Try Okta Instead.
Andres Almiray: Could you please introduce yourself
Shaw Hartsock: I'm a Senior Consultant for Open Software Integrators, a professional services provider for open source vendors, including the largest ones. I write code, articles, and consult with Fortune 500 companies about their Java architectures through my job at Open Software Integrators and I've even had the opportunity to develop, review and present SpringSource training materials as well as develop with cutting edge Open Source software.
At Open Software Integrators, our team works on all things JVM. We have people working on Android applications, and mobile development, as well as Enterprise and Cloud Scale applications. I'm very happy to have the chance to work with the excellent team here.
Andres: What drove you into Groovy?
Shawn: It was 2007. I had been working with JEE 5 for a while and I was frustrated with how slow it was to prototype simple web applications. I loved the JPA, I liked the EJB3 annotations at the time. SOAP in EJB3 was much easier than other tools I had used. But, when it came to just plain simple web applications I couldn't find a tool chain that was satisfactory. The frameworks I had examined up to that point took too long or required too much specialized knowledge and learning to use.
I attended the No Fluff Just Stuff (NFJS) tour that came through the Raleigh-Durham area that year. It was the first time an employer had ever spent any money on improving my skills. It was also the first time I met Scott Davis. Scott's passion for Groovy was infectious. I managed to secret a Grails prototype application into a project the very next week!
Andres: That’s awesome! What happened next? What were the challenges (as a Java developer) you encountered along the way?
Shawn: We had some very troubling challenges in the days before Grails 1.0 including issues with many-to-many relationships and a general desire to use our existing JPA mappings. The shop I was in was actually a LAMP shop mid-way to transitioning into a Java Enterprise shop. The problems we had there were related to developers who didn’t really understand Object Relational Mapping in any particular technology. I did run into integration issues with Java EE 5 applications. In hindsight the problem really was I didn’t know how to interconnect these applications running in different application contexts.
That was quite a few years ago now. Grails has matured, and so has my own knowledge of Enterprise Integration. Today, I would now know how to solve most of those problems easily. I now have a wealth of experience to draw on. In hindsight, some decisions I made back then were smart, some were stupid, and time has given me perspective and the ability to tell them apart. That experience is a crucial benefit that I wish we had back on my first projects. I suppose I would advocate that people who employ developers should invest in on going mentoring relationships for their development teams. It’s simply not enough to stick a developer in a cube and pay for a conference once a year. Developers need human contact and interaction too.
Andres: What can you tell us about the grails-audit plugin? Was that you scratching your own itch so to speak?
Shawn: I was working on a project related to the Department of Homeland Security's SEVIS system. We needed to capture changes to data but not merely whether something had changed. There was specific logic based on what had changed and what the different values were.
I needed to log the old value for change auditing (different from security auditing) and I needed to write something like a database trigger. I knew there was a Hibernate/JPA recipe for doing just that kind of thing. So I knew I could do the same thing in GORM since it was built on the same technology. I was utterly shocked when it worked... I was even *more* shocked when someone else used it!
I had originally only posted the plugin to my blog. I made two revisions of the plugin this way and I was shocked yet again when I actually got SVN credentials to commit to the Grails Plugins repository. It was a wholly different experience than I had previously when I was trying to make contributions to other Open Source projects. That’s why I’m still working to be even more active in the Groovy community today.
Andres: What’s the story with the QRCode plugin?
Shawn: I had this idea. I wanted to push a button and pick up a URL from off of my desktop computer and push it onto my phone so I could take it with me. I learned about these QR Codes which are 2D barcodes that you can encode up to 2 kilobytes of data into. This solved the data transcription problem, copying data by hand is slow and error prone. Using a QR Code is fast and error-free.
I had wanted to create QR Codes in my Grails applications but not necessarily transmit the data for the QR Code over the open Internet to one of the many QR Code services. I was thinking of my days in DoD or in Pharma where you just didn’t transmit data over open networks.
My 0.1 of the QR Code plugin used the Java graphics API but I went to deploy on Google App Engine for Java. When I did I found out the classes I used for graphics were blacklisted in the GAE’s JVM. So I started looking for a clean-room pure Java implementation of the PNG standard. I found nearly the perfect project in Hernan Gonzalez’s project on Google Code called “pngj” which is a pure Java implementation of PNG.
Hernan’s work is focused on high thorough-put manipulation of existing PNG files that are too large to fit in most machine’s memory. I submitted a patch to make some changes to the exposed API of the library to make it suitable for creating PNG from bit maps. The result was used in the QR Code plugin version 0.2 and I later ported this to Gaelyk and did a proof of concept Google App Engine project I called the “QRCodeLinkulator” which was an interesting project because, not only had I overcome a limitation in Google’s App Engine, but it exposed the financial model of the GAE.
Andres: Aha! Gaelyk is also in your toolbox. I’ve heard lots of good things about it but haven’t had the chance to use in a project yet. What can you tell us about Gaelyk?
Shawn: There is an interesting problem I see working with Cloud applications. The performance model is upside-down from the model most of us who have been coding for more than a decade are used to. The Cloud (and in particular Google’s App Engine) refocuses you on the performance and efficiency of algorithms, application overhead, and other performance issues that many in the web application development business for the last decade have gotten to ignore.
Let me explain a little bit... see... we used to get told: “A programmer’s time is much more valuable than a CPU, RAM, or Bandwidth so optimise for programmer efficiency.” Shockingly, this is starting to not be true anymore. App Engine as a platform exposes the cost in fractions of a penny of every single request. In the small, or even in Enterprise scale, this is meaningless... but imagine this aggregated up to Cloud scale!
All of a sudden the art of high performance computer programming becomes critical again! Things I had forgotten from University and from my time working on embedded systems came to the front. I had an epiphany: this is the new web computing. Whether people realize it or not performance is going to be king again!
The cloud drives us to seek a different application performance dynamic. In a big Java application server you get to warm up your application. This means preparing for future executions by making a time-space trade-off. You save time at the expense of taking up more space in RAM or disk. In the cloud, however, (in particular GAE) you can’t guarantee that you will hit the same prepped RAM or disk ever again! All that prep work is wasted and drags down performance on individual requests.
So when you write a cloud application (at least a GAE flavored one) you have to be concerned with the initialization cost of your environment since every web request may essentially include a service restart. We think a Tomcat start up time of 20 seconds is great these days. That’s adding 20 seconds onto your request processing time in GAE. That’s not so great.
This is kind of different from what you would expect as a server side programmer over the last couple of decades. We’ve spent my whole career driving in the opposite direction. Now Google at least is trying to push us the other way. It’s very interesting to see.
Andres: Are there any other groovy goodies in your toolbox? What about Spock or Gradle?
Shawn: I have found that I love writing Domain Specific Languages and the ones that work out the best for me are always done TDD (Test Driven Development) I even have developed a twist on the idea of Polyglot Programming … using DSL for creating modular separations in business logic. I don’t have a snappy name for this idea yet but it’s a riff on the observations of the venerable Fred Brooks.
Gant is a powerful tool by itself and I’ve developed tool kits that basically bootstrap off of Gant providing additional features and using Java libraries. There was some nifty class path and class loader hacking as well as some very early GPars type work involved on that project. I’ve not touched that CLI project for a long time so I hope the company that is using it is still pleased with the product.
I find repeatedly that Groovy is an excellent tool to bridge the POSIX environment and the JVM. It is a very valuable in scripting connections between a Linux OS and the Java run-time. In particular Groovy can speak JMX natively meaning you can do all sorts of sophisticated shell scripting magic to control Tomcat servers.
Andres: What do you consider to be the killer feature for Grails?
Shawn: Plugins. The plugin model in Grails is so much cleaner than many other plugin models I've used. This is mostly due to the way Groovy handles dynamic configurations versus how you would do the same job in XML or annotations. What those nifty executable configurations do is allow you as a plugin developer to create a plugin that can intelligently configure itself to the user’s application without necessarily getting in their way.
The fact that a Grails plugin is just a Grails project with a few extra files is immensely powerful. That’s one of the best features of the plugin system. It means there’s very little specialized learning that you have to grokk before you can make a useful plugin.
Andres: How do you keep in touch with the Groovy news and community?
Shawn: I follow the Twitter accounts of DZone and many key Groovy/Grails technologists, I try to keep up on GroovyMag as I can, and, I also try to catch the Grails Podcast when my Android device can pull it down for me. The Groovy community is moving so fast now it’s hard to keep up!
Andres: You're a published author in GroovyMag. Please tell us more about this experience!
Shawn: That was a real treat. I met Michael Kimsal at the BarCampRDU that year and he was rounding up authors. It was the first time I ever was exposed to an editorial process and I really enjoyed getting feedback on my writing. Thanks to that experience I found out I'm actually a pretty good writer. I hope that there are some future doors that will open for me but I really want to find other folks to write a book with. There are a lot of interesting topics evolving right now.
Andres: What would you like to see in a future release of the Groovy language?
Shawn: As far as syntax goes the language itself is just about right. I worry there could be learning curve problems with adding too many new language features. I think we might even consider removing features. Think of Perl. Perl had so many syntax paradigms it was nearly impossible to write alternative compilers for a while there. So, instead I guess, I would ask the language team to focus on how to make the language features we already have even more efficient.
Andres: What's on your reading table right now?
Shawn: I'm currently reading "What Technology Wants" by Kevin Kelly when I’m on flights (that’s about twice a week). He's exploring the idea of Technology as a new branch of the natural world using metaphors like Richard Dawkin's "Our Selfish Genes" and it's an interesting read. The ideas in this book have inspired me to see the technology that drives a company as if it were a living organism itself driving the human organisation toward its own care and feeding. This tweak on my view of technology has helped me write several advisories to some clients.
More down to Earth, I'm also reading "Spring Integration" because I am constantly being faced with Enterprise Integration problems from clients and from my own work history. It is really interesting to see how the team working on Spring Integration is trying to bring together many of the tools people filling the role of Java Architect (like myself) have had to solve repeatedly.
I keep trying to finish "Griffon in Action" but I'm afraid desktop applications aren't on my plate often enough that I ever manage to get past a cursory read. I've been looking in on that project as you've been writing it and I am very impressed with how well that book is coming together.
As I predicted Griffon has codified best practices in Swing applications. This is perhaps one of the most important contributions Grails has made back to Spring. Grails codifies many Spring best practices so it is a really great tool to put in front of new developers so they can learn good patterns up front. I'm really glad to see Griffon working in the same tradition.
Andres: Any parting thoughts you may want to share?
Shawn: I have a teenage son and he’s just getting started looking at future careers. I think about myself at his age. Then I think about where I am now. I can’t see how I went from there to here. That’s a problem. The road from novice to expert isn’t very well paved in our career. We need to do something about that. I think making programming less of a dark art is a good thing.
I believe that someday everyone will program. When this happens we won't think much of this. It will be like saying "everyone can read and write." We find this ubiquity of readers and writers really unremarkable today yet somehow we can recognize a really talented writer when we read their words.
I think this is where computer programming needs desperately to find itself. We need to lower the barriers to entry for programming. We need to do this in ways that not only welcome new comers but also enable people to recognize really talented developers. There is a lot of fragmentation I see right now over who's programming language does what and we really need to get over that.
What matters when you use a programming language is whether it fits the domain you are working in. This is why Groovy is a much better fit for general web development than pure Java. That's also why I think Domain Specific Languages are going to be very important for simultaneously lowering barriers to entry for lay programmers and for empowering experienced programmers.
Thank you Shawn!
Opinions expressed by DZone contributors are their own.