Skip to content

Midnight in Moscow

(joint work with Tobias Stadelmaier)

This is the story of a bug involving an arch enemy of all software developers: the time zone.

But let’s start at the beginning. Our editorial front end application deadlocked, but only under Window and only with Internet Explorer or with very old Firefoxes and only in a very specific time zone: UTC+03:00 Moscow (RTZ 2).

The culprit was ultimately found to be the DateTimePropertyField of Ext JS. When initializing such a field, Ext JS tries to prefill the combo box that lets users pick the time in 15-minute steps, advancing a JavaScript Date object using the method Date.add. The date is advanced until it reaches a maximum value (23.59 pm). Now, when you want to do that, you must choose a day for the Date object, which in the case of ExtJS is hardcoded to January 1st, 2008. And everything works like a charm.

Unless Date.add does something wrong. Looking into the Ext JS implementation of Date.add, we see that it simply sets a new minute value and trusts the Date object to normalize itself. For the very special time zone UTC+03:00 Moscow (RTZ 2) mentioned above, it does not. You can check it easily if you put your Windows 7 into the right time zone, open the JavaScript console of an IE 9 and type:

new Date(2008,0,1,23,60,0)

You get:

Date {Tue Jan 01 2008 23:00:00 GMT+0300 (Russia TZ 2 Standard Time)}

Ok, so I lied. The DateTimePropertyField is not the bad guy. The problem should really be blamed on the calendar arithmetic that comes with Windows and/or the browsers.

The fix is simple: Get ExtJs to use a different date for doing the time computations. For example by having this line:

Ext.form.TimeField.prototype.initDate = ‘2/2/2008′

executed as early as possible in the startup sequence. This fixes Ext JS 3.4. Feel free to add hacks for other Ext JS versions in comments.

But what is so bad about January the 1st, 2008? Other dates seem to work nicely, other years too. But there are other bad days: 1/1/2013, for example. Or January the 1st of 1901, 1907, 1918, 1924, 1929, 1935, 1946, 1952, 1957, 1963, 1974, 1980, 1985, 1991, or 2002. The common pattern? All of these days are the first days of the year and … Tuesdays.

So don’t worry about Mondays. It’s the Tuesdays that will come after you in the dark, cold, and stormy nights of the deepest winter.

Speed Up Your UX Work: Tables in OmniGraffle 6

OmniGraffle 6 comes with a new feature called Tables. If you use OmniGraffle for wireframing or creating mockups, this feature might come in handy whenever you want to graffle any sort of tabular data. A tabular view on data is a common requirement for enterprise software. Another use case would be the creation of repeating patterns. In Axure, these use-cases are realized using a Repeater Widget, but it is hard to find a similar function in OmniGraffle. Here’s how it works.

Creating a Shape

You can’t create an empty table in OmniGraffle. Instead, you start out with a shape and make a table out of it.

Making a Table

Use cmd+shift+t or Arrange→Make table. You can create a table out of more than one shape at a time but they will huddle together and change their sizes. Now you’ve got your table, but the only thing that changed are the little table handles on the edges of your table.

Creating Columns

To create more cells, drag the handles away from the table. Here, I’ve dragged the right handle to the right to append a new column.

Resizing Columns

You can resize individual cells. If there were more rows below, they would be resized as well.

Adding Another Row

Before we add content, let’s add another row.

Adding Text

To add text, simply double click on a table cell. Adding and formatting text works the same as in any other shape. In editing mode, you can step through the cells with tab and shift+tab.

Adding Shapes

To add images, stencils or grouped shapes, paste them into a table cell as you would paste text. This handy but little known feature works on all shapes, not only tables.

Copying Rows

Drag the bottom handle of the table to copy the bottom row. This will help you quickly create large table views.

Resizing Table

Our table didn’t quite fit the window. Let’s resize it! This is where tables really shine. Also, the borders are not necessary so I just set the stroke property to “No Stroke” for the whole table at once.

Column Header

I have moved the column header to the middle. Uncheck the “Wrap to Shape”-checkbox on the type inspector to make the text flow into the adjacent cell.

