# "devops" entries

## Four short links: 4 June 2015

### DARPA Robotics Challenge, Math Instruction, Microservices Construction, and Crypto Hardware Sans Spooks

1. Pocket Guide to DARPA Robotics Challenge Finals (Robohub) — The robots will start in a vehicle, drive to a simulated disaster building, and then they’ll have to open doors, walk on rubble, and use tools. Finally, they’ll have to climb a flight of stairs. The fastest team with the same amount of points for completing tasks will win. The main issues teams will face are communications with their robot and battery life: “Even the best batteries are still roughly 10 times less energy-dense than the kinds of fuels we all use to get around,” said Pratt.
2. Dan Meyer’s Dissertation — Dan came up with a way to make math class social and the vocabulary sticky.
3. Monolith First — echoes the idea that platforms should come from successful apps (the way AWS emerged from operating the Amazon store) rather than be designed before use.
4. Building a More Assured Hardware Security Module (PDF) — proposal for An open source reference design for HSMs; Scalable, first cut in an FPGA and CPU, later allow higher speed options; Composable, e.g. “Give me a key store and signer suitable for DNSsec”; Reasonable assurance by being open, diverse design team, and an increasingly assured tool-chain. See cryptech.is for more info.

## A “have-coffee” culture

### Tending the DevOps victory garden.

Download a free copy of Building an Optimized Business, a curated collection of chapters from the O’Reilly Web Operations and Performance library. This post is an excerpt by J. Paul Reed from DevOps in Practice, one of the selections included in the curated collection.

Any discussion surrounding DevOps and its methodologies quickly comes to the often delicate issue of organizational dynamics and culture, at least if it’s an accurate treatment of the topic. There is often a tendency to downplay or gloss over these issues precisely because culture is thought of as a “squishy” thing, difficult to shape and change, and in some cases, to even address directly. But it doesn’t need to be this way.

Sam Hogenson, Vice President of Technology at Nordstrom, works hard to make sure it’s exactly the opposite: “At Nordstrom, we value these different experiences and we value the core of how you work, how you build relationships much more than whether or not you have subject matter expertise. It’s a successful formula.” Another part of that formula, Hogenson notes, is the ethos of the organization: “It’s a very empowered workforce, a very decentralized organization; I always remember the Nordstroms telling us ‘Treat this as if it were your name over the door: how would you run your business and take care of your customers?'” [Nordstrom infrastructure engineer Doug] Ireton described it as a “have-coffee culture: if you need to talk to someone, you go have coffee with them.”

## Four short links: 21 May 2015

### Font Design, Pro Go, ICANN Foolishness, and Bad Organisations

1. On Font Design (Kris Sowersby) — The many pairs of hands and eyes involved have made this typeface special for me. For the first time I don’t feel I have ownership of a typeface I have ostensibly “created.” Lovely to read about the design journey for a font.
2. Why We Use GoWe use Go because it’s boring. Previously, we worked almost exclusively with Python, and after a certain point, it becomes a nightmare. You can bend Python to your will. You can hack it, you can monkey patch it, and you can write remarkably expressive, terse code. It’s also remarkably difficult to maintain and slow.
3. Unfortunately We Have Renewed Our ICANN AccreditationYou can thank ICANN for this policy, because if it were up to us, and you tasked us with coming up with the most idiotic, damaging, phish-friendly, disaster-prone policy that accomplishes less than nothing and is utterly pointless, I question whether we would have been able to pull it off at this level. We’re simply out of our league here.
4. Why Good Developers Write Bad Code (PDF) — trigger warning: software development pathologies from the real world.

## Four short links: 19 May 2015

### Wrist Interactions, Kubernetes Open Source Success, Product Quality, and Value of Privacy

