If you didn’t have the chance to be at the AppSecEU 2017 conference in Belfast or you didn’t make it to my talk there, here’s the official recording:
OWASP Juice Shop is a “shooting star” among broken web applications. To make sure it does not end as a “one-hit wonder”, the project embraces principles and techniques that enhance its sustainability, e.g. Clean Code, TDD, CI/CD, Quality Metrics and Mutation Testing.
In this session you will see how
– a complete and reliable test suite eliminates the “fear of change”
– automation is a key to increased productivity – even for small open source projects
– free-for-open-source SaaS tools can improve your development process
Where is light, there is shadow! You will also learn
– about some limitations in the automation processes
– why some 3rd party services had to be dropped
If the Internet gods are with us, we will even perform a production release of OWASP Juice Shop during the session!
You can find the original HTML5 slide deck at http://bkimminich.github.io/juice-shop/appseceu_2017.html. The slightly less fancy PDF-version is available on SlideShare:
“Good names – for classes, functions and variables alike – are a simple but powerful way of creating understandable code. Understandable code gives you improved maintainability. Bad names on the other hand are a heavy burden that the whole development team has to carry. Bad names hide the authors intent, leave false clues and often obscure the meaning of code. And all this calls for a certain action that developers should never have to apply lightly: The Batman Mode™. Forced into detailed detective work, developers try to find the meaning and correct pronunciation of class names like GyqfaChBppResDao. They investigate the difference between intended and entrenched meaning of variable names like ssd, sd and cd. They argue with code-villains about Encodings, Hungarian Notation and if an interface name should start with an I or not. Putting a little bit of extra care into name choices and following some simple concepts such as the “Scope Rule” and “Newspaper Metaphor” can have huge positive effects on your code. By choosing Supernames™ your team might even prevent the Dawn of Legacy Code for its own project!
You can find the original presentation slides here: http://batman-v-supername.kimminich.de
“Comments are – at best – a necessary evil” (Uncle Bob, “Clean Code”) – Over the years I gathered quite a collection of examples for bad code comments. The most precious gems among them I would like to share with you. You will listen in on developer monologues and dialogues, try to analyze cryptic bylines, experience different levels of UnCamelCasing(tm) skill and fight your way through a redundant, useless and misleading inline thicket. You will also hear about well-meant tools and plugins that should not even exist if the motto “No Comment!” would be valued as it should be.
You can find the original presentation slides here: http://no-comment.kimminich.de
Some comments on // No Comment! from Clean Code Days 2015:
Tools for unit testing, building applications, analyzing software quality and planning release scopes are an essential aspect of modern software development. With GitHub and “pluggable” external services there are lots of options to move these aspects into “the Cloud”. For open source projects this is a viable alternative to on-premise solutions. In these slides I present the CI lifecycle of some of my recent projects hosted on GitHub where I tried to integrate modern tools (e.g. Gradle, npm, bower) and external services (e.g. Travis-CI, Code Climate, Coveralls, HuBoard, AmazonSNS, NMA). I am not affiliated with any of the providers mentioned, so this is no marketing slide deck! Instead, you will hopefully learn about some enhancements to try out with your own GitHub projects!
You can view or download the PDF version on Slideshare or you can view the original HTML-based presentation here:
This is the recording of my talk Practicing Advanced Unit Testing with the TCG Kata from Agile Saturday X in Tallinn, Estonia on 15th February 2014.
Doing Code Katas alone or in a Dojo can help sharpen our elementary skills as software developers. Practicing IDE shortcuts and TDD mini-step cycles is very useful for the daily business, yet I find some existing Code Katas too far away from real-life programming situations. That’s why I came up with the Trading Card Game Kata – which is (very loosely) based on Blizzard Entertainment’s free-to-play online-game “Hearthstone – Heroes of Warcraft”. This Kata is focused on practicing TDD in a slightly more complex (but not complicated) situation where you might have to think about rules like Single Responsibility Principle or Command Query Separation and might even feel the urge to use a Mocking framework at some point.
First I will introduce the ideas of Katas and Dojos in general and explain the TCG Kata rules to you. Then I will demo some real-life best-practices for writing good developer tests, using my TCG Kata sample solution as a showcase. This will include:
- Picking the right Test Double
- Test Data Builders
- Behavior Tests with BDDMockito
- Prose-like Assertions with Hamcrest
- Readability Sugar
The full Kata ruleset and a sample solution in Java 8 can be found on https://github.com/bkimminich/kata-tcg.