pkaeding

So who should decide when the people are too dumb to know what are their own interests and their own will?

It seems unwise to gate-check a bag with a laptop anyway, given the way the luggage handlers throw bags around. Gate-checking a roller board suitcase with clothing is one thing, but I wouldn't check anything fragile or particularly expensive.

It was written by the tech columnist John C. Dvorak, who also co-hosts the media analysis podcast No Agenda. I believe the findings are based his analysis.

I believe it is meant to be a serious analysis after observing many (but clearly not all) media outlets. I suspect the intelligence agencies are included due to their ties to media outlets (while other government agencies have less to do with media).

I agree that it could use a lot more polish and copy-editing for consistency.

Learning to drive in New England, I was taught "four wheel drive is not four wheel stop", so I definitely agree.

No problem! If you happen to be in the SF Bay area (and if you will forgive the self-promotion) I'm going to be presenting this at a meetup in a couple weeks: http://www.meetup.com/AWS-EASTBAY/events/232870012/

Absolutely. In my experience, most unforeseen issues are related to performance at scale with unexpected data (the kind that seems to only ever crop up in production, and is really hard to design a load test for).

Performance issues in the browser are rare, and have nothing to do with the number of users using the application.

I usually skip feature flags for things like bug fixes where the risk that my 'fix' is actually worse than the initial bug is very small, or changes where it cannot make sense to have both modes operating at once. An example of this might be a new billing scheme, where the old system billed by the item, and the new system billed by the pound. There might not be a technical reason why both cannot co-exist, but it would cause marketing/support headaches to have some customers billed one way, and some billed another.

One surprising use case that I have had great success with, though, is in database migrations. I detailed my approach here, if you are interested: http://blog.launchdarkly.com/feature-flagging-to-mitigate-ri...

No, every call to check a flag is not making any sort of network connection. The flag ruleset (includes details like specific users that should get each variation, or particular user attributes that should indicate a specific variation, or a percentage rollout) is streamed to the SDK in a long-lived background connection.

The SDK maintains these rulesets in memory, and when you need to evaluate a flag for a given user, the ruleset is evaluated. This way, there is no I/O at the time that a rule is evaluated, so there is no real performance impact. At the same time, because of the way we stream the rulesets to the SDK, any rule changes take effect immediately.

https://launchdarkly.com/performance.html has some diagrams, etc, detailing this (sorry for the marketing fluff :)

I agree that feature flags, like any tool, should only be used where it makes sense. I disagree that they should only be used for visual changes though. Often, backend changes can have performance impacts that are only visible at scale, so being able to roll something out gradually can help there.

Also, a flag can be used as a permanent control to disable a part of the system (like an external call) if that part of the system is having problems. Imagine if you had a github activity feed integration, and you wanted to be able disable that feature when a github outage caused that call to take a very long time. Being able to easily disable that feature without needing to change your code can be immensely useful.

nb- I work for LaunchDarkly.

If anyone is interested, I wrote a blog post detailing the cleanup branch approach: http://blog.launchdarkly.com/how-to-use-feature-flags-withou...

Maybe I'm misreading the other comments in this discussion, but it sounds like people are saying that the story in the article is a special case, with elite professional photographers, but this would never work with the hoi polloi 'gig economy' companies like Uber, which will only ever pillage from their workers. (I'm exaggerating a bit here, but this is the sense I get from the tone of some comments. Apologies if I have misread them)

Passing 80% of the gross receipts (less the $1/ride safe-whatever charge, which I believe is for some sort of insurance policy?) does not seem like they are screwing the drivers to me. It seems like a pretty common split between marketplace/infrastructure providers and suppliers.

Oops, this wasn't meant to be a top level comment.

> They take a 20% cut (plus the whole of the $1 base-fare).

So does that mean that the drivers gross 80%? The photographers in the article would also be responsible for their equipment, materials, and taxes, so is this the right comparison?

Yes, and I believe iOS gives the same breakdown (though it is not as intuitive to read, and it gives all-time-since-you-reset-the-counter data usage totals).

Isn't asking content-providers to subsidize the cost of data for the users of their app contrary to network neutrality (which all three of the representatives signing this letter voted in favor of)?

