Softwerkskammer

 

Ideas for the upcoming sessions / Ideensammlung für die nächsten Treffen (in English or German)

Here you can share your proposals and / or add yourself to the speakers.
Hier könnt Ihr Eure Vorschläge teilen und / oder Euch als Moderatoren einbringen.


Template:

<snip - cut this template here>

Your topic

Speakers : [Your Name](/members/)

Hands-on programming language(s)

e.g. any, Java, Javascript, C#, Scala, Php, no hands-on

References

Topic chosen for the coming session:


Proposals for the next session to vote on:

Our experiences with code reviews

Speakers : Dimitry
Code reviews can be a great source of improvement but in my experience they do not take place often enough.
Let us see a video record of a talk about a Code-Review Culture together and discuss our daily experiences in this area and the learned ideas in small groups. Finally we try what we learned doing a small kata and reviewing code committed by peers.

Hands-on programming language(s)

any

References

RailsConf 2015 - Implementing a Strong Code-Review Culture : https://www.youtube.com/watch?v=PJjmw9TRB7s


Outside-In TDD with the Bank Kata

Speakers : Ruben
The Bank Kata is one of the most famous Outside-In katas there is. There'll be a quick introduction and an initial acceptance test, which will be our outside loop. The kata serves as a good use case for mocking all the way to the actual implementation.

Hands-on programming language(s)

any

References

https://github.com/sandromancuso/Bank-kata
https://www.youtube.com/watch?v=ty3p5VDcoOI
https://www.youtube.com/watch?v=XHnuMjah6ps


Ideas for the future:

Chesterton's Fence, Refactoring and Comments

Speakers : Justin Kaeser
If there is a fence across a road, and you can't see its use, is it always wise to tear it down? I'll argue that it makes sense to understand why it was put there in the first place, and draw the obvious parallel to code refactoring. And conversely, to not put up fences without proper justification as to why, and the value of comments in this context. We can then practice our fence-analysis and -tearing on a kata.

References

Chesterton's Fence


Subconscious Ping Pong

Speakers : Thorsten Göckeler

  • Language: Any
  • Level: Easy
  • Requires: Your favorite IDE

This will be an easy kata, however, we will restrict the setup, which will force you to improve your tooling. In addition we let the driver and the navigator play ping pong, so that it feels natural to switch roles without even thinking about it. Makes you think though why you haven't done it this way before :-).


Clean Code Testing

Speakers : Marcus Biel
As of today, Clean Code Programming is well known in the community.
Clean Code Testing however is only known to a few. In a short
introduction (~20 minutes) I want to present its ideas and concepts,
followed by a 3x30 minutes coding kata to try out Clean Code Testing
by yourself.

References

Practical Unit Test with Junit and Mockito: Tomek Kaczanowski


Asynchronous Event Driven Architecture Distilled

Speakers : Marcus Biel
Short introduction (~20 minutes) of what "asynchronous event driven architecture" means,
followed by a kata session and a moderated discussion afterwards.
References

http://en.wikipedia.org/wiki/Event-driven_architecture


Wie schreibe ich gute Blog-Artikel über Software-Themen

Moderatoren : Uli, ...
Folgende Fragen können betrachtet werden:

  • Wie finde ich ein Thema? Neuigkeit oder alter Wein in neuen Schläuchen?
  • Welche Themen eignen sich? Inhalt, Größe, Komplexität, Aktualität ...
  • Wie baute ich den Artikel auf? Teaser, Gliederung, Sprache, Spannungsbogen
  • Welche Beispiele / Code-Schnipsel verwendet man?
  • Welche Fettnäpfchen gilt es zu vermeiden?
  • Wo veröffentlicht man den Artikel? Unter welchem Namen?
  • Auf welchen Plattformen wirbt man wie für den Artikel?
  • Wie gehe ich mit Nachfragen / Kommentaren der Leser um?
  • ...

Ideen zur Abendgestaltung:

  • Gemeinschaftliches Erstellen & Publizieren eines Blog-Artikels. Welches Thema?
  • Kleingruppen recherchieren Antworten auf diese Fragen bzw. verfassen den Artikel
  • Im folgenden Treffen: Kurzes Review der Reichweite / Kommentare /etc.
  • Mögliche Variante: Tutorial statt Blog-Artikel

Mob - programmng

Speakers : Dimitry
We develop a program using only one computer with 1 Driver and N-1 (everybody else) Navigators simultaneously
This approach deserve its own session because it needs a very clear task definition to be succesful.

References

http://oredev.org/2013/wed-fri-conference/mob-programming-a-whole-team-approach
http://mobprogramming.org/


Archive:

Mockist vs. Classicist TDD (30.10.2014)

Speakers : David Völkel
TDD ist nicht gleich TDD: die "London School of TDD" ("Mockists") allen voran Steve Freeman und Nat Pryce setzen auf Top-down-Design und Interfaces um Rollen zu benachbarten Objekten expliziter herauszuarbeiten und das Design von außen ("Outside-In") durch die Akzeptanztests zu treiben. Interaktionen der Objekte untereinander stehen im Vordergrund und können durch starken Mocking-Einsatz isoliert Unit-getestet werden. Im Gegensatz dazu versucht die "Chicago School of TDD" ("Classicists") mit Vertretern wie Kent Beck oder Uncle Bob wenn irgendmöglich auf Mocks zu verzichten. Statt Interaktionen stehen "state based testing" und das Prüfen von Rückgabewerten im Fokus.

