Lach- und Sachgeschichten vom Baumarkt

Heute mit Bauhaus! Alle anderen Namen sind frei erfunden.

Vor ein paar Tagen kaufte ich beim Bauhaus um die Ecke eine Sackkarre. Eine solche hatte sich beim Umzug als sehr wertvoll erwiesen, da damit schwere Geräte wie der Kühlschrank wesentlich leichter zu transportieren sind. Da bei uns endlich die Küchenmontage anstand und wir unsere temporären Geräte (Kühlschrank, Spülmaschine) ausräumen mussten, schien eine Sackkarre eine sinnvolle Investition.

Als wir dann heute den Kühlschrank raus rollten, fiel auf, dass einer der Reifen platt war. Das machte die Sackkarre deutlich weniger nützlich, da sie mehr am schleifen als am rollen war. Da ich ohnehin noch ein paar Sachen besorgen wollte, beschloß ich kurzerhand, nochmal zu Bauhaus zu fahren, um dort die Reifen aufpumpen zu lassen.

Da ich nicht mal wieder mit der Sackkarre durch den riesigen Laden laufen wollte, fuhr ich direkt in die “Drive-In Arena” hinein – dort hatte ich die Sackkarre ursprünglich gefunden. Im Verkauf, ein beheizter, abgetrennter Raum innerhalb der sonst eiskalten “Arena”, fand ich Erwin, dem ich nach etwas Warten den Sachverhalt erklären konnte. Der delegierte das Aufpumpen dann an seinen Kollegen Anton, der sich der Sache annahm. Nachdem ich meinen PKW etwas weniger blockierend geparkt hatte, fand ich Anton mit der Sackkarre und einer mit Kompressor betriebenen Pumpe. Einen Moment später war er auch schon fertig und ich kehrte zum Wagen zurück. An der Kasse konnte ich schließlich erklären, dass ich das Gerät schon vorher gekauft hatte und nichts zu bezahlen habe. Nach Kontrolle des Kofferraums durfte ich dann auch wieder raus.

Nachdem ich die anderen Einkäufe erledigt hatte, rollte ich die Sackkarre wieder in die Wohnung und stellte sie erstmal zur Seite. Es gab noch einiges umzuräumen, bevor wir die Spülmaschine abmontieren und ebenfalls rausrollen könnten. Währenddessen gab es plötzlich einen sehr lauten Knall. Eine Tasche, die neben der Sackkarre lag, war sogar kurz in Bewegung. Nach einer Inspektion stellte sich schnell raus: Der linke Reifen war geplatzt! Wenn dieser auch ohne Belastung platzen konnte, hatte Anton offensichtlich zu viel Druck auf den Reifen gegeben.

Also fuhr ich zurück zu Bauhaus: Wieder in die Arena, wieder parken, wieder zum Verkauf, wieder warten, wieder Erwin den Sachverhalt erklären. Seine erste Erwiderung, ungefähr: “Du hättest die Reifen ja selber aufpumpen können!”. Zum Glück brachte mich das nicht aus der Fassung, stattdessen erwiderte ich nur, dass es ja wohl nicht meine Schuld ist, wenn ein Mitarbeiter die Reifen mit zu viel Druck befüllt.

An dieser Stelle hätte die Geschichte zu Ende sein können: Defekte Ware ersetzen, fertig. Aber nein, eine solche Exekutiv-Entscheidung konnte Erwin unmöglich treffen, stattdessen musste er erstmal telefonieren. Beschluss: Kunde (mich) zur Eisenwaren-Abteilung schicken, dort passenden Reifen suchen lassen, damit zurückkommen und den geplatzten Reifen austauschen. Aus im Nachhinein nicht nachvollziehbaren Gründen habe ich es mitgemacht. Auf dem langen Weg (~5 Minuten Gehweg) beschloss ich, direkt dort zur Information zu gehen, da selber suchen in den riesigen Regalen ziemlich sinnlos ist.

An der Eisenwaren-Information war aber niemand, noch auf den anliegenden Gängen. Die Dame an der Selbstbedienungskasse daneben konnte mir lediglich sagen, man sei unterbesetzt und ich müsste in anderen Abteilungen oder an der Information fragen. Vorige Besuche hatten mir bereits gezeigt, das Abteilungs-fremde Mitarbeiter keine Ahnung haben, also suchte ich selber und fand irgendwann tatsächlich den Abschnitt mit einigen Reifen. Einige Minuten später entschied ich mich dann für einen Reifen, der zwar die passenden Maße, aber nicht denselben maximalen Druck (2 vs 2,5 bar) hatte. Damit machte ich mich dann auf den langen Rückweg…