All done!

And there we have it, a complete mockup. As you might have noticed, I’ve added some bells and whistles along the way, like different background colors for some rows. Tables make these things very easy.

Note that there are new menu entries under EditTables.

Also note that tables are actually fleshed out groups. In fact, you can ungroup a table at any time using cmd+shift+u. This is probably the reason why so many features that we know from other table-supporting software is missing in OmniGraffle. For instance, there is no way of reordering rows or columns.

Tips and Tricks

The tables-feature is not flawless. I’ve come across some issues and shortcomings. Here are my top 3 grievances and workarounds:

  1. Creating a table „post hoc“
    You can make a table out of multiple shapes but not grouped of items. This can stump you when you have drawn something that includes stencils and think „Great, now I need that 10 times in a row!“ Experienced grafflers will reach for the stamp tool and miss out on the handy table features. Table enthusiasts, however, will have to create a new table from scratch.
  2. Icon support
    Icons or other stencils are usually grouped shapes. Because groups can’t be made into a table it is somewhat awkward to include icons in your table. A novice may resort to arranging icons over the table but as soon as the table needs to be resized or moved, all the icons have to be moved as well. This is no way of living and robs us of one of the key advantages of tables. OmniGraffle has a little known feature though that makes tables support icons after all: text fields can contain shapes. Simply paste the icons (or any shape, really) into the cells in editing mode and you’re golden. I have shown this in the steps above. Be aware that the shapes can’t be changed anymore once they’re pasted. Positioning them correctly can become tedious. One solution is to give them their own column. That way, you can at least position them using the type inspector.
    This workaround is not without problems though. Oftentimes, the cell margins will change unpredictably. When that happens, try to edit a neighboring cell (i. e., add a random character, leave the cell, remove the random character). This can make the offending cell snap back to normal. Also, sometimes shapes will appear to be cut off at the edges. I have not yet found a satisfying way to repair that. Try emptying the cell and pasting the shape again.
  3. Cell management
    The OmniGroup people have been careful to avoid feature creep. They have left out a way to create single cells. This wouldn’t be so bad had they not included a way to delete single cells. My advice would therefore be: never ever delete single cells unless you really mean it. The only way to get them back is through cmd+z or ungrouping, repairing and remaking the table. Instead, empty the cells in editing mode.

Down in the Jungle Room


For last week’s coding dojo at CoreMedia, I prepared a small exercise on concurrent programming. As a rule, it is a bad idea to write concurrency algorithms like a lock or a thread pool yourself. Get a proven library and use it! So the exercise had to deal with a more realistic problem: apply some changes to legacy code that is supposed to be concurrency-proof.
The given source code simulated – in the most elementary form – a company that organizes safaris. The original source code that was presented to the participants can be found here:

The task was to fix scalability issues in the code. The exact extend of the scalability issues was not mentioned, which initially did not seem to disconcert anyone. It was allowed to change the code in any way. It was pointed out that the developer of the existing code was no longer with the company.

The participants decided to try mob programming for this task. This led to very interesting discussions and provided me with a natural way to drop the occasional comment on possible alternate solutions. See for details on mob programming.

If you want to do this exercise in your dojo, it is a good idea to have someone with experience in concurrent programming attend the dojo, so that bad solutions can be spotted and hints can be given.

Spoiler alert: The remainder of this text contains hints that might lessen the experience of solving the problem oneself.

The code was sprinkled with various style issues and small inconsistencies that were supposed to serve as warm-up exercises and as distractions during the actual programming.

However, the participants ignored the small issues, hardly looking at the code. Instead, they headed straight to the test class, which actually seemed to test relevant aspects of the program. Of course it didn’t. It took some time until all of the blunders in the (green) tests were discovered and the tests were rewritten. It became quite obvious how existing code, even code that one should be suspicious of, can be accepted at face value.

After much test writing, some risen eyebrows, and finally a debugging session, it became clear why the code did not scale: nearly every method was synchronized. After removing the central synchronization point, which allowed exactly one safari at any given time, the program immediately ran into a deadlock. It was designed that way, of course, but the surprising takeaway was that you can get deadlocks by removing locks.

