So why the heck am I selling it? Well, it has been years since I played the game. It was a nice game to play with fellow students at the University and it was always a very good feeling to open up a new pack of cards and discover the new treasure. I remember the crisp sound of a fresh boosterpack being opened. There is still some tingling left when I browse my collection, but still it is time to give it up.

Collecting and playing Magic can take up the same amount of time as a full time job, or even more. I no longer have that kind of time on my hands, since I am working as a freelance Java Specialist. This job requires me to put a lot of time and energy in developing my network, my name and of course my expertise. Combine that with a very nice girlfriend and a social life and there is no more time left for Magic. After many months of doubt, I finally decided to sell the whole lot.

If you are interested, drop me a message, either as a reply or through the Contact page. Be sure to keep an eye on the Magic page, since I will update it with more details about my collection.

–JH

PS: The next post will again be on software development, I promise

This project has a set of widgets which support switching themes at runtime. That was exactly what I was looking for, but I had no need for the widgets. So I picked the project apart and adapted the way it changes CSS on runtime to fit our application. In this post I will take you through the pieces of code we used to complete this. Note: this is going to be quite a long and code heavy post ^_^

We’ve got the following:

• GWT views with UIBinder
• Default styling in CSS
• Only a few things which are customizable in the application (mostly colors)
• A preference page which allows users to change these colors
• A servlet that generates CSS based on the settings

The (highly simplified) diagram below shows the main components and their interactions. Basically what happens is the user performs some action in the GWT Client that changes something like a color setting. This causes the client to send the update over RPC to the server. After a successful store, an event is triggered inside the GWT client that this setting has been altered. Some listener picks up the event and changes the CSS reference. This change forces the browser to load the ‘new’ CSS file from the server. The server then generates this CSS file based on the settings. By now the circle is round and the updated CSS is loaded and applied.

I’m not going to talk about the Settings page and the RPC call as these are just standard GWT. You can simply incorporate the following parts into your GWT application and fire the SettingChangedEvent (or any other event) and change the CSS to reload it.

Coding Time!

Let’s introduce some pieces of code we have here. Our settings backend stores settings with a String key and fires off events of changes in settings to the GWT client. The Event triggered to notify the application of these changes looks like this:

/**
 * An Event of this type indicates one of the settings has been changed.
 *
 * @author J.H. Kuperus
 */
public class SettingChangedEvent extends GwtEvent<SettingChangedEvent.Handler> {

  /** Handler interface for the {@link SettingChangedEvent}. */
  public interface Handler extends EventHandler {
    void onSettingChanged(SettingChangedEvent event);
  }

  private String propertyName;

  public SettingChangedEvent(String propertyName) {
    this.propertyName = propertyName;
  }

  public String getPropertyName() {
    return propertyName;
  }

  // --- Boilerplate code for GWTEvents

  // ...
}

It simply passes the name of the changed setting around. This is what we respond to on the client side to change the CSS. If it is any property that is part of the dynamic CSS, we change the URL of the referenced CSS document, causing it to be reloaded by the browser. The piece of code that handles the event looks like this:

public class ColorChangeListener implements SettingChangedEvent.Handler {

  @Inject
  public ColorChangeListener(EventBus eventBus) {
    eventBus.addHandler(SettingChangedEvent.TYPE, this);
  }

  public void onSettingChanged(SettingChangedEvent event) {
    if (event.getPropertyName().startsWith("core.color")) {
      // If the color has changed, force a reload on the CSS
      ThemeUtil.setLinkHref("themeCssElement", "/activeTheme.css"
          + "?v=" + System.currentTimeMillis());
    }
  }
}

The listener implements the event’s Handler interface and registers itself to the EventBus. Note that we are using GIT injection to resolve these dependencies. If you obtain your EventBus in a different fashion, adjust your code accordingly.

The parameter added to the URL of the CSS-file is purely bogus, but prevents any proxy or browser from caching the file. The TemeUtil.setLinkHref is the piece of code I borrowed from the Advanced GWT Components library and looks like this:

public class ThemeUtil {
  public static native void setLinkHref(String linkElementId, String url) /*-{
    var link = $doc.getElementById(linkElementId);
    if (link != null && link != undefined) {
      link.href = url;
    }
  }-*/;
}

