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.

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.

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

Fast forward to the present. In an unforeseen chain of events, all of the programmers at my company all sit on one side of a newly erected wall, and QA/Services/Helpdesk sits on the other side. We have decided as a team to leave the lights off on our side of the wall, and it has made a tremendous improvement. Lighting related headaches and nausea are practically nonexistent.

I’ve noticed lately that the number one search term that brings people to this site is "flicker vertigo", sometimes combined with "aspartame". It seems time to revisit this problem.

Flicker vertigo, annoyingly, is a topic that doesn’t seem to have a lot of information behind it yet. Sure, there are lots of hits on search engines, but if you look at the content excerpts, most of the pages seem to be copied from one another. Almost all of the results involve aviation. The most unique results I was able to find are the following:

• http://www.iflyamerica.org/flicker-vertigo.asp – Anecdotal information from flying a single engine propeller airplane.
• http://www.narcap.org/PerceptualDisorders.htm – Article from the National Aviation Reporting Center on Anomalous Phenomena (NARCAP) including a couple of paragraphs about flicker vertigo. Again, mostly anecdotal evidence from single engine propeller airplanes and helicopters.
• http://asrs.arc.nasa.gov/callback_issues/cb_268.htm – More anecdotal evidence from a Boeing 767 captain affected by the strobe on top of a fuel truck.
• http://en.wikipedia.org/wiki/Flicker_vertigo – The Wikipedia entry. Just a stub for now, since it appears to have been created 10 November 2006. I find it strange that it took so long for flicker vertigo to make it onto Wikipedia.

None of the above links contain much of any information about flicker vertigo. The prevailing opinion seems to be that it only happens to those involved in the aviation industry. One commonality in the sources is that they consider a flicker between 4 and 20 Hz to be the cause of "standard" flicker vertigo. (Of course, most of the article reference the NARCAP info at some point, so that may be why they all use the same numbers.)

One cause of flicker vertigo that I didn’t find mentioned was one that gets me every time – driving on a tree lined road at a time of day where the shadows are falling on the road. The sun "flickers" in and out of the trees with a frequency that’s probably very close to 20 Hz. I can only tolerate this for a minute or two. Any longer than that and I get a splitting headache, dizziness and nausea. I’m sure there’s some term for this that would turn up more hits in a search engine, but to me it’s clearly flicker vertigo.

I mentioned that some of the searches that hit my site include the word "aspartame". In my original post, I stated that evidence had been found that aspartame was linked to an increase in flicker vertigo among (you guessed it) pilots. I still have not been able to find the study (or studies) that this information came from. There is an article on the Flight Safety Foundation’s website, but you have to be a member to access it. I didn’t feel it was worth US$280 for me to become a member just to read the article.

One of the biggest frustrations in trying to find anything associated with aspartame is the sheer number of sites on the Web that are devoted to misinformation and FUD. I mean, how am I going to take anything seriously on a website that declares aspartame to be the "Thalidomide of the ’90s"?

It’s entirely possible that aspartame has some kind of effect on flicker vertigo. My own experience doesn’t seem to bear it out. When I wrote the original article, I was drinking one drink a day that contained aspartame and experiencing vertigo. Currently, I have three to four drinks a day with aspartame, with no vertigo effects. It’s possible that the single drink I eliminated was not what stopped the vertigo. The more likely explanation is that I made some other change that was the real solution – less sugar, less alcohol, etc.

I’m not saying that aspartame is innocent. It’s a man made substitute for a natural substance, so the body is going to process it differently. Does this mean it might cause health issues? I’m not going to say it won’t, but I can’t say that it will, either. I didn’t pay enough attention in organic chemistry…

I will go out on a limb and say that for the majority of the population aspartame has nothing to do with flicker vertigo. If you are already predisposed to flicker vertigo, maybe aspartame can aggravate it, but it certainly doesn’t cause it.

technorati tags:flicker, vertigo, flicker vertigo, aspartame, dizzy, health

Blogged with Flock

One of the key parts of the article was a chart detailing the 12 Steps of Burnout. It was disconcerting to see how many of the phases I fell into, but I scoffed at the 12th stage – the physical effects.

Fast forward to the wee hours of the morning on September 13. In a series of events that involved scaring the hell out of my family, an ambulance ride, and some time in the ER I experienced my physical effects stage.

Having never spent any time in a hospital as anything other than a visitor, this was a new experience for me. I’m still wearing a portable heart monitor, but it looks like everything cardiac-wise is perfectly normal. It just seems that I may be under a bit of stress. (heh)

technorati tags:health, balance, stress, anxiety, burnout

Blogged with Flock

Maximizing windows – the little plus actually is for maximizing the window, but it only maximizes to what the application developer thought should be the maximum size. A bit disconcerting, but once you get used to the other window management techniques that the Mac offers, it’s not such a big deal. The only complaint I have sometimes is that the maximum window size is a bit small for a 13 inch laptop screen.

Mousing – this has become more of a both-hand technique than I’m used to from the Windows world. I think I’ve pretty well got the hang of hitting the ctrl key to get contextual actions, and have almost mastered using the command key as a replacement for the Windows CTRL key. It’s not too bad, but I still have moments of forgetting what key to use when I just want to open a new tab in my browser.

My last complaint was about the function keys, and getting them to perform function like activities. I still haven’t figured this one out, but I’ll admit to spending no time looking for the answer. To be honest, I haven’t missed the "regular" functions provided by the function keys.

technorati tags:macintosh, mac, laptop, gadgets, macbook

Blogged with Flock