I’ve been using Delicious Library for quite some time, and since I got my first Mac have used Apple’s Backup software as part of my backup solution. When I upgraded to DL2, I noticed that the backups weren’t changing size any more. I dug into the QuickPick package provided by the Delicious Monster website, and noticed that it hadn’t been changed to reflect the changes made in DL2.

I modified the QuickPick for my own use, expecting an official version to come soon. As of this writing, I’m still waiting.

I asked Wil Shipley why there was no updated QuickPick and got this response: “I think most people running DL2 have Time Machine.” (full response here) This seems to me to be quite a large assumption on Wil’s part. True, Time Machine is the “preferred” way to back up your Mac now, but the Backup software is still available and I would imagine there are quite a few people who still use it. For what it’s worth, I use Backup, Time Machine, Backblaze and SuperDuper! to back of various parts of my data. I’ve heard too many stories of Time Capsules failing to trust it to be my only backup solution.

The Delicious Monster website still points to the DL1 QuickPick from its FAQ entry about backing up data. This really frustrates me because users may download the QuickPick and trust that it is backing up their data while nothing of the sort is actually happening.

If you are using Delicious Library 2.x and Apple’s Backup software, you can download the QuickPick I created to correctly back up your data.

Initially, I used a <h:commandLink/> with target="_blank". This worked well until the user entered criteria that failed validation. The new window was still created, and the validation messages were shown in the new window. This was not a good solution, so after some research and experimentation I came up a solution that meets the following criteria:

• Validation messages are shown in original window.
• A new window is not created when there are validation messages.
• A new window is not created when the entered criteria returns zero (0) results.

The Action Class

For this example, the action class is very simple:

public String getReportURL() {
    return "/pdfpopup/reports/reportDisplay.seam";
}
// Getters and setters omitted
public List<String> getReportData() {
    return reportData;
}
public void doSearch() {
    // This is where the work would actually happen
    reportData = new ArrayList<String>();
    for (int i = 0; i < selectOneValue; i++) {
         reportData.add("Report Row " + (i + 1));
    }
    if (reportData.isEmpty()) {
        facesMessages.add("Report will be empty, not popping up");
    }
}

I added the getReportURL() method to the action because there may be occasions where the report URL differs based on criteria. In the application I worked on, we had to support PDF and Excel reports, so the method returned the correct URL.

The action simply takes the criteria specified on the JSF page and populates a list of results based on that criteria. The PDF generation page will access the list later.

The JSF Page

The JSF page looks like this:

<ui:define name="body">
  <script type="text/javascript">
  //<![CDATA[
  function showReport(conversationId) {
  if (document.getElementById("messages") != null) {
    return;
  }
  var reportWin = window.open('#{reportAction.reportURL}' + '?cid=' + conversationId);
  if (!reportWin) {
    alert("Could not open the report window. Please disable popup blocking for this website and try again.");
  }
  }
  // ]]>
  </script>
  <h:form id="generateReport">
  <s:validateAll>
  <h:panelGrid width="100%" columns="1" style="text-align: center; font-weight:bold; font-size: 12px">
    <h:outputText value="Report Query"/>
  </h:panelGrid>
  <h:panelGrid columns="2" border="0" frame="none" style="padding-top:30px;">
    <h:outputLabel for="selectOneValue">Number of Output Rows</h:outputLabel>
    <h:selectOneMenu id="selectOneValue" value="#{reportAction.selectOneValue}" required="true">
      <f:selectItem itemLabel="Zero" itemValue="0"/>
      <f:selectItem itemLabel="One" itemValue="1"/>
      <f:selectItem itemLabel="Two" itemValue="2"/>
      <f:selectItem itemLabel="Three" itemValue="3"/>
      <f:selectItem itemLabel="Four" itemValue="4"/>
    </h:selectOneMenu>
    <h:outputLabel for="startDate">Report Period:</h:outputLabel>
    <h:panelGroup>
      <rich:calendar id="startDate" enableManualInput="true"
        value="#{reportAction.startDate}" showWeeksBar="false" datePattern="MM/dd/yyyy"
        immediate="true" required="true" label="Report Start Date"/>
      <h:outputLabel for="endDate">through</h:outputLabel>
      <rich:calendar id="endDate" enableManualInput="true"
        value="#{reportAction.endDate}" showWeeksBar="false" datePattern="MM/dd/yyyy"
        immediate="true" required="true" label="Report End Date"/>
    </h:panelGroup>
    <a4j:commandButton id="getReportLink" action="#{reportAction.doSearch}"
         value="Get Report" oncomplete="showReport('#{conversation.id}')"/>
  </h:panelGrid>
  </s:validateAll>
  </h:form>
