Most interesting links of September ''12
- Johannes Brodwall: This dependency injection madness must end! - it's very valuable to hear well-founded arguments against any popular belief and Dependency Injection is one of these. "I have started disliking the consequence of this strategy very much: All coupling in my system becomes implicit and harder to understand. I have instead reverted to using design patterns like the Singleton pattern, but with a slight twist."
- Computer Programmers Learn Tough Lesson in Sharing - WSJ.com - A balanced presentation of pair-programming including both benefits and issues. A key point: It is a skill that must be learned (to respect the other one, give her space, be aware of how your behavior is perceived by her, ...).
- Kent Beck: Functional TDD: A Clash of Cultures - TDD has been developed for object-oriented languages and applying it to a functional language with strong type brings interesting challenges. Also a good summary of the benefits of TDD: double checking of the logic (by the implementation and the, preferably quite different, test), solution decomposition (focus on part of the problem, once solve be sure it stays solved), automatic checking of correctness, outside in design (API first, implementation after that). Plus the pleasant experience of the continuous cycle of tension (failing test) - relief (green).
- Paul Callaghan: Thinking Functionally with Haskell: Types? Tests? We Need a New Word - Powerful type systems eliminate possibility of defects thus venturing into the domain of testing - what can they offer and where the new border and symbiosis between types and tests will be?
- Tales from the Ops Side: Black Friday - an interesting and exciting view into the life of operations engineers one day when all went wrong. Key learnings: Many interdependant components are difficult to reason about; good monitoring and communication are crucial. The post refers to an interesting concept of Recovery-Oriented Computing, i.e. failures are inevitable and their prediction is nearly impossible thus we must focus on making the systems able to survive failures (e.g. vi damage containment, automatic fault detection, component-level restartability).
- Groovy: The road map for the popular JVM language - why was Groovy created (as Java companion focused on productivity), key changes in Groovy 2.0 (more suport for static typing, Java 7, modularity with speed as a side-effect) and in the future Groovy 3.0 (invokedynamic everywhere, more Groovy written in itself).
- Martin Fowler: Key Points from NoSQL Distilled - an overview of why NoSQL, data models, distribution models, consistency, map-reduce, polyglot persistence, criteries for choosing a database.
- You’re a Top Developer! - a surprising hypothesis that "90% of all developers never read a programming blog, never have any side projects to learn something new, and never spend any time or effort outside work hours to improve". However I haven't seen any data to back that up (the author only quotes Peopleware) and the author doesn't propose any explanation for the fact. I'd really like to know if it is true and why it is so.
Business & Agile
- Experimentation Is The New Planning - "You have no idea what’s going to happen to your industry. That’s why you build your organization into an engine of possibility." We need "to continually develop options and explore possibilities" to survive in the ever-changing conditions. Successful strategies emerge from the many ongoing experiments. However, "For emergent strategy to be successful, there must be enough autonomy, freedom, and slack in the system for people and resources to connect in a peer-to-peer way".
- The Buy-vs-Build Shift (part 1) - Buy to reduce risk of failure (however true agile development - with frequent deliveries and feedback-driven direction - may be cheaper and more importantly can tailor the product to the actual needs) and to avoid inefficiecy of development (but it doesn't need to be so with agile). "[..] in projects with long cycle times (years) there is a tendency for the business to be somewhat speculative and request all functionality that they can think of [..] With prioritised iterative delivery the business can halt a project when all features that are actually needed have been completed. [..] it does reduce the amount of features that are implemented, and based on my experience, quite substantially so." Today's development with e.g. TDD, powerful IDEs supporting automated refactoring, powerful development/production machine, the all-knowing Internet may be much more efficient.
- European entrepreneurs - Les misérables - A good analysis of why it is much more difficult to be an entrepreneur in Europe than in USA (the strong negative impact of a business failure, lack of local investors, cost of firing people) and the decline of European entrepreneurship since 19th century/WW1.
- U.S. Government Accountability Office: Effective Practices and Federal Challenges in Applying Agile Methods - US government considers agile effective; description of the useful practices and of challenges
- 10-minute Emacs for Clojure - getting started with Emacs for Clojure - install & config & basic usage for Emacs newbies (though no REPL integration yet)
- Keep IT Simply Simple: First month @Runa Inc. - Clojure shop in Silicon Valley - brief post about using Clojure in the wild. Some points: TDD works splendidly; frameworks are not necessary; Clojure can be really fast (<= type hinting, memoziation, performant data structures + occasional Java code)
- Blackstag: Why Clojure? The author describes the set of reasons that have led him to Clojure - and those that actually made him stick with it. "[..] what I like the most about Clojure is that it brings together the best of what many languages have to offer while not forcing it all upon me and, in doing so, has provided a good balance between power and flexibility." "With Clojure I accomplish more and have found a greater sense of happiness with the work I am doing."