Posted by Jakub Holý on August 31, 2013
Sorry folks, this month it will be very brief. I have many more great stuff in the queue but haven’t managed to write it down yet. Next month will be heavy
- Why Software Projects are Terrible and How Not To Fix Them – many teams are not ready to embrace new/better software practices, primarly for two reasons: 1) most of them are nonintuitive (f.ex. adding more people will slow dev down) and need to be sold through a high hierarchy of managament – but people/managers/organizations don’t really care, it takes years for good/bad practices to have an impact, which is not relevant “now.” 2) Businss objectives change too quickly and SW is blamed for not delivering. Based on evaluating many failed projects. Conclusion: Choose carefully people/organizations your work with. Avoid blame-driven ones. Quote on middle managers: “He has to put more developers on the project, call a meeting and yell at people, and other arbitrary bad ideas. Not because he thinks those will solve the problem. In fact, managers often do this in spite of the fact that they know it’s bad. Because that’s what will convince upper management that they’re doing their best.” “In the vast majority of failed projects I’ve been called to looked at, the managers have not read one book on software engineering.“
Data & Analytics
- Big Data: Kafka for uSwitch’s Event Pipeline – a better alternative to log files – use LinkedIn’s Kafka for messaging, have MR jobs to import latest messages into Hadoop/HDFS. The advantage of Kafka is that it persists the messages for a period of time so it is easy to batch-import and even re-import them. The uSwitch’s talk Users As Data explains the downsides of log files. LinkedIn’s Camus is a tool for importing messages from Kafka to HDFS.
- Realtime Analytics with Storm and Hadoop (at Twitter; presentation deck) – pre-aggregate some data into a read-only, random read DB such as ElephantDB, Voldemort, or Manhattan. For newer data use Storm and aggregated data in a read-write, big-data DB such as HBase, Riak, or Cassandra. For stuff that cannot be pre-aggregated you might use Storm’s Distributed RPC.
- The Unified Logging Infrastructure for Data Analytics at Twitter – a paper from late 2012 that presents “Twitter’s production logging infrastructure and its evolution from application-speciﬁc logging to a uni- ﬁed “client events” log format, where messages are captured in common, well-formatted, ﬂexible Thrift messages” – with the benefit of “s streamlined log collection and data analysis”.
- Development and Deployment at Facebook (Kent Beck et. al., 8/2013, 13p paper) – “More than one billion users log in to Facebook at least once a month to connect and share content with each other. Among other activities, these users upload over 2.5 billion content items every day. In this article we describe the development and deployment of the software that supports all this activity, focusing on the site’s primary codebase for the Web front-end.“
- One of the most valuable talks I’ve seen, in just 18 min: The Progress Principle – about the disengagement crisis and motivation at work by Teresa Amabile at TEDx Atlanta (via @thovden). Disengagement from work is increasing, at all age and salary levels, and leads to unhappy people, low productivity, huge financial losses. Based on analysing diaries of 12k participants, the single most important engaging and motivating factor is making progress in a meaningful work (including small wins). A culture of management by fear and punishment for failure creates disengagement and can crush even an innovative, profitable, praised company in a few years. Everybody, though especially the management, creates the culture through their everyday, small actions. If everybody focuses on catalysing progress and supporting their fellow humans through good and bad times, engagement and success will follow. Remove progress inhibitors, nourish the human spirit (acknowledge what we humans value, encourage people). Yet of the managers asked, very few knew of the significance of making progress (or, I can assume, of supporting people and making them happy(er) and the impact of our inner work life (perceptions, emotions, etc.) on our productivity and creativity). The study included two seemingly similar, successfull companies, one with great engagement, another with a new management that managed to destroy the engagement and thus eventually the company. Actions to take: catalyse progress, celebrate wins, encourage and support your colleagues.
- Wonderful Clojure Cheatsheet 1.5 with tooltips showing the doc and summary of information available at clojuredocs.org (other Clj versions), by Andy Fingerhut
- Chas Emerick’s Clojure type selection flowchart to help you decide whether to use a map, a record, reify, proxy, gen-class, or deftype. (Reify and proxy don’t produce a class but just an instance of an anonymous class; proxy can extend a base class, reify cannot. gen-class produces a class visible from Java and can extend Java classes. …)
- Docker.io – pack, ship and run any application (and its dependencies) as a lightweight container, i.e. essentially “a VM without the overhead of a VM,” using linux containers (chroot on steroids with resource limits via control groups) see reports of some uses such as Java app deployment, desktop virtualization, automatic app deployment in GitHub commit. Docker also supports evolving the containers over time, i.e. deploying new version, by pushing just diffs so it’s low-overhead. You can build a container (include files, SW, forward ports, …) using a Dockerfile. See dotScale 2013 – Solomon Hykes – Why we built Docker for an intro (20 min).
- Packer.io – tool for building pre-configured VM images for different platforms (EC2, VirtualBox, …), remotely similar to Netflix’s Aminator. See Immutable Servers With Packer and Puppet for an example use case.
- Ubuntu-build Vagrant boxes at cloud-images.ubuntu.com/vagrant/
- SlimerJS – PhantomJS-compatible headless browser engine based on Firefox/Gecko (well, it is not fully headless yet but that is planned; the main focus now is full compatibility with PhantomJS’ API) (Both work with CasperJS for navigational steps/testing.)
- localtunnel – instantly show locally running webapp/server to the rest of the world (gem install localtunnel, localtunnel <port to share>, => share the url returned, e.g. http://xyz.localtunnel.com) – I haven’t tried it but it looks simple and very convenient
- Logstash + Kibana (via @mortenberg): take control of your logs – while Logstash can collect (from multiple servers/services), parse (over 100 built-in patterns), store, index, search your logs, Kibana is a web interface to seach them, view them in realtime (based on a query) etc. See this Logstash slides (9/2012) and an overview of Kibana’s powers. PS: Logstash can also compute metrics and send them to graphite etc. It is typically used with ElasticSearch.
- ncdu is an interactive, command-like disk usage browser that shows a list of directories sorted by size shown in human-friendly units, you can navigate with arrows and enter and i to show the current dir/file info, d to delete it, q to quit; check out this article about ncdu with screenshots and ncdu man page. Install via Apt etc., run f.ex. with ncdu -x / .
- vagrant-cachier – Vagrant plugin for caching apt/yum/.. packages locally, thus speeding up destroy+up
Posted by Jakub Holý on August 24, 2013
All Clojure REPL variants (nREPL, REPLy, ..) share some common characteristics, inherited from clojure.main and clojure.repl. One of them, that isn’t easy to find out (unless you read e.g. Clojure Programming) is the fact that the last three results of evaluating your code are stored in the vars
*3. The last exception that has occured is stored in
;; Inside lein repl, with the user=> prefix removed and output prefixed with ;; =>
;; => 1
;; => 2
;; => 3
;; => 4
(println "results - latest:" *1 "prev:" *2 "oldest:" *3)
;; => results - latest: 4 prev: 3 oldest: 2
;; => nil
(/ 42 0)
;; => ArithmeticException Divide by zero clojure.lang.Numbers.divide (Numbers.java:156)
(println "res" *1 "exception" *e)
;; => res nil exception #<ArithmeticException java.lang.ArithmeticException: Divide by zero>
;; => nil
clojure.repl defines in its namespace some very useful functions and macros such as
dir (prints a sorted list of public vars in a ns; ex.:
(root-cause throwable) – check out their docs at ClojureDocs/clojure.repl.
Posted in Languages | Tagged: clojure, repl | 2 Comments »
Posted by Jakub Holý on July 31, 2013
This month focuses on languages and approaches (reactive programming, F#, Erlang, FP talks etc.), agile (need for speed, recommended books), Clojure/Linux/cloud tools and libs.
- The Need For Speed – the top 10 reasons for fast development flow (with time to market being one of the less important) – more learning, focus on the MVP, focus on the puprose/goal, happier customers/leadership, better quality (sic!), higher morale (I concur!), push for cotninuous improvement, “one of the only sustainable differentiators”; => “sense of urgency and motivation”; “[..] I continue to meet people and teams that not only move very slow, they don’t understand the relationship between speed and innovation, or speed and quality.”
- agile42 Summer Reading List 2013 – books recommanded by experienced people/agile experts – lot of interesting stuff! Topics: Communication and Coaching (f.ex. Practicing Nonviolent Communication), Business (How Great Companies Get Their Mojo from Maslow ,..), Learning From the Military, Agile and Technology (e.g. The Art of Action: How Leaders Close the Gaps between Plans, Actions and Results), Agile and Technology (f.ex. The people’s Scrum)
- Dan North: Are we nearly there yet? – optimize for time to business impact; SW dev as mountaineering (impossible to estimate correctly, many unknown details, dead ends, …); go fast – but sustainable; the tyranny of backglog (there are multiple paths to the top yet backlog defines only one; have you ever considerably changed it?) “Instead we could embrace the fact that today we always know more than we did yesterday, and that tomorrow we will know even more. We can take a fresh look up the mountain every time we pause to regroup, to plan.” => we ask 1) what gives us the shortest lead time to business impact? 2) what can help us to learn/invalidate more? 3) how to assure our stakeholders we are approaching the goal?
- Joel on Software: Software Inventory (7/2012) – a classical article about the evilness of software inventory (backlogs, issue trackers, undeployed features, …) ‘When I hear about product teams that regularly have “backlog grooming” sessions, in which they carefully waste a tiny amount of time and mental energy every day or every week thinking about every single feature which will never be implemented, I want to poke my eyes out.‘
- Job satisfaction self-test: Twelve questions that define a great place to work – check yourself how satisfied you are with your job (example questions: How well do I know what is expected of me? How often in the past seven days have I received recognition or feedback on my work? How much does the mission/purpose of the company make me feel like my work is important?)
- Coaching Anti-Patterns: Prescriptive Agile – a prescriptive coach “knows” what is “right” and forces it onto the client, without listening to her; instead, we should “Meet them where they are and leave them in a better place” => “[..] my first responsibility is to understand how and why they came to this practice. How did they come to this decision? What challenges does this approach address? What benefits are they optimizing for?” Worth remembering AND practicing
Languages, paradigms, approaches
- The Trouble with Erlang (or Erlang is a ghetto) - an objective criticism of Erlang by somebody who seems to be quite experienced with it; as I know very little about Erlang, it was interesting to learn about its weaknesses (no map/dict data structure, slow memory management, poor “JIT,” not usable for shared-state concurrency (contrary to e.g. Clojure), immutable state is not necessary and makes some things bad, inconsistent and ugly standard lib, …)
- Adventures in Multi Paradigm Programming – different programming paradigms/approaches re-implemented in Emacs Lisp – interesting 1) to see and compare these different approaches and 2) the flexibility of Lisp. Including iteration – Ruby’s map, Python’s list comprehension ([an_expression for x in list]), Scala’s default argument (_); search – Java’s for; arguments: direct, variadic (i.e. any number of args), named args; destructuring and pattern matching in CoffeScript/OCaml style; Haskell-like monads; objects with mixins; namespaces.
- Why bugs don’t like F# – no nulls, immutable data, strong type system, composition of small functions, asynchronous programming abstractions, higher-order functions over collections (no off-by-one), units of measure
- IBM high-fives Netflix open-source tools – it is interesting to see the spreading of Netflix’s open source tools for better cloud infrastructures; f.ex. “Karyon, is what Netflix calls the base container for applications and services built using the NetflixOSS ecosystem; Eureka is mid-tier load balancing; Hystrix controls interactions between myriad distributed services to nip cascading failures in the bud; and Ribbon is a Remote Procedure Call library.”
- ZeroMQ instead of HTTP, for internal services (with implementation in Clojure) – an interesting idea of using ZeroMQ – the sockets on steroids library – instead of HTTP in a way compatible with existing HTTP routing libs; advantages of ZeroMQ: automatic retrial (=> can restart the target service withou noticing), speed, reuse of a connection. The trick is to send a http-like structure (i.e. with method, uri, body) and pass that to Compojure or similar (update: there are now Clojure/core.async bindings for ZeroMQ)
- Joel on Software: Victory Lap for Ask Patents – killing a bad Microsoft patent request in 15 minutes – Ask Patents is a new StackExchange site that enables experts to look at SW patent requests and point to previous existing works that invalidate them; as Joel describes in his successful patent kill story, it is not difficult at all. Hopefully this will manage to really help the patent office and hit woul-be patent trolls hard! #victory
- The Dangers Of “Gamification” In Education by Kathy Sierra (a former game designer, a trainer of trainers at Sun, author of the Head First book series) – gamification is often regarded as something very desirable that will improve our lives; however, as Kathy discusses, it has also dark sides and, applied unappropriately, can actually decrease our intrinsic motivation (therefore it should be nearly never used in e.g. education)
- Choosing an OSS license doesn’t need to be scary (by GitHub) – a human-readable overview of OSS licenses; you should always assign a license to your GitHub account (Add A License can help with that; otherwise it is considered to be “all rights reserved” and you are not giving back to the community (I use the same as Clojure, Eclipse Public License)
- FunctionalTalks.org – “Brilliant people giving brilliant talks on functional programming” – f.ex. Wilkes Joiner: Functional Reactive Programming, Alexander Gounares: All your cores are belong to us, Katie Miller: Superhero monads, Bryan O’Sullivan: Running A Startup On Haskell, Rich Hickey: Introduction To Clojure, John A. De Goes: Building a Data Science Platform in Scala and many more.
- Types vs. Tests: An Epic Battle? – “Amanda Laucher and Paul Snively debate solving problems through types and tests using different approaches.” – can type system replace tests or vice versa? Interesting intro into the discussion for me. Using F#, Scala & more. Same claims: types don’t pay out so much for “small” codebases but scale better than tests. Types – Tests is a spectrum, not two single extremes. When a property should hold “for all,” a type would be a good match. Inductive types (Scala, Haskell?) can become quite complex, dependant types (as in Coq) would be much nicer [if I got that right].
- Paul Irish on Web Application Development Workflow (via M. Noddeland) – if you need to do some web development but are not up to date on the state of art, this might be useful – an overview of tools, utilities, services by a Googler and the person behind Modernizr, HTML5 Boilerplate, Yeoman etc. Including effective shell & dotfiles.GH, better ssh via .ssh/config and authorized_hosts, the all-in-one dev/build tool Yeoman with live reload, BrowserStack for testing, LocalTunnel to easily share anything running locally, Chrome Dev Tools support for SASS and testing devices (emulate touch events, screen sizes), JetBrains’ WebStorm, sharing tools via setapp.me. A genous idea to use GoogleAnalytics to track usage of features in a CLI app!
Other Interesting Stuff
Azul Systems’ high-performance JVM on the Vega architecture (from The Trouble with Erlang (or Erlang is a ghetto)) looks very interesting:
The other night I tweeted “If you’re looking for a language that gets multicore concurrency right, look at how Azul implemented Java on their Vega architecture” and I definitely stand by that. Azul is a company that got a lot of smart hardware and software people together and had them work on designing a custom system which would scale to hundreds of CPU cores (up to 768 of them), heaps that topped 500 GB (up to 768GB), and had the GC pause only 10-20ms at a time. The realtime performance characteristics Azul managed to eek out of their system lead them to often describe their GC as “pauseless”.
- Discussion: How core.async compares to agents, future and promise? – future/promise: 1 producer, 1 value, multiple consumers; agent: an unbounded queue of functions mutating a single value, with multiple producers and consumers (reading the latest value produced); channel: multiple 1:1 producers/consumers, i.e. a value can only be taken once from the channel, using a bounded queue (=> slow consumers can block fast producers). As mentioned elsewhere, channels is a relatively low-level abstraction and other things can be built on the top of it.
- Clojure Tradeoffs (design implications and why you should care) – perhaps not very unbiased but interesting anyway (shared-memory over other computing paradigms, i.e. message-passing, dynamic over static, speed over convenience, composition over IoC, …)
- Rich Hickey’s post introducing core.async with its Go-like channels as a better alternative to a collback hell (I know everybody has already read it but it is still an important link :))
- Tools etc.
- Faster Clojure Startup with Class Data Sharing – use JVM’s capability to include any classes in its boot image and include clojure in it
- lein-ancient – checks for outdated dependencies and plugins => run “lein ancient :all”
- lein-try – a Leiningen plugin that enables you to try a library in a REPL in the context of your project without having to add it to project.clj; simply run “lein try clj-time 0.5.1″ and then in the REPL “(require ‘[clj-time.core :refer :all])” and e.g. “(date-time 1986 10 14)”
- Lemur: tool to launch a Hadoop job locally/on EMR from a job definition file + actions before/after
- Emacs: sexp fold/expand is very useful for exploring source code (hide all but the first lines of all top-level forms with hs-hide-all) – the built-in hs-minor-mode can hide/show all, or hide/show/toggle one but the keys for it are cumbersome; hideshow-org makes it possible to toggle hide/show with TAB, while preserving the original TAB behavior (it does the normal TAB first only only if nothing changes does it expand/fold); very useful!
- devdocs.io (via @palruud): “an all-in-one API documentation reader for [web] developers,” navigable via keyboard – JS, HTML, CSS, DOM, DOM events, jQuery, Underscore.js
- Kilim – a message-passing framework for Java that provides ultra-lightweight threads and facilities for fast, safe, zero-copy messaging between these threads.
- AssertJ – a library of assertions similar to fest-assert but providing a richer set of assertions (nicer API then fest-assert, according to a friend)
- NetflixOSS – Netflix, the online streaming gigant, has open-sourced many fascinating components of its cloud infrastructure such as Karyon, a blueprint for web-ready components with many features (monitoring,…), Genie/Hadoop as a Service, Servo for monitoring, Archaius for configuration management – too many to list. Check out Chris Fregly’s fluxcapacitor, a demo distributed application that uses many of the components
- Tools to keep a daemon running:
Posted by Jakub Holý on July 27, 2013
Running a Java/Clojure app as a daemon on Linux used to be hard but is pretty simple with Ubuntu Upstart (docs). The short story:
- Create an all-in one uberjar via “lein with-profile production ring uberjar” (using the lein-ring plugin; a simple lein uberjar would suffice for an app with a
- Create an upstart <service name>.conf file in /etc/init/
- Run sudo start/stop/status <service name>
And of course it works with Puppet too.
Read the rest of this entry »
Posted in General | Tagged: clojure, DevOps, linux | Comments Off
Posted by Jakub Holý on July 23, 2013
Setting up the new Google Universal Analytics (still in beta) is not completely obvious. You normally won’t be able to send events from localhost and it will claim that “Tracking Not Installed.” Here are some tips how to use Analytics from localhost and test it.
Read the rest of this entry »
Posted in General | Tagged: analytics, frontend, google, troubleshooting, web | Comments Off
Posted by Jakub Holý on July 12, 2013
Incanter 1.5.1 doesn’t support logarithmic axes, fortunately it is easy to add one manually.
Update: Pushed improved version to Incanter.
This is how our final code will look like:
;; core and charts are the incanter namespaces
(defn plot-power 
(let [fun #(Math/pow 10 %)
y-axis (log-axis :label "log(x)")
chart (charts/function-plot fun 0 5)]
(set-axis chart :y y-axis)
(core/view chart :window-title "LogAxis Test: Incanter fun plot")))
Read the rest of this entry »
Posted in General | Tagged: clojure, data, incanter | Comments Off
Posted by Jakub Holý on July 5, 2013
There has been recently an article about how bad, expensive, and wasteful pair-programming is, since you need double as many developers. It used lines of code (LoC) produced per hour as the main metric. As many have commented, LoC is not the best measure, actually just the opposite, as I want to demonstrate on my experience. (The article is questionable also for other reasons, such as providing no data to back its claims of a pari costing 2.5 times more without any quality benefits, which contradicts f.ex. the studies summarized in ch. 17 of Making Software that show one1 1.6* cost + better quality, other 1.15* cost + 15% less failed tests.)
My main point is that by working with another person that you have to justify your plans to, you can be saved from pursuing suboptimal or unnecessary solution, thus considerably reducing both time spent and lines of code produced (more talk, less [wasteful] code).
Read the rest of this entry »
Posted in General, SW development | Tagged: experience, opinion, pairprogramming, practices, xp | Comments Off
Posted by Jakub Holý on June 30, 2013
Agile, process, SW dev, people etc.
- Real Options—a Mindset – an intro into the Real Options approach, which has been quite a hot topic and a transformational way of thinking for a number of inspiring people (Dan North, Liz Keogh etc.). “Real Options help us to better make decisions and commitments with three simple principles: Options have value. Options expire. Never commit early unless you know why.” We can “pay” to keep our options open longer, i.e. to avoid commiting prematurely.
- Demystifying the CHAOS report’s claim of ~ 1/2 features being unused: the Standish Group’s CHAOS report has been often quoted for its “finding” that a large percentage of features in applications is never/rarely used. However this claim seems to have never been confirmed, their “research” is reportedly not very scientific and not publicly available for scrutiny. Critique by Laurent Bossavit (2013), Jorge Aranda’s Standish, the CHAOS report, and science. Thx to @smalltalk80 for pointing this out! However there is one research, Online Experimentation at Microsoft, that supports the claim, in a different context but the same problem applies to features: “Evaluating well-designed and executed experiments that were designed to improve a key metric, only about one-third were successful at improving the key metric!”
- Why Yammer believes the traditional engineering organizational structure is dead – small teams, small projects (2-10 people, 2-10 weeks), no separation into front/middle tier/backend team (=> communication, design obstacle); have instead people specializing in these areas and construct feature teams from them based on the actual needs; engineers, not managers do eng. decisions; all aligned via focusing on the same 3 key metrics. Small projects => constant sense of urgency (and excitement): Often very long projects cause engineers to lose track of the end goal. Think of it in terms of hiking: start fresh & excited, get tired and losing track of the goal, excited again at the end => cut out the middle part, keep them in the exciting state where they can measure progress and see it visually; it’s the only way to maintain urgency and morale. Focus: people alwasy work only at one (short) project at a time (there are special bug-fixing teams for maintenance tasks with people rotating in&out).
- Agile development is more culture than process – Why thinking of agile as culture and not just process explains resistance and difficulty in teaching and learning the approach – and should be taught so => 1. Underscore agile values that motivate practice; 2. Identify organization values that compete with agile values, conflict of values; 3. Be sensitive to culture shock.
- Mark Zuckerberg’s Letter to Investors: ‘The Hacker Way’ (quite long, you might want to read only “The Hacker Way” part at the end) – about Facebook’s “unique culture and management approach” – “Hackers believe that something can always be better, and that nothing is ever complete.” “Hackers try to build the best services over the long term by quickly releasing and learning from smaller iterations rather than trying to get everything right all at once.” “Instead of debating for days [..], hackers would rather just prototype something and see what works.” “Hacker culture is also extremely open and meritocratic.” “Many of our most successful products came out of hackathons, [..].” <=> five core values: Focus on Impact (focus on solving the most important problems, be good at finding the biggest problems to work on); Move Fast (“[..] if you never break anything, you’re probably not moving fast enough.”); Be Bold (“Building great things means taking risks.”); Be Open (=> effort to make as much info as possible visible to all); Build Social Value (“[..] Facebook exists to make the world more open and connected, and not just to build a company. “)
- Dave Nicolett: I know how to tie my shoes – on the difficulty of convincing people to try unfamiliar software development techniques – “People change the way they operate when they are experiencing some sort of inconvenience or negative feedback. As long as things are going along reasonably well, people don’t go out of their way to change the way they work.” (with few exceptions) You can learn to tie your shoes in a split second, but why to invest the effort? You’d need to set aside assumptions, suppress habits, practice. You can argument there are many inconveniences (bugs, criticism for slow delivery, …) but “Unfortunately, that’s all pretty normal, and most people in the software field are accustomed to it. They don’t see it as a problem that calls for them to change their practices. Most of them probably have a hard time visualizing a different reality.” => Maybe that’s the reason there’s been no satisfactory answer to the question of how to convince people to adopt different practices. We shouldn’t be trying to convince people to do anything. We should be helping people solve their problems and achieve their goals. If they are satisfied with the outcomes they achieve using their current methods, then there is no problem to solve.
- Kent Beck: Pace of Progress = Pace of Feedback – ‘”The pace of my progress is completely constrained by the pace of my feedback”. If I want to go faster, it’s hard to achieve by going faster. I can almost always optimize my feedback loop, though.’ “The second lesson from this episode is that it’s not just the duration of the feedback loop that matters, it’s also the quality. All week I was working in tiny little iterations. Without producing useful information, though, those iterations could be as small or as large as I liked, I was still just going to spin my wheels.” => “The next time I seem to be going slow, I’m going to look at my whole feedback loop–duration, quality and my ability to respond to the information.“
- What Google Has Learned About How to Hire People – interview results have no relation to actual performance on the job: “We looked at tens of thousands of interviews, and everyone who had done the interviews and what they scored the candidate, and how that person ultimately performed in their job. We found zero relationship. It’s a complete random mess.” “Instead, what works well are structured behavioral interviews, where you have a consistent rubric for how you assess people, [..]” ‘Behavioral interviewing also works — where you’re not giving someone a hypothetical, but you’re starting with a question like, “Give me an example of a time when you solved an analytically difficult problem.”’ Link to an interesting book, Hiring Geeks That Fit.
Cool tech stuff
- The Elixir language – Clojure + Ruby + Erlang - a functional meta-programming aware language built on top of the Erlang VM; a dynamic language with flexible syntax with macros support that leverages Erlang’s abilities to build concurrent, distributed, fault-tolerant applications with hot code upgrades. First-class support for pattern matching, polymorphism via protocols, etc. (via @bodil)
- Random Testing seems to be gaining popularity and looks very interesting; at NDC Oslo, John Hughes has presented how QuickCheck, which generates random sequences of API calls, has been successfully used to find bugs in the Riak DB and a file system that a human would never think of, and Stuart Halloway has presented simulation testing with Simulant, which runs predefined actions according to a probabilistic model (e.g. 100 traders, each having 1h mean time between trades and mean traded amount 100, the test runs for 4 simulated hours). Something worth exploring!
- Dmytro Navrotskyy’s collection of Frontend Development resources and learning materials for tools (grunt, unused css detection,..), best practices (Atomic Design, …), JS/CSS frameworks, typography, animation, visualization, useful on-line services, and many more (via Herman Schistad)
- The Secret To 10 Million Concurrent Connections – The Kernel Is The Problem, Not The Solution: To have really fast SW, you need to implement your own core services (FS, net driver (packet handling), thread scheduling, ..) tuned for your app. You need to be aware of the clock-time cost of cache misses, memory access etc.. Custom solutions are times faster than what the general OS kernel can offer. => “data plane oriented system” Core areas and solutions for them: packet scalability, multi-core scalability (locks are expensive), memory scalability.
- M. Fowler: EmbeddedDocument – a pattern for working with JSON flowing in/out of our services (REST <-> JSON-friendly DB) without unnecessary conversions but with good encapsulation; naive approach: json -> object graph -> (processing) -> json; “In many of these situtiations a better way to proceed is to keep the data in a JSONish form, but still wrap it with objects to coordinate manipulation.” – use a lib to parse the JSON into a generic structure (e.g. a structure of lists, and maps/dicts) and store in a field of an object defining methods that encapsulate it – f.ex. for an Order we could have a method returning the customer and another computing the cost, accessing the underlying generic structure. The user of the wrapper object doesn’t need to know/care about the underlying structure. “The sweet spot for an embedded document is when you’re providing the document in the same form that you get it from the data store, but still want to do some manipulation of that data. [..] The order object needs only a constructor and a method to return its JSON representaiton. On the other hand as you do more work on the data – more server side logic, transforming into different representations – then it’s worth considering whether it’s easier to turn the data into an object graph.”
- ThoughtWorks’ Approach To Big Data Analytics – an inspiring, brief read. Some really good points such as “It’s not about Data. It’s about Insight and Impact” => “focus on the questions you’d love to answer for your business” => “changing big data from a technological problem to a business solution.” Also “The value of data is only realised through insight. And insight is useless until it’s turned into action.” Measure the value you gain at each step. See Introducing Agile Analytics: A Value-Driven Approach to Business Intelligence and Data Warehousing by Ken Collier
- Wired.com, Nassim Taleb: Beware the Big Errors of ‘Big Data’ – in big data, noise has much stronger effect and in a large enough dataset we will always find spurious (i.e. false) relationships => beware! “Well, if I generate (by simulation) a set of 200 variables — completely random and totally unrelated to each other — with about 1,000 data points for each, then it would be near impossible not to find in it a certain number of “significant” correlations of sorts. But these correlations would be entirely spurious.”
- A Taste of Salt: Like Puppet, Except It Doesn’t Suck – a deescription of Salt and the tools around by an enthusiastic user with deep experience with Puppet. Highlights: Light-weight communication over ZeroMQ, very active community, simplicity, configuration is YAML, Salt-cloud can spin instances in EC2/Openstack/…, Salt-virt does the same for virtual machines (KVM/Xen/…), Salt-vagrant, Salt-monitor (work in progess) can ask all the server for their stats. “Having stood up a number of different configuration management systems across a wide variety of environments, I’ve yet to find a solution that’s as rapid to deploy, simple to scale, or as well architected as Salt.”
- Trash Your Servers and Burn Your Code: Immutable Infrastructure and Disposable Components – leveraging the lectures of PF to have a stable infrastructure – instead of updating servers, throw them away and create a new one from scratch (requires virtualization/cloud); this is something that Netlfix is doing and also Comoyo is moving towards
- Robin Ward: AngularJS vs Ember – a nice overview of the different approaches of the two; the author is strongly pro-Ember, claiming that AngularJS is much closer to low-end libraris like Backbone/Knockout and that you will often need the additional features of Ember. The comments provide the right countrweight to the biased post and form thus a good whole together.
- Scala Productivity. A Survey of the Community – people (that asnwered) seem to be productive with Scala right from the start
- After Your Job Is Gone – an interesting essay on the future, which, according to the author, we can already see happening, when technology will take away most of our work and we will not need to work all day. Not very optimistic, though (the author predicts few reach and many poor people).
- Clojure Cup 2013, Sept 28-29 – create something cool with Clojure/ClojureScript within 48h and perhaps win a price! #fun
- Clojure use in the industry – examples at an e-mail forum – Netflix, Puppet Labs (e.g. PuppetDB), UBS (talk), Deutsche Bank (talk, some details), Citigroup (reportedly “the largest private sector deployment of Clojure to date,” 11/2012), getprismatic.com (with frontend moving to ClojureScript; -> Why Prismatic Goes Faster With Clojure), Roomkey.com (details in a Relevance podcast), MastodonC.com (big data), Trend Micro, Walmart, beanstalkapp.com, ReadyForZero.com (50kLoC), www.cognician.com (20kLoC), World Singles (13kLoC) and more… (another similar thread)
- Stuart Sierra’s My Clojure Workflow, Reloaded (6/2013) – mainly about reloading changes into REPL, working around things that are not reloaded/left over => restart the app from scratch after significant changes => the app as a transient object => no global state, careful management of resources, :dev profile with :source-paths to a dir with user.clj (autoloaded by repl, pre-loading useful stuff) and dev util deps
- Adam Bard’s walk-through useful Clojure libs – f.ex. clojure.[data.[csv xml json] inspector java.shell java.browse xml], tools.logging, clojure.core.[match logic typed contracts ...]
- Juxt.pro: Jon Pither’s and Malcolm Sparks’ “network of experienced IT professionals who specialise in the Clojure programming language,” providing training, consulting, talks
- Anthony Grimes: The Clojure Community and Me (2011) – an exciting insight into the embracing and supportive Clojure community
- In Clojure-based Machine Learning: “Our backend is 99.4% coded in Clojure, and 66% of the team [of 3] had never programmed seriously in any Lisp, let alone Haskell or Prolog (heck, not even I (the remaining 33%) had actually tried anything non-mainstream for real in a big project!) Maybe some Ruby, and lots and lots of Java and C and C++. But they accepted the challenge after reading around and learning the basics, and 3 months later you couldn’t take Clojure from their prying hands.”
- J. Pither: TDD and Clojure – “If you were to create a shopping list of things you really want for your development experience then what would you put at the top?” => 1. rapid feedback on changes, 2. REPL (place to explore and to play with your code <=> TDD), 3. FP and Immutability (“FP and dynamic languages lead to a lot less code. There’s less ceremony, less modeling. Because you’re managing less code you do less large scale refactorings.” => TDD needed less), 4. Regression Tests (“It’s my current opinion that what you get left out of TDD once you have amazingly fast feedback and a REPL is regression testing.”)
- More beautiful and colorful git log, by Filipe Kiss (via @lcdutoit) You may also want to have a look at tig, which is a text-based UI for git with the default view similar to git log.
- jq (via lcdutoit) – sed/awk/grep for JSON – slice, filter, map, transform structured data
- SemanticMerge (Windows) – a Java-aware merge tool – free beta (I haven’t tried it)
- JetLang – a high performance java threading library for in-memory messaging, based upon Retlang (via @tastapod, used likely in a trading SW).
Agile [is] in NOT a process — it’s a philosophy.
- Joe Wroblewski in a comment to a blog post
Teach culture first, then process and techniques
- Jeff Patton in Agile development is more culture than process
If a candidate came telling me that s/he wanted to program only in, say, Java because that’s what s/he knows best and that s/he doesn’t really feel prepared or interested in learning and using, say, Clojure (or any other language, really), I wouldn’t hire her/him in a million years, no matter what language my project were using, and no matter how many thousands of candidates like this one I had at my disposal.
- José Antonio Ortega in Clojure-based Machine Learning
We shouldn’t be trying to convince people to do anything. We should be helping people solve their problems and achieve their goals. If they are satisfied with the outcomes they achieve using their current methods, then there is no problem to solve.
- Dave Nicolett in I know how to tie my shoes
Posted in General, Languages, Testing, Tools, Top links of month | Tagged: bigdata, clojure, DevOps, fp, frontend, Git, java, lean, performance, simulation, waste | Comments Off
Posted by Jakub Holý on June 28, 2013
John Hughes and Stuart Halloway had very interesting talks about random testing at NDC Oslo, a topic I have been ignorant of but want to explore more now. Contrary to the typical example-based unit tests where the developer specifies inputs, interactions, and specific validations, random testing generates random input data and/or sequences of interactions and the verification is based on more general checks. Random testing can check many more cases than a developer would ever write and cases that a human would never think of. It can thus discover defects impossible to find by the traditional testing, as has been demonstrated f.ex. on Riak.
Random testing typically starts by creating (likely a very simplified) model of the system under test. The model is then used to generate the random data inputs and/or sequences of actions (method calls). Then the tests are executed and their input and output data captured. Finally the results are validated, either against predefined “system properties,” i.e. invariants that should always hold true, or manually by the developer.
Related/also known as: generative testing, property-based testing (a paper).
Read the rest of this entry »
Posted in Testing | Tagged: clojure, random, simulation | Comments Off
Posted by Jakub Holý on June 22, 2013
Highlights from Dan North‘s excellent, inspiring, and insightful talk Patterns of Effective Delivery at RootConf 2011. North has a unique take on what agile development is, going beyond the established (and rather limitied and rigid) views. I really recommend this talk to learn more about effective teams, about North’s “shocking,” beyond-agile experience, and for great ideas on improving your team.
The talk challenges the absolutism of some widely accepted principles of “right” software development such as TDD, naming, the evilness of copy&paste. However the challenge is in a positive way: it makes us think in which contexts these principles really help (in many) and when it might be more effective to (temporarily) postpone them. The result is a much more balanced view and better undestanding of their value. A lot of it is inspired by the theory (and practice) of Real Options.
What are Patterns of Effective Delivery?
- Patterns – strategies that work in a particular context – and not in another (too often we forget the context and to consider the context where a strategy doesn’t work / is contra-productive); beware: a part of the context is the experience of the developer; for unexperienced devs it might be better to just stick to a process and applying TDD etc. all the time than trying to guess when they are appropriate and when not without having the experience to decide it right
- Effective – optimize for something: volume of SW produced? time to market? learning/discovery? certanity? user experience?
- Delivery – get stuff that is useful out of the door; software is not important, the utility it provides is; know why you write the SW to be able to get better at it
Read the rest of this entry »
Posted in General | Tagged: agile, architecture, effectivity, favourite, lean, patterns, review, team | Comments Off