These are the talks I’ve attended at the Craft Conf 2015: Thursday 23th Opening keynote by Dan North and Jessica Kerr Writing testable code - A functional programming point of view, by Alvaro Videla Coding Culture, by Sven Peters OnConnectionLost: the life of an offline web application, by Stefanie Grewenig and Johannes Thönes Concurrency: It’s harder (and easier) than you think, by Paul Butcher Testing and Integration (the remix), by Inés Sombra Beyond Features: Rethinking agile planning and tracking, by Dan North Closing keynote by Alf Rehn Friday 24th Opening keynote: The New New Software development game: Containers, Microservices and Contract tests, by Mary Poppendieck Apprenticeship patterns, revisited, by Dave Hoover Interaction Driven Design, by Sandro Mancuso The hidden dimension of refactoring, by Michael Feathers Why is an API like a puppy, by Adewale Oshineye Microservice antipatterns, by Tammer Saleh I couldn’t attend the last talk nor the keynote as I had to get to the airport

In his book Working effectively with legacy code, Michael Feathers describes: […] legacy code as code without tests. It is a good working definition, and it points to a solution […] M Feathers, in the preface of Working effectively with legacy code I really like this definition. It is objective and measurable. But this is also a downside. Let’s take any concurrent code, for example: you can achieve 100% coverage on a single thread and the program could have defects when executed in parallel.

I’ve written a sample project with an annotation and an aspect to intercept it and decorate it. The code provides a way of doing try|catch, specifying an exception to be caught. The source code is available here In the process This has taken me approximately one hour to prepare the spike and half more to refactor and massage a bit. If you want to see the raw details, the refactor has been committed step by step (the spike hasn’t).

At a client, we’re facing this challenge: we cannot access production logs, as we don’t have access to production environments. The solution we’ve chose is to implement the logging component as a layer on top of Splunk. This formatter layer –per component– accesses a generic layer –for the whole company– that accesses splunk. In this manner, it is very easy to reuse the splunk connection and configuration and inject mocks. Also helps with the local environment: you always log to console (even if in production you don’t have access to it) and can disable this in local, not needing a local splunk installation.

I’ve seen this video by Rich Hickey: “Simplicity matters”, taken from Manuel Rivero’s google plus' site here are my notes: the software is the elephant do more, do it differently, do it better complexity of the elephant is going to dominate what you can do your ability to reason about your program is critical design is about pulling things apart become familiar by learning, trying “We can be creating the exact same programs out of significantly simpler components”.

Overheard today at the office, while they were discussing the approval of a pull request: [Pull request reviewer] - I’m sorry, can’t approve this: I don’t really agree with this design. Isn’t there an alternative for this? [Pull request author] - [redacted], of course you don’t, you’re the guardian of the source [PR reviewer] - Well, sometimes I’m a bit picky about introducing bad code into our codebase. This has made me think about Gandalf blocking the path of Balrog Demon, shouting “[you shall not pass][you-shall-not-pass-meme]” while on top of the bridge.