Acceptance testing / Specification by example:
- Gojko Adzic: Anatomy of a good acceptance test - an example of refactoring a bad acceptance test into a good one - good for learning about pitfalls and how a good one should look like
- Gojko: Top 10 reasons why teams fail with Acceptance Testing - acceptance testing is great and brings lot of value but must not be underestimated; some of the problems are bad collaboration, focusing on "how" instead of "what," confusing AT with full regression tests. Brief, worth reading.
- Specification by Example: a love story (go directly to the PDF with the story): A nice, made-up story of going from low-level, workflow-based Selenium tests through similar Cucumber ones to true BDD tests describidng clearly what, not how - very well shows the point of specification by example and how it should (and should not) look like
(Enterprise) Java best practices:
- Clean code, clean logs: 10 brief posts on logging best-practices - nothing really new here for me but in total it is a very good overview that every developer should know
- Make Large Scale Changes Incrementally with Branch By Abstraction - Continuous integration doesn't work well with branches but as this article shows, you can manage even large-scale refactorings without branches using "branch by abstraction," an approach reminding me of Fowler's "strangler application" (an incremental replacement of a legacy system). The idea is: 1. Create an abstraction over the part of code to be changed; 2. Refactor the code to use it; 3. Implement new functionality using the new way / step by step move old functionality too, the abstraction layer delegating either to the new or old implementation ... . It may be more work but: 1) your software is always working and deliverable; 2) (side-effect) in the end it will be more decoupled
- John Wiegley's Git from the bottom upp (31p, Git 126.96.36.199, PDF) - a useful explanation of the fundamentals of Git, i.e. how it is constructed and how it works, which makes it much easier to understand how to use it properly (recommended by Pål R.). Reading the The Git Parable first may be a good idea for an easy introduction into the fundamentals, though absolutely not necessary. This document introduces very well the important Git concepts (blob, index, commit, commit names such as branches, reflog) and how they cooperate to provide the rich set of functionality it has. It also explains well the value and usage of rebase. Among others I've appreciated the tip to use checkout, branch -m <new-branch> master, branch -D instead of the much more dangerous reset --hard and the tip to use stash / stash apply to create daily backups of your working tree in the reflog (with clearing it with 'git reflog expire --expire=30.days refs/stash' instead of stash clear). Also git diff/log master..[HEAD] for reviewing work done in the current branch and and git diff/log ..master for checking the changes since the last merge/rebase after a fetch are interesting.
- The secret power of bookmarklets - bookmarklets are an indispensable tool for every developer who works with web applications (to fill in test data, speed up log in, ...), yet I'm sometimes surprised by meeting people who don't know or use them; this blog explains them nicely, links to some useful ones and some useful tools for building them
- (*****) Implementing Lean Software Development: From Concept to Cash by Mary Poppendieck, Tom Poppendieck - A great introduction into lean thinking (the values and principles it is build upon), clearly communicated with the help of "war stories". I absolutely recommend it to anybody interested in lean/agile.
- (**** ) Agile Project Management with Scrum (Microsoft Professional) by Ken Schwaber - Even though you can't understand Scrum without experiencing it, this book full of war stories will help you to avoid many Scrum implementation pitfalls and to understand its mantra of "the art of the possible" and will show you how to adapt Scrum to various situations. It's very easy to read thanks to its format of brief case studies organized by topics (team, product owner, ...).
Favourite Quotes of the Month@unclebobmartin
: Cleaning code does NOT take time. NOT cleaning code does take time.