</ui:define>

This is really the guts of the operation. When the commandButton is clicked, the doSearch() method will be executed. Once that call is complete, the oncomplete handler will be called.

The page template is configured so that any FacesMessages will be displayed in an element with id “messages“. If this element is present, we assume that either a validation error or no data message is being displayed and do not show the PDF. If the element is not present, everything is OK and we open the new window with the URL for the PDF. Note that it’s crucial to pass the conversation ID along so that the data loaded by the action will be visible to the page creating the PDF.

The PDF

For completeness, here’s the sample page I’m using to create a PDF:

<p:document xmlns:p="http://jboss.com/products/seam/pdf"
   xmlns:ui="http://java.sun.com/jsf/facelets"
   xmlns:f="http://java.sun.com/jsf/core"
   title="Sample PDF Report">
<f:facet name="header">
  <p:font size="12">
    <p:header borderWidthTop="0" borderWidthBottom="0.4" alignment="center">
      <p:paragraph indentationLeft="50">REPORT HEADER</p:paragraph>
    </p:header>
    <p:footer borderWidthTop="1" borderColorTop="black" borderWidthBottom="0" alignment="center">
      [<p:pageNumber/>]
    </p:footer>
  </p:font>
</f:facet>
<ui:repeat var="item" value="#{reportAction.reportData}">
  <p:font size="8">
    <p:table columns="1" headerRows="1" widthPercentage="100">
      <p:font style="bold">
        <p:cell verticalAlignment="bottom">Report Data</p:cell>
      </p:font>
      <p:cell>#{item}</p:cell>
    </p:table>
  </p:font>
</ui:repeat>
</p:document>

Full Sample Code

You can view and download the full sample code for this solution from here.

The standard procedure for this employer is to give candidates a simple phone screen before arranging an interview. Personally, I feel that having one person make a decision about whether or not I’ll “fit well with the team” after 10 minutes on the phone is ludicrous, but that’s the game I had to play.

During the phone call, I was asked several generic questions about Java. I gave what I felt was correct answers to the questions, but the interviewer wasn’t happy with my results. Every time I answered a question, I heard “Well, I was looking for…”, with the expected answer simply being a different wording of what I had said.

I chalked this up to the interviewer simply being used to different terminology than I for the same concepts, so I was a bit surprised when I wasn’t called in for an in-person interview. It wasn’t until a few days later that I realized that the answers I was expected to give told me quite a bit about the company, and that I wouldn’t have been happy working there had I been offered the job.

The particular question that stuck in my mind was a simple one. “What are some of the benefits of the introduction of generics in Java, especially in collections?”

I gave the answer that pretty much anybody familiar with Java generics would give: compile-time type checking, no need for casting objects, etc. What I got from the interviewer was “Well, I was looking for the fact that you don’t have to do instanceof checks all over any more.”

On the surface, this may seem like another way of saying what I said, but it’s actually quite different.

Before generics, you would need to cast objects to the proper class when retrieving them from a collection. This does not mean that you would be using instanceof to do this. The only situation I can think of that requires using instanceof with a collection is if there are a lot of heterogenous objects in the collection.

There are limited situations where storing different object types in the same collection makes sense. Most of the time, however, this is a sign of either lazy development or not understanding the collection mechanism very well.

It’s generally a good idea to only put one type of object into a collection. This makes it much easier to work with and avoids any need for instanceof checks. By “one type of object”, I don’t mean that all of the objects need to be the exact same class. Chances are good that all of the objects being placed into a collection have some relationship; perhaps they will all implement the same interface.

I may have completely misinterpreted the interviewer, but I have a very strong impression that he and perhaps others on his team are used to using collections as grab bags of widely different things. Personally, I wouldn’t want to maintain that code. I can hope that the addition of generics to Java has forced the interviewer to change at least one practice for the better. I’m glad I wasn’t called in for the job – who knows how many more “well, at least it works” practices are being followed? I’ve got enough of those at my current job; I don’t need to learn a new set.

Images:

Tin Can:

Java Code:

The general consensus put forth by Twitterers with “eco” or “green” in their usernames is 2,500 gallons of water to 1 pound of beef.

This tweet, for example, was posted on April 1 and links to a Yahoo! Answers discussion.

This tweet, from June 7, links to this article from EarthSave International.