I don't know how often serial numbers are checked, but I imagine that if those bills had been in circulation, they would have been retired by now (banks will take damaged/worn-out bills out of circulation to be replaced). I'm sure that the serial numbers are recorded when bills are taken out of circulation, so if the DB Cooper money was circulating, the FBI would have heard about it.

In addition, there is a protocol for this. The pilot will contact the flight attendant working in the front of the plane. The flight attendant will lock a beverage cart in front of the bathrooms, creating a (heavy, but not immovable) barrier between the cockpit and bathroom, and the rest of the plane. The flight attendant stands behind the cart, watching the passengers. The pilot looks through the peep hole, and when it is clear, comes out, locking the cockpit door behind him/herself. After using the rest room, the pilot knocks on the door to ask the copilot to open it. The peep hold is used to be sure the flight attendant is still standing guard and everything is normal.

There are obviously some risks here, as the door is opened briefly twice, but there are a number of steps taken to minimize this risk.

Probably because in the cases being discussed, it is the police who have the guns, not the citizens. I don't think even the most hardcore gun control zealots are advocating for the American police to give up their guns (at least not their sidearms, I suppose the military weapons are a subject of a different debate).

Do you have any other resources to point me toward describing how you would set something like this up in a cloud environment? Are there other tools better suited for cloud environments?

Sounds like civil asset forfeiture to me...

Sure, but if I can lease today's equipment for a short time, and then upgrade to tomorrow's equipment, and get the better performance, that might work out in my favor. I'm not out the full cost of the equipment today, needing to amortize that over 15 years.

I agree, such abuse should be called out. I also agree that the way this article is written makes me want to disagree with it (even though the message on the surface is a good one).

It just sounds like "Just say no to rockstars!". Yes, it goes deeper, and outlines why rockstars are a problem, but the 'just say no' message makes me a bit uneasy.

Even if you plan to stay in your house long-term, buying the equipment outright risks getting stuck with outdated technology. It seems there have been a lot of advances lately in solar panel technology, so if you had bought panels a few years ago, they would not be nearly as efficient as if you bought them today. And if you bought them next year...

> And there are even still some holdout users on old-style Gchat.

I'm not sure if I'm one of those holdouts? I've been using gchat, mostly over XMPP (using adium), and sometimes in Gmail. I frequently search chat history in Gmail.

I didn't realize that gchat had such a tumultuous history.

The way LaunchDarkly does it is to hash the user key, along with the feature key. This way the same users aren't always included in the '10% set' for all features, but they are consistently in the 10% set for a single feature.

This also allows the decision to be made in memory, without an additional round-trip to the DB.

Yeah, I think if you mindlessly do anything, you're gonna have a bad time.

Think of the cleanup branch as a running list of changes that you know you will need to make to remove the flag. Any future references to the flag should keep this cleanup list in mind. Code reviewers should keep these cleanup lists in mind.

This list of cleanup tasks happens to be expressed as a branch in your VCS (this is a pretty good way to express changes that need to be applied to a codebase). You will still need to be careful when you execute that list, but it will be helpful to have the running tally of things that need to be done.

Yeah, I actually wrote about something similar recently (in the context of a database migration): http://blog.launchdarkly.com/feature-flagging-to-mitigate-ri...

In my experience, there are a few different types of feature toggles. Some are permanent, and are useful for operational tasks, like putting an application into read-only mode, or disabling one service that is overloaded to prevent a cascading failure.

For the temporary type of toggle, which is what I was addressing with this blog post, my experience coincides with yours-- usually a few weeks.

The trick with deleting a year-old flag (which I was trying to address with this post) was that you need to be careful when deleting code that you haven't worked on in over a year. If you have the list of necessary changes all pre-baked in a branch, this can be at least a little easier.

In canary launches, you might want to roll a new feature out to 10% of your users, then 20%, etc. Once it is released to 100% of your users, you might want to remove the check, since it is a no-op.

I'm not aware of any authorization libraries that let you grant access to a percentage of your users, but maybe they are out there? It is a strange use case from an 'authorization' standpoint.