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.

Inserting this code in the blog: ```clojure (defn all-access[k] (let [{:keys [a b] :as k}] (do a) (do (:b k)))) ``` the octopress processor throws the error: Error: Pygments can't parse unknown language: clojure Error: Run jekyll build --trace for more information. A solution would be to include it as lisp code: ```lisp (defn all-access[k] (let [{:keys [a b] :as k}] (do a) (do (:b k)))) ``` this is an example: