Links: 4/2
Business / Government / Management / News
Google Could Owe Oracle $8.8 Billion in Android Fight
Google could owe Oracle Corp. billions of dollars for using Oracle-owned Java programming code in its Android operating system on mobile devices, an appeals court said, as the years-long feud between the two software giants draws near a close.
Google’s use of Java shortcuts to develop Android went too far and was a violation of Oracle’s copyrights, the U.S. Court of Appeals for the Federal Circuit ruled Tuesday. The case — first filed in 2010 — was remanded to a federal court in California to determine how much the Alphabet Inc. unit should pay. Oracle had been seeking $8.8 billion, though that number could grow. Google expressed disappointment and said it’s considering its next steps in the case.
The dispute, which could have far-reaching implications for the entire software industry, has divided Silicon Valley for years between those who develop the code that makes software steps function and those who develop software programs and say their “fair use” of the code is an exception to copyright law.
“It’s a momentous decision on the issue of fair use,” lawyer Mark Schonfeld of Burns & Levinson in Boston, who’s been following the case and isn’t involved. “It is very, very important for the software industry. I think it’s going to go to the Supreme Courtbecause the Federal Circuit has made a very controversial decision.”
- This is not ideal.
- Let’s hope it ends up with the Supreme Court. And more importantly that they don’t screw this up.
Au Revoir
Today I’m announcing my departure from Docker, the company I helped create ten years ago and have been building ever since. A founder’s departure is usually seen as a dramatic event. Sadly, I must report that reality is far less exciting in this case. I’ve had many roles at Docker over the years, and today I have a new, final one — as an active board member, a major shareholder and, I expect, a high maintenance Docker user. But I will no longer be part of day-to-day operations. Instead, after obsessing for so many years over my own ideas, I am rediscovering the joys of putting myself at the service of others — my friends, my family, and the brilliant entrepreneurs I’ve been lucky enough to advise and invest in over the years. Over the coming months I plan to use my experience to help them in any way I can.
This transition is simply another chapter in a long story of change, growth, hard work… and a lot of luck.
- He (Docker) made quite the impact on the industry.
- I was at this presentation and could not wait to get my hands on Docker.
- Good luck Solomon.
The CEO of Barstool Sports Says She Measures Job Candidates’ Responsiveness by Texting Them at Odd Hours on the Weekends
If Erika Nardini is going to hire you, first she wants to know you’re committed to your job — even on a Sunday at 11 a.m.
Nardini is the CEO of the sports and men’s lifestyle site Barstool Sports. In a recent New York Times interview, she detailed her process for vetting job candidates. After saying she was a “horrible interviewer” because of her impatience, she explained a unique process for gauging potential hires’ interest in the job.
“Here’s something I do,” she said. “If you’re in the process of interviewing with us, I’ll text you about something at 9 p.m. or 11 a.m. on a Sunday just to see how fast you’ll respond.”
The maximum response time she’ll allow: three hours.
- To hell with this.
- It’s on us as employers and employees to push back on this nonsense. Especially in the tech industry where many employees have significant leverage right now.
The 6 Ws of Software Development
Every story begins with the first word. Every drawing begins with the first stroke. Every journey begins with it’s first step. Solving a problem or creating something new has a beginning, a middle and an end. I wanted to share some thoughts on what I have found to be effective to help me and the teams I have worked with solve problems or deliver new capabilities well. Disclaimer: this post is not blanket advice and there is a spectrum of complexity where there are diminishing returns on any methodology. Here are a few steps that I wander down when trying to solve both really hard problems and the occasional easy one.
- Disclaimer: I worked with Ross at Workiva and consider him a good friend.
- This post aligns very much with my view of the world. It’s not about specifics. It’s about a mentality. A mentality that is difficult to hold as systems grow in complexity. And as the frustrations of life add up. And as time crunches, failures and mistakes seem to outweigh the good. But we must always remember that it’s the journey, the process that matters. We should worry less about the unattainable outcomes and focus on maximizing value from the majority of our day. And the majority of our day is the process.
Systems / Infrastructure / Cloud
Performance Under Load
At Netflix we are obsessed with service availability, and we’ve written several blog posts over the years about how we achieve our goals. These techniques include circuit breakers, concurrency limits, chaos testing and more. Today we’re announcing our most recent innovation: adaptive concurrency limits. Adaptive concurrency limits fundamentally improve how an application behaves under extreme load, and allow us to avoid cascading service failures. We have eliminated the arduous task of trying to determine the concurrency limit of a system, while ensuring that latencies remain low. With this announcement, we’re also open-sourcing a simple Java library with integrations for servlets, executors and GRPC.
- I believe processes like this are going to become more commonplace as we work within more dynamic systems. We actually make the system even more dynamic by allowing it to react and adapt to its environment vs prescribing it based on assumptions and maybe data over time and then manually adapting it. Just automate that in.
- This is a place that I think something like Istio will be interesting to watch.
Moving Past Shallow Incident Data
In fact, I believe that the industry as a whole is giving this shallow data much more attention than it warrants. Certainly, filtering this shallow data as means, medians, and other central tendency metrics obscures more about the incidents than it actually reveals.
This is largely because incidents are much more unique than conventional wisdom would have you believe. Two incidents of the same length can have dramatically different levels of surprise and uncertainty in how people came to understand what was happening. They can also contain wildly different risks with respect to taking actions that are meant to mitigate or improve the situation. Incidents are not widgets being manufactured, where limited variation in physical dimensions is seen as key markers of quality.
Incidents are dynamic events with people making decisions under time pressure and insufficient data, and the focus of attention in an incident can change quickly and unexpectedly from one moment to the next.
- Sometimes it’s easy to spot those that have actually dealt with many incidents and their variations.
- There’s been a decent amount of work coming from the theory side of systems. And so many tools coming from those attempting to capitalize. But not nearly enough of discussion around the practical, day to day dealings of incidents by your average company. I’m happy John is attempting to take the lead here. (And yes I know he’s attempting to capitalize as well but we all are at some level. Doesn’t mean that it doesn’t help.)
Quick Hits:
- Kubernetes Engine Private Clusters now available in beta
- New — Amazon DynamoDB Continuous Backups and Point-In-Time Recovery (PITR)
- Looking back at 10 years of compartmentalization at AWS
- Anna: A KVS for any scale
- Kubernetes Races to Fix Regressions Introduced by Recent Security Patches
- Serverless is eating the stack and people are freaking out — as they should be (Good)
- Introducing Stackdriver APM and Stackdriver Profiler
- Amazon ECS Service Discovery
- Through the looking glass: Security and the SRE
- On Ways To Agree, Part 1: Links, Generals and Impossibility Problem
- Migrating to Kubernetes with zero downtime: the why and how
Programming
Putting the I back in IDE: Towards a Github Explorer
Imagine a system for editing and reviewing code where:
- Every branch of every repo gets its own sandboxed directory. Your revision history in each branch, including uncommitted stuff, is persisted, as are build artifacts. When you switch contexts, each project is just as you left it.
- Within your editor, you can pull up a global view of all your branches, your outstanding pull requests, and the pull requests you’re assigned to review. It’s one keystroke to view the summary for a pull, and one more to start editing any of its files right there under your cursor.
- Code review happens entirely within the editor. You’re fed a series of diffs: one keystroke to approve, one keystroke to start editing. Dive in, make your changes, leave comments for the author, push, and move on.
We’ve actually developed this workflow at Jane Street, and it’s been used daily by hundreds of engineers for about two years now. It feels like what an integrated development environment is supposed to feel like. Making software today is as much about collaboration as it is about writing your own code. But most developers are forced to switch from their editor to a web browser to read someone else’s code, and switch back if they want to play with it themselves.
Code review that takes place in a browser isn’t just more inconvenient, it’s often shallower, too: to really understand a piece of code you have to build it, run it, and explore it with your own hands, in your own editor. The system we’ve built at Jane Street is designed to make that level of engagement seamless.
- That last paragraph is dead on. This process they’ve laid out here is fantastic.
- This post triggered so many dev workflow ideas for tools, etc in my head.
Math / Science / Behavior / Economics
Coping with Complexity: The psychology of human behavior in complex systems
- I’m not going to copy some text in as it’s just photos. But my God read this. It summarizes everything I’ve been thinking about the past few years. I want more. So much more.
A parlor trick for SET
Tai-Danae Bradley is one of the hosts of PBS Infinite Series, a delightful series of vignettes into fun parts of math. The video below is about the same of SET, a favorite among mathematicians. Specifically, Tai-Danae explains how SET cards lie in (using more technical jargon) a vector space over a finite field, and that valid sets correspond to lines. If you don’t immediately know how this would work, watch the video.
In this post I want to share a parlor trick for SET that I originally heard from Charlotte Chan. It uses the same ideas from the video above, which I’ll only review briefly.
- This is a cool trick for a fun game.
AI / Machine Learning / Data Science
Practicing AI teams don’t know about bias
We are always trying to learn from others within academia and the industry. Research alone into AI, machine learning, deep learning, etc. has increased 9x since 1996. We wondered what other people in the industry were doing when applying these technologies to people’s problems and lead to us creating the Design for AI survey.
At first, we were really focused on the design side and wondered how other teams were doing it. Over 18 questions (~7 minutes per response on average) we dove into how people work on teams building AI. We would find that there was less concern about UX design and more concern about team communication.
While there is a lot of interesting information in the report, I wanted to go further into a few of the takeaways and provide some recommendations we have to address them. In particular, I want to talk about alignment, communication, and what teams should be focusing on more while building AI projects.
- I’m glad people are doing this research and this is why:
The biggest problem is that teams don’t even know whether bias should impact their AI projects. They are not even having the conversation.
- That is concerning and sadly, not surprising.
If you’re looking for help with your architecture or development organization feel free to reach out: realkinetic.com @real_kinetic
You can follow me directly @lyddonb
