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 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.

Co-Worker (who does not believe in unit tests): Okay. I just checked my changes in.

Me: There’s a bug in your code.

Co-Worker: How do you know? I just checked it in!

Me: It broke my unit tests. It looks like you’re not setting the flibbergibbet value correctly.

Co-Worker: What? How can you tell?

Me: JUnit showed me the difference.

Co-Worker: Oh. I guess I’ll fix it now. I would have found it eventually…

For what it’s worth, we’re handling Electronic Data Interchange documents – things that look like a page or so of line noise at a time. The bug was that one character wasn’t getting written to the output. My co-worker tests his code with the toString() and visual grep method. I’m not sure he would have ever caught the bug on his own. I keep trying to explain that unit tests are a Good Thing…

1. Watch your finances. We attended a conference shortly after I joined. We stayed at expensive hotels and spent several hundreds of dollars a night on dining out an entertainment. The company covered all costs. Overspending can lead to problems…
2. Be careful how you cuts costs. About six months after the conference, it was determined that the company was not making as much money as expected and that cuts would need to be made. In order to avoid laying off anybody, salaries were cut. My salary was decreased by 50%, which imposed quite a hardship. We were promised that the cuts were only temporary, and that as soon as salaries returned to normal, we would be reimbursed for all of the money we lost. Which leads to the next point…
3. Don’t lie to your employees. Turns out that the whole promise of reimbursement was just a pipe dream. I wasn’t too surprised by that. What surprised me was that the pay cuts were not equal, as I was told in the initial meeting. I actually took the highest cut – other employees took a 10-15% cut. I don’t care what kind of policies you have about keeping salaries secret; people will talk. If everybody is not getting the same treatment, tell them so and why. Of course, this behavior continued right on through the end of my employment…
4. If you’re laying off employees, do it right. This does not mean telling an employee that he needs to take all of his vacation time, then take unpaid leave until things "turn around". This goes back to my previous point – we both knew that there will be no turning around, and that it was a ploy to keep from having to pay me for accrued vacation while screwing me out of employment benefits since I wasn’t formally laid off. Also, remember that you’re running a business…
5. Don’t play favorites. Oddly enough, I was the only one on my team who got pseudo laid off. The other team members were old friends of the CEO and owners. Coincidence? I think not. My team lead had a habit of not showing up until almost noon and leaving to "work from home" around 2 in the afternoon. This usually meant that he checked in whatever code he had when he left, more often than not breaking the build. Whenever he worked from home, he seemed to always have problems that would prevent him from receiving IMs or email. The end result was that the entire team would be stalled until he came in the next day. He had been given many warnings, but he also played golf with the CEO quite frequently, and I think the CEO allowed his personal feelings to get in the way of business decisions.

   I’m not saying "Oh, poor me" here. I had my share of friction with my managers, so I was not surprised to get the axe. (Post coming soon on why managers don’t like me.) I was surprised that a guy who flat out refused to do work that was assigned to him would get to stay.

I got fed up and told the company to suck it up and lay me off. Luckily, I found a job within a couple of weeks and didn’t need to file for unemployment. A couple of weeks after I found my new job, the entire company went belly up. Maybe with better management and practices, the company would still be around. Maybe it was doomed from the beginning. Either way, I came away with some hard earned lessons that I won’t forget any time soon. I may not ever own a company, but many of these points apply just as well to managers and team leads.

The Swipe Toolkit is a neat collection of projects highlighting privacy issues. For some reason, their Data Calculator really reached out to me. The only problem I saw was that the calculator was only a Flash application. I wanted something I could run locally, so I recreated the calculator as a Java application.

The nice people of the Swipe Project have given me permission to release my version as an Open Source project, so I’ve created a new Sourceforge project for the development.

Right now, the only version available is for use with Java Web Start. Head on over to the information page and fire it up. Special versions, including installers, will be available soon for Windows, OS X, and hopefully Linux. In addition to the Java Web Start version, there are now packages for Windows and OS X, as well as a generic source package. Go hit the main Data Calculator page for the downloads.
Data Calculator

technorati tags:privacy, swipe, toolkit, open source, OSI, sourceforge, java, data, personal, security, data calculator

Blogged with Flock