The Blog-Health-o-Meter™ reads Fresher than ever.

Crunchy numbers

A Boeing 747-400 passenger jet can hold 416 passengers. This blog was viewed about 6,600 times in 2010. That’s about 16 full 747s.

In 2010, there were 15 new posts, growing the total archive of this blog to 115 posts. There were 24 pictures uploaded, taking up a total of 979kb. That’s about 2 pictures per month.

The busiest day of the year was June 4th with 139 views. The most popular post that day was Don’t build software that’s TOO smart!.

Where did they come from?

The top referring sites in 2010 were agile.dzone.com, java.dzone.com, twitter.com, Google Reader, and javablogs.com.

Some visitors came searching, mostly for matt stine, groovy http post, groovy post, groovy url post, and groovy url encode.

Attractions in 2010

These are the posts and pages that got the most views in 2010.

Don’t build software that’s TOO smart! June 2010
1 comment

Groovy: Post to a URL April 2009
4 comments

Resume March 2009

Deploying Grails with Groovy March 2009

LOTY Time Again: Scala or Clojure?!?! April 2009
17 comments

The first talk is entitled “The Seven Wastes of Software Development.” We’ll begin by examining one of the key tenets of Lean Software Development, that of eliminating waste. We’ll then walk through the seven wastes identified by Mary and Tom Poppendieck in their books:

• Partially Done Work
• Extra Processes
• Extra Features
• Task Switching
• Waiting
• Motion
• Defects

We’ll examine each of these wastes and look at some of their common manifestations, both in our coding practices and in our development methodologies. We’ll also examine strategies for eliminating each of these wastes from our development efforts.

The second talk is entitled “Yes You Kanban!” Kanban is sweeping through the agile software development space. Is it hype? Or is it a useful tool to add to our belt? In this session, we’ll walk through the following topics and I’ll let you be the judge:

• What is Kanban?
• What is Kanban NOT?
• Comparison to SCRUM
• Roots of Kanban
• David Anderson’s five essential elements/principles of Kanban (Visualize workflow, Limit work-in-progress, Measure & manage flow, Make process policies explicit, Use models to recognize improvement opportunities)
• Examples of Kanban systems

I hope to see some of you in these talks this Fall and I look forward to our discussions!

This sounded like a great idea to me, so I decided that we’d co-locate a NOSQL Summer discussion with our monthly Memphis JUG meetings. You can find the details of our NOSQL meetings at http://nosqlsummer.org/city/memphis. We’ll start at 5:30 and run until 6:15-6:30. If you’re interested in these discussions, come on out to Southwest TN Community College on June 24th (even if you’re not a Java type!).

Our first paper will be The End of an Architectural Era (It’s Time for a Complete Rewrite). Please read it before the meeting and come prepared to mindshare.

If there’s enough interest in these discussions, we could start having a lunch time discussion at a centrally located restaurant halfway between each JUG meeting. We can discuss this at our first meeting in June. I hope to see you there!

The following is a listing of the problem titles that were presented:

1. Life’s Persistent Questions
2. Instruments of Torture
3. Iterator Titillator
4. Searching for the One
5. Cogito Ergo Sum
6. Thread Friendly
7. When Words Collide

I’m going to spend my time focused on the last puzzler, as it was the one for which I was ABSOLUTELY CERTAIN that I knew the correct answer. Here’s the code listing:

public class PrintWords {
  public static void main(String[] args) {
    System.out.println(
      Words.FIRST + " " + Words.SECOND + " " + Words.THIRD);
  }
}

public class Words { // Compile PrintWords against this version
  public static final String FIRST  = "the";
  public static final String SECOND = null;
  public static final String THIRD  = "set";
}

public class Words { // Run against this version
  public static final String FIRST  = "physics";
  public static final String SECOND = "chemistry";
  public static final String THIRD  = "biology";
}

So here’s the problem. We have two versions of class “Words.” We compile class “PrintWords” against the first version and we then run the class against the second version. What does it print out? I used my trusty “seasoned Java programmer” knowledge to assert that the program would print “the null set.” Why? Well, any seasoned Java programmer realizes that static final variables (or “constant variables” – what a curious concept) are inlined by the compiler. So it’s quite obvious that “the” would be inlined wherever FIRST appears, null would be inlined wherever SECOND appears, and “set” would be inlined wherever THIRD appears.

Imagine my frustration when Josh and Neil announced that the program would in fact print “the chemistry set.” As it turns out, null cannot be inlined! It is not a constant variable. So when we run our Java program, the JVM smartly picks up the non-null value of SECOND that is is able to find in the new version of Words.

Simply because this one got me, I wanted to highlight it for my readers. The “moral” of this story is that only primitives and strings can be constant, and that null is not a constant. One should use a constant field ONLY if its value will NEVER change. For final fields whose value may change, they suggest the use of an ident() method:

// Returns its argument
private static String ident(String s) {
  return s;
}

// None of these fields are constant variables
public class Words {
  public static final String FIRST  = ident("the");
  public static final String SECOND = ident(null);
}

The compile will not inline the call to ident.

Want more? Pick up a copy of Neal and Josh’s book, Java Puzzlers: Traps, Pitfalls, and Corner Cases!

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!