The setLinkHref method is a native piece of JavaScript that tries to find the element identified by the linkElementId and sets its href property to the specified URL. In order for all of this to work, you must also include your dynamic CSS in your main HTML file. We simply added the following to the <head> section:

Alright, that’s all the client code required for this work. Now let’s hop over to the last piece we need to build: the CSS servlet. This servlet basically just extends the HttpServlet class and implements the service() method to write a standard CSS file. In our app, we use a class called ServerSettings to retrieve the stored colors from the Datastore. Adapt this to your situation as needed:

public class CssThemeServlet extends BaseServlet {

  @Inject
  private ServerSettings settings;

  @Override
  protected void service(HttpServletRequest req, HttpServletResponse res)
      throws ServletException, IOException {
    res.setContentType("text/css");
    PrintWriter writer = res.getWriter();

    StringValue coreColor1Setting = settings.getStringSetting("core.color1");
    StringValue coreColor2Setting = settings.getStringSetting("core.color2");

    writer.println(".themedGradientBackground {");
    writer.println("    background-image: -moz-linear-gradient(top, "
      + colorStop1 + ", " + colorStop2 + ");");
    writer.println("    background-image: -webkit-gradient(linear, left top, left bottom, color-stop(0, "
      + colorStop1 + "), color-stop(1, " + colorStop2 + "));");
    writer.println("}");
  }
}

You can write any CSS you want here, however, writing it with println-statements will get crazy fast. So think about a using a template engine, or putting it in a JSP. We are probably going for Velocity.

The last step to make all of this work, is to serve the URL used above (/activeTheme.css) with the CssThemeServlet. You either put it in your web.xml, or in you Guice ServletModule. Choose the appropriate method for your setup:

  <servlet>
    <servlet-name>cssTheme</servlet-name>
    <servlet-class>CssThemeServlet</servlet-class>
  </servlet>

  <servlet-mapping>
    <servlet-name>cssTheme</servlet-name>
    <url-pattern>/activeTheme.css</url-pattern>
  </servlet-mapping>

  serve("/activeTheme.css").with(CssThemeServlet.class);

Last but certainly not least, we still need to fire the Event somewhere. This is most likely done from a drop down or list box. Implement the appropriate event handler for your box (probably something like onChange):

public void onChange(ChangeEvent event) {
  // if event.getSource() is our list box
  eventBus.fireEvent(new SettingChangedEvent("theme"));
}

Now you can use the classes from your dynamic CSS in your widgets to provide dynamic themed colors, borders, shadows, backgrounds, whatever your want. If you have any questions, feel free to leave a comment. Happy theming! ^_^

–JH

Assuming your team has now incorporated standup meetings, preferably on a daily basis, it is time to take the next step. Agile methodologies generally rely on a rather simple notice: Visualized Management! Now don’t get scared, the word ‘Management’ here does not mean you need another manager. When done right, this visualization can eliminate the need for a manager. Now doesn’t that sound sweet?

Probably the best known example of this visual management is the Scrum Board, or Activity Board, or ToDo Board. However you call it, it’s a big board containing lot’s of post-its all describing work. Some of this work is yet to be done, some of it is in progress and hopefully, some of it is already done. What status a particular piece of work is in should be apparent from its location on the board.

Most boards contain three columns: To Do, In Progress and Done. These columns are however not mandatory, you can make any set of columns you like. You could for example also create columns for each expertise in your team, like To Do, In Design, In Development, In Test, Done. The possibilities are literally limitless, all you need to do is find a set of columns that work for your team. (And don’t be afraid to modify it if you are missing something, or feel a column is not required).

You could start by asking your team members to write down what task they are working on right now and put all those post-its in an In Progress-column. Ask them to move the post-it to the Done-column when they complete the task and then write a new note for the next task. The next step would be for people to write things they know still need to be done, or things which are discovered along the way down and put them in a To Do-column. Slowly but surely, you will begin to see progress!

If you are already working in sprint-like increments, you can cleanup all the Done work at the end of a sprint and (re)populate the board with work at the beginning of a sprint. If you have not yet incorporated such increments in your work style, then you could make sure a certain minimum amount of work is on the board. Don’t put an entire project’s worth of work on the board or you might risk your team members feeling overwhelmed.

