• It is only capable of handling payments for one item transactions via “Buy Now” buttons. I want to upload an entire shopping cart full of multiple items.
• It currently won’t handle shipping addresses. The site I’m building allows the user to maintain a list of shipping addresses, and I’d want to send the address information they choose along to PayPal.
• Minor issue: needed to upgrade the plugin to Grails 1.1.

So, I decided this evening to fork the plugin. I want to leverage all of the great work that has been done thus far (especially with the IPN processing part – superb stuff), but I have to add in these two functions and do the version upgrade. Interestingly enough I couldn’t get the tests to run out of the box after the upgrade. No good developer likes to modify code without a stable running test suite, right? So what I ended up doing was creating a new Grails 1.1 plugin project and copying the original artifacts over. Once this was done all of the tests ran perfectly.

So, at this point I’ve added function #1. You can now redirect to the “uploadCart” action. It assumes that you have already constructed a Payment object (now containing PaymentItems) and saved it, and then passed the transactionId along. I did this so that folks with multiple different ways of handling shopping carts could have some degree of flexibility – the onus is on you to map your cart to your Payment object correctly. The original functions implemented by Graeme are backward compatible, assuming only one PaymentItem in the Payment. I’ve run all of the original tests and also did some manual functional testing by running the plugin app against my own PayPal Sandbox account. So far so good. Look for more updates as this evolves. Once I get something I’m totally happy with I’ll see about getting it pushed back into the main plugin repo.

Want to take a closer look? Visit http://github.com/mstine/grails-paypal-plugin/tree/master

private def evaluateCaptcha(def remoteIp, def challenge, def response) {
    def config = recaptchaService.getRecaptchaConfig()

    def urlString = "http://api-verify.recaptcha.net/verify"
    def queryString = "privatekey=${config.recaptcha.privateKey}&remoteip=${remoteIp}&challenge=${challenge}&response=${URLEncoder.encode(response)}"

    def url = new URL(urlString)
    def connection = url.openConnection()
    connection.setRequestMethod("POST")
    connection.doOutput = true

    def writer = new OutputStreamWriter(connection.outputStream)
    writer.write(queryString)
    writer.flush()
    writer.close()
    connection.connect()

    def recaptchaResponse = connection.content.text
    log.debug(recaptchaResponse)

    recaptchaResponse.startsWith("true")
}

I have to credit Justin Spradlin for the code that ultimately got me here. Consider this a +1.

Basically what prompted this was the need for my wife to be able to sort the various product images that she had on a screen at any given time in any way that she pleased, and it had to be easy to work with. What follows is by no means a complete solution to this problem, but it represents where I am in the development process and may be useful to you, my hapless reader.

Here’s some GSP code which basically lays out a grid of product images, 3 wide by n deep:

<div id="productThumbContainer">
  <g:set var="rowIndex" value="${0}"/>
<g:each in="${products}" var="product" status="index">
  <g:if test="${index % 3 == 0}">
    <div id="productRow${rowIndex}" class="span-20 last product-row">
  </g:if>
  <div id="product_${product.id}" class="span-6 product <g:if test="${(index % 3 == 2) || ((products.size() - index) == 1)}">last</g:if><g:else>append-1</g:else>">
    <img src="${resource(dir: grailsApplication.config.store.productImages.webPath, file: product?.thumbnailImage?.name)}" width="230" class="productImage">
    <h3><g:link controller="product" action="show" id="${product.id}">${product.name}</g:link></h3>
  </div>
  <g:if test="${(index % 3 == 2) || ((products.size() - index) == 1)}">
    </div>
    <g:set var="rowIndex" value="${rowIndex + 1}"/>
  </g:if>
</g:each>
</div>

Now here’s where the magic happens:

document.observe('dom:loaded', function() {
      var productRows = $$('.product-row');

      var options = {
        constraint: false,
        overlap: 'horizontal',
        containment: productRows,
        dropOnEmpty: true,
        tag: 'div',
        onUpdate: updateRows
      };

      productRows.each(function(item) {
        Sortable.create(item, options);
      });

      $('persistOrderingButton').observe('click', function(event) {
          var sortString = '';
          productRows.each(function(row) {
              sortString += '&';
              sortString += Sortable.serialize(row);
          });
          <g:remoteFunction action="sortProducts" params="sortString" update="ajaxMessage" onSuccess="\$('ajaxMessage').show()"/>
      });
});

What we’ve got here is, failure to communicate…oops, wrong synapse there…what we’ve got here is a Prototype selector that grabs everything with the class “.product-row.” It then takes these and creates a Scriptaculous Sortable for each of them, providing the object-literal “options.” Notice the “containment” option which allows you to drag products back and forth between the various rows.

Delving deeper into the magic is the callback function “updateRows.” This guy is my favorite Javascript creation in quite some time:

function updateRows(list) {
      var children = list.childElements();

      if (children.size() < 3) {

        //If I'm the last row, who cares!
        if (list.next() != null) {
          var prevRow = list.previous();

          if (prevRow != null) {
            var lastChild = prevRow.childElements()[prevRow.childElements().size() - 1].remove();
            list.insert({top:lastChild});
            updateRows(prevRow);
          } else {
            var lastRow = list.up().childElements()[list.up().childElements().size() - 1];
            var lastChild = lastRow.childElements()[lastRow.childElements().size() - 1].remove();
            list.insert({top:lastChild});
            updateRows(lastRow);
          }
        }
      } else if (children.size() == 3) {
        //Do nothing...gets me out of the recursion I hope!
      } else {
        var nextRow = list.next();
        var lastChild = children[children.size() - 1].remove();

        if (nextRow != null) {
          nextRow.insert({top:lastChild});
          updateRows(nextRow);
        } else {
          var topRow = list.up().childElements()[0];
          topRow.insert({top:lastChild});
          updateRows(topRow);
        }
      }

      var i = 0;
      Sortable.sequence(list).each(function(item) {
        var productId = 'product_' + item;
        if (i < 2) {
          $(productId).removeClassName('last');
          $(productId).removeClassName('append-1');
          $(productId).addClassName('append-1');
        } else {
          $(productId).removeClassName('last');
          $(productId).removeClassName('append-1');
          $(productId).addClassName('last');
        }
        i++;
      });
}

This function is organized around the fact that the only valid state for a grid of n-rows will be n-1 rows of 3 products, followed by one row of 1 <= numProducts <= 3. In most cases, if you drag a product from one row to another, you are violating that rule by creating a row with 2 products and a row with 4 products. This function solves the problem by recursively shifting the products down until reaching a stable state again.

There's a bit of noise there at the bottom of the function. I'm using Blueprint CSS to do the layout for this application and I need to shift the various Blueprint classes around once everything is settled.

Finally, here's the persistence of the data when we click save:

def sortProducts = {
    TreeMap rowMap = new TreeMap()

    params.each {key, value ->
      def matcher = key =~ /productRow(.*)\[\]/
      if (matcher.matches()) {
        def rowId = matcher[0][1]
        rowMap[rowId] = value
      }
    }

    def productIds = []
    rowMap.values().each { row ->
      row.each {
        productIds << it.toLong()
      }
    }

    shoppingService.saveSortOrder(productIds)

    render("Product sort order saved!")
}

and the logic from shoppingService.saveSortOrder():

def saveSortOrder(def productIds) {
    def productsToSort = Product.findAllByIdInList(productIds)

    def productMap = [:]
    def sortIndexList = []

    productsToSort.each {
      productMap[it.id] = it
      sortIndexList << it.sortIndex
    }

    sortIndexList.sort()
    sortIndexList = sortIndexList.reverse()

    productIds.each {
      productMap[it].sortIndex = sortIndexList.pop()
    }

    productsToSort.each {
      it.save()
    }
}

You might wonder why this is so complex. What I haven’t fully described is the way products are organized into a hierarchy of various categories. When you’re sorting a screen, you’re only sorting a subset of the products that are in that particular category. However, the sort order is maintained across the entire product set in the database. So, this logic basically just shifts around the existing sort indicies, placing them in their new relative order.