Wir wollen uns ansehen was beide Ansätze ausmacht und vor allem herausfinden welcher für welche Probleme besser geeignet ist. Und wie immer gilt, bringt bitte euer Notebook mit. Denn wir wollen eine Kata mit beiden Ansätzen lösen und unsere Erfahrungen vergleichen.

References

Micado Method (27.11.2014)

Speakers : Dimitry
We try to do safe step by step program transformation using Micado method.
"Code changes are like the Mikado game. When you want to make changes to a code base, you can rarely make the exact changes you want right away. You have to prepare some, move code, extract classes, and much more. Picking up the Mikado on your first grab is a rare thing! More often you make a sequence of moves before the Refactoring Mikado is available, working your way systematically to the bottom of the pile, to reach your goal."

This method was one of the interesting things discussed on Socrates 2014

References

https://pragprog.com/magazines/2010-06/the-mikado-method
http://mikadomethod.wordpress.com/
http://www.manning.com/ellnestam/
https://github.com/mikadomethod


Domain Driven Design on the touchstone (15.01.2015)

Speakers : Marcus Biel
Short introduction (~20 minutes) of what "Domain Driven Design" means,
followed by a kata session and a moderated discussion afterwards.

References

Domain Driven Design by Eric Evan
Implementing Domain Driven Design by Vaugh Vernon
Applying Domain-Driven Design and Patterns by Jimmy Nilsson
Domain Driven Design Using Naked Objects
http://www.infoq.com/presentations/model-to-work-evans


Property Based Testing (12.02.2015)

Speakers : Justin Kaeser

What if you could write thousands of test cases in just a few minutes? If your tests could find weird edge cases that you didn't even think of?
Turns out you can, of course. Property Based Testing is the keyword, with QuickCheck and ScalaCheck as typical implementations. The catch is, you need a little extra abstraction and think about general properties of your functions rather than the specific set of inputs and outputs. I will give an interactive introduction to some concepts and usage in ScalaCheck. We will discuss how to test specific functions and how to apply this approach to our real world problems.


Hexagonal Architecture (Ports And Adapters) Explained (12.03.2015)

Speakers : Marcus Biel
Short introduction (~20 minutes) of what "Hexagonal architecture" means,
followed by a kata session and a moderated discussion afterwards.
References
http://www.marcus-biel.com/hexagonal-architecture/
http://userscape.com/laracon/2014/chrisfidao.html
https://speakerdeck.com/fideloper/hexagonal-architecture


Baby steps TDD approaches (09.04.2015)

Speakers : David Völkel
Doing TDD using one baby step at a time can greatly improve our development speed. But often the next test forces us to implement too much in one step. So I will introduce some approaches I stumbled upon that help us to tackle this challenge. Of course we will try these out together on the "baby steps" threatening "diamond kata" and exchange about our experiences.
#####References
http://blog.adrianbolboaca.ro/2013/03/taking-baby-steps
http://claysnow.co.uk/recycling-tests-in-tdd
http://blog.johanneslink.net/2014/08/01/on-site-tdd


Practice GoldenMaster on legacy with hard to test dependencies(21.05.2015)

Use of approvaltests framework for creating acceptance tests in case unit tests are not easy enough to write.
Speakers : Dimitry
In the introduction I shall shortly demonstrate use of approval tests library, XStream, Moco and Eclemma using an example from https://github.com/martinsson/EncodeAudioLegacy. Unfortunately this project is only thought as demonstration of testing tools and not as a refactoring exercise. Therefore in the coding session the approval test framework and eclemma can be applied to another well known refactoring kata, and at the end we should discuss our experiences.

References:


Unit vs. Integrationtests (18.06.2015)

Speakers : David Völkel
Unit and integration test fan boys have been fighting against each other since the early days of TDD. Nevertheless in the last years the test pyramid has become the common sense strategy for automated tests synthesizing both approaches in an economic ratio. Unfortunately in practice the vague and abstract concept leaves us alone with a lot of remaining questions.

I will start the session introducing the test pyramid strategy and the strengths and weaknesses of the different kinds of tests followed by implementation approaches valuable for real life. Then we will split up into small groups and discuss there what in our current projects works well for us and work together on how we can approach remaining chalenges. In the end we will come together again and exchange our solutions in the full audience.

References

Codes faster, runs faster, easier to adapt ... (09.07.2015)

Speakers : Thorsten Göckeler

  • Language: Java
  • Level: Easy
  • Requires: Java 1.8+, Maven, IDE recommended

We'll tackle a standard task performed probably many times by most of you. In this session we will try to code it in the most common styles and check which version is faster or easier to code, which code performs best in some given scenarios, and which version can be easier adapted. You can have a try at multiple solutions and check against the other pairs. This is only a competition of solutions, not between you and the other pairs.


Ultratestable coding style (20.08.2015)

Speakers : Justin Kaeser
Unit and integration tests live in a constant area of conflict. Integrated tests usually involve I/O, which is costly to test and prone to errors in the tests themselves, while unit tests often fail to cover a lot of the logic of your software.

I'd like to explore the concept of "ultratestable coding style" together with you. The idea is to split up the logic and i/o or other code as much as possible, to be able to test the bulk of it without resorting to expensive integration tests.

I'll give a short presentation of the basic idea, after which we can try our hands at a refactoring kata and finally discuss our approaches to the problem.

#####References
Jessica Kerr: Ultratestable Coding Style


 

Wiki Links

Europaweite Veranstaltungen 2019
Jahreskalender von Konferenzen, Open Spaces, BarCamps und anderen Veranstaltungen