Why is this important?

Why does this help you be more agile? For one thing, it helps during the daily standup meeting since you can now talk about the things that are on the board. It helps people remember what they were doing and hopefully takes away the number of “let’s see, what did I do yesterday?”-questions during a standup .

It also provides a very visible way to demonstrate the progress of the project. Anyone interested in the progress of the project can simply walk up to the board and see what is currently being worked on. Ideally this should stop management from continuously asking your developers what the status of the project is. If they still do, simply explain the board to them and refer them to it. Let your developers do what they do best: write code.

A very nice extra piece of visual management would be to create a (burndown) chart which displays the rate at which tasks are being performed. We all know how much management loves to look at charts, but with a burndown chart, they might need require some ‘training’. You see, management is used to the paradigm that an upward trend is good and a downward trend is bad. On a burndown chart we display a line of work that still has to be done. Usually this starts out at some arbitrary number of tasks and goes down over time as work is completed. Make sure management understands this

If you are looking for some more pointers on creating your own board, check out some of these links:

• Elements of taskboard design – A very nice explanation of a very detailed board
• Burndown Charts – A good explanation of what a burndown chart can tell you

Try it sometime. Just pu

Since my last post, we have pretty much finished our JavaFX project. I was at the NLJUG’s JFall where I hosted a JavaFX workshop all afternoon and I have been to Devoxx in Antwerp where I met Richard Bair and Jasper Potts from the Oracle JavaFX team.

I have also joined Stephen Chin in the maintenance of the Visage language. This is the continuation of the JavaFX Script language as an open source project (see Google Code).

Now shut it, you mentioned something about agile…

Yes I did. We have recently moved into a new engineering phase of a large project at work. We had previously used some agile concepts here, but never really moved into full blown Scrum or anything. This time we have, or rather, we are migrating to a real Scrum project setting.

So I thought it would be nice to share how we are currently moving to a more agile project. Although I think we are pretty late to actually fully embrace it, I’m sure there are still plenty of others out there struggling to go agile. I intend to chronicle the steps we took and discuss the ups and downs we perceived.

Today, the first step: standup meetings. The first thing we picked up (again) were the standup meetings every morning. This is probably the easiest piece of Agile/Scrum to incorporate into an existing team. It can however be hard for people to adjust to these meetings.

The first thing you need for a good standup is a leader. This should be a Scrum Master if you have one, or one of the team members who can maintain order. This is due to the first pitfall with taking up a standup meeting: taking too long.

The key to a good standup and a good feeling among your team is to really keep it short. Make it clear to everyone that they should only briefly answer these three questions:

1. What have you achieved since the last meeting?
2. What are you planning to do today?
3. Is anything hindering you in those plans?

People initially tend to take a while explaining their answer to the first question. They may actually feel like they have to defend what they are doing. This is not true and such feelings should be countered as soon as possible. Make sure everyone understands that the goal is just to increase team communication and team spirit. If someone hears a colleague struggle with a problem that he is familiar with, he may be triggered to help. If someone hears a colleague work on something in which he is also interested, a nice discussion might come up. Just make sure the discussion takes place after the standup. This is where the leader should stop any deviations in their tracks and keep the standup going.

The second question also does not require long answers. If you can say it in one sentence, that will do, as long as everyone has an idea of what you will be working on. This is mostly just meant to make sure the whole team knows what is happening and to potentially spot conflicts. Although the answer to this question is somewhat a commitment to the team about what you will do, it should never be used against anyone. Heck, if something goes terribly wrong, or someone interrupts you, you can name those interruptions during the next standup. If required you can name those interruptions as your ‘problems’.

The third question is hardly ever answered with anything else than ‘no problems’. It is however a very important question. From time to time, something might actually be holding you back. It can be silly things like ‘we ran out of sugar’, to really serious issues like trouble at the homefront. If at all possible, the leader / scrum master should try to take these problems away. The power of the scrum master is obviously limited here, but offloading certain things can help you be more productive.

That’s it for now, next time I’ll write about taking up a rhythm by adopting sprints. If you have any questions or other experiences about standups, feel free to leave me a comment.

