22 November 2016

Followup Global Day of Coderetreat 2016

This is an email I sent to all the participants of the recent Global Day of Coderetreat, Vienna. Because it applies to all participants worldwide, I repost it here.

Looking back at the Global Day of Coderetreat 2016
It is a month since you participated in the Global Day of Coderetreat. Let us look back for a moment. At the end of the day, during the final retrospective, you answered the questions
  • What you learned at that day?
  • What surprised you during that day?
  • What you planned to do differently?
Final RetrospectiveSome of you learned "new programming concepts" and that "it can be done in a simpler way". (These quotes were things you wrote on the Post-its on the picture on the right.) Others found new ways "how to split the problem". Several people discovered that pair programming was productive. You were surprised that there were so "many different ways to do the same functionality". But most important you decided to do things differently in the future. Here are some things that you wanted to do:
  • "Try TDD at work!"
  • "Learn more shortcuts!"
  • "Aim for simpler code!"
  • "Code more!"
These were just a few examples for the 21 things you wanted to do differently. Try to remember your personal plan. What did you write on your Post-it? In the last month, did you apply the things you learned? Did you do the thing you wanted to do differently? Did it work for you? We fall back into old patterns easily - changing habits is hard. If your first attempt failed, I encourage you to try again. Do not give up!

A box of things to take from the Coderetreat
At the end of the Coderetreat the facilitators, Houssam and I, talked about things you might want to try after the event. Houssam called it the "Box of things to take home".
  • Code Katas. Code Katas are exercises like the Game of Life. You can find many suitable exercises at codingdojo.org or codekata.com. If you like to crack some math problems I recommend Project Euler. It is a lot of fun!
  • Coding Dojo. A Coding Dojo is an event like a Coderetreat, just shorter. In Vienna there is the Coding Dojo Vienna. If you need for more practise this is the place to go. The dojo happens once a month. To get notified about upcoming events register at Softwerkskammer Gruppe Wien or follow #CodingDojoVie on Twitter. More information about Coding Dojo can be found in Emily Bache's excellent book.
  • Pair Programming. You can run your own practise session in a coffee shop or McDonalds. Talk to people in your company or at local meetups and find some like minded individuals.
  • Screencasts. Recordings of Code Katas, sometimes called Katacasts, are a great source for learning. This way you can (kind of) pair program with famous people like Robert C. Martin, J.B. Rainsberger, Sandro Mancuso and others.
  • For more details on how to improve your skills further, I recommend Houssam's (and Boris Gonnot's) article How to Boost Your Skills to Become a Better Developer.
Craftsmanship Community
Finally I want to point you to the Software Craftsmanship community in general. In Germany, Austria and Switzerland the local Craftsmanship communities are hosted by the Softwerkskammer. There is a group for Vienna and Linz. These communities run yearly conferences, the SoCraTes (Software Craftsmanship and Testing) unconferences. Currently we have SoCraTes conferences in many countries. In Austria the next SoCraTes will be autumn 2017 in Linz.

I wish you all the best for your future. You can do it!

9 September 2016

Mechanical Keyboards

Over the years I developed a love for keyboards. It is not surprising as I used keyboards since 1995 to do my work. I spent countless hours typing and writing. I am not a collector, I own some cheap and a few mechanical keyboards. Each of them has its use. Recently I did some research about them. Here is what I found:

Cherry G81-3000 KeyboardCherry - G81-3000 (DE)
The Cherry G81 does not look special. I did not select it, I just bought it together with one of my early computers. It is a regular 105-key PC German QWERTZ keyboard as used in Austria and Germany. (The 104/105-key layout is like the 101-key keyboard including some special keys to activate common Windows functions.) I bought it in 2000 and it worked well. Two years later - when I killed it by pouring a glass of water into it - I bought another one. It is connected via PS2 plug, which gets rare these days.

Switches: It was cheap and I always believed it to contain rubber domes. But even after buying my first mechanical keyboard I went back to using it. I was used to it and liked the typing experience. Recently I found out why. During cleaning I recognised the typical Cherry MX mounts - could my old Cherry keyboard be a mechanical one after all? The Cherry G81 contains the Cherry MY switch, a semi-mechanical keyboard switch, with a spring in each switch. It is considered something between rubber dome and MX with a life expectancy of 50 million presses, which is the same as of modern MX.

Typing: The Cherry MY have no tactile feedback and actuation happens two third on the way down. The counter force of the spring increases linearly while pressing it, with a peak force of 120 cN. In a way they feel like linear MX switches. (Some people say MY feels like MX-Black but harder. I do not own any MX-Black, but the keys are definitely harder to press than any MX I know, even MX-Clear. The comparison of MX switches states that MX-Black has an actuation of 60 cN, much less than the MY.) There is no click sound, only some slight noise from the key caps. This is the most muted keyboard I know. When I press slowly then there is absolutely no sound at all. None of my other keyboards are that quiet.

