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?

Some 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!

Using Hamcrest Matchers With Composer

To help my friends of the Vienna PHP User Group to get started with Coding Dojos, I created a project template. Obviously the used programming language was PHP and PHPUnit, the PHP xUnit implementation, was required.

Composer
Setting up a new project almost always starts with dependency management and I used Composer to define my dependencies. Composer was configured by its composer.json,

{
  "name": "codecop/CodingDojo-PHP",
  "description": "Coding Dojo template",
  "license": "BSD",
  "require": {
  },
  "require-dev": {
    "phpunit/phpunit": "4.5.*"
  }
}

After verifying my composer installation with composer --version I downloaded PHPUnit with composer install. PHPUnit and its transitive dependencies were installed into the vendor directory as expected.

PHPUnit
Next I configured PHPUnit with its phpunit.xml,

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.5/phpunit.xsd"
    backupGlobals="false"
    colors="true"
    beStrictAboutTestsThatDoNotTestAnything="true"
    beStrictAboutOutputDuringTests="true"
    beStrictAboutTestSize="true"
    beStrictAboutTodoAnnotatedTests="true"
    verbose="true">

    <testsuites>
        <testsuite name="All Tests">
            <directory suffix="Test.php">test</directory>
        </testsuite>
    </testsuites>
</phpunit>

This told PHPUnit to load all the *Test.php files inside the test directory for test classes. I especially like the beStrictAbout* flags and enabled them all. These flags warn about smelly tests, e.g. test methods without any assertions. I ran PHPUnit with ./vendor/bin/phpunit to verify my setup. It did not show any tests - after all this was a new and empty project. I have seen people creating an alias to run PHPUnit, but I created a (Windows) script phpunit.bat in the local directory with the same effect,

@call "%~dp0vendor\bin\phpunit" %*

Now I was ready to go and wrote some unit tests, e.g.

<?php

require 'Hello.php';

class HelloTest extends \PHPUnit_Framework_TestCase {

    /** @test */
    function shouldReturnHelloName() {
        $greeter = new Greeter();
        $this->assertEquals("Hello Peter", $greeter->greet("Peter"));
    }

}

Hamcrest Matchers
In the Java community Hamcrest Matchers are popular and they even ship with the core JUnit framework. I like Hamcrest because it allows me to write my own matchers, which make assertions much more expressive than plain assertEquals. Luckily there were some ports of it and I was happy to see a Hamcrest PHP port. I added it to composer.json,

"require-dev": {
  "phpunit/phpunit": "4.5.*",
  "hamcrest/hamcrest-php": "1.2.*"
}

and updated my installation with composer install. Hamcrest offers global functions for its matchers, which allow for shorter syntax, especially when matchers are chained together. To enable this global functions, Composer has to auto load the main Hamcrest file, which is configured using autoload-dev in composer.json,

"autoload-dev": {
  "files": ["vendor/hamcrest/hamcrest-php/hamcrest/Hamcrest.php"]
}

Using global functions has some drawbacks and is considered a bad practise in large scale projects. There are different ways to use Hamcrest PHP with Composer without loading the global functions, e.g. see Hamcrest PHP issues at GitHub. For a first time Coding Dojo I wanted to stay with the simplest way to use Hamcrest and kept the global functions.

So I was able to write my unit tests using Hamcrest matchers, e.g.

<?php

require 'Hello.php';

class HelloTest extends \PHPUnit_Framework_TestCase {

    /** @test */
    function shouldReturnHelloName() {
        $greeter = new Greeter();
        assertThat($greeter->greet("Peter"), equalTo("Hello Peter"));
    }

}

While the test above succeeded, PHPUnit refused to show me a green bar. This was because Hamcrest's assertThat was not recognised as assertion and PHPUnit marked the test as erroneous. With a heavy heart I had to remove one of PHPUnit's beStrictAbout flags,

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="http://schema.phpunit.de/4.5/phpunit.xsd"
    backupGlobals="false"
    colors="true"
    beStrictAboutTestsThatDoNotTestAnything="false"
    beStrictAboutOutputDuringTests="true"
    beStrictAboutTestSize="true"
    beStrictAboutTodoAnnotatedTests="true"
    verbose="true">

That was it. Finally I was ready to rock, matchers included!

(The complete project as zip is here.)

The 13th and Final Week

