Tim Bourguignon tells us how he became a developer, then an agile coach and then “chief learning officer” at Mathema.
In this interview, Simon Harrer shows you how code becomes more readable when you do not separate state and behavior.
Tim Bourguignon, agile coach and “chief learning officer” at Mathema, talks about one of his favorite topics: Mentoring.
Simon Harrer and I talk about the chapter “Name Things Right” from his book “Java by Comparison”.
When you already know the algorithm you want to implement, why should you use test-driven development to write it? And how do you test-drive a known algorithm or formula?
Why doesn’t React come with dependency injection? Short answer: Because it doesn’t need it and also because it is not its responsibility.
But how do you isolate your components during testing then? How do you achieve inversion of control for dependencies when you do not have a dependency injection container?
Let’s have a look…
Some years ago I was talking to the technical lead of a medium-sized company. I told them that I had just taught a 2-day training about the new features of Java 8 to two teams at a very large company.
He said: “I will never understand why those large companies spend money on training something like that. Like, language features! I expect my employees to learn those on their own, out of curiosity!”
When test-driving a UI, should I test whether the text of the start button is “Start”? What about the CSS class or style of the button? It’s disabled state?
Of all the possible tests I could write, which are the ones that bring value? Which ones would get in my way later if I wrote them?
Can you test-drive the UI of a web application? And why would you even want to?
With React and some extra tools, testing at least some aspects of the UI is easy. Let’s take a look…