Only now did the participants look more closely at the entire set of classes. The code was a jungle of interrelated code that exhibited a highly interwoven call structure. Of course, this is bad news for concurrency requirements. Furthermore, the code suggested that this is really a thoroughly chosen architecture that closely matches the application domain. Thoroughly chosen, yes, but …

At this point, some approaches were considered and it was decided to reduce the potential for deadlock by removing those locks that were provably not necessary, because they protected immutable data or data that was accessed in one thread, only. The participants were very careful in this phase, avoiding a trap that would have led to an inconsistent object graph when synchronizing too little. I was quite proud of them.

When all was done, we talked a little about the result of the refactorings and about general approaches to deadlock avoidance.

It was a lot of fun to do this exercise. It turned out to contain the right amount to trickery, so that a robust solution was found before time was up. If there had been more time, code cleanup and further testing would surely have been possible.

CoreMedia Photowalk

Some photo enthusiasts at CoreMedia  formed a photowalk group that is called „Boring Photos Questionmark“. The question mark stands for “no-boring photos at all”! Some of our results are published on our group page in Flickr.
During our photowalk we do not snap everything. We have special topics which we try to express by images. For me it’s very interesting to see how my colleagues look at the perspectives, their methods, their techniques and their final results. Together we learn different camera movement techniques such as panning shot, where you rotate the camera on its horizontal/vertical/diagonal axis in order to keep a moving object in view while the rest of the scene is blurred. For the night photography we use the time exposure made by leaving the shutter open a relatively long time. The moving elements such as the lights of cars for example become drawing lines while the rest of the scene stays sharp.

Even without a camera we spend our time with knowledge sharing sessions such as Lightroom functions or portrait photography. For the next walk we are planning to visit the very interesting photography exhibition “100 years of Leica”.

Beside that, our photowalks are a special social event with lots of fun, where we share our experiences, skill improvements and knowledge.


Pandora Cart: Creating a Sprint Timeline

In a recent retrospective I wanted to dissect the sprint day by day. The books recommend drawing a timeline, adding events to it, and then maybe drawing a satisfaction graph for every team member across the whole thing. This always felt time-consuming and tedious to me.

Enter Gamification

When in doubt, make a game of it, I thought. So here is Pandora Cart. The name is a mix of the team name and the console game that inspired me.

1. Preparation

The team coach sets up a course of n x 3,5 numbered playing fields (just use index cards), where n = sprint length in days. Include field 0 as “start”.

Also, the coach creates a large number of event cards, about 5cm x 5cm. Half of them shows the picture of a banana, the others show a mushroom. There is plenty of space on the cards to make notes. A sensible number is m x 6 cards, where m = team size.

Finally, a game progress marker is required, preferrably a toy car approximating the shape of a cart; plus a D6 (regular 6-sided dice).

2. Game Setup

The team coach lays out the course on a table in numerical order.

Team members are asked to remember the sprint and all events that helped or hindered the team or the individual colleague. For each helping event, the team member takes a mushroom card and jots down a short summary of the event. For each hindering event, the team member writes a note on a banana card. Include the day of the sprint it occurred.

When setup is finished, we have

  • the course, i.e., the numbered fields, on the table
  • the cart sits on field zero/start
  • each team member has a stack of banana and mushroom event cards in front of them
  • the D6 lies on the table

3. The Rounds

There are n rounds in the game, representing the days in the sprint. For each round:

  1. One of the team members rolls the die and advances the cart by the according number of fields.
  2. All team members play event cards for the round, i.e., they describe the event and place the card on the table:
    • Whenever a mushroom is played, the cart advances by one field.
    • Whenever a banana is played, the cart moves back to the previous field.
  3. Take care to lay out the cards for each round in one separate row.

4. Game End

The game ends after the last round no matter what. No player should have any event cards in their hands any more. All event cards are on the table in n rows, the rows ordered by rounds (days). This display of event cards is your timeline of the sprint!