The 13th week of my Pair Programming tour started a bit uncertain. I had not been able to finish the arrangement with the company I had planned to visit. I had got positive replies from my contact there that his team was interested and that he would ask the HR department for final approval. And then there was only silence ;-) Additionally winter came to Austria and the temperature fell by ten degrees just over night. I was exhausted and thought about quitting the tour prematurely.

But then, in the beginning of the week, the first FirefoxOS DevTreff meetup in Austria took place and I met some really enthusiastic hackers who immediately agreed to host me. So I went on with my tour for another week. First I visited a development team to run some in-house training. Besides the usual Coding Dojo we wanted to try something different this time. We started refactoring some nasty piece of production code Randori-style. It was really interesting to see the whole team communicating, e.g. the architect was surprised to see certain patterns in the class we worked on. Everybody was engaged and I wanted to encourage everybody to contribute so I abandoned the Randori-dojo protocol and the session turned into Mob Programming. It was fascinating. In the end the team agreed to use this style of working for our next session as well.

Déjà vu
Then I visited Jürgen Cito in his office at the University of Technology, Vienna. I had a strong sensation of Déjà vu because many years ago, I had roamed these very same rooms in the beginning of my own studies. Jürgen told me about his master thesis about Statistical Methods in Managing Web Performance. It looked great and I am looking forward to the finished work. He had finished his research and was just wrapping things up so there was little we could work on. Instead Jürgen told me about an idea he had for some time and so we created Sinatramania. Sinatramania compares (or rather will compare) the different frameworks based on the Ruby Framework Sinatra by implementing the same simple REST API in the different programming languages and frameworks. We created a Cucumber test suite and started with the Sinatra reference implementation. It was much fun and I will definitely send him some pull requests as soon as things settle down. If you use one framework inspired by Sinatra, e.g. Flask, Laravel, Ratpack or Scalatra, then I encourage you to add your implementation to Sinatramania.

Tying up loose ends
I started my tour visiting the Vienna Ruby Community, presenting them my idea of Journeyman Tour. Back then the leaders of the group had invited me to run a Coding Dojo but it had taken almost three months to find a suitable date while I was busy on tour. Finally I came back to deliver the promised Ruby Coding Dojo. We worked on the String Calculator Kata, a perfect exercise for a first time Dojo. We had excellent discussions and I particularly liked Ben's question if three powerful Ruby functions like split, map and reduce might be too much to squeeze into a single line of code. Yes, with great power comes great responsibility ;-)


Friday I visited an old friend. His line manager had agreed to my visit but he had not bothered to ask for full, official approval up the hierarchy. So I cannot name him nor his employer. Nevertheless it was a great day. In the morning we discussed TDD and integration tests. Then we created a new Maven plugin, test first of course. I proposed to create a guiding test, which we built using the Maven Invoker Plugin. It took us half of a day to get the guiding test ready, because asserting the proper behaviour of our plugin under test was tricky. I learned a lot and Maven Invoker looked like a good alternative for the Maven Plugin Testing Tools, especially when considering the problems I had with them. Using the guiding test, further development was smooth and we would have finished the plugin on the second day. I was really sad that we only had one day to work on it.

This is the end my only friend, the end
As the title of this blog post implied, this was the last week of my tour and it ends my diary. You ask me why? You say that my tour sounds like some serious fun and I should go on forever. Actually I cannot. First I need a break. Second I ran out of companies. I wrote earlier that it took me roughly a man-month (160 hours) to find the 16 companies that hosted me and during my tour I did not have time to look for new hosts. Further I had planned my tour to last for three months and it had been exactly three months. Finally I need to go back to work and earn some money again. Although lunch was free, I spent a lot of money on commuting. Although my tour has ended, I still have many things I want to share. I will discuss what I have learned in upcoming posts, so stay tuned.

A Dozen Weeks

Gilded Rose, again
In the 12th week of my Software Craftsmanship tour I ran an in-house Coding Dojo for a team that wanted to improve their unit testing skills. After an introduction what constitutes (and what does not) a good unit test I wanted them to practice. Understanding the concept of unit tests and using the corresponding testing framework was no big deal, but applying all the principles in practice was harder than it looked. I asked them to write the Test Cases for the Gilded Rose Kata, an exercise designed by Emily Bache. Since I participated in Emily's session during this year's XP conference in Vienna, I just love this kata. Although creating test cases for a small piece of logic might seem trivial, there is so much one can learn here. I had run the same kata during one of my Dojos at Agile Testing Days before and got a lot of positive feedback. If you got curious about the kata, it is described in full detail in Emily's excellent Coding Dojo Handbook.