–JH

NPE’s are meant to signal development errors. In other words, if you see an NPE, you can call your developer and tell him he screwed up. Some developers even need them to be reminded of the pieces of an application they were working on.

The fact that JavaFX swallows many exceptions, makes it hard to find out if you made a programming booboo or not. As an example, today my colleague was working on a zooming/scaling algorithm. The calculations were all correct, since we could check them by the many FX.println statements we added to the algorithm:

-----------------------
Scale factor: 2.5
sceneX: 254.0
sceneY: 158.0
... etc
topLeft X: 0.0
topLeft Y: 0.0
-----------------------

It all seemed a-okay, with one exception: the topLeft X and Y remained at 0.0, even though the following statements were included in the algorithm:

topLeft.x = x;
topLeft.y = y;

Now, after some more println statements and some name-calling, we found that the topLeft object was null. It simply had not been initialized. Normally, in Java, this would have become apparent the very first time we ran the application, but now it required fifteen minutes of wonder and debugging.

If someone can explain the use of this feature to me, I invite them to leave a comment. On the other hand, I would like to ask the JavaFX people to at least give me a way to turn this off, so I can tell my colleague he made a booboo

–JH

When you are doing your layout by binding the layoutX and layoutY properties of your controls, you may experience a degradation of performance while resizing or scrolling. This will probably not be noticeable with only a handful of controls/shapes on screen. If however you start drawing hundreds of shapes/controls with this method, you will certainly see the slowdown. Let’s see why…

Currently, I am involved in building an application that visualizes railway tracks and train positions on screen. This visualization literally consists of hundreds of lines, circles and triangles. At first we also used binding to perform the layout of these shapes, but eventually scrolling and zooming became very slow.

Eventually, we decided to switch the layout from binding to a Panel‘s onLayout function. This performed a lot better. The reason this performs better lies in the different timings of binding and calls to onLayout.

A bound variable will be updated any time its source variable is updated. If you bind a lot of controls’ layout to the size of a Scene, you will eventually end up with something called bindstorm (term coined by Jim Conners).

The JavaFX platform performs layout functions only periodically, on so-called pulses. All the JavaFX layout container classes have optimizations to perform their layout as efficiently as possible, during these pulses. Because resizing will trigger a new layout on the next pulse, layouting is done less frequently than bind updates, causing these actions to be more smoothly and less cpu-hungry.

We certainly saw an increase in performance when we switched to the onLayout method. However, I may have misinterpreted the cause. If I am wrong about the way these pulses work, I invite someone from the JavaFX team to correct me in a comment.

Now, coming back to the post I referred to in the first section of my rambling, let’s talk about centering controls. Knowing the difference between bind and the way layout containers work, I think it is better to let a highly optimized container handle the centering of your controls. There are a number of different containers you can use for this.

The code sample below is derived from the bind-example, only this time notice the Stack and the LayoutInfo objects, which make sure the Label remains centered.

import javafx.stage.Stage;
import javafx.scene.Scene;
import javafx.scene.text.TextOrigin;
import javafx.scene.text.Font;
import javafx.scene.text.FontWeight;
import javafx.scene.layout.Stack;
import javafx.scene.layout.LayoutInfo;
import javafx.scene.text.Text;
import javafx.geometry.HPos;
import javafx.geometry.VPos;

Stage {
  title: "Centering Nodes"
  var scene: Scene;
  scene: scene = Scene {
    width: 400
    height: 100
    content: Stack {
      layoutInfo: LayoutInfo {
        width: bind scene.width
        height: bind scene.height
      } // end LayoutInfo
      content: Text {
        textOrigin: TextOrigin.TOP
        font : Font.font(null, FontWeight.BOLD, 16)
        content: "Look ma! I centered this text!"
        layoutInfo: LayoutInfo {
          hpos: HPos.CENTER
          vpos: VPos.CENTER
        } // end LayoutInfo
      } // end Text
    } // end Stack
  } // end Scene
} // end Stage