This image from a running game shows day four in a bad shape, while day six collected many mushrooms. The cart track is partly shown in a circle around the timeline, by the way, the cart is on field 18 at the lower right.


Now that you have gathered the data, you can move on to the “generate insights” stage of your retrospective.


The final field of the cart could be a point of discussion, but chance will heavily impact the result. Also, it does not matter at all where the cart ends up. Throwing dice is just there for the fun of it.

It is probably best to play this game for sprint lengths up to ten working days. For longer sprints and more rounds the game might become boring.

About the length of the course: The cart should, on average, advance by 3,5 fields per round. If, for every sprint day, you expect one more banana than mushrooms, you’ll end up at 2,5 fields per round on average,and can shorten the track accordingly. Maybe you even need negative fields if the first day of the sprint was a real mess …


How a flat-design approach and shadows go together

written by Nils Morich and Kris Lohmann


In the past weeks, the UX team at CoreMedia has been working on a new design approach towards the editorial interface for our CMS. This interface is a rich-web client called the CoreMedia Studio. The original design from 2009 was based on gradients and rounded corners – These elements feel a little outdated, 5 years later and in the time of Google’s Material design, Apple finally going flat, and Windows 8.

In this article, we discuss thoughts on flat design and how to apply it without falling into common traps (for such traps, see this post by NormanNielsen Group).

Reduce to the Max

Consequently, in our new design, gradients disappeared and transparency is history. Inspired by the references mentioned above, which became very popular with the release of Windows 8, we decided to pick up that trend and iterate our design approach. For example, the new approach manifests in the design of the icons used in the studio. No borders, no gradients, not more than just one color. The basic principles are driven by a flat-design approach. They are vector-based, which makes them future-proof for high-resolution displays that are more and more used. The following image exemplifies the old and the new look of the icons.


CoreMedia Icons

Old Icons (Sample)


New CoreMedia Icons

New Icons (Sample)


Visual Cues

So what is this shadow-thing all about? What are shadows used for and why is it important to us to know? There are two occasions when shadows become important:

  1. When the source and the direction of light is important
  2. When the position of elements on the z-axis is important

For a usual software project, the source of light is nothing that concern. However, the position of several objects in the z-axis is an important cue to the user. It makes the hierarchy or special highlighting of elements visible. Especially once there is a focus on elements such as windows, shadows can be very useful for that purpose. Have a look at the next pictures. The first window comes with a shadow and the second window without a shadow. The first window gives the user the feeling that the window is only loosely connected to the ground. Users have the impression that they can physically interact with the element – which is called an affordance in UX design.


CoreMedia Library with Shadow

With Shadow


CoreMedia Library Without Shadow

Without Shadow

A flat design in its most consequential application gets rid of shadows and other elements that are a first glance solely for decoration. However, looking carefully at it, there is a functionality assigned to some of these graphical elements. In the physical world, elements still interact in a three-dimensional space with each other. The understanding of these interaction is a basis for our understanding of the world. Nobody is surprised by the fact that things tend fall to earth (OK, some do): The laws of physics are deeply integrated in our cognition and are, as such, processed with cognitive ease.

An example makes this evident. The following pictures show a dropdown many used in the CoreMedia Studio. On the first picture there is a blurry shadow around the persona chooser. On the second picture, the same element is shown without any shadow applied. As you can see, it is much easier to distinguish the activated element from the rest of the studio. Without a shadow, things will get more complicated, and they will get worse when several elements happen to overlap each other.

UI Element with Shadow

UI Element with Shadow

UI Element without Shadow

UI Element without Shadow

Shadows Help Understanding a User Interface

But is this really necessary? Why is it so important to visualize the position of an element within three-dimensional space? In fact we still mostly run software on devices with flat screens (Monitors, cell phones, tablets, …). So do shadows not just add visual clutter to a user interface?
Futhermore, there are other popular examples, that do not make use of shadows. Consider Comic-Movies like Southpark. There are neither body-shadows (shadows that appear on the objects caused by light) nor object-shadows (shadows that are caused by objects on the environment). So why does this work? In this case it is a movie, so we have the additional dimension of movement and animation that helps the viewer process the visual content.
In a user interface for software, which is in contrast to the movie interactive, the user is much more reliant on the affordances of objects. Hence, using shadows to induce affordances into objects by imitating physical interactions is not necessary.

