1 Web

I’m tasked with some css tweaking to our current product. We need to implement a ‘Print Preview’ screen so the customer can see how this looks before printing. Css supports exactly this use case with the @media notation.

So far so good.

Now Internet Explorer gives me some headache. Basically it looks like that if I render a page and then render the same page again with a slightly different style sheet, the lovely IE (7) will cache the width/text-align of the element. That means formerly right aligned text now looks like center aligned. Using FireBug under Firefox confirms the correct right aligned styled text. Even using the IE Developer Toolbar shows the correct style sheet information and element. Still, it renders sort of centered. By accident the right border of the text is exactly as far away from the left border as in the previous rendering. If I add any attribute to the text cell (or delete an attribute) all of the sudden the text will be rendered right aligned exactly how it should have been in the first place.

My guess is that IE remembers the width and alignment of the text cell from the previous page (why else the centered text appears to be the size). Deleting/adding an element via the developer tools forces a refresh and voila it renders how it should be.

I hate it.

First rendering of the text cell

Rendering with almost the same style sheet

Identifying the cell with the IE developer toolbar

Deleting the 'id' attribute with the Developer Toolbar

Voila, just after deleting the attribute, the cell renders how it should have been

I guess there is a solution for this, I just don’t know it. In any case….this is unexpected behavior.

On top of that: using css and Apache Trindad with a print preview on screen makes it hard to manipulate the css for the printout since I just don’t know the names of the css classes nor the imported Trinidad css file name (and I do have pre compiled/packaged css file where I have to restart the server every time if I do some changes).

*rant off*

2 Java

A couple of days ago I had the case that I needed to test a method with different parameters. I ended up writing a couple of test methods differing only in passing various arguments to the unit under test.

Tonight I was at a TestNG talk and while I knew most of the stuff already the DataProviders (which I heard of before but unfortunately never really payed attention to) really caught me.

Now I can create a DataProvider which generates test data. Each of these data sets will result in call of the test method with the corresponding arguments.

The following code will test a String to Property Converter if it works correctly. It takes two parameters, first the string to be converted, second the result which I will assert.

@Test(dataProvider = "convertTestDataProvider")
public void testConvert(String property, String result)
{
    Properties properties =
      stringPropertyConverter.convertString(property);
    Assert.assertTrue(properties.get("A").equals(result));
  }

Now the DataProvider must return an array of array of objects. TestNG will cast the return values to the method signature of all the tests with the corresponding annotation.

    @DataProvider(name = "convertTestDataProvider")
    public Object[][] convertTestDataProvider()
    {
        return new Object[][]{
                {"A=", ""},
                {"A=1", "1"},
                {"A=2=3", "2=3"},
                {"A=2" + StringPropertyConverter.ideaLineSeperator +
                 "# Comment" +
                 StringPropertyConverter.ideaLineSeperator + "C=1", "2"},
        };
    }

Here I cover 4 test cases. It is very easy to add more tests just by adding one more line with the values to test and the expected result.

TestNG results with DataProvider

This will save me some amount of time.

Good Job Cedrik & friends.

Next step: How to make sure you cover all the relevant test cases (and having a systematic way of getting there). Anybody has an Idea?

1 Development

We are using JSF, Facelets and Spring Webflow in the product I’m currently working on. What bugged me for some time already was that when we started to refactor the domain and the corresponding dto’s the GUI was a problem since the variables which get pulled out of the webflow are just string declarations. I had to go to each xhtml file and change the code to reflect the access to the new properties.

For some reason I missed a feature of IntelliJ IDEA completely.

If you are using Spring Webflow your code might look like this:

<tr:outputText value="#{flowScope.myViewBean.creditCardDto.fullName}"/>

You get no code completion nor refactoring security.

Now it is possible to make this a little bit better.

<c:set value="#{flowScope.creditCardDto}" var="creditCardDto"></c:set>
<!--@elvariable id="creditCardDto"
     type="net.wehrens.accounting.CreditCardDto"-->