Both of the aforementioned tweets use the 2,500 gallons per 1 pound of beef figure. What’s not so clear is how the number was determined in each case.

The Yahoo! Answers discussion arrives at the number from a YouTube video titled You can’t be a meat eating environmentalist by a user named “LiveVegan”. In the course of this video, text is shown on the screen, citing various “facts” about the livestock industry. One of the facts is the 2,500 gallons of water statement. The video does not state where this number came from, nor does it cite any of its sources in any more detail than “2006 United Nations Report & WoodstockFAS.org”.

The EarthSave link similarly comes up with the 2,500 gallon number, based on a couple of sources. The first source is “a statement by the renowned scientist Dr. Georg Borgstrom at the 1981 annual meeting of the American Association for the Advancement of Science”. The next is the book Population, Resources, Environment, apparently published in 1978 and not easily obtained (at least for me). The last source cited is a publication titled Water Inputs in California Food Production, that is described as distributed by the Water Education Foundation. I visited the Water Education Foundation’s website at http://www.watereducation.org/, but was unable to find this publication.

What do we have so far from Twitterers to support the 2,500 gallons per pound of beef claim? One YouTube video published by a person who could certainly be seen as having a biased opinion, and an article published at an indeterminate date quoting a statement, a 30-year old book, and an article that can’t be found.

I was raised on a cattle ranch, the same one that my father and grandfather were raised on. It’s probably fair to say that I have a biased opinion of the agriculture industry as well. I can’t, however, just deny the water for beef argument because I don’t like the numbers. I did some research of my own and found startlingly different results.

This article, from a website created by the Cattlemen’s Beef Board and National Cattlemen’s Beef Association, gives a number of 435 gallons per pound of beef. This number is backed first by Animal Agriculture and Global Food Supply, from the Council for Agricultural Science and Technology (CAST). The report is quite exhaustive and places doubt on the larger estimates of water usage due to overestimating the amount of irrigation used in growing the feed.

Both the website and the CAST article reference Estimation of the water requirement for beef production in the United States. This publication delves into great detail about the amount of water used to grow various feed crops, as well as the amount of water used for finishing slaughtered animals. The results of this study were that it takes approximately 441 gallons of water per pound of beef. Additionally, this article points out that livestock production is responsible for just over 11% of all U.S. water use.

Sure, it’s easy to take the outrageous numbers as facts and pass them along, especially when you’re anti-beef. The livestock industry as a whole seems to be a convenient target for environmentalist outcry lately, but I would urge people to keep in mind that “livestock” also includes pork and poultry. Pork and poultry deserve additional scrutiny due to the conditions that the animals are raised under.

I’ve only been arguing the claims that beef requires a large amount of water. There are similar claims regarding the amount of grain it takes to produce a pound of meat. I could probably fill another blog post with this debate, but I can summarize quickly. It takes 2.6 pounds of grain, not 16, to produce a pound of beef. Similarly, a significant amount of cattle feed is not food-grade, meaning it’s inedible for humans.

Sources:

How much food energy is lost by consuming meat instead of vegetables?
Yahoo! Answers, ~October 2008

2,500 Gallons All Wet? – John Robbins
EarthSave International, Date Unknown

You can’t be a meat eating environmentalist – “LiveVegan”
YouTube UK, 15 May 2007

Water Education Foundation

Beef Myths and Facts
Beef from Pasture to Plate, Date Unknown

Animal Agriculture and Global Food Supply
Council for Agricultural Science and Technology, July 1999
Available from http://www.cast-science.org/

Estimation of the water requirement for beef production in the United States – J.L. Beckett and J.W. Oltjen
Journal of Animal Science, 1993
Available from http://jas.fass.org

The one thing that makes this man stand out in my memory is that whenever we parted ways, he would say “make it a good day”. I usually said “you, too”, or something similarly uninspired.

What he was saying finally struck me one day. He was not telling me to have a good day. He was telling me to make it a good day.

As nice as the sentiment sounded, I didn’t really see how it applied to me. My job sucked, and it was causing me all kinds of stress – even to the point of visiting the emergency room. I experienced a lot of anxiety and had a few panic attacks.

I got to the point where I reacted badly to everything that happened at work. I can remember telling my manager more than once that decisions made by upper management were going to cause me to have to take another trip to the hospital. He finally got tired of my complaining and told me that work was not causing me stress; it was my reaction to work that was causing stress. That was not the answer I was looking for, so I added him to my mental list of stressors.

