duggan

There is, sort of. If you're hosting on Linux, you can use iptables to artificially delay responses.

That and some other methods are described in a post on the Yelp engineering blog[1].

1: http://engineeringblog.yelp.com/2015/04/true-zero-downtime-h...

This is neat! Threw together an Ansible role for it:

https://github.com/duggan/ansible-slack-notify-ssh

> Full disclosure: I'm building a much, much better provisioner for multi-provider cloud infrastructure. Neither of the projects I recommend are mine; mine's not done yet.

One of the convenient things about software that doesn't exist is that it doesn't have any bugs.

Let your software speak for itself when it exists; until then, this seems an undeserved critique of software, and a team, that is solving problems every day.

Some of us have an idea, if only because a full build and integration test cycle for clusters of virtual machines can take hours depending on how the pipeline is organized!

I'd actually be ok with explicitly endorsing something if it's something I really like (and not get a revenue cut). The sort of product/services where I'm a "Net Promoter" 9-10.

Could have a sort of "tinder for endorsements" built into the platform, refreshed once every week maybe, that lets companies request your endorsement for a particular ad/message.

You flip through with an endorse/don't endorse (and some granularity around "I'll never endorse" this) and have that tied to a custom decay function where your endorsement expires and needs to be requested again.

Maybe you have a paid sub to opt out of this system entirely. And for those who don't want to pay or endorse, ok, let's see if the other mechanisms are enough to support them too.

I think if you Google many of those names, the first thing that will come up is a Wikipedia article about them.

> Who is the most competent to make this decision? The medical professional. Of course government (advised by medical professionals) will set the policy which will constrain the possible decisions.

This has gone poorly quite often throughout history, which is why it's a tough question. Homosexually was officially considered a mental illness in America until 1974.

> color me skeptical that these stack discussions are entirely spontaneous.

Author here, I suspect all this means is that Datadog's marketing is as effective as their product.

It's rare I give any software or service truly glowing praise. Rare enough that I'm pleased to do so at any opportunity I get.

To my recollection, EBS has only suffered one such major failure, some time in 2011 (I was working for Engine Yard at the time). It hasn't factored strongly into my decision making since, other than that since AWS weathered it, they're likely now well prepared against it.

AWS is a known quantity to me, Joyent is unfortunately not. I have a lot of time for Bryan Cantrill though, so I'm sure they're doing good stuff - I just don't have the extra cognitive cycles to handle a whole new base layer on top of all the scheduler / container stuff right now.

Similar work is progressing well for (off the top of my head) Kafka[1], Riak[2], and MySQL[3] though you'll note they're all quick to point out "don't use this for production yet."

I'll be keeping on top of these developments, but for now, managing yourself or leaning on AWS services is definitely the pragmatic decision.

[1]: https://github.com/mesos/kafka

[2]: https://github.com/basho-labs/riak-mesos

[3]: https://github.com/apache/incubator-cotton

Yeah, I sort of alluded to it in the article but didn't expand on it - we're doing a combination of things.

1. Using AWS services where we can (DynamoDB)

2. Provisioning more "traditionally" to instances, and managing those independently of the Mesos scheduler

3. Experimenting with scheduler based solutions[1] (which are still pretty bleeding edge, but are promising)

As I mentioned, EMC are (to me) doing the most interesting stuff here[2] because they're leaning on a lot of existing production systems like EBS and Mesos' own scheduler.

[1]: https://github.com/mesos/elasticsearch

[2]: http://blog.emccode.com/2015/10/08/enabling-external-volume-...

> Like any high performance system, it won't do this out of the box and does require some tuning based on your use case.

Absolutely, I'm just trying to discern whether it can reasonably be considered a "second choice" after S3 today.

I think what I'm finding out here is that the choice is highly dependent on the workload. I suppose there isn't anything terribly surprising in that.

This is largely what I'm trying to avoid. Looking at the Hadoop toolchain raises more than a few alarm bells, but I don't want to dismiss it too quickly since a lot of people have clearly invested a lot of time into it.

Both this and Twitter Engineering's recent post[1] on HDFS make me wonder whether HDFS is something a team would reach for in 2015.

I'm starting to read into the technologies in this area (i.e., I have not used much of the Hadoop stack yet), and I haven't found a fundamental reason why one would not base their batch processing on S3 (or your object store of choice). Existing software appears to make assumptions about the storage medium being a local hard drive.

Much of the challenge of HDFS appears to be around scaling the NameNode, and provisioning capacity. S3 dispenses with these issues, and the only cost appears to be throughput.