<tr:outputText value="#{creditCardDto.fullName}"/>

With the clever Inspection ‘Declare External Variable in Comment Annotation‘ (just press Alt+Enter on the usage of creditCardDto) IDEA creates a comment annotation which tells the IDE of what type the given variable is. Since you are using webflow, you would pull the needed variable with a c:set tag out of the flowScope (or any other scope) and then declare the variable and it’s type.

There you go.

You can now start refactoring the creditCardDto and the GUI will reflect the changes. No more manual editing.

To make sure the comments do not get rendered out to the client (and with that the class information) you can turn that off for faclets in the web.xml configuration.

<context-param>
    <param-name>facelets.SKIP_COMMENTS</param-name>
    <param-value>true</param-value>
</context-param>

This is not specific to JSF, facelets or anything. This works with Freemaker, JSP’s and others as well.

My life just got a whole lot better.

2 Agile

So just in the last sprint we (re) discovered that we need an owner of each story. A person who makes sure things are going smoothly and takes care that everything is done in a way so we can fulfill all acceptance tests. At sprint start the person which feels the strongest about the first story will be owner and he will drive the story.
Very often we do operate in a king and servant model. The king (story owner) calls as many servants he needs to get ‘his’ story (with the highest priority) done. If this story does not scale to the full team the others are starting on the next story. Again, a story owner (king) is chosen (or whoever wants to drive the story). Of course story priority is always determining the order of allocating resources to finish the job.
To formalize the story owner a little bit we do write down the name of the person in the upper right corner of the story card. I updated the scrum board cheat sheet.

Get version 1.1 of the Scrum Board Cheat Sheet.

4 Development

I found SOLID Development Principles – In Motivational Pictures a couple of days ago. I put one of them up in the restroom. So it turned out some clever colleague enhanced the SRP picture. Nice job.

Single Responsibility Principle and Don't Repeat Yourself

9 Agile

We do have our Sprint Review tomorrow. We will not meet our commitment. Bummer.

What happened?

After the planning we did the breakdown of almost all stories. We had 5 Stories and another epic. As we did the epic breakdown we knew that we could not nail down every task since it was clear that some refactoring along the user story would be needed. So we marked one card in that story to remind us that we need to break things further down and refine the tasks.

The first couple of stories went very well (although we still suffer from estimating small stories too big and big stories too small). In the third week we got to our reminder card and our domain experts began to really think about the tasks needed and designed a much more useable and better architecture. This took a couple of hours and could not have been done at breakdown time (or could it?). It turned out it was quite some work to be done but we still could meet the deadline.

Some of us started to implement the new design and things seemed well. What we not did is a detailed planning of the tasks. It was more like we do see what is needed and write down task cards as we see the need for it. This was mostly done on ‘unplanned task cards’ (see earlier post on Scrumboard Cheat Sheet).

Due to the complexity that team could not check in their changes for some days (Remember? Never check in code which does not pass all tests). The only problem was that without that part of code most members of the team could not proceed very effectively on the epic. We found ourselves in a classic deadlock. I was part of those who could not work as intensive on the sprint goal as they would have liked to. It was a frustrating experience. In the end I think we could have been somewhat closer to the goal if we would have seen the warning signs like we just do write the task cards at the stand up (and acting on them). This goes down in my book under ‘Lessons learned’.

I’m not sure how we could have made it better. Doing a better task planning at the breakdown? We usually spent about two hours to define the tasks. Going over that time with the whole team seemed always to stress this a bit and it got less effective .
Should we have spent earlier on more time in designing the refactoring? Two people could have started right after that on that topic. But that epic had a lower priority and everything else should have been done before that if we do follow agile ideas.

However since our Product Owners saw that coming (there were usually at our daily standup) there were not shocked about it as they would have never heard of that problem before. But I guess they are not too happy with us.

Three more days and we are done. Promised.