maplebed

There are a number of articles on this topic coming from the perspective of martial arts rather than music. Start at http://codekata.com and you’ll find good articles. (Note - I am not associated with codekata; just find the idea neat.)

For the curious, the first failure I saw was at 13:15UTC and the last was 14:59UTC.

Yup! It's hard! All the things you point out are right on.

We don't have the visualizations for histograms yet (though you can chart specific percentiles), but for the reasons you mention, Honeycomb is perfectly suited to give you that kind of data. I can't say we'll get that out the door soon, but it's one of my pet most wanted features so as soon as I can convince myself it's actually more important than all the other mountain of things that need to get done, you'll get your histograms and your time over time comparisons.

I've been advocating for a heat map style presentation of histograms for a long time, but I hadn't considered the difficulty that creates when trying to show time over time. That's an interesting one to noodle on.

Thanks for articulating well the value and reasons for difficulty in implementing histograms!

(bias alert - I work on Honeycomb)

Are you a plant? It must just be coincidence that the second post in the series is titled "measuring capacity." :) https://honeycomb.io/blog/2017/01/instrumentation-measuring-...

(bias alert - I work on Honeycomb)

By creating events that contain both the duration of the request and whether it succeeded, you can create graphs that show you the detail you need. Unless you include those data together at the beginning, it will be impossible to tease them apart later on. Combining them into one graph will likely conceal the difference in the two cases, as you describe, unless you feed them in to a system that an natively tease them apart as easily as show them together (such as http://honeycomb.io). So it seems like the disagreement is more about visualization than collection (the section of the blog in which that quote appears).

The originally quoted advice, to show "the duration it took to serve a response to a request, also labelled by successes or errors" remains good advice, so long as the visualization of that data makes clear the separation.

I absolutely agree that careful consideration is required when choosing what to put on dashboards to avoid confusion. That seems to be a separate issue.

(bias alert - I work on Honeycomb, and care deeply about collecting data in a way that lets you pull away the irrelevant data to illuminate the real problems.)

Nice to see that 36 years later they're writing the same thing. https://www.nytimes.com/2017/01/21/us/san-francisco-children... "San Francisco Asks: Where Have All the Children Gone?"

Once you have your report card, don't forget to revoke access. https://github.com/settings/applications

[nit] Daniel-san

Though there's no answer in the video, the classic demonstration of TMS (Transcranial Magnetic Stimulation) you'll find in an intro to brain imaging class is to trigger sections of brain containing the motor neurons. This creates involuntary movement in the muscles of your body, rather than any kind of information you would process willfully act upon. Given the mention of placing the TMS paddle on the opposite hemisphere of the brain from the subject's arm, it's plausible that they are actually just aiming at the motor neurons.

As a tech worker who is more focused on the back end than the visible product, I have found a very low correlation between my belief in the product and my satisfaction with the job. I find that my job is pretty much the same regardless of the actual product. This experience is likely different for people more directly involved in the actual product.

I get much higher signal to indicate whether I will enjoy a job from my coworkers and the culture of the company. If I am working with smart motivated people, I will be happy no matter what I'm working on. If I am in an environment where people are continually innovating and pushing the boundaries of the status quo in the field, I will be happy with my job.

This awareness leads to a very different typo of job search. It's easy to start a job search by thinking of a product you like then trying to see if you can work for that company. It's harder to think of a culture you want to join and then look for that.

I thankfully have not been employed by a company whose product I actively despise; I'm sure that would have a disastrous effect on my job satisfaction.

My two favorite parts of this article: the author lives in New York and "Don’t let people merge in front of you, ever." Now I understand New York drivers!

No, I took a different approach. Any normal cron job that wants to be run only once (per cluster) grabs a zookeeper lock. Those that fail to acquire the lock exit and try again during the next interval. This is implemented with a wrapper around the cron job that takes care of locking: https://github.com/ParsePlatform/Ops/blob/master/tools/get_z.... More details here: http://blog.parse.com/2013/03/11/implementing-failover-for-r...

I chose Zookeeper to achieve this same goal a while ago (before I heard of etcd). I have been pleasantly surprised at how useful having a coordination service is in my infrastructure in addition to a configuration management service. Because of this, even though etcd looks like it serves distributed configuration management better (aka simpler), I'm happy with my choice of Zookeeper.

Two examples of how a coordination service has been useful:

* cluster wide throttles to help protect overwhelmable backends

* redundancy in maintenance cronjobs that really only want to be run once per cluster per time period

(edited for formatting)

I've used monit since forever, but have really come to like runit more recently.

Having a minor in CS means I understand conversations about algorithmic complexity, have experience with parsers, can discuss data structure analysis, and all those other things that you don't learn when you learn a language. Computer Science isn't about building websites, it's about understanding theory and reasoning about logic. It won't help you get your RoR site up any faster, but it will definitely help you understand good engineering and create a stellar product. You should stay all four years, or five if you can afford it, and you should pursue the minor.