Most interesting links of December '13

Recommended Readings

Society
  • HBR: Want to Build Resilience? Kill the Complexity - a highly interesting, thought provoking article relevant both to technology in particular and the society in general; f.ex.: more security features are bad for they make us behave less safely (risk compensation) and are more fragile w.r.t. unexpected events. "Complexity is a clear and present danger to both firms and the global financial system: it makes both much harder to manage, govern, audit, regulate and support effectively in times of crisis. [..] Combine complex, Robust-Yet-Fragile systems, risk-compensating human psyches, and risk-homeostatic organizational cultures, and you inevitably get catastrophes of all kinds: meltdowns, economic crises, and the like." The solution to future financial crisis is primarily not more regulation but simplification of the system - to make it easier to police, tougher to game. We also need to decrease interconnectednes (of banks etc.), one of the primary sources of complexity. Also a great example of US Army combatting complex, high-risk situations by employing "devil's advocates / professional skeptics" trained to help "avoid the perils of overconfidence, strategic brittleness, and groupthink. The goal is to respectfully help leaders in complex situations unearth untested assumptions, consider alternative interpretations and “think like the other”".
  • The Dark Side of Technology - technologies provide great opportunities - but also risks we should be aware of - they create a world of mounting performance pressure for all of us (individuals, companies, states), accelerate the rate of change, increasing uncertanity (=> risk of Taleb's black swans). "All of this mounting pressure has an understandable but very dangerous consequence. It draws out and intensifies certain cognitive biases [..]" - magnify our perception of risk, shrink our time horizons, foster a more and more reactive approach to the world, the "if you win, I will lose" view, erode our ability to trust anyone - and "combined effect of these cognitive biases increases the temptation to use these new digital infrastructures in a dysfunctional way: surveillance and control in all aspects of our economic, social and political life." => "significantly increase[d] the likelihood of an economic, social and political backlash, driven by an unholy alliance between those who have power today and those who have achieved some modest degree of income and success." Complexity theory: the more connected a system is, the more vulnerable it becomes to cascades of disruptive information/action.
  • What Do Government Agencies Have Against 23andMe, Uber, and Airbnb? - innovative startups do not fit into established rules and thus bureaucrats do not know how to handle them and resort to their favourite weapon: saying no, i.e. enforcing rules that harm them (f.ex. France recently passed a law that requires Uber etc. drivers to wait 15 min before picking up a customer so that established taxi services have it easier; wot?!)
  • Nonviolent communication in action - wonderful stories about NVC being applied in difficult situations with a great success
Tech
  • D. Nolen: The Future of JavaScript MVC Frameworks - highly recommended thought food - about React.js, disadvantages of event-based UI, benefits of immutability, performance, the ClojureScript React wrapper Om  - "I simply don't believe in event oriented MVC systems - the flame graph above says it all. [...] Hopefully this gives fans of the current crop of JS MVCs and even people who believe in just using plain JavaScript and jQuery some food for thought. I've shown that a compile to JavaScript language that uses slower data structures ends up faster than a reasonably fast competitor for rich user interfaces. To top it off Om TodoMVC with the same bells and whistles as everyone else weighs in at ~260 lines of code"
  • Quora: Michael Wolfe's answer to Engineering Management: Why are software development task estimations regularly off by a factor of 2-3? - a wonderful story explaining to a layman why estimation is hard, on the example of a hike from SF to LA
  • Style Guide for JavaScript/Node.js by Felix Geisendörfer, recommended by a respectable web dev; nothing groudn breaking I suppose but great start for a team's standards
  • Johannes Brodwall: Why I stopped using Spring [IoC] - worth to read criticism of Spring by a respected and experienced architect and developer; summary - dependency injection is good bug "magical" frameworks decrease understandability and encourage unnecessarily complex code => smaller code, , easier to navigate and understand and easier to test
  • Misunderstanding technical debt - a brief discussion of the various forms of tech. debt (crappy code x misaligned design and problem domain x competence debt)
  • Tension and Flaws Before Health Website Crash - surprising lack of understanding and tensions between the government and contractors on HealthCare.gov - "a huge gap between the administration’s grand hopes and the practicalities of building a website that could function on opening day" - also terribly decision making, shifting requirements (what news!), management's lack of decision power, CGI's blame-shifting. A nice horror story. The former head knew that they should "greatly simplify the site’s functions" - but the current head wasn't able to "talk them out of it".
  • The Log: What every software engineer should know about real-time data's unifying abstraction - logs are everywhere and especially important in distributed apps - DB logs, append-only logs, transaction logs - "You can't fully understand databases, NoSQL stores, key value stores, replication, paxos, hadoop, version control, or almost any software system without understanding logs" - I have only read a small part but it looks useful
  • What I Wish I Knew When Learning Haskell tl;dr
  • Better Than Unit Tests - a good overview of testing approaches beyond unit tests - including "Automated Contract Testing" (ability to define a contract for a web service, use it to test it and to simulate it; see Internet of Strings for more info), Property-based Testing (test generic properties using random data/calls as with Quickcheck), Fault Injection (run on multiple VMs, simulate network failures), Simulation Testing as with Simulant.
  • Use #NoEstimates to create options and deliver value reliably - a brief post with an example of an estimation-based vs. no-estimates project (i.e. more focus on delivering early, discovery)
  • How Google Sold Its Engineers on Management - managers may be useful after all :-); a report about Google's research into management and subsequent (sometimes radical) improvements in management style/skills and people satisfaction; I love that Google hasn't HR but "people ops"
  • Roy Osherove: Technical Disobedience - take nothing for granted, don't let the system/process stop you, be creative about finding ways to improve your team's productivity; there always is a way. Nice examples.
  • Uncle Bob: Extreme Programming, a Reflection - a reflection on changes in the past ~ 14 years since XP that have seen many of the "extreme" practices becoming mainstream
  • The Anti-Meeting Manifesto - essentially a checklist and tips for limitting meetings to minimum