Quality important is. Fight for it you must ;-)
Next I visited Gregor Riegler. I had not known Gregor before my tour, but his blog Be a Better Developer had attracted my attention. I really liked its subtitle "Quality important is". When I studied his blog I noticed that he was from Austria, even Vienna. I immediately sent him an email and Gregor was interested in my tour right away. Although it looked like we would not be able to pair, he managed to get approval from his management in the end. I spent three days in the office of EBCONT enterprise technologies, in the 34th floor of the Millennium City and enjoyed the view.

Gregor called himself a Restifarian and so we rightfully worked on a REST API for his current project. The Spring Web-MVC powered REST resources would just display data from the database, and first it looked that there would be no particular logic to put into the resource controllers. But we needed links to related resources, the so called hypertext. We had great discussions how to create and add these links to the response in a DRY way without messing up the domain model which we wanted to stay independent of any technology. I liked our session very much and learned a lot both about REST and learning in general. Thank you Gregor!

November is DemoCamp Time
Since the very first Eclipse DemoCamp in Vienna, November 30th 2009, we kept up the tradition of organizing an Eclipse DemoCamp twice a year. So Friday afternoon was demo time. For the ninth time the Vienna Eclipse enthusiasts met to see all the cool technology being built by the Eclipse community. There were great presentations by Tom Schindl, Gunnar Wagenknecht and Benjamin Cabé as well as some local people. The closing presentation was Flo's famous demo remote controlling Sharky. It was a pleasant event and socialising continued till late night. You should definitely attend our next DemoCamp in June. To keep updated about it, follow us on Twitter: @edcvienna. (Please note that the Twitter handle was changed recently.)

CodeCopTour Weeks 8 and 9

Today ends the tenth week of my Software Craftsmanship tour. I visited several companies, paired with many developers and discussed with even more people about our craft. My memories are blurry, there is just too much to keep track of. Fortunately I use a large notebook to collect thoughts and findings during my tour and it helps me to continue my diary about the recent weeks of my tour. As I need to catch up with three weeks by now, this one is going to be brief.

Week 8
I started the eighth week of my tour visiting Codeship, a Vienna based startup offering hosted Continuous Integration and Continuous Deployment solutions for many technologies and hosting platforms. Together with Codeship's development lead Clemens Helm I worked on a feature deep inside the Codeship's Ruby on Rails core. Clemens, of "Testing Tuesday" fame, created a guiding test with Cucumber and then switched to RSpec unit tests for the details. It was a great pairing experience despite that my Ruby skills have degraded considerably causing me to slow down Clemens a bit. Between pairing I joined the Codeship team playing some rounds of tabletop football and improved my skills there as well ;-)

Then I spent three days at Irian, a Java Enterprise consultancy famous for co-founding the Apache MyFaces project. I worked with Jan Zarnikov on a new application in TypeScript. TypeScript, the new open source language from Microsoft, was designed for application-scale JavaScript development and compiles to plain JavaScript. I had never heard of it (it was just created last year) and Jan was concerned if I would be able to work with it. But I had no problems and we made good progress. Jan had prepared all the details in advance and we were just banging out the first version of a touch enabled learning game, driving the whole development by tests. It was awesome! Typescript looked cool and was easy to work with, just the development environment and infrastructure (outside of Visual Studio) needs to catch up.

Dojo Week 9
The following Monday I facilitated an in-house Code Retreat for two development teams. Although there were only ten participants, the final retrospective showed many learnings, which was proof for me that the Code Retreat was useful for them. I want to point out how great this Vienna based company is. Running Code Retreats as part of developer education is awesome and I only know a few companies that do things like that.