1. Android Wear vs Apple Watch (Luke Wroblewski) — comparison of interactions and experiences.
2. Eric Brewer on Kubernetes — interesting not only for insights into Google’s efforts around Kubernetes but for: There’s so much excitement we can hardly handle all the pull requests. I think we’re committing, based on the GitHub log, something like 40 per day right now, and the demand is higher than that. Each of those takes reviews and, of course, there’s a wide variety of quality on those. Some are easy to review and some are quite hard to review. It’s a success problem, and we’re happy to have it. We did scale up the team to try and improve its velocity, but also just improve our ability to interact with all of the open source world that legitimately wants to contribute and has a lot to contribute. I’m very excited that the velocity is here, but it’s moving so fast it’s hard to even know all the things that change day to day. Makes a welcome change from the code dumps that are some of Google’s other high-profile projects.
3. We Don’t Sell Saddles Here — Stewart Butterfield, to his team, on product development and quality. Every word of this is true for every other product, too.
4. What is Privacy Worth? (PDF) — When endowed with the $10 untrackable card, 60.0% of subjects claimed they would keep it; however, when endowed with the$12 trackable card only 33.3% of subjects claimed they would switch to the untrackable card. […] This research raises doubts about individuals’ abilities to rationally navigate issues of privacy. From choosing whether or not to join a grocery loyalty program, to posting embarrassing personal information on a public website, individuals constantly make privacy-relevant decisions which impact their well-being. The finding that non-normative factors powerfully influence individual privacy valuations may signal the appropriateness of policy interventions.

## Four short links: 15 May 2015

1. Army Cloud Computing Strategy (PDF) — aka: “what we hope to do without having done, to use what we’re doing to them.”
2. Guide to Technical Development (Google) — This guide is a suggested path for university students to develop their technical skills academically and non-academically through self-paced, hands-on learning.
3. Immutable Infrastructure is the Future (Michael DeHaan) — The future of configuration management systems is in deploying cloud infrastructure that will later run immutable systems via an API level.
4. machineryan asynchronous task queue/job queue based on distributed message passing.

## Four short links: 14 May 2015

### Human-Machine Cooperation, Concurrent Systems Books, AI Future, and Gesture UI

1. Ghosts in the Machines (Courtney Nash) — People are neither masters of machines, nor subservient to their machine-learning outcomes — we cannot, and should not, separate the two. We are actors, together, in a very complex system. David Woods calls this “joint cognitive systems.”
2. TLA+ (Leslie Lamport) — two tutorials: “Principles of Concurrent Computing” and “Specification of Concurrent Systems.” Ironically, I see people grizzling that the book on distributed systems hasn’t been linearised. I wonder if you can partition it into the two tutorials and still have full availability…
3. Deep Learning vs Probabilistic vs LogicAs of 2015, I pity the fool who prefers Modus Ponens over Gradient Descent.
4. Touché (Disney Research) — measur[es] capacitive response of object and human at multiple frequencies, a technique that we called Swept Frequency Capacitive Sensing. The signal travels through different paths depending on its frequency, capturing the posture of human hand and body as well as other properties of the context. The resulted data is classified using machine learning algorithms to identify gestures that are then used to trigger desired responses of the user interface.

## Four short links: 7 May 2015

### Predicting Hits, Pricing Strategies, Quis Calculiet Shifty Custodes, Docker Security

1. Predicting a Billboard Music Hit (YouTube) — Shazam VP of Music and Platforms at Strata London. With relative accuracy, we can predict 33 days out what song will go to No. 1 on the Billboard charts in the U.S.
2. Psychological Pricing Strategies — a handy wrap-up of evil^wuseful pricing strategies to know.
3. What Two Programmers Have Revealed So Far About Seattle Police Officers Who Are Still in Uniformthrough their shrewd use of Washington’s Public Records Act, the two Seattle residents are now the closest thing the city has to a civilian police-oversight board. In the last year and a half, they have acquired hundreds of reports, videos, and 911 calls related to the Seattle Police Department’s internal investigations of officer misconduct between 2010 and 2013. And though they have only combed through a small portion of the data, they say they have found several instances of officers appearing to lie, use racist language, and use excessive force—with no consequences. In fact, they believe that the Office of Professional Accountability (OPA) has systematically “run interference” for cops. In the aforementioned cases of alleged officer misconduct, all of the involved officers were exonerated and still remain on the force.
4. Understanding Docker Security and Best Practices — explanation of container security and a benchmark for security practices, though email addresses will need to be surrendered in exchange for the good info.

## Four short links: 6 May 2015

### Self-Driving Cars, Cloud BigTable, Define "Uptime," and Continuous Delivery Architectures

