As for every I TAKE Unconference edition, we want to give a chance to the software crafters from the audience to showcase their skills and learn more in the process. And because we appreciate passion, we offer a prize to those who convince a jury of well-known international developers that they are the most skilled in the room.
This contest is not meant to be easy. It will require you to practice beforehand, so please read the instructions carefully.
It will also require you to register before the event.
Mechanics
- IMPORTANT: Register to the contest latest one day before I TAKE Unconference by sending an email to steliana.moraru@mozaicworks.com
- On the first day of the event, after lunch, you have max 15′ to do a performing kata in front of the jury.
- The winner will be announced at the end of the second day
Constraints
To simplify the jury’s decision, the performing kata has to conform to the following constraints:
- Only the following programming languages are accepted: Java, C, C++, C#, Python, Visual Basic .NET, PHP, Javascript, Swift or Ruby
- Only solo contestants are accepted. Sorry, no pair programming this time
- The kata has to showcase refactoring skills.
- The kata has to last max. 15′
How we will judge
The jury will judge your refactoring skills.
The ideal kata looks like this – you will get maximum point if you:
- clearly state the smells you see in the code
- pick one of the smells
- clearly state your plan to fix the smell
- fix it in small, safe steps
- run tests after each step to prove you didn’t break anything
- commit after each step with a clear message explaining why you made the change
- fix as many smells as possible within the time constraint
You will loose points if you:
- make big or unsafe changes to the code
- break the behaviour after changing the code
- don’t improve the code a lot
- don’t improve the design by the end of the kata (hint: we judge design using SOLID principles and the four elements of simple design)
Recommendations
To help you, we’ve thought out what we would do if we participated to such a contest. Here’s what we recommend.
1) Use one of the following codebases for the kata:
- https://github.com/emilybache/GildedRose-Refactoring-Kata
- https://github.com/emilybache/Tennis-Refactoring-Kata
- https://github.com/emilybache/Yatzy-Refactoring-Kata
- https://github.com/emilybache/Parrot-Refactoring-Kata
2) Practice beforehand on the structure we presented for the ideal kata. Ideally find someone to practice with.
3) Watch other people refactoring. YouTube has many videos on the topic, including using the recommended code bases.
Glossary
A programming kata is a repeatable exercise used to practice specific skills.
Performing kata means doing a kata in front of an audience.
Refactoring means changing the internal structure of the code without changing its behaviour.
Brutal Building Constraints
Enjoy the following series of interviews with the speakers, top-notch software crafters from across Europe, joining I T.A.K.E Unconference, Bucharest, 11-12 May. Discover the lessons learned and what drives them to challenge the known path in their field.
Peter Kofler is a software developer since 17 years and still enthusiastic about writing code. At I T.A.K.E Unconference, he will share more about Brutal Coding Constraints.
#1. Please share with us 5 things you did that helped you grow & become the professional you are today
1. The biggest thing I did that changed me was a Journeyman Tour. For three months I visited different companies in Vienna and paired with their developers. See here for more information. (Three Month Journeyman Tour)
2. This included a lot of pair programming with strangers. I like pair programming and make use of it to learn from others. (Pair Programming)
3. I did (and still do) a lot of Code Katas to practice and experiment with code, patterns, and design. (Code Katas)
4. Try to continuously improve.
5. Read technical books.
#2. What challenges will the participants find solutions to during your session at I T.A.K.E Unconference 2017?
Yes, my session, the Brutal Coding Constraints, is a real challenge. It challenges our perception of Object Orientation and aims to deepen our understanding.
#3. Recommend for the participants 3 sources you find inspiration from and would help them better understand you
* Michael Feathers – The Deep Synergy Between Testability and Good Design
* Bryan Liles – TATFT – Test All the F…in Time
* J.B. Rainsberger – The Worlds Best Introduction to TDD
Want to join Peter and ~300 software crafters from around Europe?
Register now for I T.A.K.E Unconference 2017!
Rebecca Wirfs-Brock: Maintaining Your Code Clint Eastwood Style
Rebecca Wirfs-Brock is the object design pioneer who invented the set of design practices known as Responsibility-Driven Design (RDD), the first behavioral approach to object design. She is the lead author of two software design books and design columnist for IEEE Software. By accident, she started the x-Driven Design meme (TDD, DDD, BDD…). Although best known for software design, she is has a passion simply expressing complex requirements and effectively communicating software architecture.
Rebecca shared with the audience how to maintain your code in the keynote address from the first edition of I T.A.K.E Unconference. Watch below her remarks!
Code. Craft. Learn. Share. Repeat. Call for Speakers for I T.A.K.E Unconference, 5th edition, is open! Apply here.
The Pyramid of Programming Skillsets with Alex Bolboaca
Unit testing, code review, TDD, BDD, refactoring, legacy code techniques, pair programming, continuous integration, architecture styles … So many things to learn and so little time.
In his talk at I TAKE Unconference 2014, Alexandru Bolboaca described a model that allows a programmer to organize these practices in an order that is most helpful for her career. At the same time, it allows a CTO or technical manager to roughly evaluate the teams he’s leading and figure out the next steps in their development.
Enjoy his talk @ I T.A.K.E. Unconference 2014 edition.
Check out more about I T.A.K.E. Unconference 2015 or see directly the Schedule.