Seeking Inspiration

What do others do? Let’s have a look at the Google’s material design: The philosophy is to stay close to the physical world and convert the behavior of physics (light, mass, material,…) to a flat-design. Google manages the shadow-topic in a very strict way:


There is a range of five different states of depth (Depth 1 is very close to the ground – Depth 5 is far away from the ground). As you can see, the shadow gets bigger and more blurry the greater the distance is between object and ground. Depending on their depth-level an object overlaps or is overlapped by other elements (i.e. an object with a depth-level of 3 covers all objects of depth-level 1 and 2, but is covered by all objects of depth-level 4 and 5). Elements which are supposed to match the same high as the ground are considered “Depth 0”.

Our Solution

We created several variants of adapting the behavior of shadows. We came to the result that three levels of depth dealing with shadows would be enough for our software products.
The shadows are constructed as follows:

CoreMedia Shadow Construction

CoreMedia Shadow Construction

The pictures below show two examples of how the new shadows look, applied to the CoreMedia Studio. You see a component called dashboard with widgets on it in the first picture. In the second picture, an opened free-floating window is shown. The widgets have depth level 1; the window has depth level 3.

Example for Shadows with Depth Level 1

Example for Shadows with Depth Level 1

Example for a Shadow with Depth Level 3

Example for a Shadow with Depth Level 3


Minimalistic design such as flat design eliminates unnecessary visual clutter from a user interface. Carefully applied, it results in a clean look and feel. Still, the elimination of some visual elements is risky. As exemplified by shadows, some visual elements provide cues that allow the user to better and easier understand what is going on. In particular, it allows the designer to inform the user on relations between objects and on potential interactions with these objects.
Visual elements such as shadows carry information that is processed by the user of the interface. Carefully applied, such elements can and should augment a minimalistic design approach.

JUnit-@RunWith: SpringJUnit4ClassRunner vs. Parameterized

If you like Spring but you also like data-driven-testing (DDT) you will soon run into a problem: both approaches require to define a runner with @RunWith – but JUnit only allows one runner for one test class.

A blog post by Konrad ‘ktoso’ Malawski actually points to a very interesting approach which is to copy the test-initialization behavior of the SpringJUnit4ClassRunner: @RunWith JUnit4 with BOTH SpringJUnit4ClassRunner and Parameterized.

The solution provided by Konrad uses @Before to set up the TestContextManager which is also used by SpringJUnit4ClassRunner. He actually misses to also respect the other life cycle phases of a test:

  • before test class
  • before test method
  • after test method
  • after test class

To solve these issues you can extend calls to the TestContextManager to @BeforeClass, @AfterClass and @After. But to have a reusable pattern we placed the solution into a JUnit Rule. Because it needs to run in test class and test method mode there is a slight quirk: You have to use the rule as @ClassRule as well as @Rule.

Usage in test:

public static final SpringAware SPRING_AWARE = 
public TestRule springAwareMethod =

Having this you can configure your test nearly just as if you have a SpringJUnit4Runner (with ContextConfiguration and such) despite some exceptions. The following annotations are not interpreted:

There might be more differences – just as always with any copy & paste approach.

Find the rule and a small example test as GitHub Repository.

Autowiring of @Required spring bean properties

Spring 2.0 introduced @Required, Spring 2.5 added @Autowired and Spring 3.0 added even more annotation driven configuration capabilities by introducing @Configuration and added support for JSR 330 annotations. So given a legacy bean of type A whose properties are annotated with @Required we might want to derive a more modern-style spring bean using @Named and @Inject. The problem now is that we can’t simply extend class A like that:

public class B extends A {

By default, springs RequiredAnnotationBeanPostProcessor would raise an exception when processing the bean named "fail". So we should either think about using delegation instead of inheritance – thus using two separately defined beans like outlined below:

public class B {
    @Inject private A a;

If we can’t resort to delegation for some reason, the following configuration class can solve our problem:

@Configuration public class TestConfiguration {