The Cherry G81 is heavy because it has a steel plate, like high quality keyboards nowadays. This might explain why I stayed with it for such a long time without looking somewhere else. For the small price of 29 Euro (price in 2002), it is definitely the best keyboard I own.

DasKeyboard Model S Ultimate KeyboardDas Keyboard - Model S Ultimate (III) (DE)
Das Keyboard Model S is a "high-quality mechanical keyboard." I was new to mechanical keyboards - thanks to peer-geek Michael Clay for telling me about them - and had no idea about switches. The Model S was the first high quality mechanical keyboard that I liked which I found on the German market. It was supposed to be cool so I bought it. I even went for the ultimate version with blank key caps, because I wanted to master touch typing.

Switches and typing: The Model S contains gold-plated, mechanical, Cherry MX-Blue switches. They offer the classic mechanical typing experience: There is a tactile feedback halfway down as the key actuates. The noticeable bump lets you know that your key press has been registered. And it is noisy. Really, the MX-Blue clicks noticeably, and can be disruptive in close working conditions. It makes so much noise that it breaks my own thoughts when I type fast, especially as I am used to the super quiet Cherry G81. Due to this noise I am not using it on a daily basis. Maybe I should by it again with other switches.

The Model S comes with an USB hub included, which is very handy to connect a mouse or other devices, especially when working with a different computer almost every day. I love the look of its blank surface. The packaging includes a tiny cloth to wipe it and keep it shiny black. Its blankness makes it perfect to show off your mastery of the keyboard to your peers. Most colleagues are confused (and unable to use it) or amazed. It is definitely useful to improve typing accuracy, and it has improved mine.

TKL Keyboard Bag, courtesy of Michael ClayTKL (Tenkeyless)
Since my Pair Programming Tour and working as freelance Code Cop, I am almost exclusively programming in a pair. When I visit someone to pair with, I bring my own keyboard. I have to carry it, which makes me wish for a small one. I do not like compact or laptop keyboards, because I am really used to regular QWERTZ layout. The answer is TKL - "Tenkeyless". As the name suggests, tenkeyless keyboards are standard full-sized keyboards without a tenkey / number pad on the right side. The number pad contains not ten but 17 keys, making the TKL an 88-key PC German QWERTZ keyboard (if such a thing exists). As the TKL is a standard keyboard I am able to type as usual. The only slight problem is that I am unable to press Ctrl Numpad / which toggles line comments in IntelliJ IDEA. I own a bag for the TKL, courtesy of Michael Clay. When he heard about my planned Code Cop Tour he showed up with four different TKL keyboards so I could chose one. I bow to the master of keyboards.

Diatec Corp Filco Majestouch-2 TKL KeyboardDiatec Corp - Filco Majestouch-2 TKL (DE)
I needed a TKL to put into my backpack. While I could have created one by myself, I bought a Filco Majestouch-2.

Switches and typing: This time I avoided Blue switches and bought the Majestouch with Cherry MX-Brown ones. The Brown switches are one of the most widespread switches today. They are tactile, non-clicky and relatively soft with an actuation force of 45 cN. They are supposed to be silent, still there is some sound from the key caps themselves. When I type fast the plastic key caps make a high pitch noise. Of course the sound is not as nasty as from the Model S, but it is quite noisy for my liking. Fortunately its noise is not a problem during pair programming because there are no extended periods of silent, fast paced typing.

The Filco Majestouch-2 is a basic keyboard, exactly what I need. Maybe it is a bit of an understatement because it looks so very basic. The TKL version is ideal for travelling. I always carry it with me when I am going to pair with an Austrian or German developer during work or Coding Dojo. With the Majestouch I mistype more often. I guess this is because the mechanical switches actuate half way down, while the MY switches register the key around two third of the way. I am just too used to my old Cherry G81.

Cooler Master NovaTouch TKL KeyboardCooler Master - NovaTouch TKL (US)
During my pair programming activities I often work under UK or US layout. I am able to operate the English layout sufficiently well if I see the right labels on the keys. So one TKL is not enough. I took the NovaTouch with (87-key PC) US English QWERTY keyboard layout. It is "exceptionally quiet and suitable for heavy-duty typing or gaming."

