Writings and links of interest
[…] we’ve attempted to build a ProtoBuf compiler that fulfills our performance needs while learning from the lessons of Gogo ProtoBuf:
vtprotobufis a ProtoBuf compiler for Go that generates highly optimized (un)marshaling code for APIv2, whilst being (hopefully) easier to maintain in the long term.
The first beta version of vtprotobuf is now publicly available: it supports optimized code generation for marshaling, unmarshaling and sizing. The resulting codegen is based on the original implementation in Gogo ProtoBuf, but it is fully adapted to ProtoBuf APIv2 messages and has received numerous micro-optimizations that make it run as fast or faster in all our benchmarks. Furthermore, we’ve also implemented a new feature which is not available in the original Gogo ProtoBuf compiler: memory pooling.
Thought provoking presentation from Reginald Braithwaite.
I am going to talk about Optimism, and conversely, about Pessimism.
I’m going to describe a framework for understanding why some people are optimistic and some are pessimistic. I’m going to explain how you can actually become more optimistic in your life, and I am going to explain how I think you can help other people be more optimistic in your personal life and in your community.
One of the key gaps in Rust’s ecosystem has been a strong story for fast and productive asynchronous I/O. […] We’ve wanted something higher level, with better ergonomics, but also better composability, supporting an ecosystem of asynchronous abstractions that all work together. […] Over the past couple of months, Alex Crichton and I have developed a zero-cost futures library for Rust, one that we believe achieves these goals.
- The monolithic of source code management works well when coupled with an engineering culture of transparency and collaboration
- Google has invested heavily in scalability and productivity tooling to support this model, due to significant advantages it provides
- This may or may not be the right approach for your company
Over the years I’ve given my direct reports and their direct reports the same insights I’m going to share with you now. These insights are hard-won wisdom rather than something I intuitively knew or read about. That is to say, I learned the hard way.
- Be Wary of High Performers
- Encourage Continual Product Improvement
- Encourage Code Ownership
- Recognize Leaders
- Watch Out for Misleading Metrics
- Limit Interruptions
- Prefer Private Workspaces
- Encourage Experimentation
- Let Employees Leave
- Never Turn Down Small Requests
- Abolish Yearly and Bi-Yearly Performance Reviews
- You’re Not Better than Your Employees
- Don’t Discount Younger or Older Developers
- Don’t have Stupid Dress Codes
- Build evolvable systems
- Expect the unexpected
- Primitives not frameworks
- Automation is key
- APIs are forever
- Know your resource usage
- Build security in from the ground up
- Encryption is a first-class citizen
- The importance of the network
- No gatekeepers
And so, the problem, more or less, is identified:
- I cannot read books because my brain has been trained to want a constant hit of dopamine, which a digital interruption will provide
- This digital dopamine addiction means I have trouble focusing: on books, work, family and friends
Really in-depth introduction into Rust programming language.
- Rust is a fast but safe language with good support for concurrency
- Has unique concept of “ownership” & “borrowing” to manage access to the memory
- Variables are immutable by default, but Rust allows to enable mutability per variable
- By using the ownership & borrowing it really helps with concurrency by eliminating data races
- Supports communication using channels
- At the same time tasks can share memory if needed
- Supported data types:
- Primitive types (ints, etc)
- Enums (more in line with types from SML, OCaml) with support for pattern matching
- Traits with support for usage of the traits in generics
- Allows to run “unsafe” code where a programmer can sidestep checks enforced by Rust
- Very easy, transparent and efficient FFI support
It’s always fascinating to get to know how complicated systems work underneath.
The linked blogpost by James D Bloom provides in-depth and easy to grasp description of the Java Virtual Machine’s internals.
Recommended reading for anyone interested in programming languages.
These are some of the first steps toward creating huge herds of tiny robots that form larger structures – including bigger robots
Intercom’s Des Traynor on three key design trends users now expect from software and which will ensure they have a magical experience with your product.
Nice overview of Netflix’s approach to systems resiliency.
Good, approachable guide to Bézier curves and their application to typography.
A hidden gem on AWS site.
- annotate the data
- annotate the slopes
- exclude (or flag) incomplete periods
- enable projections
I realized that in this group, no one was actually “making” anything. My entire generation had grown up to go into professions focussed around selling things to other people. I felt sick.
Thought provoking peace on current trends in product/design process.
If product design is about solving problems for people within the constraints of a specific business, then it simply feels that many people calling themselves product/UX designers are actually practicing digital art. They are Artists. They are Stylists. Executing beautiful looking things, certainly an important skill, but not practising product design.
You can broadly separate product design into two phases. First you come up with the concept of what you are doing, and then you implement it. The concept you come up with is like a map for the implementation. It tells you where you are, what you are working on, and what’s left to do. […] This article is about how you define the problem to begin with and how you get from there to a concept.
Yesterday I gave a presentation on an ULCamp::Dev meetup about Erlang and how to start programming in it.
The presentation covered:
- Functional Programming Ideas
- Erlang as a Functional Language
- Erlang Data Types
- Erlang Concurrency Model
- OTP Introduction
- Useful Erlang Tools (eunit, rebar, cover, xref)
Slides for the presentation can be found at SpeakerDeck.
Over my career, I’ve come to place a really strong value on figuring out how to break big changes into small, safe, value-generating pieces. It’s a sort of meta-design – designing the process of gradual, safe change.
Very good article on how to handle process of rewriting a major piece of a running complex system.
I believe that introducing visceral elements into an app will take it past the point of just being awesome. It will make your app speak to the subconscious, built-in affinity that humans have for the physical properties I mentioned before.
Great write up on how to be productive on your job.
Basically it all comes down to the point #2 from the article: “Give a shit”. I can not sum it up any better. If you are passionate about your job, your reputation, customers, etcetera, you won’t need to force yourself into writing that boring unit test you’ve been procrastinating for an hour to do by reading email or Hacker News instead.
I think system composition is important in distributed design. Every one of these components is complex. It helps to approach each task as an isolated system, and enforce easy-to-understand guarantees about that component’s behavior. Then you can compose different systems together to make something bigger and more useful. In these articles, we composed an efficient (but nonscalable) CP system with an inefficient (but scalable) AP system to provide a hybrid of the two.
This presentation describes how the Netflix API supports [client] devices and achieves fault tolerance in a distributed architecture while depending on dozens of systems which can fail at any time. It also explains how a new system design allows each device to optimize API calls to their unique needs and leverage concurrency on the server-side to improve their performance.
We propose a new programming model, discretized streams (D Streams), that offers a high-level functional programming API, strong consistency, and efﬁcient fault recovery
A really good introduction into Clojure and ideas behind it by Neal Ford.
What we’re learning at GitHub is that opting in to open source project constraints often results in better natural survivability characteristics for many types of business, product development, and operations activities. That is to say, processes designed to conform to open source constraints results in a project that runs well, attracts attention, and seems to be self perpetuating where the same project structured more traditionally requires much more manual coordination and authoritative prodding.
Finally, we sum up all of the “trending” and “non-trending” votes, and see if the ratio of these sums is greater than or less than 1. One could think of this as a kind of weighted majority vote k-nearest-neighbors classification.
Common sense technique, but quite interesting nonetheless.
A really great presentation by Josh Clark on how to rethink and leverage touch and multi-touch gestures in mobile applications development.
Since today is Friday - Ditch work
– Jason Fried
I’ve decided to take a closer look into DTrace on FreeBSD and found out that quite a few DTrace scripts from the DTrace Toolkit are not compatible with FreeBSD (since DTrace works on kernel level and FreeBSD has different kernel structures for file descriptors, etc.)
To overcome the issue, I’ve adapted some of the scripts from the DTrace Toolkit to FreeBSD. My collection of the FreeeBSD compatible scripts can be found at github.com/zaa/freebsd-dtrace-tools.
With a wealth of ideas and tools at our disposal, we often muddle our messages and complicate our code.
We appreciate that less is usually more, yet stuff our sites to bursting point, failing to be economical with what we have.
We must know when to stop, and when to throw things out. We should embrace simplicity and subtlety, and exploit the invisible.
This paper takes the position that disk-locality is going to be irrelevant in cluster computing, and considers the implications this will have on datacenter computing research. The quest for disk-locality is based on two assumptions: (a) disk bandwidths exceed network bandwidths, (b) disk I/O constitutes a considerable fraction of a task’s lifetime. We show that current trends undermine both these assumptions.
Your talented team is the most vital part of any startup. The way to retain the best talent is by having a clear vision, working in an area where you’re the only company and creating a place where people connect with each other.
This essay is about an investigation into the Mac OS X kernel to track down a strange bug in Chrome on Lion. It details the steps that I took during the investigation and discusses how to write a kernel extension to expose private data in the kernel to an analysis program.
Very informative and interesting read on Mac OS X internals.
I’d like to recommend this method to everyone. Just make a list or a mindmap of all your skills. Don’t spend days recalling all technologies your worked with. The important part is to give you a high level picture of what you know and what you’d like to become better at.
We all suck at estimating, regardless of how experienced we are. This is a fact that you should accept. Most of us are either ignorant to this or in denial.
On a production machine with 144GB of RAM and a 120GB InnoDB buffer pool, all used memory has been allocated within 152 pages (0.00045%) of perfectly balanced across both NUMA nodes
Really nice article by Fred Hebert on usage of Erlang in bilding a real time bidding service (with hands-on information on obstacles he had to overcome, experience with different erlang packages, etc). Well worth a read.
In this talk, I’ll describe a collection of techniques and practices lowering response times in large distributed systems whose components run on shared clusters of machines, where pieces of these systems are subject to interference by other tasks, and where unpredictable latency hiccups are the norm, not the exception.
A new commit protocol and programming model for efficiently achieving strong consistency in databases across data centers.
Joseph Blomstedt on usage of QuickCheck in building Riak.
When programming distributed systems becomes part of your life, you go through a learning curve. This article tries to describe my current level of understanding of the field, and hopefully points out enough mistakes for you to be able follow the most optimal path to enlightenment: learning from the mistakes of others.
For the record: I entered Level 1 in 1995, and I’m currently Level 3. Where do you see yourself?
Me? Level 2, I guess :-)
Salvatore Sanfilippo published a really detailed article on how redis handles persistence. A must read for anyone interested in redis.
Really great introduction into character encodings, Unicode and its usage in Erlang. A must read for all erlang programmers.
Distributed systems solve a number of key problems at the heart of scaling large websites. I absolutely think this is going to become the default approach to handling state in internet application development. But no one benefits from the kind of irrational exuberance that currently surrounds the “big data” or nosql systems communities. This area is experiencing a boom—but nothing takes us from boom to bust like unrealistic hype and broken promises. We should be a little more honest about where these systems already shine and where they are still maturing.
As designers, we tend to get distracted by aesthetics of our designs, and often do not pay enough attention to the other, invisible side of our creations.
This talk discusses the value of functionality, storytelling and thorough editorial work in Web. It argues about the significance of purpose, context and quality in our decisions. It also provides personal insights and practical examples of invisible design being used in practice.
Don’t trust anyone or anything. Have test systems that bit flips and corrupts and ensure the production system can operate through these faults – at scale, rare events are amazingly common.
Interesting and practical presentation from Shaneal Manek.
Mind blown. A must see video for software engineers.
It is no longer enough to simply ask someone if they are a programmer. Saying a programmer writes programs is like saying a scientist does science. The difference is that botanists don’t design nuclear reactors.
Interesting reading with a lot of technical details.
Emotionally moving presentation by Wilson Miner on the role of design.
Great article on amount of support a project might need to provide.
As Matt Gemmell puts it, supporting only the latest versions of OS brings you:
- Less hassle
- Less code
- Better customers
- Free marketing
There is no right time to start selling.
Hilton Lipschitz nails it.
If you’re making a developer focused product, the documentation is as core to the user experience as the endpoints themselves. I’ve seen far too many projects that simply dump you to a GitHub page with a two-liner readme. The most successful API docs are carefully crafted with love.
Quite good read on how to create outstanding API docs.
I really like the way Consolas font looks on Mac OS X.
Here is an instruction on how to install it (open Mac OS X’s Terminal application, then type the commands below):
# brew is a part of Mac OS X package manager called Homebrew (http://brew.sh/).
brew install cabextract
curl -O http://download.microsoft.com/download/f/5/a/f5a3df76-d856-4a61-a6bd-722f52a5be26/PowerPointViewer.exe
# Press Intall font. That is all.
Really good hands-on recommendations on how to ace an interview for a software engineer position.
Simple, one page manual on how to start working with git.
Fantastic presentation by Artur Bergman.
He curses a lot, but shows great understanding of the full stack (network, os, application), plus shares quite a few know-hows along the way.