The only binding I used in this example, is the size of the Stack. If the user now resizes the window, binding makes sure the Stack is resized. JavaFX then requests the Stack to redo its layout on the next pulse. Due to the vpos and hpos hints, the Stack knows that this control must be centered. All calculations will then also be handled by the Stack, which takes everything like effects, translations and transforms into account.

Happy layouting!

–JH

If you’re working with JavaFX, you will probably know these two truths:

• The JFXtras library has some really awesome components
• The JavaFX platform is trying out new controls in the preview packages

A good thing about this, is that the JavaFX team is taking the good stuff from the JFXtras library and putting it into the platform. A bad thing about it is you start to expect the preview controls have the same functionality as the JFXtras controls.

I was working with the Grid layout container from the preview packages and ran into a wall. I was trying to make a node have a vspan of 2, and two nodes in the next column, like the image on the right here.

The code I tried, was simple enough:

def s = Stage {
   title: "Grid"
   scene: Scene {
       content: [
            Grid {
                id: "debug"
               rows: [
                   GridRow { cells: [
                       Button { text: "..."
                         layoutInfo: GridLayoutInfo {
                           vspan: 2
                           vfill: true} }
                       Button { text: "..."}
                   ] }
                   GridRow { cells: [
                       Button { text: "..." }
                   ] }
               ]
           }
       ]
   }
}

That should have worked. However, when starting the little test application, the result looked like this:

The vspan does not seem to work as expected. At first I thought I was doing something wrong. Then I tried to switch out the preview Grid with the JFXtras XGrid. Check out the result:

Tadaaa, that was the result I was looking for. As it turns out, the preview container does not handle the vspan attribute correctly. I guess that’s why it’s called a preview .

Another small illustration of the differences. Amy Fowler has an example at JFXtras with the XGrid container. I switched out the XGrid with the normal Grid and got these two results:

Bottom line is: if you need vspan right now, use the XGrid. If you only need hspan, you can safely use the preview container, as long as you keep in mind that it may change in the next JavaFX release.

Cheers!

–JH

Originally posted at Java Competence Network Blog

Line {
  startX: 40
  startY: 40
  endX: 50
  endY: 40
}

Sure, easy peasy. What if you want this Line to move around based on some variable’s value? You could alter the definition so its properties are bound:

var linePosition : Number = 40;

Line {
  startX: 40
  startY: bind linePosition
  endX: 50
  endY: bind linePosition
}

Works like a charm. However, doesn’t this start to feel like a lot of information for just a horizontal line? And what if I alo want to change its x-position? What you can do in JavaFX is actually define a horizontal line, simply define it relative to its origin:

Line {
  endX: 10
}

This makes a horizontal line of 10 pixels long. Now, if you want to move this around, instead of changing its startX, startY, endX and endY properties, use layoutX and layoutY:

Line {
  endX: 10
  layoutX: 40
  layoutY: 40

To me, this reads exactly like what it is: a horizontal line who’s origin is (40, 40). It makes it a lot easier to check whether the Line is in its correct place, if it is the right size, etc.

Same thing goes for vertical and diagonal Lines obviously:

// Vertical
Line {
  endY: 10
}

// Diagonal
Line {
  endX: 10
  endY: 10
}

Happy layouting!

–JH

What happened was that not all Transitions seemed to work. I have not yet been able to determine the root cause of it, but the Transition seemed unable to update properties of its target node. After some frustrated trial and error, I discovered a working solution: put the Transitions in the same file as their target node.

Again, I have not yet found the root cause. If someone can tell me why this is a problem, please let me know. I can’t stand not understanding

–JH

Recently I switched from using Windows and Outlook at work to my brand-spankin’ new MacBook with Apple Mail. The first thing I ran into was getting replies to my emails that my signature was all borked.

After a long search I have finally been able to fix these so they look good in my colleagues’ Outlook. The problem lies with the editor in Apple Mail, somehow it just makes completely borked HTML that Outlook interprets differently.

The good news is that the solution is devilishly simple. Just follow these steps for each signature you want:

• Create the signature in Apple Mail
• Save the signature
• Close Apple Mail
• Open ~/Library/Mail/Signatures
• Open one of the .webarchive files with TextEdit
• Make the signature the way you want it in TextEdit
• Save it and re-open Mail and you’re done!

Cheers!

–JH