Other

Talks

  • Pete Hunt: React: Rethinking best practices (JSConf 2013, 30 min) - one of the most interesting talks about frontend development, design, and performance I have heard this year, highly recommended. Facebook's React JavaScript framework  is a fresh and innovative challenger in the MVC field. It is worthwile to learn why they parted ways with the popular approach of templates (spoiler: concern separation, cohesion x coupling, performance). Their approach with virtual DOM enables some cool things (run in Node, provide HTML5-like events in any browser with consistent behavior, ...). Key: templates are actually tightly coupled to display logic (controllers) via the model view tailored for them (i.e. Controller must know what specific data & in what form View needs) => follow cohesion and keep them together componets, separate from other components and back-end code. Also, state changing over time at many places is hard => re-render the whole app rather than in-place updates. Also, the ClojureScript Om wrapper enables even more performance optimizations thanks to immutable data structures etc.
  • David Pollak: Some musings on Scala and Clojure by a long time Scala dude (46 min) - a subjective but balanced comparison of Scala and Clojure and their strengths/weaknesses by the author of the Scala Lift framework (doing Scala since 2006, Clojure since 2013)

Clojure Corner

Tools/Libs

  • Apache Sirona - a new monitoring tool in the Apache incubator - "a simple but extensible monitoring solution for Java applications" with support for HTTP, JDBC, JAX-RS, CDI, ehcache, with data published e.g. to Graphite or Square Cube. It is still very new.
  • GenieJS - Ctrl-Space to popup a command-prompt for your web page, inspired by Alfred (type ' to see all possible commands)

Favourite Quotes

A good #agile team considers their backlog inaccurate. It is merely a list of assumptions that must be tested & refined by shipping product - @mick maguire 12/10
Ada Lovelace (1st program), Grace Hopper (1st compiler), Adele Goldberg (1st OO language), why would anyone think women aren't in computing? - @Dan North 12/11
There will always be a shortage of talented, self-motivated creative professionals who will unquestioningly follow orders. - @Thomas K Nilsson 12/7
Estimation paradox = If something unpredictable happens, predict how long it will take to fix it - me 12/7
IT systems can be inspired by AK-47 a.k.a. Kalashnikov. The rifle was purposefully designed to be simple and to be tolerant to imperfections in most parts; as a result, it required essentially no maintenance and was extremely reliable. - summarized from Roman Pichlík's Odkaz Michaila Kalašnikova softwarovému vývoji

Tags: scala clojure webdev design monitoring haskell JavaScript DevOps library


Copyright © 2024 Jakub Holý
Powered by Cryogen
Theme by KingMob