Can you copy a culture? The NUMMI story (audio/transcript) - how the GM factory with the worst workforce has been turned around via a good application of Toyota Production System - "a truly inspiring story of human potential and how systems can be designed to bring the best or worst of of people." And how GM failed to learn from it and to copy Toyota's culture.
The Reactive Manifesto - why to write reactive SW - "Reactive applications represent a balanced approach to addressing a wide range of contemporary challenges in software development. Building on an event-driven, message-based foundation, they provide the tools needed to ensure scalability and resilience. On top of this they support rich, responsive user interactions. We expect that a rapidly increasing number of systems will follow this blueprint in the years ahead."
Frameworkless JavaScript – Why Angular, Ember, or Backbone don't work for us [Moot discussion platform] (via JavaScriptWeekly) Me: Frameworks are not always evil, but are likely overused and there are good cases when rolling your own solution is the best way. Why in Moot? Because the want a minimal API (no framework methods), small code size, small and familiar code base, no dependency hell and external package updates, no lock-in to technology that will be gone in few years, need WebSockets not REST. "Moot uses native pushState for managing URLs, John Resig's "micro templating" for views, and internal communication between model and views happens with a custom event library. There is no router or automatic data-binding." The looked at Angular, Ember, Backbone. "As a result of our combined perfectionism and minimalism, Moot is an extremely lightweight, manageable, and independent web application [..]"
Gojko Adzic: How we solved our #1 product management problem - valuable experience of false assumptions, learning from users, and a much helpful UI remake: even if you build a product to scratch your itch, you have to test it with real users
Big data
Don't use Hadoop - your data isn't that big - a great post about the downside of Hadoop and that there are much better options (large disks, large RAM, Pandas/R/Postgres) for data up to few TBs. "In addition to being more difficult to code for, Hadoop will also nearly always be slower than the simpler alternatives."
Gartner On Big Data: Everyone's Doing It, No One Knows Why - golf talk / hype -driven initiatives FTW! "According to a recent Gartner report, 64% of enterprises surveyed indicate that they're deploying or planning Big Data projects. Yet even more acknowledge that they still don't know what to do with Big Data."
What makes Spark exciting - why it might be a good replacement for Hive/Hadoop, based on experiences with H/H: "Hive has served us well for quite a while now. [...] That said, it has gotten to the point where Hive is more frequently invoked in negative contexts (“damn it, Hive”) than positive. (Primarily due to being hard to test, hard to extend.)" "We had heard about Spark, but did not start trying it until being so impressed by the Spark presentation at AWS re:Invent [..] that we wanted to learn more. [..] Spark, either intentionally or serendipitously, addresses both of Hive’s primary shortcomings, and turns them into huge strengths. (Easy to test, extend.) [..] I find the codebase small and very easy to read, [..] –which is a nice consolation compared to the daunting codebases of Hadoop and Hive." Cons.: Spark is only pre-1.0, the author hasn't yet tested it heavily.
10 Ways to Make Your Office Fun To Work In - because we spend there plenty of our time so why not have a pleasant/cosy, inspiring environment? Some tips: plants, not-your-boring-enteprprise-look-and-feel, open it to the nature (I want this!), design it as home, not office, provide play space (I am too into work to want to play but having a resting place for a nap is st. I'd love).
Books
Book: The Architecture of Open Source Applications (via @rmz) - learn by studying architectures of existing systems - "In these two books, the authors of four dozen open source applications explain how their software is structured, and why. What are each program's major components? How do they interact? And what did their builders learn during their development?"
Book: Seven Concurrency Models in Seven Weeks: When Threads Unravel - "how to exploit different parallel architectures to improve your code’s performance, scalability, and resilience" - threads & locks, actors, FP + immutability/futures/promisses, Software Transactional Memory etc., GPU, MapReduce on clusters, ... (intro) Personally, I would prefer from theory to practice approach and mention of CSP (-> Go's channels, core.async) and more.
NYT: The Banality of Systemic Evil - a good article about human tendency to "obey the system" thus potentially causing evil - and thus the need to resist the system, as heroic individuals such as Snowden, Hammond, Schwartz, Manning. See the famous Eichmann in Jerusalem for how "doing your job" can create evil - "[..] what happens when people play their “proper” roles within a system, following prescribed conduct with respect to that system, while remaining blind to the moral consequences of what the system was doing — or at least compartmentalizing and ignoring those consequences." (Tip: The book Moral Mazes explores the ethics of decision making within several corporate bureaucracies => mid-managers rules of life: (1) never go around your boss, (2) tell the boss what she wants to hear, (3) drop what she wants dropped, (4) anticipate what the boss wants so that she doesn't need to act as a boss to get it, (5) do not report something the boss does not want reported, cover it up; the the job & keep your mouth shut.) "The bureaucracy was telling him [Snowden] to shut up and move on (in accord with the five rules in “Moral Mazes”), but Snowden felt that doing so was morally wrong." "[..] there can be no expectation that the system will act morally of its own accord. Systems are optimized for their own survival and preventing the system from doing evil may well require breaking with organizational niceties, protocols or laws."
Fairphone - "A seriously cool smartphone that puts social values first" (likely the only one not built by poorly paid workers and creating too much ecological burden), for just €325. You can see detailed cost breakdown, list of suppliers, specs, and essentially everything. This is, in my opinion, super cool! Go and read the story!
Clojure Corner
Amazonica - "A comprehensive Clojure client for the entire Amazon AWS api."
Talk Ritz, The Missing Clojure Tooling (40min, 9/2013) - thanks to this I finally understood how to use Ritz but it still seems not to work well, f.ex. setting a breakpoint always reported "Set 0 breakpoints" (lein ritz/middleware 0.7.0, nrepl-ritz.el 0.7.1); according to callen, debug-repl is simpler and nicer if you only care about local vars and evaluation. To try ritz: use M-x nrepl-ritz-jack-in, then M-x nrepl-ritz-break-on-exception, exec. f.ex. "(/ 1 0)". In the poped-up buffer, t or enter to show frame locals, e to eval a code in the context of the frame etc. If you managed to trigger the debug buffer through a breakpoint, the actions lists would contain STEP etc. (See fun. nrepl-ritz-line-breakpoint)
C. Grand's spreadmap - "library to turn Excel spreadsheets in persistent reactive associative structures" => access content via map functions; changing a value updates formula cells using it
Alembic Reloads your Leiningen project.clj Dependencies - add a dependency to your project.clj w/o needing to restart your REPL (just call (alembic.still/load-project), provided you have it in your lein dependencies). Limitations: cannot remove deps or change versions.
Defeating stack overflows - techniques for transforming mutually recursive calls etc. into something that won't blow the stack - "Priming the pump" (memoize subresults first), core.async
Google Groups: Clean Architecture for Functional Programming - How do the Clean Architecture and the Clean Code best practices apply to FP (Clojure/Haskell)? Some points: OOP isn't worse than FP, only people do class-oriented programming instead; OO better e.g. for UIs, combining them (func. core, imperative shell) can be sometimes best. Some clean arch. patterns are actually more like functions - "Interactors and Presenters, for example, do not maintain any state of their own. Even those objects that do imply some kind of state, such as entities and gateways, keep that state hidden behind boundaries and present a functional interface instead."
night-vision: Handy, super light weight debugging utility - add it to your lein profile and then call (night-vision.goggles/introspect-ns! '<name of ns>) and it will print each entry/exit of a function within the scope of the namespace with the argument/return values
Nil Punning (Or Null Pointers Considered Not So Bad) - a great post about why nil in Clojure is not bad contrary to Java's null (because it is actually an object, you can call functions on it, treat it as false/empty list/map/set, most core functions work on it)