Dort angekommen, entschloss Erwin immerhin, einen anderen Kunden erstmal warten zu lassen, und sich direkt mit meinem Fall zu beschäftigen. Zunächst machte er noch einen halbherzigen Versuch, das Thema loszuwerden (“Können Sie den Reifen selber wechseln?”). Mangels Werkzeug und Ahnung lehnte ich das ab. Mit einem winzigen Schraubenzieher bekam er die Kappe nicht ab, mit einem etwas größeren und viel Mühe löste er sich aber schließlich. Damit ließ sich dann der platte Reifen ab- und der neue aufziehen. Doch dann zeigte sich: Das passt nicht. Die Felge hatte die falsche Form, die Achse war so zu kurz und die Kappe passte auch nicht mehr.

An dieser Stelle hätte die Geschichte ebenfalls zu Ende sein können: Ersatz geben, fertig. Aber nein, Erwin überzeugte mich, doch nochmal zur Eisenwaren-Abteilung zurück zu kehren, und dort jemand zu finden, der den passenden Reifen ausfindig machen kann. Wie ihm auch diese Überzeugungsarbeit gelang, ist mir im Nachhinein völlig unklar. Ich machte mich also wieder auf den Weg, diesmal mit dem kaputten sowie dem unpassenden Reifen. Immerhin ohne die restliche Karre, die lehnte noch im Verkauf an einem Stapel Eimer.

Mir war schnell klar, das es die korrekten Reifen nicht gab, aber immerhin fand ich diesmal einen Verkäufer, der gerade einen anderen Kunden mit irgendwelchen Schrauben beriet. Also platzierte ich mich direkt neben ihm, um als nächstes dran zu sein. Als es soweit war, konnte ich dann Franz das Problem schildern. Auch Franz sah schnell ein, das er den richtigen Reifen nicht da hatte, aber ihm fiel eine Lösung ein: Schlauch austauschen! Ging aber auch nicht, da die passenden Schläuche nicht vorhanden waren. Da ich befürchtete, mit leeren Händen wieder zurück zu kehren, bekniete ich Franz, mich nicht im Stich zu lassen. Nachdem einem kurzen Telefonat mit Erwin beschloss er, mit mir mitzukommen, um von einer der anderen Sackkarren einen Reifen abzumontieren, und diesen an meine dran zu packen. Franz zeigte hier nicht nur Eigeninitiative, sondern auch etwas Vorrausicht: Er packte direkt passendes Werkzeug ein.

Nach ein paar weiteren Gehminuten in die allerletzte Arena-Ecke und etwas mehr Hebelei machten wir uns auf den Weg zurück zum Verkauf. An der Ecke fiel Franz dann auf, das dort allerhand Reifen gestapelt waren, inkl. dem passenden für meine Sackkarre. In der Arena! Und mich schickt man ganz woanders in! Franz grummelte etwas eher Unflätiges…

Als wir dann den Verkaufsraum betraten, wunderte ich mich, wieso sowohl der Stapel Eimer als auch die Sackkarre am Boden lagen. Die Karre hatte ja nur noch einen Reifen, bei einer näheren Untersuchung stellte sich raus: Jetzt war auch der andere platt! Der musste in meiner Abwesenheit geplatzt sein, und hatte dabei den Stapel Eimer mitgerissen. Erstaunlicherweise (oder auch nicht) ignorierte mich Erwin jetzt komplett. Auch Anton sagte kein Wort, obwohl zumindest einer von beiden den Knall mitbekommen haben musste.

Auch hier zeigte Franz wieder seine kompetente Seite und traf endlich die lange überfällige Entscheidung: “Holen Sie sich einfach einen Ersatz.”

Als ich dann damit nochmal in den Verkaufsraum zurück kehrte, wurde ich weiterhin ignoriert. Franz war inzwischen verschwunden. Nach einer Minute beschloss ich dann, die Karre wieder ins Auto zu packen und damit wieder zum Ausgang, respektive Kasse, zu fahren. Nach einer weiteren Kofferraum-Inspektion und der Erklärung, das ich jetzt Ersatz hätte, durfte ich dann auch wieder fahren…

Implementing HTTP/2 push in Java

This is another guest post by my friend Tobi. —Jörn

The story:

Some months ago I started to play around with HTTP/2 and wondered what should get better with this piece of technology, where are the limitations and pitfalls. So I first went to Wikipedia and read the Wikipedia article about HTTP/2 and the RFC 7540 standard. I was quite impressed about the idea to reduce the latency of web pages.

Because I am familiar with JEE development I just had a look at how to integrate this technology in an existing JEE application and read about PushBuilder API. Cool – a Java API which handles to push resources before the actual response is submitted to the client. I thought this sounds good and build up my first application with it.

First I tried to configure tomcat with SSL and HTTP/2, but I failed sadly as you can read within this mailing list topic Apache Tomcat 9.0.0-M4 and http/2 on Mac OS X 10.11.4 (If you have any hints what I did wrong please let me know!). Then I tried it by configure a Jetty Servlet Container which was a great straight forward implementation as you can see in this Sample.