Switches: The NovaTouch contains Topre switches with MX compatible key caps which is great if you love custom keys. The Topre switches are semi-mechanical, hybrid capacitive switches "that combine the benefits of a mechanical spring-based switch and an electrostatic capacitive sensor to provide excellent tactility, comfort, and durability. The unique design of these Hybrid Capacitive switches require no physical mechanical coupling, therefore eliminating key switch bounce and chatter for a frictionless experience."

Typing: The Topre switch is similar to the Cherry MX-Brown, a tactile, non-clicky switch. There is the bump halfway down. Compared to the Majestouch-2 the force needed to press the key is slightly higher and the bump seems "bigger" and more articulated. (Actuation is at least as strong as for MX-Clear as used in the CODE keyboard described below.) While the marketing description above describes the keyboard as exceptionally quiet, unfortunately it is not. Like the Majestouch-2, its plastic key caps create some noise when pressed. The NovaTouch ships with a set of o-rings which made it more quiet, but some sound remains, especially when typing fast. At least the noise of the key caps is more low pitched than of the Majestouch-2.

The NovaTouch is a bit bloated because it has some audio and repeat rate adjustment function keys, which I never use. Even worse, the function (Fn) key replaces the menu/right click key. I do use the menu key because I love keyboard navigation and I rely on it to activate functions from context menus that do not have their own keyboard shortcut.

The NovaTouch is despite the missing menu key a very nice keyboard. Its cable is braided and can be removed from the keyboard. It comes with o-rings and and a wire key cap puller to remove the key caps. But the best thing is its box. While all other keyboards ship in a simple cardboard box, the NovaTouch lies in a large, shiny black box, softly bedded on rubber foam. It looks like decoration inside its jewel case. It is marvellous.

I use the NovaTouch when I pair program with someone who uses UK or US layout. I bring it to international Coding Dojos or workshops. It is small enough to fit into my hand luggage when flying. During my Pair Programming Tour I even carried both, the DE and US layout because I never knew which layout my next pairing partner would use.

WASD Keyboards CODE V2B KeyboardWASD Keyboards - CODE V2B (DE)
Despite all these keyboards I was still looking for a keyboard to use every day - as a replacement of my trustworthy Cherry. I did not really need it, but somehow wanted it - the perfect opportunity for a present. For Xmas I ordered a WASD CODE V2B, with 105-key PC German QWERTZ layout. It is a "simple, clean and beautiful mechanical keyboard, a collaboration between WASD Keyboards and Jeff 'Coding Horror' Atwood."

Switches and typing: I selected the CODE because of its switches. The MX-Clear are stiffer than the Brown ones, with a tactile bump and weighting of 65 cN. The harder actuation force is good for me, being used to the Cherry-MY keys, which are still harder to press. The tactile bump feels right. Again the plastic key caps make some noise and the keyboard is louder than the NovaTouch.

Like the Majestouch-2 the CODE is a very basic keyboard, without any label, its black matte surface looks sharp. Like the NovaTouch its cable can be removed and a key cap puller is included. Most important has a series of dip switches which enable the function key, caps lock and different layouts. This is most useful, because I can have my menu key instead of the function key. It also has LED back lighting, which probably is the reason for it to be more expensive than my other keyboards. (The CODE is around 200 Euro where my other keyboards are between 100 and 160 Euro.) There is a slight glitch: when my computer wakes up from power-saving/standby mode, sometimes the keyboard is not activated and I need to disconnect and reconnect the USB cable to activate it, which is annoying. After a few months I got used to the CODE and despite the glitch it is my favourite German keyboard. I enabled LED back lighting and found it quite comfortable because I am working a lot in the evenings.

It is difficult to predict the future. At the moment I like my CODE and it looks like I finally found a keyboard to keep. On the other hand I have not tried all Cherry switches, e.g. MX-Black. Maybe I should get a Cherry MX Switch Pro Sampler to compare them. The sampler looks like a great desk toy to impress and confuse colleagues. At the moment MX-Clear is the stiffest switch available from Cherry, so I might need to look for alternatives. I am curious about the Buckling Spring as used in the original IBM's Model M. People say that this is the best keyboard ever made. I will have to try it one day.

16 August 2016

Absolute Priority Premise, an Example

Optimus Prime, Transformers ToysTransformation Priority Premise
I would like to start this article with Uncle Bob Martin's Transformation Priority Premise - TPP for short - which he defined in 2011. With the premise Uncle Bob gave an algorithm how to find the next test when doing Test Driven Development. During (classic) TDD we use transformations to change the code to get from red to green. For example when starting with a new method the very first test is usually red because the empty or generated method returns null. We fake the first test by changing that null to return a constant value, e.g. return 5. This transformation is called nil->constant and has a high priority. A later test might force us to add a conditional to enable another fake. This transformation is called unconditional->if and has a medium priority. Replacing the value of a variable, i.e. variable->assignment has a low priority.

