pkaeding

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.

Yes, this clarification is accurate. I was thinking of 'canary launch'-style releases, where you release the new thing to a small group, then a larger group, etc, until everyone is getting it, and you don't need the flag any more.

You are right that the real world is always more complicated. However, I think the idea holds. If another dev needs to use the flag in another area of code, the flag cleanup branch should be maintained with this change.

The point is not to make flag cleanup automatic. It is to front-load the work of cleaning it up when the complexities involved are fresh in your mind. That way, when it comes time to clean it up, it is much easier to be more confident that you found all of the edge cases.

Sure, use debt where appropriate (be it technical or financial). But be responsible with it, and manage it well.

There shouldn't necessarily be any merge conflicts if you branch the cleanup branch off of your feature branch. So, it might look like this:

  -master---------------*--------------------*--
    \-feature-branch---/                    /
                      \-cleanup-branch-----/

Author here.

The point is not to delete the flag promptly, the point is to delete it cleanly, when you are confident the new feature is good.

I remember the Droid X had a FM tuner in it. I thought that was pretty cool when I bought it, but then I never used it. When I bought it, I had forgotten that there is never anything good on FM... (though FM tuner was not the reason that I bought the phone)

Google took over because PageRank was a revolutionary change over the evolutionary changes that came before (think Lycos -> Altavista). All anyone needs to do is to come up with the next revolutionary thing. Just do that, and you will overturn Google and take over the world.

Keep in mind that Google hasn't been a superpower for very long. All of this 'no one can ever disrupt Google' talk is nonsense.

You can definitely use feature flags to slowly (and controllably) roll out an alteration to an existing database, but exactly what it would look like depends on the alteration.

If you are going to make a schema migration with no downtime (even if you are not feature-flagging it) you will need to make the code work with both the old and new schema for a period, anyway. So, if you are feature flagging it, this period might just be extended, and you roll out the migration slowly. The 'new' thing I introduce with this approach is really just the 'integrity check' (and the gradual rollout, allowing you to monitor for errors/performance issues).

For example, if your migration involves:

- adding/removing a field: your code needs to deal with the fact that the field might not be there. This usually means you have a reasonable default value, or something.

- restructuring: this is a broad category, so lets work with a more concrete example: you currently have a nested (unbounded) repeating sub-object, and you want to break them out into their own top-level documents in another table/collection. In this case, you will have a DAO function `getChildren(parent)`, which uses the feature flag to decide if it should make the query to read the parent, and then pull out the nested list of children, or if it should load the children from their separate collection. You can save the children in both places, and do the dual reads as well, comparing the results. When the cutover is complete, you run a script that removes the nested children (instead of decommissioning the old database, like in the example in the blog post).

Ultimately, the concept is the same: you do the work in both places for a period of time, and check the results. If there are any discrepancies, you still have the fully-functional original data source.

Because we continued writing 100% of the data to Mongo until we were certain that everything was working, it was always safe to stop using Dynamo (or use it for less traffic). In the canary read phase, we always returned the mongo data to the caller. We read from both sources, compared the data, logged an error if there was a difference, and discarded the dynamo data.

In this way, the Dynamo data was kind of throw-away, until we were confident in everything.

Author here.

Yeah, at that point, you are doing two writes, and (possibly) two reads. I simplified the code a bit for the blog post, but you can do the read and write pairs concurrently, so you don't have to wait longer to get data to return to the caller.

For local development, you can create an 'environment' for each dev, which will maintain a separate set of targeting/rollout rules for each feature. This will make development/testing fast when you are connected to the Internet. You can flip the toggle value on the LaunchDarkly dashboard, and it will be instantly updated the next time your code gets the feature flag.

You can also provide a default value that will be used if the network is not available. You can read from a config file to drive this if you need to, to allow devs to specify the flag value when offline. This is what we do for our dogfood environment (prod, staging, and dev environments all talk to dogfood, but dogfood doesn't have another LaunchDarkly to talk to).

Hope that helps!

It is really quick to get started. You just drop our SDK into your project, and add a few lines to your code around where you want to toggle. Our docs [1] give examples in each language that we support.

[1]: http://docs.launchdarkly.com/

nb: I'm an engineer at LaunchDarkly

It seems the 'random' number is actually the important bit. You can remove the `/flexible-feature-control-at-instagram/` part, which is only there for SEO (presumably). StackOverflow URLs work the same way, in fact...

After reading Confessions of an Economic Hit Man[1], by John Perkins, it sounds like this has been standard practice since at least the cold war.

[1] https://en.wikipedia.org/wiki/Confessions_of_an_Economic_Hit...

That is great in areas where Uber/Lyft operate, but in rural areas, there is no public transportation, no taxis, etc. In these areas, a designated driver is really the only responsible option.

Yeah, that definitely works as well, and it is also what I did before I found ngrok. It is a few more hoops to jump through in order to get things flowing, though, and you don't get the introspection/replay functionality. You can use wireshark to inspect the traffic, I suppose, but again, it isn't as easy.

That is true, but that is only a small part of the usefulness of ngrok. It can tunnel TCP port, assigning you a random high-numbered port at their end (like with ssh -R).

But if you are tunneling an HTTP service, you can be assigned a random hostname (random.ngrok.com), or you can request a specific hostname (pkaeding-test.ngrok.com), and your service will be available over both HTTP (port 80) and HTTPS (port 443) on that hostname. This can be critical for testing webhook callbacks where the remote service only allows HTTPS on port 443.

Also, when you are tunneling HTTP services (using HTTP or HTTPS), ngrok will start a web UI running at localhost:3030, detailing all incoming requests. You can examine the headers and body from both request and response, and even replay requests. This is immensely helpful when debugging webhooks.

(I am not affiliated with ngrok, except as a happy user.)

The world is better now than it ever was, in many ways: http://sploid.gizmodo.com/the-world-is-now-safer-and-better-...

I love my slow cooker too, but I just want to dispel the myth that a slow cooker saves much time-- it just shifts the prep time from early evening to morning. Often mornings are just as hectic :).

At least, that has been my experience, though I may make more of an effort than most to use fresh ingredients rather than canned/prepared foods (based on the slow cooker recipes online, which seem to disproportionately call for canned ingredients).

That said, I love the output of the slow cooker, and I agree it is a great tool to have. It helps to mix things up and have a different meal this week than last week.

I'd be careful implying causation here. Another way to look at it is that people who often find themselves in dangerous situations feel the need to have guns to protect themselves. When you think about it that way, it doesn't sound so 'funny'.

The caption now reads "767". Maybe it was a typo?

I like to play a game where I take the antonyms of each word in a bill's "marketing name", and see if that is a better fit for what the bill would do. It often is :)

If nothing else, that headline is great!

I created an old version of this idea many years ago, when I needed to see where a few addresses were in relation to each other. I recently re-wrote it, improving the UI and stability by pushing geocoding out to the client. It is written in Scala using Play, and backed by MongoDB.

It was a fun project, and hopefully people (continue) to find it useful!

It doesn't sound like they are excluding people from Antarctica (since it is REMOTE), just that they don't have an office on that continent (yet ;).