The rest of the week I attended the Agile Testing Days 2013, an annual European conference. I had been invited by the organizers to run the Coding Dojos each afternoon of the conference. I chose three different katas for the Dojos to keep things interesting. I started with Refactoring the Tennis Kata, a kata designed by Emily Bache. The provided source code of scoring a Tennis game was awful but had a comprehensive suite of automated tests which allowed the participants to focus entirely on refactoring. All seats were taken and we had a great Dojo with good discussions in the end. The following day I helped the participants to Design Test Cases for the Gilded Rose Kata, originally made up by Terry Hughes and modified by Emily Bache. The prepared code base contained some (spaghetti-) business logic but no tests. The participants were asked to add test cases. Again we had a great Dojo with good discussions in the end. For the third Dojo I had prepared the exercise of TDD as if you meant it, as proposed by Keith Braithwaite. I considered it a difficult exercise and the participants were struggling with the concept in the beginning. After some time they made progress and even skipped the break to enjoy pair programming for additional 25 minutes. Obviously they meant it ;-)

I did not pair program with anybody during this week, but learned many new things in the conference sessions and taught a few things to the participants of the Coding Dojos. I had great discussions in the evenings with like minded people and made some new friends as well. Food was provided at the conference venue and travel cost was refunded by the conference organizers. All these facts come pretty close to the requirements for my Journeyman Tour ;-)

CodeCopTour Weeks 4 and 5

Today The day I started writing this post was the first day since more than five weeks that I did not schedule any pairing session. Somehow the day stayed blank in my calendar. Still it was a busy day. I spent more than four hours on emails, preparing stuff for our upcoming Eclipse DemoCamp and in the evening I attended an user group meeting. There was just enough time to squeeze in a blog post about the last two weeks, the fourth and fifth week of my CodeCopTour. Both weeks I visited a larger IT service provider. As I tweeted earlier this company wanted to stay anonymous for reasons I will explain later, so lets just name it Reynholm Industries. When planning my tour I had aimed for sessions of two or three days with each host but the management of Reynholm had invited me for two full weeks to visit several teams and pair with different people. I agreed and they had prepared for my visit three months in advance, at least that was what I thought.

Legal Issues
Obviously Reynholm was large enough to employ one or more legal advisers and they were afraid. I would work for Reynholm for two weeks and would not get any money. Nobody would believe that, so Reynholm might be accused of employing me without paying taxes. Austria has mandatory social insurance and its institution is lacking money and tracking down all possible cases of black market work to collect their share of the salary. In the morning after I arrived I was brought to the legal adviser and he told me that we had to cancel my visit. After preparing my visit for three months he had started his work one day before the deadline, my arrival. I was not amused and in no mood to drive back two hours with my business here unfinished. It took us half a day to work something out. In the end I signed a contract, accepting the responsibility to pay taxes for my income as necessary and I paid for the hotel and food myself. The fee of the contract was exactly the amount of money Reynholm had planned for my expenses, which was pretty accurate. I hope that in the end I will get back all the money I spent. Working on a contract and spending all income on expenses also does not sound reasonable, and I hope I will not get in trouble with the tax office.

First Code Retreat in Graz
Being in the area of Graz I used the opportunity to meet with my friend Wolfgang Kaufmann. Before I arrived I had talked to him about running a Code Retreat in Graz and he immediately agreed. He brought in some of his colleagues to help us organize and even talked his employer INFONOVA into sponsoring the coffee and lunch during the event. The local university FH Campus02 let us use one of its lecture rooms and we were ready to get started.

After morning coffee I introduced the participants to the idea of Code Retreat and we started practising TDD, pair programming and object orientation.

During the first session almost all teams used arrays of integers or boolean flags so I chose No Naked Primitives as constraint for the second session. During that session only one pair worked on the business rules and all others created only infrastructure, so I proposed to focus on the domain in the next session. Lunch was great, we had wine and beer, several main dishes, even cheese and sweets. It was luxuriant - thank you INFONOVA. (I know I already mentioned them, but the lunch was really awesome, so one extra link will not hurt. Did I mention that they are looking for all kind of developers, just check out their web site ;-)

After lunch we had a session of Ping Pong Mute, which was really fun. One participant complained that he could not go for a design he wanted to try because his pair would not understand it without long explanations. I liked the idea of measuring a design by its simplicity - by its ability to be understood without much discussion. Probably his idea did not follow the KISS principle. After another round I asked the audience what they would like to work on in their last session and Wolfgang proposed No Conditionals. Although this is one of the more difficult exercises they came up with great solutions using nested maps or state machines.

It was a very nice Code Retreat. The 15 participants were a good mixture of junior and senior developers, Scrum Masters and even one Product Owner who wanted to know what "his" developers do in their personal time ;-) People learned a lot, many of them had their first contact with TDD and pair programming in practice. Several decided to give TDD a try in their daily work. Thanks to our awesome sponsors INFONOVA and Campus02 we had everything we needed and the attending developers used the opportunity and made it a great event. Thank you all!

