I learned yesterday that JQuery's post can only post data that is a string, or a map of string:string. While the documentation says this, the code doesn't mention it at all.
The error message you get if you pass something more complex is something like "this is undefined in jquery.size", rather than anything useful like "This data can't be posted".
current task is sub-meter GPS accuracy out of an iPad
definitely doesn't come stock with iOS, so we've got (very) expensive bluetooth GPS antennas
the + side is they're pretty accurate and they don't guess like iOS sometimes can
the - side is they literally do not work indoors, or with any solid obstruction to the sky at all. they don't even work badly. they simply don't work. so...
the +++ side is i can only calibrate it by taking a nice field trip to the park tomorrow with my laptop
Wee, more Go package manager drama. Glide to stop development "in near future". Recommends "dep".
dep is the official experiment, but not yet the official tool.
OK, maybe that will stick around.
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited October 2017
You guys are thinking of NoSQL far too narrowly. MongoDB and Couch are document stores which happen to be NoSQL...but things like BigTable, HBase, Cassandra, RedShift, Redis and Riak are NoSQL databases as well. To say things like Cassandra, Redis and Riak aren't seeing big time use for some serious problems, especially in the big data, high availability space, is kind of silly goosish. Not every problem needs foreign keys thrown at it.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Package management has been a nightmare in Go for a while and one of the things holding it back in my opinion. Google built "go get" for how Google works internally but it forces a dependency model on outside users that is untenable.
Then vendoring happened, then glide, then <insert your thing here> and now it's a damn mess because Google didn't take the problem by the horns earlier and do something about it.
You guys are thinking of NoSQL far too narrowly. MongoDB and Couch are document stores which happen to be NoSQL...but things like BigTable, HBase, Cassandra, RedShift, Redis and Riak are NoSQL databases as well. To say things like Cassandra, Redis and Riak aren't seeing big time use for some serious problems, especially in the big data, high availability space, is kind of silly goosish. Not every problem needs foreign keys thrown at it.
That's why I mentioned graph databases specifically as having very interesting applications. Unfortunately though, in my experience NoSQL has meant document stores 100% of the time in the wild.
Package management has been a nightmare in Go for a while and one of the things holding it back in my opinion. Google built "go get" for how Google works internally but it forces a dependency model on outside users that is untenable.
Then vendoring happened, then glide, then <insert your thing here> and now it's a damn mess because Google didn't take the problem by the horns earlier and do something about it.
Yeah, that's annoying as shit about the whole attitude of the Go devs. "We know what's good for you."
You guys are thinking of NoSQL far too narrowly. MongoDB and Couch are document stores which happen to be NoSQL...but things like BigTable, HBase, Cassandra, RedShift, Redis and Riak are NoSQL databases as well. To say things like Cassandra, Redis and Riak aren't seeing big time use for some serious problems, especially in the big data, high availability space, is kind of silly goosish. Not every problem needs foreign keys thrown at it.
That's why I mentioned graph databases specifically as having very interesting applications. Unfortunately though, in my experience NoSQL has meant document stores 100% of the time in the wild.
You're in a different part of the wild than me I guess. I haven't used a document store, outside of dumb toy projects where they are great to get spun up fast, in a while. I use Redis and RedShift every day, at least indirectly as they are part of our infrastructure. My last position we used Cassandra and Redis quite a bit.
I was wondering if anybody has any good resources on source control management and branching, or some personal experience they're able to share? I work for a small game dev company; and our release/update process is a small nightmare to organize at the moment - we're working on three consecutive updates, and people are having trouble organising things so that features due to come in later updates don't contaminate the current update.
I'm not one of the main programmers (more of a technical artist that fell into programming) so some of the literature I've found seems to apply more towards code bases where there are a lot of dependencies outside of whats in the repository (I don't know the difference between a 'development environment' and a 'production environment' for example). All of our stuff is usually self-contained in one repo.
At the very least, I was going to suggest we move from master / dev / feature branches to master / release candidate / dev / feature branches. But unless I build my case, no one is going to go along with that.
We're using Cassandra as part of a data science project, storing large binary files for data sciencey things with no real need for relationships between data. Seems to be working nicely so far, just being able to chuck JSON in is pretty handy!
I was wondering if anybody has any good resources on source control management and branching, or some personal experience they're able to share? I work for a small game dev company; and our release/update process is a small nightmare to organize at the moment - we're working on three consecutive updates, and people are having trouble organising things so that features due to come in later updates don't contaminate the current update.
I'm not one of the main programmers (more of a technical artist that fell into programming) so some of the literature I've found seems to apply more towards code bases where there are a lot of dependencies outside of whats in the repository (I don't know the difference between a 'development environment' and a 'production environment' for example). All of our stuff is usually self-contained in one repo.
At the very least, I was going to suggest we move from master / dev / feature branches to master / release candidate / dev / feature branches. But unless I build my case, no one is going to go along with that.
Any pointers would be very appreciated!
There are a couple ways I've seen so far in production at our company:
Development branch and a release branch that is periodically merged into from dev, or has certain changesets grafted on from dev.
Dev branch and a per-release branch, each release gets a specific set of changesets from feature branches, then merged into default (if those changes are not already merged into default)
Feature switches to activate/deactivate certain features (doesn't avoid code contamination, potentially avoids feature contamination; can be compile time or runtime)
Default is the dev branch, with tags for specific releases (does not solve your problem)
@Orca Glad the question isn't completely trivial; was worried about wasting people's times.
Out of the options you've shown there, I think I definitely prefer 2. The disadvantage of course that over a large period of time, you end up with tons of redundant branches (and we're poor, so we've hit the branch limit more than once for .git).
I guess once you're done with a release though you could merge that entire release branch into master (our "Master" is basically builds that we know to be stable), and then prune the release branches every so often.
Thanks for the insight! Also curious to see what other workflows people have used!
Most companies strive for continuous delivery and very short branch life, so dev/release often end up being redundant. If you have the ability to do feature flags(the #3 from Orca), that's a significantly more powerful approach and odds are you will need it anyway at certain point.
For others, based on the amount of red tape, neither of the above is possible.
If you would like to "not think" about what you are doing, pick up "git flow"(it's already similar to what you describe) and just use some of the many tools that already implement it to facilitate your process.
Cue: People running in telling me how they "Really need their 3 month old branch and the feature couldn't be done without it!"
in short, everyone works on master, all the time. ideally they only commit things that are not going to break the entire project for everyone else. if you need to do a release but have to trim out a bunch of in-development stuff, you cut a branch, do what you need to do to disable the in-dev work, do your build, and never look at that branch again, including never merging it.
i've been using this methodology since 2009 and have never found it lacking
Jasconius on
0
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited October 2017
We use hybrid gitflow with development being the main integration branch, which has feature branches for individual stories snapped off of it. Master is our direct line to production and anything checked in to master will be on prod in very short order. So we control pretty tightly the merges between development and master.
We don't "cut releases", things just release, as fast as we put them in master. Master is always the pristine snapshot of what's in prod. If we have to hot fix, we snap a feature branch off of master, do the fix, then back merge it to development.
I say hybrid gitflow because we don't do all the release branching stuff because, again, we don't cut releases.
What methodology you choose should be about what kind of software you're writing and what your release infrastructure looks like. There is no one right answer or magic bullet.
Alright, golang people - give me your opinions on web framework stuff. I come from a mostly Django (and full custom stuff before that) background, but I'm not sure that's the best route to go with Go.
From the research I've been doing, if comparing Go to Python
Revel -> Django
Gin (or Martini) -> Flask or Bottle
Gorilla -> no real equivalent that I am aware of
Bare go -> Python http.server, but the go may be more functional out of the box
Given what I've been reading so far, it seems like either Gin or the Gorilla toolkit is likely the route I want to be going for web stuff. Any opinions on that?
GnomeTankWhat the what?Portland, OregonRegistered Userregular
Why Go for an HTTP service? Go's strength is vertically scaling with safe parallelism and solving CPU bound tasks. Unless you're doing some pretty heavy lifting in your web routes, you're going to have a Go program spending most of it's life waiting on I/O events. Not really it's strength, though it can certainly be done.
If you're just doing it for fun/to learn, carry on (and use Gorilla because it's name is cool).
Why Go for an HTTP service? Go's strength is vertically scaling with safe parallelism and solving CPU bound tasks. Unless you're doing some pretty heavy lifting in your web routes, you're going to have a Go program spending most of it's life waiting on I/O events. Not really it's strength, though it can certainly be done.
If you're just doing it for fun/to learn, carry on (and use Gorilla because it's name is cool).
Several reasons.
1) Fun and learning - it's always interesting to see how to solve the problems I'm used to solving but with different tools and Go seems to be a pretty good tool to have in my belt for ensuring I stay employable.
2) We do actually have a client we recently picked up at work who uses Go for some back end web and mobile app API stuff which we will be doing some work on. From what I've seen of their code so far, they do not have any standard set of tools they always use, so I'm keeping all of my options open, but will almost certainly be doing some web stuff with it. This client is why I initially started working with go (it had been on my to-do list for a long time, but I just didn't have enough reason)
3) I actually kind of like it for my main language - a lot of the ideals I like from Python but with type safety, better support for immutability, concurrency, etc. Even if it's even better for other stuff, it's not like it seems to be bad for web stuff.
Alright, golang people - give me your opinions on web framework stuff. I come from a mostly Django (and full custom stuff before that) background, but I'm not sure that's the best route to go with Go.
From the research I've been doing, if comparing Go to Python
Revel -> Django
Gin (or Martini) -> Flask or Bottle
Gorilla -> no real equivalent that I am aware of
Bare go -> Python http.server, but the go may be more functional out of the box
Given what I've been reading so far, it seems like either Gin or the Gorilla toolkit is likely the route I want to be going for web stuff. Any opinions on that?
Go is amazing for an http api and has one of the easiest testing stories for http you will ever find(and I am sure you will appreciate it, coming from python). When you see how it deals with TLS, you will blush. Go is an excellent choice for API and there are a shitload of companies migrating from ruby and particularly from node to it(big ass huge resources companies as well as smaller startups).
To be honest, if you were not coming from python I'd say that you should start with just httprouter.
If you want something *slightly* more advanced, I have used chi.
Finally, any of the frameworks you list will do the work adequately, there is no right choice, see what fits well with your mindset.
Alright, golang people - give me your opinions on web framework stuff. I come from a mostly Django (and full custom stuff before that) background, but I'm not sure that's the best route to go with Go.
From the research I've been doing, if comparing Go to Python
Revel -> Django
Gin (or Martini) -> Flask or Bottle
Gorilla -> no real equivalent that I am aware of
Bare go -> Python http.server, but the go may be more functional out of the box
Given what I've been reading so far, it seems like either Gin or the Gorilla toolkit is likely the route I want to be going for web stuff. Any opinions on that?
Go is amazing for an http api and has one of the easiest testing stories for http you will ever find(and I am sure you will appreciate it, coming from python). When you see how it deals with TLS, you will blush. Go is an excellent choice for API and there are a shitload of companies migrating from ruby and particularly from node to it(big ass huge resources companies as well as smaller startups).
To be honest, if you were not coming from python I'd say that you should start with just httprouter.
If you want something *slightly* more advanced, I have used chi.
Finally, any of the frameworks you list will do the work adequately, there is no right choice, see what fits well with your mindset.
Chi looks nice as well. Go doesn't seem to have quite hit the same level of "Use one of these 2-3 tools" like everything else I work in (even Elixir has a definitive web framework, orm-like thing, etc), which is both cool and frustrating at the same time. I don't want to spend a bunch of time learning something just to have the whole Go community decide it's shit and abandon it in 6 months.
I'm mostly looking for something which is relatively common and no one is going to fault me for choosing to work with it/use it for a project, will handle most of the tedious (or worse, tedious yet easy to fuck up) bits so that I can solve the problems I really want to, but also not force my hand too much. As to the last point, Django for instance, as much as I love it, much of my development is spent not so much on "how do I solve this problem" but "how do I solve this problem WITHIN DJANGO'S STRENGTHS AND TOOLS" - which is fine until you hit something which Django just doesn't do well and then you have to write code that everyone hates you for as long as the project lives.
gorilla/mux is the only thing I've used that's not native when writing APIs. It's a snap to register routes as sub-routers (which in turn can have sub-routers), which is handy if you have a bunch of separated sub-systems you can just add under a prefixed path, and Gorilla does the routing. Super quick to just change where the sub-router hooks in without having to change dozens of individual paths.
No man, don't fear that. Http routing is almost all compatible or close to. Signatures of handlers are very easy to migrate and middleware is trivial.
I have migrated chi to <undisclosed because I won't recommend> before, it's very, very fast work. If you still don't want to go for smaller libs, gorilla/gin/revel will be here for a while for sure.
@zeeny@jasconius@gnometank Thanks for the answers! Looks like our current process isn't that different from trunk based development really; though we might be finding a few reasons to branch a bit too often. There's definitely more discipline in this literature than I've ever seen at my company; though I think that's a function of the fact that we just have too few programmers for our projects. (Hence art to code).
We have actually done feature flags before; we just haven't thought about them as a tool for facilitating major changes. Mostly we just use a flag in-engine to say whether a build is a release, dev, alpha, or beta build - with various functions attached to the flag from enabling dev cheats to showing a different welcome message for alpha/beta testers. In practice we can just expand that.
No company ever does a 100% pure approach, when you start attaching actual constraints and reality something's gonna give
Yeah, our problem is that literally everyone just wings it 100% of the time though. Which is definitely not where we want to be either. :biggrin: Not looking for perfection, just an approach people can solve most of their problems with!
anyone have some experience with bootstrap? Having a lot of trouble getting it to not look awful. I copied and pasted some of the example code from the documents and it looked like crap on my app : /
anyone have some experience with bootstrap? Having a lot of trouble getting it to not look awful. I copied and pasted some of the example code from the documents and it looked like crap on my app : /
Are you using version 4? it just got officially released and it's a pretty major step forward over 3.x, especially in terms of "not looking like butt"
What aspects are you dealing with?
So far in my experience with 4, the most challenging aspect is not overusing certain conventions like Cards, which take up tons of space
@Taerak Specifics sometimes vary depending on the project and exact features, but what we strive for is generally a master branch, a staging branch, and then feature branches. When things are going smoothly, a user story/card/ticket (whatever you want to call it) will have one or more branches (but not too many, if it needs a ton, then it probably should have been multiple stories/cards). We branch from master, do some work, merge it into staging and deploy to a staging environment.
In the past, we would then wait on testers to test on staging, etc. Then merge the branch to master and deploy. I have been pushing using feature flags and immediately merging to master and deploying after a quick developer verification on staging which mostly exists to ensure that your code works with the deploy processes in place, etc since local testing does not hit that. The feature flags then get turned on on staging for more testing and verification by others, turned off on production (and sometimes turned on for specific users, etc). The biggest challenge I am running into with this is that no one wants to pay for cleaning up the old code once it's no longer needed and the features are permanently enabled.
This keeps feature branches from getting too crazy far out of sync by getting them back into master quickly and allowing for other devs to merge or rebase to get your changes into their branch. It gets especially important with db migrations because Django's db migrations get to be a real nightmare with version control if you let two branches with db changes get misaligned.
For a larger change which is not easily done in bits and pieces we will branch from master, then treat the new branch as if it were master - branching from and merging into it. Then merge it into master when it's ready. We've been trying to not get into that situation, though.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
#1 rule of any source control methodology: Delayed integration is bad, avoid it. The longer your feature/release/stage/whatever branches stay out of step with the flow of your code, the worse it is. You want the state of your code to be as consistent as possible across as many active branches as possible to avoid the dreaded "Oh god merge conflict" or "Oh it worked until your code merged with mine" BS you see happening all the time at shops with sloppy controls and lack or professionalism and attention to detail in their code management processes.
Yeah, we don't let our branches run on for too long, and most development work happens on our dev branch anyway so people on separate branches usually have no significant merge conflicts.
@Jimmy King that actually sound fairly appealing as a process too. I discussed feature flags with our lead today, and he was fairly excited about the idea. With any luck we'll try it on our next project which is a couple of weeks out at most.
Today one of the developers I work with implemented this clever permissions scheme:
Page A's controller checks the user's authentication and passes a list of their access groups to the view, which renders itself as appropriate. To see Page B, you then click on a link, to which he has helpfully appended "?hasPermission=true". B's controller checks the URL, and makes sure it says the user has permission before allowing them into the page that actually contains the sensitive information that would lose us all our jobs if it got out.
Thankfully he didn't make hasPermission an optional value, so when the users that lacked permission started complaining about the exception screen I was alerted and quickly swept everything under the rug.
+4
OrcaAlso known as EspressosaurusWrexRegistered Userregular
Today one of the developers I work with implemented this clever permissions scheme:
Page A's controller checks the user's authentication and passes a list of their access groups to the view, which renders itself as appropriate. To see Page B, you then click on a link, to which he has helpfully appended "?hasPermission=true". B's controller checks the URL, and makes sure it says the user has permission before allowing them into the page that actually contains the sensitive information that would lose us all our jobs if it got out.
Thankfully he didn't make hasPermission an optional value, so when the users that lacked permission started complaining about the exception screen I was alerted and quickly swept everything under the rug.
Posts
Yo dawg, I hate to break up to you, but if your rabbitmq got anihilated, it's gonna split. Cause....RabbitMQ!
This guy stores logs!
The error message you get if you pass something more complex is something like "this is undefined in jquery.size", rather than anything useful like "This data can't be posted".
I really hate dynamic typing.
definitely doesn't come stock with iOS, so we've got (very) expensive bluetooth GPS antennas
the + side is they're pretty accurate and they don't guess like iOS sometimes can
the - side is they literally do not work indoors, or with any solid obstruction to the sky at all. they don't even work badly. they simply don't work. so...
the +++ side is i can only calibrate it by taking a nice field trip to the park tomorrow with my laptop
OK, maybe that will stick around.
Google projects are in either of two states: deprecated or not ready yet; some projects get to be both at the same time
Then vendoring happened, then glide, then <insert your thing here> and now it's a damn mess because Google didn't take the problem by the horns earlier and do something about it.
That's why I mentioned graph databases specifically as having very interesting applications. Unfortunately though, in my experience NoSQL has meant document stores 100% of the time in the wild.
Yeah, that's annoying as shit about the whole attitude of the Go devs. "We know what's good for you."
I love govendor - it pretty much gets it right in terms of keeping everything you need in the Git repo of the proect.
You're in a different part of the wild than me I guess. I haven't used a document store, outside of dumb toy projects where they are great to get spun up fast, in a while. I use Redis and RedShift every day, at least indirectly as they are part of our infrastructure. My last position we used Cassandra and Redis quite a bit.
I'm not one of the main programmers (more of a technical artist that fell into programming) so some of the literature I've found seems to apply more towards code bases where there are a lot of dependencies outside of whats in the repository (I don't know the difference between a 'development environment' and a 'production environment' for example). All of our stuff is usually self-contained in one repo.
At the very least, I was going to suggest we move from master / dev / feature branches to master / release candidate / dev / feature branches. But unless I build my case, no one is going to go along with that.
Any pointers would be very appreciated!
http://steamcommunity.com/id/pablocampy
There are a couple ways I've seen so far in production at our company:
I'm curious to see what other folks have used.
Out of the options you've shown there, I think I definitely prefer 2. The disadvantage of course that over a large period of time, you end up with tons of redundant branches (and we're poor, so we've hit the branch limit more than once for .git).
I guess once you're done with a release though you could merge that entire release branch into master (our "Master" is basically builds that we know to be stable), and then prune the release branches every so often.
Thanks for the insight! Also curious to see what other workflows people have used!
For others, based on the amount of red tape, neither of the above is possible.
If you would like to "not think" about what you are doing, pick up "git flow"(it's already similar to what you describe) and just use some of the many tools that already implement it to facilitate your process.
Cue: People running in telling me how they "Really need their 3 month old branch and the feature couldn't be done without it!"
https://trunkbaseddevelopment.com/
in short, everyone works on master, all the time. ideally they only commit things that are not going to break the entire project for everyone else. if you need to do a release but have to trim out a bunch of in-development stuff, you cut a branch, do what you need to do to disable the in-dev work, do your build, and never look at that branch again, including never merging it.
i've been using this methodology since 2009 and have never found it lacking
We don't "cut releases", things just release, as fast as we put them in master. Master is always the pristine snapshot of what's in prod. If we have to hot fix, we snap a feature branch off of master, do the fix, then back merge it to development.
I say hybrid gitflow because we don't do all the release branching stuff because, again, we don't cut releases.
What methodology you choose should be about what kind of software you're writing and what your release infrastructure looks like. There is no one right answer or magic bullet.
From the research I've been doing, if comparing Go to Python
Revel -> Django
Gin (or Martini) -> Flask or Bottle
Gorilla -> no real equivalent that I am aware of
Bare go -> Python http.server, but the go may be more functional out of the box
Given what I've been reading so far, it seems like either Gin or the Gorilla toolkit is likely the route I want to be going for web stuff. Any opinions on that?
If you're just doing it for fun/to learn, carry on (and use Gorilla because it's name is cool).
Several reasons.
1) Fun and learning - it's always interesting to see how to solve the problems I'm used to solving but with different tools and Go seems to be a pretty good tool to have in my belt for ensuring I stay employable.
2) We do actually have a client we recently picked up at work who uses Go for some back end web and mobile app API stuff which we will be doing some work on. From what I've seen of their code so far, they do not have any standard set of tools they always use, so I'm keeping all of my options open, but will almost certainly be doing some web stuff with it. This client is why I initially started working with go (it had been on my to-do list for a long time, but I just didn't have enough reason)
3) I actually kind of like it for my main language - a lot of the ideals I like from Python but with type safety, better support for immutability, concurrency, etc. Even if it's even better for other stuff, it's not like it seems to be bad for web stuff.
Go is amazing for an http api and has one of the easiest testing stories for http you will ever find(and I am sure you will appreciate it, coming from python). When you see how it deals with TLS, you will blush. Go is an excellent choice for API and there are a shitload of companies migrating from ruby and particularly from node to it(big ass huge resources companies as well as smaller startups).
To be honest, if you were not coming from python I'd say that you should start with just httprouter.
If you want something *slightly* more advanced, I have used chi.
Finally, any of the frameworks you list will do the work adequately, there is no right choice, see what fits well with your mindset.
Chi looks nice as well. Go doesn't seem to have quite hit the same level of "Use one of these 2-3 tools" like everything else I work in (even Elixir has a definitive web framework, orm-like thing, etc), which is both cool and frustrating at the same time. I don't want to spend a bunch of time learning something just to have the whole Go community decide it's shit and abandon it in 6 months.
I'm mostly looking for something which is relatively common and no one is going to fault me for choosing to work with it/use it for a project, will handle most of the tedious (or worse, tedious yet easy to fuck up) bits so that I can solve the problems I really want to, but also not force my hand too much. As to the last point, Django for instance, as much as I love it, much of my development is spent not so much on "how do I solve this problem" but "how do I solve this problem WITHIN DJANGO'S STRENGTHS AND TOOLS" - which is fine until you hit something which Django just doesn't do well and then you have to write code that everyone hates you for as long as the project lives.
I have migrated chi to <undisclosed because I won't recommend> before, it's very, very fast work. If you still don't want to go for smaller libs, gorilla/gin/revel will be here for a while for sure.
We have actually done feature flags before; we just haven't thought about them as a tool for facilitating major changes. Mostly we just use a flag in-engine to say whether a build is a release, dev, alpha, or beta build - with various functions attached to the flag from enabling dev cheats to showing a different welcome message for alpha/beta testers. In practice we can just expand that.
Yeah, our problem is that literally everyone just wings it 100% of the time though. Which is definitely not where we want to be either. :biggrin: Not looking for perfection, just an approach people can solve most of their problems with!
If you can slow/soft roll out any given feature to a subset of users, then process of it getting there doesnt matter much at all.
PARKER, YOU'RE FIRED! <-- My comic book podcast! Satan look here!
If you're shipping an online thing, possibly. An app or other binary release not so much I feel.
I used to work where it was flags etc etc. It was painful as heck, and now it's git flow with a whole bunch of CI, and it's like night and day.
Are you using version 4? it just got officially released and it's a pretty major step forward over 3.x, especially in terms of "not looking like butt"
What aspects are you dealing with?
So far in my experience with 4, the most challenging aspect is not overusing certain conventions like Cards, which take up tons of space
Feature flags is how chrome does a ton of development work, among other google projects
In the past, we would then wait on testers to test on staging, etc. Then merge the branch to master and deploy. I have been pushing using feature flags and immediately merging to master and deploying after a quick developer verification on staging which mostly exists to ensure that your code works with the deploy processes in place, etc since local testing does not hit that. The feature flags then get turned on on staging for more testing and verification by others, turned off on production (and sometimes turned on for specific users, etc). The biggest challenge I am running into with this is that no one wants to pay for cleaning up the old code once it's no longer needed and the features are permanently enabled.
This keeps feature branches from getting too crazy far out of sync by getting them back into master quickly and allowing for other devs to merge or rebase to get your changes into their branch. It gets especially important with db migrations because Django's db migrations get to be a real nightmare with version control if you let two branches with db changes get misaligned.
For a larger change which is not easily done in bits and pieces we will branch from master, then treat the new branch as if it were master - branching from and merging into it. Then merge it into master when it's ready. We've been trying to not get into that situation, though.
@Jimmy King that actually sound fairly appealing as a process too. I discussed feature flags with our lead today, and he was fairly excited about the idea. With any luck we'll try it on our next project which is a couple of weeks out at most.
Page A's controller checks the user's authentication and passes a list of their access groups to the view, which renders itself as appropriate. To see Page B, you then click on a link, to which he has helpfully appended "?hasPermission=true". B's controller checks the URL, and makes sure it says the user has permission before allowing them into the page that actually contains the sensitive information that would lose us all our jobs if it got out.
Thankfully he didn't make hasPermission an optional value, so when the users that lacked permission started complaining about the exception screen I was alerted and quickly swept everything under the rug.
inarticulate rage