If software like Spark was modified to have a much more native approach to S3, could HDFS be dispensed with entirely?

[1] https://blog.twitter.com/2015/hadoop-filesystem-at-twitter

The problem is that this is just rephrasing "survival of the fittest," a concept misappropriated from evolutionary theory into societal planning numerous times by despots, and which - to my mind - has no place in a society mindful of its incomplete information about what constitutes "fittest."

This is basically how Datadog works. Unfortunately they do service monitoring rather than exception tracking, but certainly lessons can be learned from them.

Hands down the best designed operations product I've used.

In a pithy one liner: it's curl pipe bash for local binaries.

I've run into it when I used to install Virtualbox "Guest Additions" or whenever I'd make the questionable decision to use the latest video drivers during my annual dalliance with desktop Linux a decade ago.

The value it provides is fewer steps in an installation guide for non-power users (or as jakobdabo mentions below, particularly for users coming from the Windows "double click to install" world). It would extract and run a post extract hook. I haven't come across it much in the last few years though.

> That said, for some projects I’d prefer Rust. Specifically for very large projects, a heavier reliance on abstractions starts to make more sense.

This is an interesting point, because I've never actually worked on a large project that shipped. Lots of brow furrowing and hand wringing over correctness, but at the end of the day nothing for customers to use, or too late for it to matter - which is more or less the same thing.

Conversely, I've seen plenty of small "shim" projects that grew, sometimes rapidly, into much larger projects. Few, or no tests. Awkward, meandering blocks of logic, often with developers lamenting the lack of good abstractions (myself included).

Large projects tend to be second systems, and second systems tend to suffer second system effects.

It seems as though the profession of software development curses its practitioners to remain unsatisfiable.

I certainly recall them, but is there value in that? It's not like I, or many others, I imagine, associate it with a positive purchasing intent.

I remember memes, but does that make the meme creator, or subject, powerful? Influential? Rarely.

Just on the first point, I'd heard a couple of years back that CPI/CPM was on the decline due to lack of measurable impact. Does that ring true?

It does sound believable that serious saturation campaigns would work, though I'd wonder at the cost effectiveness.

I wrote a similar tool for Digital Ocean a couple of years ago, for the same reasons! Improving CLI UX is shooting fish in a barrel, few designers seem to care about the non-web experience.

If you limit your speech based on a speculative Orwellian autocracy, you are already living in your own personal one.

For anyone else who had to dig around to figure out what Ionic was:

> Ionic is a powerful HTML5 SDK that helps you build native-feeling mobile apps using web technologies like HTML, CSS, and Javascript. [0]

[0]: http://ionicframework.com/docs/overview/

> For one, all the other developers are going to make you maintain that code for the rest of your life.

Ah, if only that were the case. In reality, developers move between jobs, and bad code always becomes someone else's responsibility eventually.

Instead, it's better to understand that as a professional you should be - if not proud of your results - proud of making the best of a bad situation for whoever will inherit your codebase, be that your future self or a colleague.

I'm wondering if this is a difference between people who went through childhood or adolescence with weight problems versus people who developed them later?

I was pretty slim until about 23, so my identity was always firmly rooted in a healthy weight range. I never felt defensive over being overweight; sensitive, certainly, but I was also my biggest critic (no pun intended).

Then again, maybe it's something entirely different!

Not poached, but definitely now in the 30-day grace period[1].

[1] https://www.dotster.com/domains/faq.bml

No "soon" about it, this is already how companies behave.

If you have a Spotify subscription, try to cancel it.

As I've been trying out various companies for different (B2B) services over the last few months, I've noticed the wonderful "sign up in a few seconds with your credit card!" onboarding paired with "contact our customer service team if you want to cancel," which inevitably leads to a protracted discussion with a retentions team.

If there was any chance I'd have recommended them (or at least not actively recommended against them), that ship sails when I have to invest more time into offboarding than onboarding.

You might be surprised how easy it is to become overweight without really realizing it.

I slowly gained about 30kg (66lb) in my early twenties (I went from about 75kg to 105kg at peak over about four years). When I started having trouble breathing at night I knew there was a problem (and figured the weight might be the cause), but I didn't hear of sleep apnea until a few years after I had lost the weight (the breathing difficulty disappeared with it).

If this surprises people, it's definitely doing some good.

Nicely presented, Filippo!

Somehow I can never turn down a data dump, despite never having done much with one.

Some day!