Second Week
In the second week I continued my journey through different teams at Reynholm and paired with different people for a day. All developers I met were friendly and open and I had a lot of interesting discussions. I already knew many people from the previous week and kept meeting known faces in the hallways and during lunch. At the end of the second week I felt like I had been with Reynholm for a long time and I even felt a bit sad I had to go away now because the people were so awesome. Thank you Alexander, Andreas, Andreas, Bernhard, Harald, Karl, Martin, Peter, Robert, Sabine, Stefan, Tom and Wolfgang. I will miss you.

CodeCopTour Week 3

I was waiting for the legal advisor of TechTalk to review the five lines I wrote about my visit at their office the week before, which caused some delay in my blogging queue, but now I am back on track and will continue with week number three of my tour. I started the week with going to the country-side of Lower Austria. While driving I reflected about my tour (and I already published my thoughts here). Markus Schinerl had invited me to stay at his house for three days. Markus runs a small company called sdguide.org which is specialized in calculating metrics like the carbon footprint for factories in the pulp and paper industry. Pulp and paper is a very competitive industry and customers like governments demand the highest environment-conserving certificates from their paper providers. Sdguide's office was located in an old house and due to old age and structural damage it was under construction and looked terrible, see the image on the right side. Some windows were broken and we worked on a raw, wooden construction resembling a table. However we had a powerful computer, two keyboards and two huge screens - no problem there ;-)

Spreadsheet Monstrosities
Markus used a gigantic spreadsheet to enter all parameters needed for such a calculation. It contained roughly 200 input parameters and 500 metrics for up to 50 product parts resulting in huge files with thousand of lines. Obviously Excel was reaching its limits and he needed something more powerful. We spent the first day discussing the domain of carbon footprint and created a small diagram defining the core elements of his calculations. Although we did not write any code it was a productive day because I helped Markus to reflect on his needs and he explained the requirement to me at the same time. We came to the shared conclusion that he needed a real database, but one that he might be able to develop himself, so we ended with Visual Basic (for Applications aka VBA) and MS Access. Although I did not fancy VBA it was the best choice for his needs and he liked the idea that he would be able to use parts of our VBA code in his spreadsheets as well.

Markus had used VBA some years ago and I had never worked with it before. It took us half of a day googling and reading StackOverflow until we got fluent and then we flew. VBA does not offer much and I missed a lot like unit testing, collection classes, closures and much more, still we made good progress. At the end of the second day, actually the very end of the day - it was 10pm, we had built full end-to-end functionality. Of course it was not finished and only calculated one simple formula of one metric for one product part without considering scenarios, different years or different customers. Still it showed the way. I had aimed for that because we needed to know if the chosen design would work. It looked good. During the third day we added more features Markus wanted to investigate, we even created an infix math parser to evaluate arbitrary formulas. It was great and I learned a lot.

Being Brutal
Back in Vienna I helped a small team of developers to improve their refactoring skills. The developers liked practice and I chose Adrian Bolboaca's Brutal Refactoring Game. I had participated in Adrian's session during XP2013 earlier this year and had liked it a lot. It is a programming challenge focusing on refactoring. The brutal part is that each code smell needs to be refactored right now, regardless how small it is. This makes an excellent exercise to train developers in spotting code smells and refactoring them. Adrian lists 17 code smells as the base of the game and I asked the team to prepare short presentations about each of them. At the beginning of the session the developers presented the material to the audience. I just love when trainees teach themselves ;-) During the sessions I collected all the smells I had flagged. Half of them was about naming, i.e. "name not from domain" and "name not revealing intent" which did not surprise me because naming is a difficult problem. Further 30% were "Primitive Obsession" and "lack of tests", common problems in most code bases. One participant was disappointed that he did not hit each of the 17 smells at some point during the game - maybe I will add some game like achievements for completionists like him.

Even for a small group it was demanding to watch out for the smallest code smell in several evolving code bases at the same time. I noticed that pairs kept hitting the same smells again and again. Besides naming, which all participants had to deal with, one pair was "obsessed with primitives" several times, whereas another team had trouble writing tests to cover their design ideas. A fast typing pair, two developers who knew their IDEs well, created a lot of code, but as soon as I found a smell they were unable to remove it by refactoring and had to delete the new code and start over. Although I was as brutal as possible and challenged the participants a lot, I got positive feedback after the exercise and all participants learned something.

