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.
<snip - cut this template here>
Speakers : [Your Name](/members/
e.g. any, Java, Javascript, C#, Scala, Php, no hands-on
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.
any
https://github.com/sandromancuso/Bank-kata
https://www.youtube.com/watch?v=ty3p5VDcoOI
https://www.youtube.com/watch?v=XHnuMjah6ps
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.
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 :-).
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.
Practical Unit Test with Junit and Mockito: Tomek Kaczanowski
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
Moderatoren : Uli, ...
Folgende Fragen können betrachtet werden:
Ideen zur Abendgestaltung:
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.
http://oredev.org/2013/wed-fri-conference/mob-programming-a-whole-team-approach
http://mobprogramming.org/
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.
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
https://pragprog.com/magazines/2010-06/the-mikado-method
http://mikadomethod.wordpress.com/
http://www.manning.com/ellnestam/
https://github.com/mikadomethod
Speakers : Marcus Biel
Short introduction (~20 minutes) of what "Domain Driven Design" means,
followed by a kata session and a moderated discussion afterwards.
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
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.
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
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
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:
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.
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.
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
Speakers : Dimitry
Code reviews can be a great source of improvement but in my experience they do not take place often enough. Let us discuss our daily experiences in this area in small groups and together see a video record of a talk about a Code-Review Culture. Finally we can try the recommendations from the video doing a small kata and reviewing code committed by our peers.
any
RailsConf 2015 - Implementing a Strong Code-Review Culture : https://www.youtube.com/watch?v=PJjmw9TRB7s