Most interesting links of June '12
Recommended Readings
Development- Neal Ford: Evolutionary architecture and emergent design: Emergent design in the wild - discusses why not to do Big Design Up Front and how to recognize the "last responsible moment". Quote: "It's puzzling that so many organizations continue to use BDUF in the face of so many failures and underachieving projects."
- Gojko Adzic: How To Solve “Not Enough Time” - everybody in IT complains about too much work. The solution acording to Gojko? Kill software already made that isn’t needed (ex.: deleted 70% functionality that wasn't used; remember that maintenance costs grow ~ exponentially with size/complexity). Kill software in making that won’t be needed (know the value - effect maps). Kill software that was not successful (if you measure the value of SW, you know whether its existence is worth it). Well written and inspiring. I'm looking forward to killing some SW :-)
- Coding Horror: Postponing decisions to the last responsible moment - a brief and pretty good explanation of this key lean principle together with its connection to YAGNI (and some criticism of LRM by A. Cockburn - I agree with the postscript 2)
- Build The (USS) Enterprise - A fascinating site by an engineer who dares to think big yet manages to stay rooted in reality. A huge inspiration for us all! We tend to think too small. Having a great, inspiring goal is what moves us forward. And people are known to have achieve seemingly impossible things nobody else believed in (how many believed Columbus could reach India by by sailing the opposite direcetion? and even though he actually hasn't, the impacts of his discovery were tremendous)
- Hooking Users In 3 Steps: An Intro to Habit Testing - to be successful with a new web product in this age of distraction, you need your users to build the habit of using the app regularly (think of Twitter, Facebook, newspaper); this post describes how to find your habitual users, understand them, and optimize the application to turn more occassional users into habitual ones (identify habitual users - learn how they use the app & learn what turns random users into "devotees" - optimize the "habit path")
- Puppet: Serve configuration from a particular Git branch on demand (original: Git Workflow and Puppet Environments) - at Comoyo we use Puppet to configure all our environments and developers need to test their changes before pushing them to the live environment, preferably without interference from other devs. This post by Adrien of PuppetLabs describes how to enable each developer to have her private branch(es) and have Pupet Master serve the config from the branch on demand, using little puppet environments and hooks magic. (Notice that if using Puppet to serve files then you'll need to have them inside a module, which is a good practice anyway.)
- DZone reference card for Jetty (DZone login required) - useful, brief overview over Jetty XML and programatic configuration, especially useful is the overview of handlers, use of servlets and webapps, SSL support, websockets
- What’s new in Groovy 2.0? - static type checking, Java 7
- Speed, memory and LOC of Python 3 vs. Java 7 [fixed link] (the computer language benchmark game) - Python tends to take more time (though not terribly more) but is quite economical with memory and visibly more productive (3* less lines of code). Ruby is similar but way slower. Scala is little slower and more memory hunrgy but also more productive. Of course performance is rarely the key factor for picking a language on often it doesn't matter that much.
Favourite Quotes
Goodhart's Law: once a metric becomes a target, it loses its meaning as a measure.
Clojure Corner
- What Sucks about Clojure...and Why You'll Love It Anyway - 40 min talk by Clojure Programming author Chas Emerick. Some of the negative points: Namespaces - complex (use x refer etc.; no package.* import, ...), no forward references; Dynamic scope (with-foo ...) has subtle, complex behavior and hard to see => avoid when you can; Using STM (effectively) is hard even though it looks easy, it's overused, think of it rather as in-memory db with superior integr. with Clojure (ex.: what is the right ref granularity? whole word map? small particle?), nondeterministic (which tx will fail/suceed? - can't reason) => strange error under high load/mix of operations; JVM: long startup time, ...; Macros look easy but are hard (don't compose nicely with the rest); Function composition - hard to find failure root cause.
- Why is Clojure so slow? (2/2012) - an interesting comparison of Clojure and other languages (C, F#, Groovy etc.) and an analysis of its slow start-up time (metadata and docstring building) and slower performance. (Interestingly, ClojureScript runs it 9* faster.) According to the author, it's slower partly due to the imutable data structures (nothing new here, we knew we have to offer some performance for the increased safety and robustness). Conclusion: "Clojure is a beautiful, powerful and very useful language, but [...] not great for small script-y programs." Also, the usefulness of the benchmark is limited if you aren't writing games. Plans for making Clojure leaner and faster are under way.
- Stuart Sierra: Functional Relational Programming with Cascalog - a brief introduction into Cascalog with a valuable background info about Hadoop, MapReduce, relational programming in Clojure. Good links, especially the paper Out of the Tar Pit looks interesting.