• Home
  • Events
  • About
  • Hackergarten Screencasts: CodeNarc and GroovyServ

    November 29th, 2010

    At the last Hackergarten we came together and created two screencasts, both about projects in the Groovy ecosystem.

    The first is about GroovyServ, an application that increases the startup time of Groovy scripts. It is in German, but is easy to follow along even if you don’t speak the language. You can vote for it at DZone here and watch it below:

    The second is about CodeNarc, a static analysis tool for Groovy similar to FindBugs or PMD for Java. The screencast can be upvoted at DZone or watched below:

    Be sure to follow the mailing list for future Hackergarten events… it would be great to have some more people come out and join us next time.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    There and Back Again – A Developer’s Recursion Tale

    November 8th, 2010

    Recursive functions are so 2009. All the cool kids are now scrambling to convert those legacy recursive functions into stack based iteration. Why would you ever need this, you ask? Maybe you’ve heard of my friend “StackOverflowError”, he likes to hang out on the JVM. Or maybe you’re a browser kinda guy and you’ve seen your alert messages say “Stack Overflow”. Or worst case (like me), you’re supporting IE6 and you finally figured out that the “Browser shows a blank screen” defect you can’t reproduce is IE’s way of overflowing (oh yes it really is). Well, stack based iteration is a way to leave your nice recursive function the way it is, yet still avoid the overflow errors. You just have to keep track of the function stack frames yourself by adding a little boilerplate around your method (and even that can be cleaned up fairly easily).

    So here is the tale of taking the road now commonly traveled. Learning to program imperatively, writing some beautiful recursive functions, and then ripping it out again because of platform limitations. There and Back Again – A Developer’s Tale of Recursion. The code below is Groovy, but could easily be most any popular language.

    Let’s start at the beginning, with a simple function that reverses a string:

    And the way most of us learned to write the function in the first place, using iteration and an imperative style:

    If it weren’t for the curious popularity of printing out greetings to the console, this might very well be the canonical intro example in most text book. The code keeps a counter starting at the maximum offset of the string and steps backwards by one appending the offest byte of the string back into the StringBuffer. The dest variable is mutated every step of the way and hopefully ends up with the correct value.

    Enter recursion. It’s new. It’s different. It’s so much simpler. Can I complete new tasks that I couldn’t before? No, but as Steve Yegge said, “There is in fact one thing you can do using recursion that you can’t do using iteration, namely: You can use it to weed out stupid fugging interview candidates.” Check out the new coolness:

    It’s declarative. The reverse of a zero or one length string is itself. Otherwise it’s the last char plus the reverse() of the rest of the string. It’s immutable. There are no mutations anywhere in this code. It’s independent of types (even though I did specify the input and output types). And it’s beautiful in a way.

    And it shouldn’t be used on the JVM and in any browser Javascript that I know of. Even for recursions of one or two, some versions of IE actually detect code that looks like this and preemptively throw an exception even when there is no real Stack Overflow error.

    I’ve now had several occasions to have to revert recursive functions back to iteration (both my own code and that of others). You don’t have to go all the way back to step one. You can keep your algorithm and emulate stack frames yourself. It’s a basic recipe:
    1. Create a Stack datatype to store method parameters (LinkedList works nicely)
    2. Add the original method parameters to the stack
    3. Create storage for your output (here a StringBuffer)
    4. While the stack still has elements… pop the head off your stack and run your basic algorithm. Where recursion was needed, do not call yourself, instead just push the new parameters back onto the head of the stack so the next iteration will execute it. Your stack will grow and shrink as your algorithm runs, just like your call stack would have.

    Is this better than the original iterative version? Certainly not for this trivial example. The stack management obscures the simplicity and intent of the function. But maybe this approach is better for your complex example, where your algorithm really is expressed more clearly using recursion. And I believe that we could remove this boilerplate in Groovy with a little metaprogramming (a task for a different night).

    And what do do when your method has multiple parameters? Just make the stack be a stack holding arrays, and each entry in the array is a parameter value. With Groovy and multiple assignments this is quite simple. Here is a cute little anagram finder that requires two parameters. See how they are pushed and popped in pairs:

    So what’s it all come down to? What is the best way to write this code? The first iterative version is plain and boring, the recursive version is sexy but dangerous, and the stack version is too complex for such a simple task.

    I submit that the code should be written like this:

    Effective Java Tip #47 – Know and use the libraries. Behold the wonders of the JDK.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Advanced Mocking: Capturing State with Answer and Captors

    November 5th, 2010

    Hmmm… I really need to mock out java.sql.ResultSet, I know I’ll just subclass it with a hand-rolled mock. Oh-no, the default implementation without method bodies is 650 lines of code long. WTF? Did you know there are 197 public methods on the java.sql.ResultSet interface? This is an absurdly large interface, possibly the largest in the JDK (if not drop a comment, I’d love to know what the largest is). The workaround is to throw one together in Mockito (or your mock framework of choice). My implementation turned out to be 21 lines of code long. Not bad at all. To do it I creatively used ArgumentCaptors, Answer objects, and anonymous inner classes to capture state. The samples below are in Java, but they would be a little nicer in Groovy.

    Anyway, here is the API I wanted to end up with… specify a String List for the column names, and then give any number of Object Lists for the data.

    As you can see, the makeResultSet method creates a ResultSet object. ResultSet is part Map implementation and part iterator. As a Map, you can ask things like getString(“columnName”) and get a String result for a named column. Tons of data types are supported. As an Iterator, you can call next() to advance the recordset cursor, which tells you if there is a next record and also allows you to access the next record’s contents. It’s a pretty stateful object.

    So here is how I implemented it in Mockito. We’ll dissect it below.

    The basic flow is, create the mock ResultSet, mock out the iteration/cursor functionality, then mock out the row/column lookup functionality. Let’s take it from top to bottom.

    1. static – I make private methods static. Almost always. It makes refactoring and moving the method so simple. Plus, you can easily analyze the dependencies of the method. They are all right there in the parameter list, no syntax highlighter needed. Moving on…

    2. varargs – In unit test helper methods I use varargs a lot. It makes a really nice API for creating data. And remember, varargs is just syntactic sugar for a Java Array. In this example, rows is an Array of Lists. In production code you’d always want to check this parameter for null.

    3. final – The parameters are final because we’ll need to reference them from within anonymous inner classes.

    4. AtomicInteger – The result set functions as a cursor so there is always a current record. We model this as an integer and the current record is just the index into the rows array. It’s Atomic and final so that we can reference and modify it from within the anonymous inner classes.

    5. next() and Answer – The Mockito Answer interface is a high powered “thenReturn” statement. With “thenReturn” you can only return simple objects, with Answer you get to do the same with an anonymous inner class. Think of it as a “thenReturn” factory. Notice, next() returns false when the currentIndex advances beyond the end of the rows Array. And next() calls increment the index to advance the record pointer. When I say “capturing state”, the AtomicInteger is the state and it is captured within the Answer instance. It’s good to know the Atomic family of classes.

    6. Captore and Answer for Row/Column Lookup – Now we combine an ArgumentCaptor and another Answer object to implement the getString/getInt/getX functionality. The ArgumentCaptor is an object used to capture parameters sent to methods. It can tell us whether “Birthday” or “Name” was passed to our method. It wraps around the parameter and allows you to call it back later. Again, we use an Answer, combined this time with the Captor to return a row/column value. Our rowIndex is just the currentIndex pointer, and the columnIndex is the index of the parameter name (“Birthday” or “Name”) within the column list. From here it is just a multidimensional “array” access to get our cell value. Woot.

    7. when() and the rowLookupAnswer – the rowLookupAnswer can be reused for any datatype in the ResultSet. This isn’t a complete list but was everything I needed.

    The Point?
    Mock object frameworks are very much about creating objects without the usual constructors and concrete implementations. For my project, Mockito was insanely useful without even using the assertions and verifications that normally go with mocks. Maybe the code is a little complex, I admit, but at least it is short. And as long as you understand Captors and Answers then it really shouldn’t be a problem.

    Happy Mocking!

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    Interview with Dierk Koenig – Author of Groovy in Action

    November 3rd, 2010

    Early this week I pestered Dierk Koenig into letting me ask him a few questions about Groovy past and present and the upcoming release of Groovy in Action 2nd Edition. If you aren’t aware already, Dierk is the author of Groovy in Action, a Canoo Fellow, and a Groovy, Grails and GPars committer.

    Hamlet: The original Groovy in Action was published almost 4 years ago using (I believe) Groovy 1.0, and the 2nd Edition of the book is scheduled next year to coincide with the 1.8 release. What are the biggest productivity improvements between Groovy today and that of 4 years ago?

    Dierk: Well, there are so many cool developments that I hardly now where to start, and in the end I will probably end up forgetting the most important one. Anyway, I will try.

    One of the most important features is backward compatibility. I think the Groovy team has done a very good job in advancing the language without introducing breaking changes.

    For me, it is often the small changes that make a big difference like “power assert“. A newcomer may dismiss this as a minor thing but it is of ubiquitous use, beside showing the language power of Groovy. I could mention many more improvements: the completion of the GDK, Mixins, more Metaprogramming options, command expressions, the Grape packaging system, and so on, but two features make the biggest difference in productivity for me: AST Transformations and IDE support.

    AST Transformations use annotations to demarcate classes, methods, properties, and the likes in order to
    achieve an enriched compilation. You want your class to be immutable? Simply give it the @Immutable annotation and you have all the goodness. There are endless possibilities with this approach and it comes without runtime costs!

    IDE support has evolved far beyond what I ever thought possible for a dynamic language. Code completion for dynamically added methods? Yes, that’s possible! And even though the Groovy compiler has no need for type inference, the IDEs can give code completion on inferred types. Cross-language refactoring? Done. And the list goes on…

    Hamlet: In 2007 Groovy won the JAX Innovation award. Is Groovy still a leader in JVM innovation?

    Dierk: Looking into the roadmap for Java 7 and 8, it is pretty obvious that many developers have fallen in love with Groovy features and this forces Java to provide equivalents for at least a subset. Groovy has become and still is a pioneer for Java language features, simply because we strive for language features that make us more productive while keeping the solution Java-friendly.

    Hamlet: James Gosling wrote a famous paper called “The Feel of Java” in which he described Java not in terms of language features but in terms of a general mindset and philosophy. You’ve been involved with Groovy since almost the beginning. What is the “Feel of Groovy” and has it changed in the 7 years the language has been alive?

    Dierk: There are two sides to this: the user view and the developer view.

    As a user of the Groovy language, I would say that Groovy still feels as groovy as in the early days. The important points are:
    – Groovy is dynamic (that’s the nature)
    – Groovy is feature-rich (that’s where the fun comes from)
    – Groovy is Java-friendly (hence easy to use)
    Groovy always was and still is a “getting things done” language. It is pragmatic – as opposed to being dogmatic about language design theory.

    For a developer, the feel of Groovy has changed. The early days were a bit of a wild-west but since version 1.0 (and not coincidentally the release of Groovy in Action) we feel a high obligation to evolve the language in a controlled fashion. In my perception, Groovy has become the de-facto industry standard for dynamic programming on the JVM and many projects and organisations rely on it.

    Hamlet: Lastly, I see that readers can already download parts of Groovy in Action 2nd Edition from Manning’s MEAP program. Is the MEAP complete enough to be useful today or Groovy newcomers stick to reading the 1st edition for now?

    Dierk: The first edition is still fully valid and for the sake of completeness I would advice newcomers to go with it. You can always buy the second edition later. Honestly, computer books are ridiculously cheap, especially if you compare it against the price-tag for the invested reading time (not even mentioning the invested writing time).

    Hamlet: Thanks Dierk!

    Dierk: My pleasure!

    You can catch Dierk at the upcoming W-JAX conference this November in Münich. He will talk about parallel processing with Groovy, advantages and limitations of dynamic programming as well as about the Canoo RIA Suite.

    Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
    • email
    • Print
    • Twitter
    • LinkedIn
    • XING
    • Facebook
    • Google Bookmarks

    css.php