The Millions Silicon Valley Spends on Security for Execs

There’s plenty of talk about security when it comes to giant technical companies, like Google, Facebook, Amazon, and Apple. But that’s all usually from the perspective of the software security and end-user privacy. Here’s a different perspective on the subject – “The Millions Silicon Valley Spends on Security for Execs“.

Apple’s most recent proxy statement, filed earlier this month, shows the company spent $310,000 on personal security for CEO Tim Cook. But that’s a fraction of other tech giants’ expenditures.
Amazon and Oracle spent about $1.6 million each in their most recent fiscal years to protect Jeff Bezos and Larry Ellison, respectively, according to documents filed with the US Securities and Exchange Commission. And Google’s parent company, Alphabet, laid out more than $600,000 protecting CEO Sundar Pichai and almost $300,000 on security for former executive chair Eric Schmidt. In 2017, Intel spent $1.2 million to protect former CEO Brian Krzanich. Apple, Google, Intel, and Oracle declined to comment; Amazon did not respond to a request for comment.
Facebook CEO Mark Zuckerberg was the costliest executive to protect; Facebook spent $7.3 million on his security in 2017, and last summer the company told investors that it anticipated spending $10 million annually.

Well, that’s pretty impressive in terms of money! But do they need it really? They do, at least, to some degree:

While Silicon Valley firms haven’t disclosed many threats to the safety of their executives or offices, they have good reason to take precautions. In December, Facebook evacuated its headquarters after the company received a bomb threat. Last year an unhappy YouTube user entered the company’s San Bruno, California, headquarters and shot three employees before killing herself. And in 1992 the president of Adobe, Charles Geschke, was kidnapped at gunpoint and rescued by the FBI.

Do you still dream of being an executive in a large company?

How to Slow Down to Go Faster Than Ever in Software Development

While reading through “How to Slow Down to Go Faster Than Ever in Software Development” I couldn’t help but nod my head in agreement continuously. The article goes over the well-known and familiar challenges in software development, but it also words them in a very simple and straight-forward way. It’s difficult to disagree with.

Here are a few quotes to get you started.

As Robert C. Martin mentions on the primary value of software at CleanCoders, “The ability of a software system to tolerate and facilitate such ongoing change is the primary value of software”. Rushing is evil in software development. Any attempt to rush causes dramatic damage in productivity, focus, people’s effectiveness, adaptation capability, and tolerance of software.
For instance, we always have time for fixing bugs, but no time for writing tests. We don’t refactor and write tests because we don’t have enough time. But we have time for debugging, hacking code and fixing bugs.
We focus on processes so much that we often forget the main asset in software development: people. Processes help people to improve the way they build products, increase motivation and cultivate a healthy environment. In the end, the efficiency of processes is important, but people are crucial.

Processes and tools do not build products, but people do. We have to admit, “talent hiring” is the most important functionality of an organization. It has direct impact on the future of the company and the product itself.
Hire the best talent for your organization. By saying “the best”, I do not mean the smartest, or most experienced people around. I look for passion, discipline and motivation at a minimum. If all three exists in a talent, the other skills can grow with ease. Hiring is a win-win process, so both sides should gain from the process. So you should slow down your hiring process and invest on improving it. People join companies in which they believe. So model the behavior you want to see. And through your company culture, your vision and people, make talent believe in you.

One thing is clear. Without having a quality codebase, you cannot be agile, sorry. The first thing you need to do is eliminate technical debt and resolve bugs. If you need to stop building the features for a while, and focus on eliminating bugs.
“Fixing bugs and deploying to servers afterwards” is not a proper procedure today. It contains risks and danger. We need a better and more disciplined way of doing it. When you want to fix a bug, first write a test and reproduce the problem programmatically. Then fix the bug and see that the tests are passing. Deploying to production is safe afterwards.

Vim: persistent undo

Learning Vim is an endless process. Even after using it for two decades I still keep discovering new settings, features, and plugins that significantly improve my productivity.

The other day I came across “Ask HN: Best things in your bash_profile/aliases?” thread, with plenty of tips and tricks. One particular comment highlighted a feature that I kind of heard about but never got to setting up – persistent undo.

It turns out that starting with Vim 7.3 you can preserve the undo history between editing sessions. Which means that you make changes to a file, save it, close it, and when you reopen it later, you can press ‘u’ to undo the changes you’ve done during the last edit.

In order to set this up, you first need to create a folder, where Vim will store the undo history files. For example:

$ mkdir ~/.vim/undodir

Then, you need tell Vim that you want to use persistent undo and where to store the files. Edit the .vimrc file and add the following:

set undofile
set undodir=~/.vim/undodir

As long as you are using Vim 7.3 or newer and the directory exists, your persistent undo history will work like a charm.

Read the rest of the thread for more tips on how to clean it up periodically, and how to further improve your experience with Vim’s undo, using plugins that help navigate the undo tree.

UK’s ICO Guide to GDPR

Information Commissioner’s Office (ICO) is the the UK’s independent authority set up to uphold information rights in the public interest, promoting openness by public bodies and data privacy for individuals.

They have published their own Guide to GDPR, which I find somewhat better than this one from the European Union.

Reading postmortems

Once in a while a seemingly straightforward article turns into a goldmine of links and resources. This happened to me today with this one – “Reading postmortems“.

Not only this article itself is a very nice roundup of common sources for system failures, but it also links to a couple of awesome references:

  • Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems. This is both a talk and a paper.
  • danluu/post-mortems – a GitHub repository with a collection of publicly available postmortems from a variety of organizations, like Google, Amazon, Facebook, NASA, GitHub, and more.

If you still have no idea what postmortem is, Wikipedia explains.

GraphViz dot: Format: “png” not recognized.

As I’ve mentioned many times, I’m a huge fan of GraphViz software suite in general, and the dot tool in particular. It’s super handy for generating graphs and diagrams out of plain text files.

Today though I came across a problem that I haven’t seen before. While trying to generate an updated PNG graph from a dot file that used to work just fine before, I got the following:

$ dot -Tpng source.dot -o destination.png 
Format: "png" not recognized. Use one of: canon cmap cmapx cmapx_np dot dot_json eps fig gv imap imap_np ismap json json0 mp pic plain plain-ext pov ps ps2 svg svgz tk vdx vml vmlz xdot xdot1.2 xdot1.4 xdot_json

That looks weird. I tried the same with a few other formats and none of them were working. A quick Google search around found the solution over at StackOverflow. All I had to do was:

$ sudo dot -c

After that, dot started working as always.

Cloud Diagrams & Notes

Jerry Hargrove – Cloud Diagrams & Notes is an excellent resource for (mostly Amazon AWS) cloud diagrams and notes. I’m sure I’ve seen some of these around, but never thought to visit the original site. To some degree, these are similar to the Julia Evans’ drawings, but are more subject specific.

Managing dotfiles with rcm

These days it is a common practices to manage, version, and share configuration files for command line tools (bash, vim, etc) via a GitHub repository. There are plenty of open repositories to study and borrow things from, as well as the tools and scripts to help one with setting things up. Have a look at the awesome-dotfiles – a curated list of dotfiles resources.

Fedora Magazine runs an article about rcm – one of the many tools that are handy for managing dotfiles.

Personally, I haven’t heard of rcm until now. My own setup went through several iterations, varying from custom scripts, to Puppet, and now to Ansible. Have a look here. By the way, my dotfiles aren’t only about the command line tools. I also keep my desktop environment configuration in there (MATE + i3).