- GM: That Car You Bought, We’re Really the Ones Who Own It — GM’s claim is all about copyright and software code, and it’s the same claim John Deere is making about their tractors. The TL;DR version of the argument goes something like this: cars work because software tells all the parts how to operate; the software that tells all the parts to operate is customized code; that code is subject to copyright; GM owns the copyright on that code and that software; a modern car cannot run without that software; it is integral to all systems; therefore, the purchase or use of that car is a licensing agreement; and since it is subject to a licensing agreement, GM is the owner and can allow/disallow certain uses or access. In the future, manufacturers own the secondary market.
- Architectural Robots (Robohub) — The concept is named ‘Minibuilders.’ This is a group of robots each performing a specific task. The first robot layers a 15 cm (6 in) footprint or foundation, while a second and a third robot print the rest of the building by climbing over the structures they already printed and laying more material over them. This design is only possible at construction scale where printed layers are solid enough to support a robotic print head.
- The Psychology of UX — digging into 10 things about human psychology that should inform UX.
- gigo — Fetching packages in golang can be difficult, especially when juggling multiple packages and private repositories. GIGO (Gigo Installer for Go) tries to solve that problem, effectively being the golang equivalent of Python’s pip.
Finding the holes in qualitative and quantitative testing.
I can’t tell you how often I hear things from engineers like, “Oh, we don’t have to do user testing. We’ve got metrics.” Of course, you can almost forgive them when the designers are busy saying things like, “Why would we A/B test this new design? We know it’s better!”
In the debate over whether to use qualitative or quantitative research methods, there is plenty of wrong to go around. So, let’s look at some of the myths surrounding qualitative and quantitative research, and the most common mistakes people make when trying to use them.
How inclusivity, complexity, and empathy are shaping DevOps.
Over the next five years, three ideas will be central to DevOps: the need for the DevOps community to become more Inclusive; the realization that increasing Complexity of systems is the underlying reason for DevOps; and the critical role of Empathy in the growth and adoption of DevOps. Channeling John Willis, I’ll coin my own DevOps acronym, ICE, which is shorthand for Inclusivity, Complexity, Empathy.
There is a major expansion of the DevOps community underway, and it’s taking DevOps far beyond its roots in agile systems administration at “unicorn” companies (e.g., Etsy or Netflix). For instance, a significant majority (80-90%) of participants at the Ghent conference were first-time attendees, and this was also the case for many of the devopsdays in 2014 (NYC, Chicago, Minneapolis, Pittsburgh, and others). Moreover, although areas outside development and operations were still underrepresented, there was a more even split between developers and operations folks than at previous events. It’s also not an accident that the DevOps Enterprise conference took place the week prior to the fifth anniversary devopsdays and included talks about the DevOps journeys at large “traditional” organizations like Blackboard, Disney, GE, Macy’s, Nordstrom, Raytheon, Target, UK.gov, US DHS, and many others.
The DevOps community has always been open and inclusive, and that’s one of the reasons why in the five years since the word “DevOps” was coined, no single, widely accepted definition or practice has emerged. The lack of definition is more of a blessing than a curse, as DevOps continues to be an open conversation about ways of making our organizations better. Within the DevOps community, old-time practitioners and “newbies” have much to learn from each other.