The Java User Groups of Austria
For the rest of the week I went "on tour" with the Java Klassentreffen 2013. The Klassentreffen is a series of events organized by the Austrian Java training company Ciit and sponsored by Oracle. It is a mixture of sales pitches and technical presentations, covering various aspects of Java. Technically the Klassentreffen did not meet my requirements for the pair programming tour, but the organizers had invited me to speak and food was provided. Together with Martin Ahrer, the founder of the eJUG Austria, I introduced the audience to Java and Java related user groups in Austria. I started my talk with the reasons to attend user groups, then covered the core groups of Java, Eclipse, Android and Scala and finished the presentation with Open Source, Software Craftsmanship and upcoming Code Retreats. (For details and links please open the slides.) Later the leaders of several groups told me about new registrations, so I guess my presentation was a full success.

CodeCopTour Week 2

Culture Shock
My second week's journey brought me to the highest towers of Vienna (see picture on the right). After previous week's startups this felt different. Paul Rohorzka had invited me to join him for two days. I had not known Paul before but had seen his name on the manifesto. Later when I met him in person during a Code Retreat I told him about my tour and he immediately agreed to pair with me. Working for a regular company TechTalk he had to get permission for my visit which took some time to figure out but finally he managed.

In the morning Paul surprised me with a list of several things he wanted to work on. On his current assignment he worked alone and lacked potential reviewers and therefore wanted several pieces of his code discussed. He had prepared his expectations, work packages and a list of verification "milestones" for these two days. After previous' week marathon coding sessions I felt like using Pomodoros and his work packages were sized small enough to fit into Pomodoros which we kept doing both days.

On the first day we worked on improving the readability of his specs. He used SpecFlow, a BDD testing tool for .NET, which worked just fine. I am generally disappointed by .NET tooling, but I was positively surprised how nice SpecFlow worked, just like you would expect it to work. Although we did not finish the work on the specs, Paul wanted to work on something else the second day, to get as much coverage of his work as possible. We dived into test infrastructure and reworked the part for creating test data. Its core class really needed some refactoring and we spent the entire day cleaning it up and making it ready for new features Paul knew he would have to add soon.

Paul is a true craftsman. I thought that I was a structured worker, but he was much more structured than I, which was nice to witness - there is always room for improvement ;-). Although I had never worked with C# before we had a shared understanding and were productive after the first hour. I enjoyed working with him and had a great time. Thank you Paul.

In the middle of the week I moderated the September Coding Dojo of the Scala User Group Vienna. (A Coding Dojo is a meeting where a bunch of coders get together and work on a small programming challenge to improve their skills. You can find more information about Coding Dojo in Emily's excellent Coding Dojo Handbook.) It was their eight dojo and I wanted to try something more advanced than basic code katas. I chose the TDD as if you meant it exercise by Keith Braithwaite. This was a difficult exercise and it was difficult on purpose, but the participants did well, much better than I did my first time during GeeCON 2012. It was my first time facilitating and their first time working through this exercise, and all of us learned a lot.

Yak Shaving
The remainder of the week Florian Pirchner hosted me in the office of his company Lunifera. I knew Florian since several years as organized the Eclipse DemoCamp in Vienna together. Lunifera was a development shop specialized in OSGi technologies and its "office" was still located in the living room of his flat which made a comfortable place to work and we had a lot of fun. But the work - the work was terrible and we spent almost three days Yak Shaving.

When I arrived at Lunifera, Florian showed me his current pet project, a radio controlled air swimmer, a flying shark, using BeagleBone, Arduino, many cables and - of course - OSGi technology. He prepared the project for his upcoming talk at EclipseCon Europe and needed some third-party code deployed to Eclipse Virgo, an OSGi compliant server. And it just did not work. After reading the documentation several times, we started from scratch, took baby steps and reproduced the smallest examples from the documentation. Based on these working Virgo examples, we moved forward to implement the code he needed, a m2m server based on Apache ActiveMQ. Besides some integration tests, we did not write a single line of Java, but many lines of poms, manifests, Spring and other XML configurations. I hate infrastructure work. Finally we got it to work and Florian was thankful for my help on this task, I even got a new nick-name "Config-Cop" ;-)