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 : Dimitry
Our community loves exchanging opinions, practices and knowledge. The most famous format is series of software craftsmanship conferences named SoCraTes. Instead of setting up their programs in advance they give participants a forum to tell what they like to learn and to share what they like to show to the others. It is like a two days filled with a never ending coffee break full of inspirational talks and discussions.
In this session we can try to have this experience. Think about questions and topics you would like to ask, to discuss or to share and let the magic happen.
http://www.mindviewinc.com/Conferences/OpenSpaces.html
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 : 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 with a mocking framework
https://github.com/sandromancuso/Bank-kata
https://www.youtube.com/watch?v=ty3p5VDcoOI
https://www.youtube.com/watch?v=XHnuMjah6ps
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
Speakers : Bradford Hovinen
Most business applications treat persisted data as just a permanent mirror of the objects in memory. To a class Customer is associated a table TAB_CUSTOMER whose fields correspond roughly 1-1 with those of the class. References between objects are translated to foreign key constraints in the tables. And so on.
This is far from the only way to consider persisted data, and not always the best way. In many applications, the way persisted data are manipulated and the way they are presented to the user are completely different. The architecture pattern CQRS embraces this by explicitly separating the writing and manipulation of data from their reading and presentation.
Event Sourcing is in particular one manifestation of CQRS, in which the record of changes to the entities -- rather than the entities themselves -- are the source of truth in the persistence layer. Thus changes as such have a meaning in the context of the domain, allowing the evolution of the entity over time to be modelled.
This session will include a presentation on CQRS and Event Sourcing followed by a kata to try these ideas out.
Java
http://martinfowler.com/bliki/CQRS.html
http://martinfowler.com/eaaDev/EventSourcing.html
Speakers : David Völkel
During TDD we always ask ourselves, which of the many tests on our list we should implement next. In our experience some work better than others. But which ones?
To give orientation here Uncle Bob introduced his heuristic "Transformation Priority Premise", which basically classifys and prioritizes possible next implementations by their complexity. A nice side-effect of following the approach: Developing complex algorithms incrementally becomes very similar to writing a mathematical proof. Be surprised!
As always after a short introduction we will start trying the approach on an algorithmic coding kata hands-on in pairs. So please bring your laptop with a running IDE and a unit test framework in the language of your choice.
any
Tranformation Priority Premise
Speakers : Bradford Hovinen
How do we know whether our tests are good enough?
One common measure is code coverage, but it has its limits: one can take any test suite providing good coverage, remove all of the assertions, and still have good coverage. The resulting test suite will, however, be next to useless.
The only real way to know whether our tests are doing their job is to see what happens when our code breaks. This is the idea behind mutation testing: we deliberately introduce defects into productive code and then see which tests (if any) break as a result. If a real defect is introduced and no tests break, then we know that our tests are inadequate.
In this session there will be a short presentation on the technique followed by some exercises to try it out by hand. Time permitting, we will try out an automated tool for doing mutation testing in Java.
Java