According to Uncle Bob, these transformations have a preferred ordering. We should prefer higher priority transformations to pass tests and chose tests in a way that they can be passed with higher priority transformations. When an implementation seems to require a low priority transformation, we could backtrack to see if there is another test to pass first which does not need that transformation. The theme behind the TPP is that as the tests get more specific, the code gets more generic. If you want to know more about TPP, see Uncle Bob's cartoon follow-up on the TPP and Sorting and his talk on the Transformation Priority Premise.

Absolute Priority Premise
In 2012 Micah Martin set out to define some heuristics to compare code objectively and proof that some code is better than some other code. Building on the TPP's priorities he defined the Absolute Priority Premise - APP for short. The APP knows six components, i.e. basic building blocks of code, and assigns them a mass. The building blocks and their weights were
  • constant, a value in code has mass of 1.
  • binding, a name or variable has a mass of 1, too.
  • invocation, calling a method or function - mass 2.
  • conditional, any form of if, switch or case - mass 4.
  • loop, for or while loops - mass 5.
  • assignment, replacing the value of a variable - mass 6.
More complex building blocks have a higher mass. The total mass of a piece of code is the sum of the mass of its respective components. A lower value is better. The best set of specific values of mass are unknown and I will use Micah's weights. If you chose to count different, please let us discuss!

A detailed explanation of the Absolute Priority Premise is given in the two presentations of 8th Light University (8LU) - Part One and Part Two. See also Micah's Coin Changer Kata as a complete example of applying the premise.

Measuring the Mass of Code
I like Micah's idea to measure the mass of code. It might not be a direct indication of readability but simpler code is always better. I wrote six different versions of the Word Wrap kata and was wondering which one would be considered the "best". I should have calculated the mass of these algorithms manually, but I followed Terence Parr's advice, to avoid working by hand five days what I can spend five years of my life automating. I had to create a tool to calculate the mass of Java code - which of course took me much longer, especially as I verified the mass of each algorithm manually to make sure my code worked as expected.

Absolute Priority Counter
I created abpricou, the ABsolute PRIority COUnter. It parses Java source and collects its mass as defined by the Absolute Priority Premise. It is written in Python, because it was Python month when I started working on it. It uses the Python Java Parser plyj. plyj offers a Visitor API for parser events,
class CountingVisitor(m.Visitor):
    def __init__(self):
        super(CountingVisitor, self).__init__()
Constants and bindings are staight forward, e.g.
    def visit_Literal(self, literal):
        return self._a_constant_value()

    def visit_FormalParameter(self, parameter):
        return self._a_name()
Literals in the code are counted as constants and parameters are only names for values, thus bindings. A method or function counts as a constant for the code it represents and a binding for its name.
    def visit_MethodDeclaration(self, declaration):
        return self._code_is_a_constant()
Invocations, conditionals and loops are the same. For example
    def visit_MethodInvocation(self, invocation):
        return self._an_invocation()

    def visit_IfThenElse(self, conditional):
        return self._a_conditional()

    def visit_While(self, loop):
        return self._a_loop()
The only interesting case is the assignment. Not every assignment in Java is counted as an assignment, only re-assignments which modify values are counted. final fields or local variables are just names for expressions similar to parameters.
    def visit_Assignment(self, assignment):
        if ... :
            # code to ignore
            # final field is assigned in constructor
            # final local is assigned in block
            return self._an_assignment()
View the complete source of the Absolute Priority Counter on Bitbucket.