Ok the first implementation was made.

Then I had a look into the console of my browser and saw the resources are pushed all the time and I thought this might cause a big impact on the network traffic which outweighs the latency benefit. So I posted a question at stackoverflow about “Jetty respond with status 200 instead of 304 while using http2” and happily Martin Grigorov (Tomcat Committer) and Simone Bordet (Jetty core developer) helped me within this question and a corresponding issue ticket jetty.project issues 801 to understand that it is up to the developer when a resource should be pushed and when the browser should use the cache. One sentence I want to quote: “I think there is a misunderstanding of what the push APIs do. Right now, they just push.”

By consolidating those new information I came up with a new Implementation for Apache Wicket to handle HTTP/2 push very easily. You can find the implementation in the corresponding PushHeaderItem class in the wicket git repository

Here are some facts / pitfalls that you should consider when using HTTP/2 push:

  1. Think about when should resources be pushed and when it makes more sense to get them out of the browser cache with a minor “overhead request” – depending on this you have to build up your own implementation
  2. Some browsers like Chrome do not cache resources if the SSL cert is self signed – consider this if you check the caching behavior of your implementation
  3. Try to implement your push API docile so that the browser can also use HTTP/1 and get the resources in a normal way as fallback
  4. You can check the push behavior of your implementation / example application. Chrome example: chrome://net-internals/#http2

Conclusion:

When using HTTP/2 and PushBuilder API you have to think about a lot of marginal conditions like Caching, SSL implementations, traffic impact to find a good solution that does exactly what you want.

Release: Validation Plugin 1.15.1

I’m happy to announce the first patch release for the jQuery Validation plugin 1.15.x series.

11 people helped out to add a few enhancements and fix some bugs. Kudos to all of you, namely: adhayward, Bill Sorensen, Brahim Arkni, Hugo, Huseyn, Jordan Clark, Markus Staab, Michael Hohlovich, svrx, TLib and Torgny Bjers.

This is another release which would not have been possible without the help of Brahim Arkni. Thanks again for your support!

For a full list of all the changes, check out the changelog below.

Download this release.

If you use the plugin, please donate or ask your boss to make a donation! This helps to run the plugin site and makes releases like this one possible.

Click here to lend your support to: jQuery Validation Plugin and make a donation at www.pledgie.com!

  • Please post questions to the official Using jQuery Plugins Forum, tagging your question with (at least) “validate”. Keep your question short and succinct and provide code; a testpage makes it much more likely that you get an useful answer in no time.
  • Please post bug reports and other contributions (enhancements, features, e.g. new validation methods) to the GitHub issue tracker

The full changelog:

Additional

  • Fix multiple mime-type validation
  • IBAN require at least 5 chars (Closes #1797, Fixes #1674)
  • Correct notEqualTo jQuery reference

Core

  • Added failing test for #1805
  • Fix group validation with 3 and more fields
  • Fix regressions introduced in #1644 and #1657 (Closes #1800)
  • Update step validation to handle floating points correctly
  • Fix error when calling $.fn.rules() on a non-form element
  • Call errorPlacement in validator scope
  • Fixed issue with contenteditable elements in forms where events for single input validation would cause exceptions

Demo

  • Add links to Bootstrap and Semantic-UI demos to index.html
  • Use .on() instead of .validateDelegate()

Localization

  • Added Azeri language

Tests

  • Added regression unit tests for PR #1760

Computer science research ideas

Every now and then I get emails from researchers (often students), asking me to participate in their particular study. Sometimes I participate, sometimes I don’t, often I’m thinking: Couldn’t you ask me what you should be researching in the first place? While that is an inappropriate response for these emails, I wanted to write down my ideas for researchers, in public, so that they can either find them on their own or I can at least ps-link to them.

Since I’ve been doing mostly JavaScript development in the last few years, with about 80% of that in the browser, my perspective is mostly from that platform. Though I expect that most of these ideas can be applied to other platforms as well.

If you have ideas that would fit in this list, let me know.

Testing tools

How can better testing tools help write better software? This area seems to have so much untapped potential. Most open source testing tools are developed and improved in very small increments, the “this feature would be with this usecase”, but its rare to find features that make big leaps. While I still haven’t used it, Intern is an interesting tool, because it integrates all kinds of frontend testing usecases into a single suite, and usually integration, especially if we think of it as fusion, can set free extra energy.

One example of a feature in a testing tool that is rather unlikely to happen in regular open source development scenarios is the reordering feature in QUnit. Its not a well known feature, since its behaviour is rather subtle. It might also not be as useful as I’m thinking it is, since I haven’t been able to do any research to verify that. But I think its an interesting example anyway. And since I came up with it (more or less) and implemented it, I can tell you how it happened.

Some years ago, I was listening to a podcast, with Kent Beck, one of the original authors of JUnit, as a guest. He was talking about a project he had been working on for some time, called JUnit MAX. It was a plugin for the Eclipse IDE, providing a better test runner. One significant feature of this plugin was its reordering of tests after previous runs. Kent was talking about how research showed that the odds of a failing test failing again on the next run are much higher then for a passing test to start failing. So for shorter feedback loops, it makes sense to run tests, that previously failed, first on the next run. JUnit MAX would also consider the time it takes for various tests to run, and run the fastest failing tests before the slower failing tests.

After hearing that, I figured that I could implement a subset of that feature in QUnit, reordering test runs, based on previous failures (ignoring the secondary sort on runtime). While it required some rather complicated changes to make the queue flexible enough for the reorder and maintaining the original output order, the result was a faster feedback loop with no additional effort needed by the developer using QUnit. The only time this failed was when tests weren’t atomic, that is, test B relied on test A running first. Non-atomic tests are a significant code smell by themselves, and in way this feature helped uncovering them. In the end, it still required an option to turn the reordering feature off.

I’m optimistic that there are plenty ways to write better testing tools, and academic research could provide ideas and do verification of those ideas.

Error messages

“undefined is not a function” is a terrible error message, but its not even the worst you’d ever run into when writing JavaScript for browsers. “Script error” without a stacktrace definitely is worse, but hopefully not occuring anymore.

Elm is known for spectacularly good error messages, almost obsessively improving the compiler, even with a separate repository collecting “broken Elm programs / data to improve error messages.

I’d love to see a researcher doing some ground work like this for JavaScript, collecting errors across browsers and serverside runtimes, and at least filing issues to improve these messages.

Bug reporting

Consider these two scenarios.

Scenario A: You get an email with the subject “the site doesn’t work”, and no body. You don’t even know which site this refers to.

Scenario B: You get an entry in your issue tracking system, with some descriptive fields, but most importantly, a link. You click that link, which brings you to your app, along with some debugging tool. One element of that tool is a slider that lets you go back in time. It also shows you various relevant variable. Going back in time you can see what interactions the user did before running into the issue they reported. You can quickly identify the issue based on the steps and the state of the system.

Now, which of these two would you prefer if you get paid for solving issues (not so much for spending time on solving them)? Scenario B supposedly is also something Elm provides (or at least helps with). But I don’t see why other platforms shouldn’t be able to provide at least partial support for that kind of error reporting and debugging.

Code Review

If a code review finds no issues, does it mean that the reviewer didn’t bother looking too much? Or that there are no issues? How can you review the reviewer? Are there metrics or tools that could help become better at reviewing? A reviewer that points out a lot of style issues might never catch actual bugs. A reviewer who always ignores styles issues might have a hard time catching bugs due to style issues.

This seems like an area with a lot of untapped potential, but its hard to tell without some research.

Working remote

Collaborating within a team can vary a lot by physical difference, from pair-programming at the same desk, to being on different sides of the planet in wide apart timezones. There are a lot of options in-between those two extremes. Martin Fowler does a great job of explaining the various options and some of their strengths and weaknesses in Remote versus Co-located Work

There isn’t a simple dichotomy of remote versus co-located work, instead there are several patterns of distribution for teams each of which has different trade-offs and effective techniques suitable for them. While it’s impossible to determine conclusive evidence, my sense is that most groups are more productive working in a co-located manner. But you can build a more productive team by using a distributed working model, because it gives you access to a wider talent pool.

In my experience, once you’ve built a team where everyone can work remotely, you get the benefits of that model even if parts of your team are (sometimes) together in one room. For example, assuming a core team of 5 people shares an office. Every other week one of those people needs to work from home, to take care of family, dealing with home repairs, or one of many other reasons. Usually these activities don’t need an entire day off (and they’re not real vacation!), so being able to work from home just as effectively as in the office makes this much less of an issue.

That said, how to actually build an effective non-co-located team has no clear answers. There are various technical solutions that I found working quite well, but I’ve never done any research to evaluate the ones I’m using or studying alternatives. Coming up with a list of options and ways to evaluate them seems like an interesting research topic to me. Only some of this is specific to software development. For example, communication tools that can properly format and highlight code snippets or error logs are more specific for developers.

History

All of the above have changed over time, and the bug reporting scenario B I described above has supposedly been possible with Smalltalk years (decades?) ago. I suspect that there’s a lot of history to study in software development even in just the last 10 years. From a historian’s perspective, the whole industry might be too young to study effectively, but that shouldn’t prevent studying trends like “best practices” in architecture, tools, project management, design, or any of the topics mentioned above. A good example is the Born for it article on martinfowler.com, looking at “How the image of software developers came about”.

A big thank you to Enes Fazli for reviewing drafts of this article.