Anyway, I don’t know how generally applicable this code is, but I had fun writing it and I hope you can get some use out of it. Cheers!

To summarize:

1. As far as the polls go, Scala is in the lead by a margin of 4 to 2.
2. Two of the Scala votes have been simple +1′s, and two have provided a supporting argument.
3. Both Clojure voters have provided a supporting argument.
4. So, to make this a bit more of a fair fight, I’m only going to consider the “supported votes” at this point. This leads to the obvious result of a tie!

So, what to do?

The argument for using Scala is that it is a functional/OO hybrid, so it will be easier to slide into. Interestingly enough, the argument against using Scala is that it is a functional/OO hybrid, so it will be easier to slide back into OO/imperative habits! Clojure, being more of a purely functional language, will be harder to get into initially, but will force me to think functionally. Hmmm…

So here’s my idea. Let’s do this the agile way. What I’d like to do is complete a timeboxed spike (in terms of actual time spent learning the language, not calendar time – I’m doing this in my spare time, and I’ve got my wife, four kids, and three other side projects competing for my attention!) of roughly two weeks in each language. The first week of the spike would be spent getting comfortable with the syntax, reading articles/documentation/blogs/etc., writing “Hello, World!” etc. The second week of the spike would be spent solving the same problem in each language, preferably a problem sitting in the functional sweet spot.

How does this sound to everyone? And to follow up, does anyone have a suggested problem I might tackle? Cheers!

Since establishing and reporting on these goals, I’ve had several things get in the way of fully realizing all of them. However, I can safely say that in the last two years I have mastered enough Groovy and Grails that they no longer fit in the LOTY category. At this point they’re really not showing my anything that is causing any paradigm shifts for me. They’re comfortable. When I learn a new feature, it just seems to make sense, and nothing surprises me anymore. Languages like these aren’t good LOTY candidates because one of the purposes of learning a LOTY is to challenge and change your ideas about programming. Groovy doesn’t do this for me anymore. It’s time to move on (not to say that I’m dropping Groovy and Grails as a tool – I’m using them more now than ever – they’re just not a learning tool for me anymore).

So, at this point I want to delve into a language that attempts to tackle the concurrent/multicore programming challenge. I’d like to stay on the JVM because I appreciate the benefits that it brings as a platform, so for now Erlang is out. The two leading candidates in the JVM/concurrent/multicore arena seem to be Scala and Clojure. An added benefit of both of these languages is that they support the functional paradigm, something I haven’t really played with since my computer science education days and a very interesting language named Haskell.

Scala is a multiparadigm language, supporting both object-oriented and functional constructs. It is statically typed, yet offers very nice type inference. Clojure, on the other hand, is a functional Lisp derivative with almost no OO constructs that is dynamically typed. Both are designed to enable concurrent programming. Which one do I choose? I open the floor for comments.

Agile development uses feedback to make constant adjustments in a highly collaborative environment.

Here’s my graphical representation of this quote:

I decomposed this into an “ecosystem” of multiple feedback loops:

What I’d like to focus on in this post is what I consider to be the heart of the “Developer to Code” feedback loop: The Developer Iteration.

You see, iterations aren’t just for teams. Indeed they are also for developers. So many times I have witnessed individuals struggling to participate fully in an agile project because when they return to their desks, for all intents and purposes, they are pretending to be a waterfall. They spend days analyzing a feature, code for days without sharing any code, test the happy path toward the end of the iteration, and attempt a big bang integration on the last day. I’ll be the first to admit that I myself tried to code this way and had a couple of realizations after a short time:

• Something felt completely unnatural about it, especially in the context of what we were trying to do as a team…
• I was awfully miserable, especially at the end of the iteration.

So, what does the developer iteration look like? It is essentially a microcosm of events that occur during a regular team iteration:

1. Look at your feature or task, and plan out what you have to do.
2. Break the work into small chunks, where each chunk leaves the system in a stable state, yet that much closer to the feature or task being complete.
3. Develop each chunk (preferably using Test-Driven Development), unit and integration testing your work along the way.
4. Check-in your code EVERY TIME you again arrive at a stable state.

I’ll give my definition of stability: A system with NO broken tests. How do we maintain stability? Here are several “smaller” steps that should immediately proceed your check-in step:

1. Run the tests on your development machine, fixing all broken ones until you reach 100% passing with the code you have.
2. Check out the latest code from your version control system, thereby integrating your team’s changes with your own.
3. Run the tests AGAIN, fixing all broken ones until you reach 100% passing with the integrated code. At this point, your system is stable locally.
4. Check-in the code! Now the entire team has a stable, fully-integrated system.

So, what’s the point of all this? Look at how much feedback you’re giving yourself along the way! Each time you stop and run the tests, you’re getting feedback about the stability of your code. Not only that, but your constant striving for 100% stability greatly enhances your ability to refactor your code to keep it clean. You’re able to constantly refine the code, creating smaller methods, more cohesive classes, and an overall simpler and better design combined with the confidence that your system is functionally equivalent to what you started with prior to refactoring.

Yet another benefit is an enhanced ability to timebox yourself. Working this way enhances your ability to plan to be “done” by the end of the day, as you’re never very far from your next stable state. Go home with a stable system, and find a stable system when you get back in the morning. Doesn’t that feel great? Even if you can’t reach a stable state by the time you head home, there’s always the throwaway option. Just revert your changes and go home with stable code. Try again with a fresh mind the next morning. Again, if you’re working the developer iteration, you haven’t written that much code since your last stable state anyway.

Try it out. I’m not a salesman. I’m a satisfied customer.

On to the meat. I’ve been steadily working on a couple of Grails applications, one being the website for the Memphis JUG, and another being the e-commerce site for my wife’s soon to be launched designer stationery business. Just like your average Grails developer, I’ve been happily coding away at 127.0.0.1 using the good old development Jetty+MySQL stack. Well, in the last week or so it’s come time to actually deploy both of these applications into production. I started out last weekend with the Memphis JUG site. My first approach was to build the WAR file locally and then “scp” it up to the server.

YMMV, but the upload speed on my DSL connection is horrible! After doing this three or four times in one night, waiting 15-20 minutes for the WAR to upload each time (Grails WAR’s are rather thick when carrying all of the dependencies along), I decided to myself, “There must be a better way to do this.”

Fast forward a week and here I sit working on the first “pre-production” release of my wife’s store site. With quite a bit of time on my hands during these “dark and early” hours (a story for a later entry), I decided it was time for the experiment.

Each of these projects is hosted at GitHub, so the process that I mapped out in my mind looked like this:

1. Check out the latest code from GitHub
2. Run “grails war”
3. Stop the Tomcat service (my hosting provider sets up Tomcat to run as a service)
4. Delete the remnants of the previous deployment from Tomcat’s deployment directory
5. Copy the new WAR file to Tomcat’s deployment directory
6. Start the Tomcat service

By the way, I forgot to mention that before doing all of this I moved the production data source definition from being locally defined to being a JNDI lookup within Tomcat. This posed its own challenge, which I’ll blog about a bit later.

Anyway, back to the deployment. I though this would be an excellent opportunity to take Groovy’s Antbuilder out for a spin. Here’s an example of what I put together:

#!/usr/bin/env groovy

def ant = new AntBuilder()

//Update the codebase from GitHub
ant.exec(executable:'git', dir: "${PROJECT_DIR}") {
        arg(value:'pull')
}

//Generate the WAR file using Ant
ant.ant(dir:'"${PROJECT_DIR}"', target: 'war')

//Stop Tomcat
ant.exec(executable:'service') {
        arg(line:'tomcat6 stop')
}

//Delete the old webapp contents from Tomcat's deploy directory
ant.delete(includeemptydirs:'true', verbose:'true') {
        fileset(dir:"${CONTEXT_ROOT_DIR}", includes:'**/*')
}

//Copy the new WAR file to Tomcat's deploy directory
ant.copy(file:"${WAR_FILE}", tofile:"${CONTEXT_ROOT_DIR}/ROOT.war")

//Start Tomcat
ant.exec(executable:'service') {
        arg(line:'tomcat6 start')
}

As you can see, I have a few undefined Groovy constants in there. Let’s just say I didn’t want to expose ALL of the details of my server.

At any rate, it’s pretty simple. One word of warning – if you’re using Ehcache, make sure to add it to your ivy.xml dependencies, or the Ant build won’t bring it in like running “grails war” will. I hope someone finds this simple script useful. Enjoy!


"Linked Text":http://www.site.com


This syntax will result in the following HTML:

<a href="http://www.site.com">Linked Text</a>

Unfortunately, if you have a bang (!) in your “Linked Text,” most of the Textile engines that I used would not recognize it as an HTML link. Plextile does!

The only drawback, however minimal, to using Plextile is that it does not come with a pre-packaged JAR file. You have to take the compiled code and JAR it yourself. Now, for free, I’ll include how I integrated Plextile with Grails. Grails has a very nice codec feature that provides a facility to register encoders and decoders of textual data as methods on any object. Grails searches for classes following the convention XCodec and dynamically registers encodeAsX and decodeX methods on java.lang.Object so that any data can be encoded and decoded. Enter the TextileCodec:

import com.plink.plextile.TextParser

class TextileCodec {

   static encode = {str ->
      new TextParser().parseTextile(str, true)
   }

}

Believe it or not, that’s it! Here’s the GSP template for rendering a JUG meeting:

<div class="post">
  <h2>${event.title}<br/><br/><g:formatDate format="EEEE, MMMM dd, yyyy" date="${event.startTime}"/><br/><g:formatDate format="h:mm" date="${event.startTime}"/>-<g:formatDate format="h:mm a" date="${event.endTime}"/><br/><g:if test="${!event.archived}"><a href="http://jugevents.org/jugevents/event/${event.jugEventsId}">Click HERE to register!</a></g:if></h2>
  <div class="entry">
    <h2 class="title">Speaker/Topic:</h2>
    <p>${event.description.encodeAsTextile()}</p>
    <h2 class="title">Location/Directions:</h2>
    <p>${event.location}</p>
    <p>${event.directions.encodeAsTextile()}</p>
  </div>
</div>

Enjoy!

As aspiring Software Craftsmen we are raising the bar of professional software development by practicing it and helping others learn the craft. Through this work we have come to value:

• Not only working software, but also well-crafted software
• Not only responding to change, but also steadily adding value
• Not only individuals and interactions, but also a community of professionals
• Not only customer collaboration,but also productive partnerships

That is, in pursuit of the items on the left we have found the items on the right to be indispensable.

© 2009, the undersigned. this statement may be freely copied in any form, but only in its entirety through this notice.

You can’t even imagine my excitement in reading this. This statement of values is something that I have been trying to get across without having the needed words for quite some time.

The motivation, says the InfoQ article, is right on target:

The members of the manifesto group answered two key questions: “How will it help solve the problems of crap code?” and “What will motivate “The developer just churning out code” to become a craftsman?” – the distinction is between the developer who is just getting it done vs the one getting it done right.

I have felt for a long time that the elements of craftsmanship are something sorely missing from our field. We, as programmers, are often so consumed with getting the job done that we do often neglect getting it done right. In our haste to move on to the next exciting project and/or technology, we neglect the tenets of simple design, test-driven development, merciless refactoring, clean code, etc. We’re often quite satisfied with the “hacky solution here” and the “quick and dirty solution there.”

Quite frankly, I’ve had enough of that. I’m not satisfied when the contractor building my house cuts corners. I’m quite irritable when my mechanic does a less than thorough job with my car. Why should I expect my clients to settle for software built like that?

So, to make this a practical rant, I thought I’d share a couple of the things that we’re doing in our team to move us in the right direction:

1. First of all, we started a weekly “brown bag lunch/workshop,” inspired by Andy Hunt and Venkat Subramaniam’s discussion in Practices of an Agile Developer.
2. Second, we selected books to read as a team that will point us in the right direction. Our first two titles were The Pragmatic Programmer: From Journeyman to Master (see, there’s craftsmanship right away!) and Clean Code: A Handbook of Agile Software Craftsmanship (sense a pattern yet?).
3. Third, we make a point of our weekly discussions to look at ways we can integrate the principles and practices that we’re learning into our daily work. An example: We’re working to integrate peer code review into our development process. The principles, patterns, and practices that we’re picking up from Clean Code will be informing us as we review code and look for possible improvements.

So, with that said, tonight I became a signatory of the manifesto. Why don’t you join me and fight the fight against crappy code!

First, to set the stage, I’ve upgraded the application all the way to the newly released Grails 1.1.

To start off, I naively attempted to use the built-in Prototype library to do the upload with a simple <g:submitRemote/> tag. You might have guessed that this didn’t work at all. Continuing to learn the hard way (without reading the manual I might add), I submitted this as a bug to the Grails project. Graeme ever so politely informed me that this was known and expected behavior, as Prototype doesn’t support such a thing. However, it was Graeme that also tipped me off to try Dojo.

So, continuing down this path, I proceeded to install the Grails Dojo plugin. Once this is done, a <g:javascript library="dojo"/&gt is supposedly all that is required to convert your Ajax calls from Prototype to Dojo. This turned out to not be the case for me, with Javascript errors popping up all over the place, not the least of which was that dojo.js seemed to be installed in an unexpected location via the plugin. The hacker in me simply copied this to the expected location and moved along. However, as I attempted to work with Dojo’s file upload support, I discovered that the version of Dojo shipped with the plugin seemed at first glance to be way behind. Frustrated by this, I went ahead and stripped the Dojo plugin out and installed the latest version available (at this writing 1.2.3), and set about to develop my solution.

Here goes:

1. Add the necessary Dojo dependencies to your GSP:

<script type="text/javascript" src="${createLinkTo(dir: 'js/dojo', file: 'dojo.js')}"
   djConfig="parseOnLoad:true, isDebug:true"></script>
<g:javascript>
   dojo.require("dojo.io.iframe");
</g:javascript>

2. Write a function using dojo.io.iframe to send the form:

function submitForm() {
   dojo.io.iframe.send({
      form: 'uploadProductImageForm',
      load: function (data) {
         dojo.byId('productImage').innerHTML = data;
      }
   });
}

3. Create the file upload form:

<g:form name="uploadProductImageForm" method="post" action="uploadProductImage" enctype="multipart/form-data">
   <input type="hidden" name="id" value="${productInstance?.id}"/>
   <input type="file" name="newProductImage"/>
   <span class="button"><input class="add" type="button" name="uploadImage" value="Upload Image" onclick="submitForm()"/></span>
</g:form>

4. Create the controller method:

def uploadProductImage = {
   def f = request.getFile('newProductImage')
   if (!f.empty) {

   def imagePath = grailsApplication.config.store.productImages.location

   //Create unique name for this image set based on current timestamp
   def name = "image" + new Date().getTime()

   //Store the file
   def file = new File("${imagePath}/${originalFilename}")
   f.transferTo(file)

   //Do some image processing (resizing, etc.)
   ...

   //Dojo requires returning the result nested in an HTML document containing a body and textarea tag. Do this with
   //Groovy's built-in MarkupBuilder

   def writer = new StringWriter()
   def xml = new MarkupBuilder(writer)

   xml.html {
     body {
       textarea {
         img(src: resource(dir: grailsApplication.config.store.productImages.webPath, file: product.mediumImage.name), width: '250')
       }
     }
   }

   render writer.toString()
   }
   else {
      flash.message = 'file cannot be empty'
      redirect(action: show)
   }
}

And there you have it. Let me know what you think of this solution. It definitely works for me. You will notice that I didn’t include an upload progress bar – I’ll be doing this in a future iteration of the project. Cheers!