1. Andrew Ng (Wired) — I think self-driving cars are a little further out than most people think. There’s a debate about which one of two universes we’re in. In the first universe it’s an incremental path to self-driving cars, meaning you have cruise control, adaptive cruise control, then self-driving cars only on the highways, and you keep adding stuff until 20 years from now you have a self-driving car. In universe two you have one organization, maybe Carnegie Mellon or Google, that invents a self-driving car and bam! You have self-driving cars. It wasn’t available Tuesday but it’s on sale on Wednesday. I’m in universe one. I think there’s a lot of confusion about how easy it is to do self-driving cars. There’s a big difference between being able to drive a thousand miles, versus being able to drive anywhere. And it turns out that machine-learning technology is good at pushing performance from 90 to 99 percent accuracy. But it’s challenging to get to four nines (99.99 percent). I’ll give you this: we’re firmly on our way to being safer than a drunk driver.
2. Google Cloud BigTable — Google’s BigTable, with Apache HBase API, single-digit millisecond latency, and “fully managed”. G are hell-bent on catching up with Amazon and Microsoft at this cloud serving thing.
3. Call Me Maybe: AerospikeWe’re setting a timeout of 500ms here, and operations still time out every time a partition between nodes occurs. In these tests we aren’t interfering with client-server traffic at all. Aerospike may claim “100% uptime”, but this is only meaningful with respect to particular latency bounds. Given Aerospike claims millisecond-scale latencies, you may want to reconsider whether you consider this “uptime”.
4. 31 Continuous Delivery Architectures (Slideshare) — from a vendor, so one name crops up repeatedly (other than “Jenkins”), but it’s still good devops voyeurism/envy.

## The two-sided coin of Web performance

### Hacking performance across your organization.

I’ve given Web performance talks where I get to show one of my favorite slides with the impact of third-party dependencies on load time. It’s the perfect use case for “those marketing people,” who overload pages with the tracking pixels and tags that make page load time go south. This, of course, would fuel the late-night pub discussrion with fellow engineers about how much faster the Web would be if those marketing people would attend a basic Web performance 101 course.

I’ve also found myself discussing exactly this topic in a meeting. This time, however, I was the guy arguing to keep the tracking code, although I was well aware of the performance impact. So what happened?

## Chaos Monkey for systems of people: The ultimate performance hack

### The O'Reilly Radar Podcast: Alois Reitbauer on performance hacking, DevOps applications, and fostering a culture of respect.

Subscribe to the O’Reilly Radar Podcast to track the technologies and people that will shape our world in the years to come.

In this week’s episode of the Radar Podcast, O’Reilly’s Courtney Nash chats with Alois Reitbauer, chief evangelist at Ruxit, about how DevOps is deeply woven into the Ruxit culture. Reitbauer also talks about how the term “performance hacking” came about at Ruxit, why Chaos Monkey should be applied to systems of people, and why trust across — and between — all departments in an organization is essential.

## DevOps beyond DevOps

Performance hacking is a term that emerged at Ruxit about a year ago as the company prepared for the beta launch, Reitbauer said, when they realized as the company scaled up, they needed to bring everyone from all their teams together. “The idea of performance hacking, then,” he noted, “was really, how can we scale up this collaboration between the DevOps teams, the product development teams, and our go-to-market growth hacking teams while we grow as an organization.” The ultimate aim was to figure out how to continue to act like a three-person, one-room startup as the company scaled to a couple hundred people.

One of the approaches embraced at Ruxit is to apply some of the DevOps best practices to their growth hacking and product development strategies. As an example, Reitbauer offered up the idea of Chaos Monkey, as applied not to AWS instances, but to the organization as a whole. The way it works, he explained, is to send a member of a team — any team — away on short notice (or no notice) and see what breaks. Reitbauer said that they’d actually done this and outlined what they learned from the exercise:

We have done it, and it also came up as part of our regular organizational practices. Like, when we had our first very strong conference season — we sent people to different shows all over the place; we picked people from the team who had to go somewhere. And even if people knew they were going to be out of the office in a couple of weeks, they still started to behave as if they would be around all the time, that they wouldn’t be leaving the office. Then, suddenly they were on a plane. They had no time to do their everyday work, and suddenly they realized where they really needed help. So, you don’t even have to make it a total surprise. You just have to plan how to get people out of their regular working behavior to do something else. Then we were able to figure out, ‘We really need somebody else to be able to jump in here or to help somebody out over there.’ It might be a regular holiday or just not daily routine.