Fast forward a couple of years to a new job. As I’ve mentioned before, I’m now leading a pilot project using an agile process (Scrum). For the first several iterations everything annoyed me. My developers couldn’t follow simple instructions. They couldn’t write good code. They had to be constantly prodded to keep them going. Every day had its share of “what now?” moments.

For some reason I started thinking about the man at the gym again. This time, it paired perfectly with my old manager’s advice. Despite my annoyances, work continued to get done and things were working. It wasn’t the work that was bothering me. It was my reaction to work.

I’ve been trying to be very mindful of how I’m reacting to things at work. I still get pulled in a lot of different directions, and I’m still having trouble getting my team involved in the process. What I’m not doing is worrying about it. I’m learning to be more aggressive about my time management. Instead of wondering why my team can’t grasp simple process concepts, I’m asking them how I can explain or demonstrate it better.

Don’t get me wrong. There are a million things I’d like to change about my environment and my team every day, but instead of waiting for a good day to just “happen” to me, I’m becoming an active participant and “making it a good day”.

In the last several weeks, I’ve noticed that my anxiety level has plummeted, my stomach is not upset every day, and I’m sleeping better. That’s good enough for me.

Amazon has added the ability to add third party items to wishlists, so I figured I could move back with little difficulty. One thing I quickly discovered was that I  couldn’t syndicate my list through RSS directly from Amazon. Some searching later, I found what appeared to be the answer: Ed’s Amazon RSS Wishlist. It looked to be exactly what I was looking for, except for one small problem – it didn’t work.

I had never used either Yahoo! Pipes or the Amazon Web Services API before, but this looked like a good opportunity. I cloned Ed’s pipe and began updating the calls to work with version 4.0 of Amazon’s ECommerce Service (ECS).

Working with Yahoo! Pipes turned out to be quite a bit of fun, and the Amazon API is well documented. Output from my modified pipe can be seen at the bottom of this post.

If you’d like to use my pipe to create an RSS feed for your own Amazon wishlists, you can find it here: http://pipes.yahoo.com/iamthechad/amazonrsswishlist

The single largest variable on any development team is the developers. I’ve found that moving to an Agile process like Scrum can really expose developers who’ve been hiding behind “traditional” processes.

Therein lies one of the biggest problems I’ve run into. One of my developers is not what you could by any means call a self starter. He has been able to get along well with the official process, which does not do a good job of tracking what developers are working on. Now that he’s been thrown into Scrum, it’s become quite obvious that he really doesn’t do anything until somebody nags him long enough to get him going.

This is where inertia comes in. This developer is a textbook example of an object staying at rest until the team lead can poke and prod enough to finally get him moving. His previous lead had simply taken it as granted that he would have to spend a certain amount of time micromanaging to get any work out of the developer. I think it’s a waste of time and energy for me to constantly remind him to pick a task and work it, but that’s what I’ve been reduced to doing. This week, for example, it took two days of nagging to get him to perform a ten minute refactor. (I would have done the refactor myself, but I have to trust that my team can do their jobs, too.)

I don’t know how to engage this guy. I can spend time collecting data and create metrics, but I don’t think that’s an effective motivator. What I’d really like to see is a commitment to the team and to the project that leads into a desire to pull his fair share. I don’t even know if these are feelings I can engender in this developer.

Motivation is an issue for teams using any kind of development process. Every team member reacts differently to various inputs. Some members like recognition, while others prefer a bonus. Some just want to be left alone so they can do the bare minimum to get by. I’m hoping this isn’t the eventual outcome with this developer.

I ran into a bit of a quandary the other day. I had to modify a piece of legacy code in our system – one that has no tests written against it. My first task was to write as many JUnit tests as I could to document the behavior of the component to help ensure that I didn’t break existing functionality with my changes.

After a few tests, however, I began to notice something troubling. The component I was writing tests against had some bugs in it, and in order to make my unit tests pass, I had to code to those bugs. This in itself did not bother me too much, since I had no expectation that the component I was testing was error-free.

What bothered me is that unit tests are often the best documentation of how a system works, and I would be creating misleading documentation. So, I did what anyone in this situation would do: I emailed someone a lot smarter than me. 

The reply email contained several suggestions, all of which I plan to implement. The first suggestion is to carefully name the test methods to make it clear which ones work because of defects. The second suggestion is to create an annotation that can be added to a method to indicate that it works because of a defect, coupled with some way to report on all uses of the annotation.

After a few hours of coding, I’m happy to announce that I’ve created a Java annotation named KnownDefect as well as a detector plugin for FindBugs to collect all of the annotation instances.