  @Inject private ConfigurableListableBeanFactory beanFactory;

  @Bean(autowire = Autowire.BY_TYPE)
  public BeanWithAutowiredProperties beanWithAutowiredProperties() {
    AutowiredAnnotationBeanPostProcessor autowiredAnnotationBeanPostProcessor = new AutowiredAnnotationBeanPostProcessor();
    BeanWithAutowiredProperties beanWithAutowiredProperties = new BeanWithAutowiredProperties();
    return beanWithAutowiredProperties;

  @Bean public BeanWithAutowiredProperties fail(){
    return new BeanWithAutowiredProperties();

  @Named public static class A {  }

  @Named public static class B {  }

  public static class LegacyBean {

    private A a;

    public A getA() {
      return a;

    @Required public void setA(A a) {
      this.a = a;

  public static class BeanWithAutowiredProperties extends LegacyBean {

    private B b;

    public B getB() {
      return b;

    public void setB(B b) {
      this.b = b;

    @PostConstruct void initialize(){
      if(null == getA()) {
        throw new IllegalStateException("required property must not be null");
      if(null == b) {
        throw new IllegalStateException("autowired must not be null");


Note that we’re using a local bean post processor so that the spring lifecycle for other beans is not affected.

Each Voice Enriches Us

Each voice enriches us. – G’Kar, Babylon 5

On today’s Diversity Day (German) I want to share a story with you.

One of our software engineers is hearing-impaired and needs to read people’s lips in order to fully understand what they are saying. The Daily Scrum in front of the taskboard can sometimes be challenging. People point at tasks and at the same time talk about what has changed, then they wave about in the general direction of “done” and mention something that got done, and then ask whether that thing with the build pipeline has occurred again, while pointing towards the seven tasks in “to do” from five feet’s distance away. It can be quite hard at times to match the conversation to an actual card on the board.


Image So our colleague asked whether we could introduce a pointer device to the Daily Scrum and hand it about. Now, each speaker in the Daily Scrum takes the laser pointer, highlights the task they are talking about, and then passes the laser pointer on to the next guy.

Then the person who initially felt the need for a laser pointer due to impaired hearing went on vacation — and the team kept using the pointer. They admitted that highlighting the tasks helped them all to structure the discussion and to not get lost. Image

There are a few more very similar examples. Behavior modifications were triggered on behalf of only one person with a disability and then turned out to improve communication for everybody.

The point to drive home is this: What seems like an extra effort and cost factor, serving only people with uncommon needs, can actually be beneficial to everybody. The position of a minority can be the crucial difference that makes a difference.

(PS: The title of this article is a quote from the Declaration of Principles.)


My internship at Coremedia

In the course of 8th grade, one is supposed to do an internship. I am very interested in programming and also coded on my own before, so I wanted to find out how this works out in large companies and if it fits my interests and the image I had.
Eventually, I was taken in by Coremedia’s Product Center.
As good as this sounds, I originally searched for a spot at one of Hamburg’s numerous companies producing games. However, none of them were eager to take inexperienced trainees, so I decided to publish a blog post addressing anyone working in the IT business in search for an internship. Martti was the one who answered and took me in along with another applicant.
Over the course of two weeks, we were introduced into the teams and not only did we learn about their work, we also got our own task, closely related to their work which gave us a very detailed insight into programming with HTML and JavaScript.
The employees received us in a very friendly and open manner and were eager to help if needed. We were treated as coworkers and Martti used a lot of time to help and coach us in the process of coding our application.
It was great to be at Coremedia AG, as a trainee I learned a lot about the used IT languages and the overall work ethic. At the same time as being very informative and funny, it was still exhausting at times, especially when we were stuck with a task. To conclude, as this was supposed to help us in determining whether working in this industry fits our interests, we definitely think that it helped to be here at Coremedia AG. I can imagine myself working on IT in the future.


Get every new post delivered to your Inbox.

Join 276 other followers