- Microservices in Go — tale of rewriting a Ruby monolith as Go microservices. Interesting, though being delivered at Gophercon India suggests the ending is probably not unhappy.
- Watch & Wear (John Cross Neumann) — Android watch as predictor of the value and experience of an Apple Watch. I believe this is the true sweet spot for meaningful wearable experiences. Information that matters to you in the moment, but requires no intervention. Wear actually does this extremely well through Google Now. Traffic, Time to Home, Reminders, Friend’s Birthdays, and Travel Information all work beautifully. […] After some real experience with Wear, I think what is more important is to consider what Apple Watch is missing: Google Services. Google Services are a big component of what can make wearing a tiny screen on your wrist meaningful and personal. I wouldn’t be surprised after the initial wave of apps through the app store if Google Now ends up being the killer app for Apple Watch.
- Solving 11 Likely Problems In Your Multithreaded Code (Joe Duffy) — a good breakdown of concurrency problems, including lower-level ones than high-level languages expose. But beware. If you try this [accessing variables with synchronisation] on a misaligned memory location, or a location that isn’t naturally sized, you can encounter a read or write tearing. Tearing occurs because reading or writing such locations actually involves multiple physical memory operations. Concurrent updates can happen in between these, potentially causing the resultant value to be some blend of the before and after values.
- Obama Sharply Criticizes China’s Plans for New Technology Rules (Reuters) — In an interview with Reuters, Obama said he was concerned about Beijing’s plans for a far-reaching counterterrorism law that would require technology firms to hand over encryption keys, the passcodes that help protect data, and install security “backdoors” in their systems to give Chinese authorities surveillance access. Goose sauce is NOT gander sauce! NOT! Mmm, delicious spook sauce.
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.
Design is transforming the way things are to the way they ought to be.
Design aligns humans and technology, it aligns business and engineering, it aligns digital and physical, and it aligns business needs and user needs. Here at O’Reilly, we’re fascinated by the design space, and we’re launching several initiatives focused on the experience design community.
Design is both the disruptor and being disrupted. It’s disrupting markets, organizations, and relationships, and forcing us to rethink how we live. The discipline of design is also experiencing tremendous growth and change, largely influenced by economic and technology factors. No longer an afterthought, design is now an essential part of a product, and it may even be the most important part of a product’s value. Read more…