Let's see some code: Word Wrap Kata
As I said before, I developed the counter to calculate the mass of my different implementations of Word Wrap. I was interested in the mass of the algorithm and skipped constructs like class definitions. (I suppose a class definition is a constant for the code and a binding for the name.) I also ignored Annotations, Enumerations and Generics. The first algorithm uses recursion to loop over the blanks to find the end of each line. Its code is
   final char BLANK = ' ';
   final char NEWLINE = '\n';

   String wrapRecursive(String line, int maxLineLen) {
      if (line.length() <= maxLineLen) {
         return line;

      int indexOfBlank = line.lastIndexOf(BLANK, maxLineLen);
      int split;
      int offset;
      if (indexOfBlank > -1) {
         split = indexOfBlank;
         offset = 1;
      } else {
         split = maxLineLen;
         offset = 0;
      return line.substring(0, split) + NEWLINE
           + wrap(line.substring(split + offset), maxLineLen);
including the components
| Component   | Mass  | Count |
| constant    |   1   |   7   |
| binding     |   1   |   8   |
| invocation  |   3   |  10   |
| conditional |   4   |   2   |
| loop        |   5   |   0   |
| assignment  |   6   |   0   |
resulting in a total mass of 53. Further implementations have the following masses:Scales
  • The tail recursive solution has neither loops nor assignments similar to the recursive one and has a total mass of 71. (The source of this and all further variants is given in Word Wrap Kata Variants.)
  • The looping variant contains a loop and an assignment resulting in a mass of 68.
  • The optimised loop which avoids temporary String objects, contains a loop and an assignment and some more invocations. Its mass is 80.
  • The loop using a buffer saves even more heap allocations and needs more invocations summing up to 105.
  • The solution using Regular Expressions as shown in the original article has a mass of 55. Merging the parts of the expression into a single expression would save five invocations, but makes the expression less readable. I argue that the Regular Expression itself has some weight, as it contains one conditional ("|" in line 3) and two loops ("(.{1," + maxLineLen + "})" in lines 1 and 4). So a fair weight is 69.
  • The functional version using flatMap and reduce is quite verbose due the lack of inferred pair types in Java. As plyj does not support Java 8 I was unable to measure its mass.
First Conclusion on Algorithms
The most basic, recursive version of Word Wrap has the least weight. What does it mean? Is it the best version? It is the most compact version without playing Code golf, at least in Java. It does not mutate any variables but it puts the highest load on the Garbage Collector. All the discussed algorithms have different memory and run time performance characteristics. I had hoped for a clear answer what the best version would be and I am not seeing that. I challenge you to leave a comment with a version of Word Wrap with a smaller weight. Would it be considered better code?

The mass of the basic loop version seems too much compared to the recursive version. The current weights favour functional programming by putting a penalty on loops and assignments. Mutating a local variable has a smaller weight than mutating the state of an object. The looping version uses StringBuilder instead of plain String + which needs two more invocations for its construction. Then its components are
| Component        | Mass  | Count |
| constant         |   1   |   8   |
| binding          |   1   |  10   |
| local assignment |   1   |   3   | like a new local binding
| invocation       |   3   |  10   |
| conditional      |   4   |   1   |
| loop             |   5   |   1   |
| assignment       |   6   |   0   |
and its mass is 60 which is a bit more code than the recursive solution.

More Structure
The different wrap() functions above are just algorithms. They are not factored into parts that might change at different speeds over time and definitely violate the SRP. They also break the OCP as it is impossible to change the strategy of splitting without touching the logic of collecting. To address this I wrote another recursive version following Tell, don't ask,
interface Page {
   void renderLine(String lineOfProperLength);

class Wrapper {

   final char BLANK = ' ';

   final Page page;
   final int maxLineLen;

   Wrapper(Page page, int maxLineLen) {
      this.page = page;
      this.maxLineLen = maxLineLen;

   void wrap(String line) {
      if (line.length() <= maxLineLen) {

      int indexOfBlank = line.lastIndexOf(BLANK, maxLineLen);
      int split;
      int offset;
      if (indexOfBlank > -1) {
         split = indexOfBlank;
         offset = 1;
      } else {
         split = maxLineLen;
         offset = 0;

      page.renderLine(line.substring(0, split));
      wrap(line.substring(split + offset));
which is very similar to the tail recursive solution above, with a total weight of 56. The number is smaller because it does not contain the necessary implementation of Page.renderLine(). The shown code does less, which makes it difficult to compare. On the other hand Page.renderLine() might be used by other parts of the code as well, so it is not strictly a part of Word Wrap.

Moar Structure!1!!
Later I created an extremely factored and decomposed implementation of Word Wrap that separated concepts of rendering, splitting, accumulating lines and hyphenation rules which should fulfil both SRP and OCP. Ignoring the HyphenationRule because that is not covered by the other solutions, its mass is 167 due to many method invocations and parameter names:
| Component   | Mass  | Count |
| constant    |   1   |  17   |
| binding     |   1   |  33   |
| invocation  |   3   |  30   |
| conditional |   4   |   4   |
| loop        |   5   |   1   |
| assignment  |   6   |   1   |
There is a loop and an assignment, at its core this implementation is a looping one. Using the recursive solution I should be able to get rid of the loop and the assignment.

The Absolute Priority Premise counts the different components of a program and sums their weights. If the weights are correct than the program with the smallest mass would be considered the "best" program. This is not true for algorithms like the Word Wrap because the APP ignores features like memory usage or performance optimisation. For general purpose code the validity of the APP is unclear. It just measures the number of code constructs, favouring more compact, functional code. On the other hand the four rules of simple design encourage us to introduce explaining variables to reveal the intent of the code which is more important than fewer elements.