I have not had much luck so far with figuring out what makes a good company purpose. However, I did spend the past few weeks thinking about what Phusion should stand for. One of the topics I have been researching a lot is technology ethics. Technology...

It has often been stated by business consultants and startup advisors that a company should have a purpose beyond vision. Studies show that that result in more motivated and loyal customers and employees. As Simon Sinek said: people don’t buy or follow what you do, but why you do it.

I agree. That was the easy part. But how do you actually define a good purpose? People need to feel that your purpose is aligned with their own values, and a purpose statement needs to balance many different things for many different people.

This post documents the start of my journey in an attempt to find answers.

I have been researching how the Kubernetes Ingress system works. My use case is to setup an autoscaled Nginx cluster that reverse proxies to Pods in multiple Deployments. It wasn't immediately obvious how to do this. By default, Pods in Kubernetes are not supposed to be reachable from outside the cluster. One makes them reachable either by associating those pods with a Service of the right type (i.e. either NodePort or LoadBalancer), or by defining an Ingress. But what is an Ingress? How do I put Nginx in between an Ingress and a set of Pods? This post describes my journey through the jargon-loaded Kubernetes documentation which does not hold any hands, as well as my journey through the Kubernetes source code, all in a quest to find answers.

This post a bit long, so if you just want a summary then you can skip straight to the conclusion at the bottom.

Even though I rejected Prometheus as a choice in my last blog post about Netdata, I actually appreciate Prometheus' engineering quality. From its documentation it is apparent that the authors are very experienced on the subject and have thought through things.

This post reviews some of the things that demonstrate that, namely their responses to the push vs pull debacle, the way they limit Prometheus' scope, the way their alerting system is designed and documented, and the way they treat storage.

I have been looking for an easy-to-use monitoring solution for Phusion's servers. One that does not require a lot of setup and that provides a reasonable interface without too much work. Such a solution has to display a bunch of graphs at the very least. (Email) alerting is considered a bonus. The solution also has to be open source, not only because of the cost factor but because I want to own my data. So solutions like New Relic and Datadog are out.

In this blog post I will describe the solutions that I've checked out – Ganglia, Monit, Munin, Prometheus, Grafana – and why I didn't like them. Then I will explain why I think Netdata is a good choice and review its pros and cons.

In general, people do not customize their tools or environment. They tend to work with whatever was the initial setup. In this post I will explore the consequences of this phenomenon, which even extends beyond the world of software.

People who have upgraded to macOS High Sierra and who are using a preforking app server such as Puma or Unicorn (with the right settings), may have noticed this error:

objc[81924]: +[__NSPlaceholderDictionary initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

This cryptic error is triggered under the following conditions:

1. You are using Unicorn with preload_app, or Puma in cluster mode, or iodine in prefork mode, or Passenger in smart spawning mode.
2. And you are using MRI.
3. And your application uses a gem that is either directly or indirectly linked to the macOS Foundation framework.

This error is caused by changes in how fork() behaves in High Sierra. This article covers:

• What is this and why did Apple change it?
• How are the Puma, Unicorn and Passenger authors responding to this?
• What can you do about it, and do you need to do anything at all?
• What should the wider Ruby ecosystem do?

Update August 9: urikanegun has kindly contributed a Japanese translation of this article.

Developers love speed, so developers love benchmarks. Benchmarks on programming language performance, app server performance, JavaScript engine performance, etc. have always attracted a lot of attention. However, there are lots of caveats involved in running a good benchmark. One of those caveats is benchmark stability: if you run a benchmark multiple times then the timings usually differ a bit. A a lot of people have the tendency to hand-wave this caveat by just shutting down all apps, rerunning the benchmark a few times and averaging the results. Is that truly good enough?

Lately, I have been researching the topic of benchmark stability because I am interested in creating reliable benchmarks that are reproducible by third parties, so that they can verify benchmark results by themselves — e.g. allowing users of my software to verify that my benchmarks are reliable. Such research has led me to Victor Stinner, a Python core developer who has been focusing on improving Python 3 performance for several years.

Red Hat and New Relic are some of the most interesting companies out there. We all know how big Red Hat is. New Relic is an application monitoring tool company that sped past all its competitors in its early days and achieved IPO. In 2015 the company had a monthly revenue of $29 million, with a year-on-year revenue growth of 69%. What do these tech giants have in common? Their marketing strategy.