In the parlance of “Working Effectively with Legacy Code“, I have been creating “characterization tests“. These tests look like normal unit tests, but they document the current state of the system, warts and all. Using the KnownDefect annotation helps make the warts stick out better.

Here’s an example:

public void testValidateNullResponse() {
   try {
      ProtocolParser.validateResponse(null);
      fail();
   } catch (InvalidRequestException expected) {
      // Caught expected exception
   }
}

This test documents the system as it currently exists, but the behavior is obviously not correct. The ProtocolParser class should be throwing an InvalidResponseException, not an InvalidRequestException. To document this defect, I change the method name and add the KnownDefect annotation to the test method, resulting in the following:

@KnownDefect("Should throw InvalidResponseException")
public void testValidateNullResponseShowsKnownDefect() {
   try {
      ProtocolParser.validateResponse(null);
      fail();
   } catch (InvalidRequestException expected) {
      // Caught expected exception
   }
}

The correct behavior is now documented, and the test still passes.

Instead of writing a new tool to manage the KnownDefect instances, I ended up writing a new plugin for FindBugs. The FindBugs detector will collect all instances of the annotation and group them under the “Correctness” heading so they’re all in one place. Bug reports can then be created and the defects fixed or not as business needs dictate. (Sadly, the FindBugs plugin for Eclipse does not find the annotation in Groovy code. The standalone version of FindBugs works fine, so I assume there’s a resource filtering issue with the Eclipse plugin.)

Instructions for using the annotation and the detector are included in the download file. Try it out – hopefully it will be useful to somebody other than myself.

(Download KnownDefects) (Subversion: http://subversion.megatome.com/projects/KnownDefects/trunk)

(Click to get the shirt)

I’ve been coding with an agile mindset for quite some time now. Some practices have become second nature to me over the years. One of these practices is aggressive code refactoring, coupled with test driven development (TDD).

I’ve been adding new functionality to our system at my new job, and as usual I’ve been following my standard techniques. My part of the system involves handling certain requests and responses. I wrote unit and functional tests for the request half of the equation, then began to tackle the response side. As I added (and tested) functionality, I began to notice a large amount of similarity in the code. This in turn led me to create an abstract base class for both request and response, pulling up all of the shared functionality. This resulted in the actual request and response classes being quite small, with just a few method implementations from the base class.

So far, this activity should seem pretty normal to most developers. As I said, it’s pretty much second nature for me, and I don’t even remember consciously making the decision to make the abstract class. Imagine my surprise when my team lead admonished me for creating and abstract class, and warned me not to do it again without explicit approval.

Of course I had to ask why we would not refactor code in this manner when the opportunity presented itself. My lead’s answer involved several parts, none of which have convinced me that refactoring is bad:

1. The abstract class is not consistent with the rest of the system. This, to me, seems to be a fault of the system. I’m not knocking consistency, but at some point you have to realize that you may be building something that’s consistently bloated/overcomplicated/etc.
2. The abstract class changes the design. Huh? Sure, if I go generate a UML diagram of the system, there’s going to be this abstract class and inheritance there. This is the only place the design is different. Requests and responses are being correctly handled just like the legacy ones in the system.
3. Too much refactoring is bad, and each case should be thoroughly examined before code is changed. This is how religious wars start. My lead claims that developers start out on the “no refactoring” end of the spectrum, simply because they don’t know any better. Once they learn about refactoring, they then swing to the “refactor everything” end of the spectrum where anything and everything is a potential target. Seasoned, knowledgeable developers fall somewhere in the middle. I got the impression from this speech that my lead considers me to be on the radical end of the spectrum.

Why are people like my lead so scared of refactoring? The arguments given really seem more like rationalizations than actual reasons – they don’t really stand up to scrutiny. I have a hard time believing, for example, that my lead truly thinks that the system is better because each request and response is a totally separate class, albeit with most of the code copied and pasted from one to the other. If anything, he should know that this approach leads to more problems, no matter how pretty it keeps the class diagrams.

(Click for Larger)

Yup, they sent me a faceplate for my Wii guitar, along with a note explaining that the gift is a thanks for being patient and waiting to get my remastered GH3 disc.

While this probably isn’t the design I would have picked on my own, I have yet to find faceplates for the Wii guitars in stores yet, so beggars can’t be choosers.

This gesture is nice and aimed at keeping customers. I appreciate the gift, but I’d rather have an apology for the way they screwed up and shared a bunch of email addresses that should have been kept private. I guess customers have been more concerned about how many speakers their game’s music comes out of than who has their email address.