> One best practice that I'd love to see spread (in our codebases too) is always naming the full feature flag directly in code, as a string (not a constant).
Can you elaborate on this? As a programmer, I would think that using something like a constant would help us find references and ensure all usage of the flag is removed when the constant is removed.
One of the most common things you want to do for a feature flag or metric name is ask, "Where is this used in code?". (LaunchDarkly even has a product feature that does this, called "Code References".) I suppose one layer of indirection (into a constant) doesn't hurt too much, although it certainly makes things a little trickier.
The bigger problem is when the code constructs metric and flag names programmatically:
That kind of thing makes it very hard to find references to metrics or flags. Sometimes it's impossible, or close to impossible to remove, but it's worth trying hard.
Not OP but multiple code bases may refer to the same flag by a different constant. Having a single string that can be searched accross all repos in an organization is quite handy to find all places where it's referenced.
especially when you have different languages with different rules, `MY_FEATURE_FLAG` and `kMyFeatureFlag` and `@MyFeatureFlag` might all be reasonable names for what is defined as `"my_feature_flag"` in the configuration.
Using just the string-recognizable name everywhere is...better.
As an aside, those “feature flags as a service” tools have some neat features, but are just way too expensive for what most apps probably need: simple binary flags that can change at runtime.
Example: just use a database table. Query and cache in memory for 60s. If you want, build a simple internal web page or tool to toggle flags. This works, and scales (from experience).
Do many apps really need A/B testing or segmented rollout? Maybe, but probably not.
Because feature flags often intersect with segmentation and AB testing.
So it's not just a byte in memory, but often also correlating the status of said byte with a users identity and then tracking and summarising user behaviour based on that relationship.
It's become fairly standardised and requires engineer time to setup and maintain the services behind all that, so it's valid to go third party for less than the cost of said engineer time, if all you want is standard.
Edit:it's also hard to always predict when a standard flags going to become part of a test, so just integrating for every flag and making that a standard process for your teams becomes the simplest approach.
I am not a fan nor a user of backend feature flags, so don't ding me for relaying this: they tout features such as central management of these settings, bringing them in the hands of the product team rather than being tugged away in code, allowing for canary deployments where you fade in a feature based on performance metrics, a/b testing, and so on. In their own interest, these folks take an as broad as possible view on what is a feature flag, often including things that you'd otherwise call system configuration or entitlements or permission toggles. It's not a new trend, LaunchDarkly is probably the best known commercial party here, and they've been around for about ten years, and I don't think they were first.
I wouldn't say a new trend, it did go through a hype cycle a few years ago, and some teams have adopted it. I definitely wouldn't call it a standard practice though, as it brings with its own overhead. In effect you've got "byte in memory as a service" with its own deployment, maintenance, and statefulness. It's only useful if you have a business model that really relies on having this capability. That could be in a sufficiently large, already complex, sprawling application estate, having a single flag in a central location could be useful if several pieces of your sprawling estate need it.
"Just use a database table" solves for the simplest cases - a single monolithic app. It works incredibly well in this case. It falls apart when I need to turn features on across multiple apps together.
I think OPs point was a simple app doesn't need this whole suite of tools, but you pay for them anyway, which makes it a bad cost/value proposition for simple apps.
So yes a more complex situation could benefit from all this extra tooling and complexity but otherwise it is dead weight/cost.
I would claim that release a new feature by enabling additional code path across multiple apps at once is a bit of an anti-pattern. It seems rather dangerous and error prone. In that case I'd actually release it in reverse order, so to speak. Release the apps that use the services of others first and have it check is this service is available/functional and if not, skip calling it. The release the feature to the next service down the stack. Then you can always rollback the last service and be confident that the callers still work.
It's way more work and I can see why for certain types of application isn't not really worth the trouble.
> Just use a database table" solves for the simplest cases - a single monolithic app.
Most cases are the simplest cases.
No approach works for every single use case, but OP was specifically talking about the common case. You don’t have to shoot for the most complex use case every time.
I think most frameworks I have worked with have the concept of configurations, more advanced ones have config that can be overriden by environment files. Definitely a solved problem if you want to roll your own.
.env files are the quick and dirty version for simple sites that don't have an admin panel or database.
This technique has been used since Wordpress days and earlier. At it’s core, it’s a “meta” table with a string identifier and some value. It’s a pattern I still use today in my own web apps.
It is, but the key point is that this doesn't lead to people sending mail to the wrong address since nobody can sign up to "the wrong address" in the first place. There's one address allowed, aliased to all permutations.
It does lead to people sending mail to the wrong address, from personal experience since Gmail was in beta. I've gotten sensitive emails and account signups with different dots for years.
But the cause of that appears to be user error -- people thinking they own email addresses that are not actually theirs.
This happens to me all the time. There are two people, one in Massachusetts and one in Suffolk UK who have my same name and regularly put in FirstLast@gmail as opposed to the first.last@gmail that I use. The Massachusetts person does this because they forget that their gmail is the full version of “first” as opposed to the shorter version I use. The Brit is confusing gmail for hotmail. Yes really. Most people don’t care that much about computers. If it’s possible to screw up, someone will.
Someone gets righteously indignant that this cannot happen in every thread about dots in gmail, despite the fact that there are many people it happens to. They’re not making it up, why would someone do that?
Please look at my example up thread. It’s the combination of mistakes amplified by the dots. The dots make it worse by far.
I just searched for my name with no dots in my gmail. Man. It’s a dumpster fire. I have to put up with hundreds and hundred of wrong mails monthly because this feature amplifies the mistakes so much. And it adds to spam because other people type the wrong mails into forms and gmail “fixes” it by ignoring the lack of dots. It’s honestly infuriating. We know we own all versions. We get it. That’s what causes extra work for us and makes us like the product less.
My experience would be significantly improved if I could have all the non canonical addresses bounce. I agree that I would also like nobody else to own one of the other dot versions but that’s also possible.
Rewritten:
For various reasons, people mistype emails and they usually end up with a no-dotted address. Mine, as the catch-all, gets that mail.
A classic made up example is eg “fred.fredflintstone@gmail”. I have many times received mail for that person because I’m “fred.flintstone@gmail”. People see the double fred, remove the first and hit my account. I also get for “fredtflintstone” (notice the t, many don’t) and this last month “fredrflintstone”. Life would be much easier for all if gmail just bounced those when someone types it as “fredflintstone”. They’d check and fix it.
This is amplified by spam, because any leaks others make hits my account. They should bounce.
This morning I put up a filter to the no dot version. About a month ago someone put my no-dot version on their dodgy Microsoft ads account. I spent ages trying to get off it and somehow Microsoft still hasn’t taken me off. Now I’m just filtering that to deleted, along with mail for all the mistakes above. I’m done. Gmail’s dot policy enables this hugely.
1) people who are sending important emails are ending up with the wrong person and they don’t know. Fixing that takes effort on my part, I have to tell individuals or a group mail I’m the wrong person. A bounce would fix that, instantly with no effort. I sometimes try find the right person. That also takes effort, I have to look for clues. Locations, work hints etc.
2) I’m fairly careful with my email. Others aren’t. Most of the spam I get is linked to the wrong address. Those should also be bounces. Because I get mail for all dot variants, I get a multiplied amount of spam compared to just my version.
3) I’m pretty sure a dodgy money making racket is to sign people up via affiliate programs in the hope some of those get added. I see this in a huge amount of random email lists, products etc. I’d say 80% minimum of those use the no-dot version. The problem is that 80% I shouldn’t have to put up with. The people doing this are just being lists of addresses and firing them at anything that works. They aren’t targeting me, they’re just using the strings they’ve harvested. So they don’t know about the version I use.
The Microsoft issue pushed me over the edge. I’m now going to trash that entire set of problem for my own (selfish) purposes by filtering it out. The people being harmed are those whose contacts mis-type addresses and now eg invites to funerals will go to trash.
The optional dots would seem to be irrelevant. You seem to be asking that all email sent to your address, but not intended for you, to be bounced. An email address can only be validated (as in "Is this an email address?") by trying to send mail to it. Assuming the mail is deliverable, there is literally no way for the sender or any mail server involved to know whether the address on the message has anything to do with any person who has access to the contents of that mailbox.
The only possible way that I know of to provide feedback is to send a reply to the sending address. Perhaps you're asking for an addition to the email system so that a recipient can "click a button" to generate at the protocol level a response from your mail server like "errNum% - Wrong recipient. Undeliverable as addressed."?
No, I want all mail that doesn’t use the email address I chose, which is “fred.flintstone@gmail” to be blocked as it would be on any other mail platform. I want gmail to act like any other mail provider, no dot innovation because I don’t want it. I’ve had this address since 2005. That’s a long time to learn about the benefits and costs.
Rule: for any email address variant that is not what the user selected, reply with “550 no such user here”.
Instant reduction in both spam and mistyped emails. Instant feedback to sender.
If they forgot a dot and received a "no such mailbox", they'd check and fix it.
Some data, sans opinion: I checked my trash this morning after clearing it out. Total messages in trash: 47. Trashed messages linked to the "fredflintstone" variant: 40, all of them spam. The other 7 are all real messages I've just deleted after reading, none of them are spam.
> If they forgot a dot and received a "no such mailbox", they'd check and fix it.
why would they? do you think another person would not register
fredflintstone@gmail
and another user could register
fred.flint.stone
and another user
fred.flints.tone
then you have lots of people using email addresses that are the same if the end user excludes the easily forgettable punctuation marks.
Your anecdote about one person who keeps giving your email address out does not mean that Googles dot policy is bad.
I can't expand any further on what I've already said so I'm going to leave the discussion
I’ve gotten emails from some other Gmail account, for example an Uber receipt. I found that by digging in the header that there was a “x-forwarded-to:” to me. My guess is that the original user accidentally configured a bad email forward.
That's the point I think, the dots aren't causing any issues here, some people just assume their account is f.m.lastname@gmail.com and many of them are too stubborn to accept that it's not.
They never had an email address with or without dots that's made up of the same letters as your email address. Their email address is probably very different (maybe they forgot to add a number, or a middle initial, or typed Gmail when they should've typed Outlook). The dots are just a stylistic choice.
Exactly. The dots are useful from a UX perspective, as it makes "incorrectly addressed" email more obvious.
I've spent way too much time thinking about this.
Well, specifically about the kind of person who would use an email address they don't own to (a) buy a house, (b) apply for a FL sheriff's job, (c) conduct financial transactions, etc. (all actual examples I've received).
You think you have a bead on how ignorant people are, and then you realize there's a long tail you weren't aware of...
I think there's also a distinct possibility that the senders just have the wrong email address, especially when it contains a name.
You could own steve.brown@gmail.com but someone you only occasionally do business with might have accidentally put down steven.brown@gmail.com when you first met. Emails back and forth will work (because they can reply to your emails) but when they try to send you email, someone else will receive it.
This can also go unnoticed (i.e. when someone sends an email stating "when are you sending the documents?" -> "I already did, maybe they ended up in spam, here you have them again"). People probably won't notice unless the unintended recipient tells the sender that they got the email address wrong. I imagine that might happen a few times, but after a few years of other people using your email address, you'd stop bothering.
I generally try and reply with "This email address isn't owned by the person you're trying to reach. Please reach out to them and reconfirm what email they want you to use."
Responses have been pretty bizarre though. I usually get what amounts to an "Okay".
I would have expected some sort of "Could you please delete those sensitive documents we sent you?" at minimum.
Also bizarre... I don't have a very common name or email address for my main Gmail.
I can only imagine what john.smith@gmail.com has to deal with.
From a solution / feature perspective, it'd be nice to have a auto-response + trash on anything other than allowlisted dots and plusses. Maybe Gmail supports this? The worst offenders finally got the picture, so I didn't dig into it.
Gmail does support conditional auto replies and filters. You could probably filter out most typos if you stick to your own format for every website and contact you have.
The point is "ignoring dots" doesn't lead to "constantly getting e-mail for other people" (because there are no other people that own the "dotted" version of the email).
It does though. My gmail account has a dot. For some reason someone with a similar name to mine must have for believed his address was the non dotted version of mine and to this day I keep getting emails addressed to this other person... and yes, it is a real person who I've managed to contact.
The point is that without the dots rule I'd never get those emails, and the senders would get their message bounced back right away.
You’re probably thinking of debug symbols, i.e. the PDB file that is generated alongside the binary. You can generate this for both Debug and Release builds (should be on by default in fact). It’s super useful for debugging crash dumps from production, and for exception logging in web apps.
You can think of this like a source map, but only files and line numbers.
Another common spot to easily find Megalodon and other large shark teeth is the Savannah River just past the shipping ports. The river dredging from a few years ago created a few new “islands” where shark teeth are plentiful.
It's an almost verbatim example of getting to 1NF, the first and most basic normalization. The value (department name) is repeating and should be extracted and given its own ID.
1NF bans relation-valued attributes, not repetition of attribute value across tuples in a relation. Mainstream SQL databases don't support relation-valued attributes, so any table you make in a relational database is 1NF.
You can push back on this a little - for instance maybe you consider an array-valued attribute to be enough like a relation to argue array-valued attributes violate 1NF. But if you do that you must also explain what makes arrays different from strings, since strings are pretty similar to arrays of characters and can be treated the same way in most respects (for instance characters in a string can be addressed by index or split into substrings).
> The value (department name) is repeating and should be extracted
Then the id would be repeating. Furthermore, the department name would make a fine primary or alternate key for the new relation you're proposing.
Also, that's not what 1NF is. 1NF means there should be no table-valued attributes. And neither is any column list-valued nor does any subset of columns form a subtable.
The other normal forms talk about functional dependencies and there aren't any.
The only possible violation of 1NF could be not splitting the name in given name and family name. Other than that, the table is normalized.
Yes, but it's an ID, not a value. No problems there.
> Furthermore, the department name would make a fine primary or alternate key for the new relation you're proposing.
They're called "natural keys" and there's a lot of problems with them not actually mapping to identity. Like for one example, if a department's name is changed, it isn't just a change to the database column, you have to update all associated code as well - which is why you should have an ID and use that in the code anyway.
> Also, that's not what 1NF is. 1NF means there should be no table-valued attributes. And neither is any column list-valued nor does any subset of columns form a subtable.
If there's only one such column and you switch perspective to the inner table, the transformation is the same. That's why I said "almost" - it's not exactly the same, there are additional conditions, but if you hit them it's the same thing and the result is extracting the duplicate values into their own table, linking them with an ID instead.
In normalization theory and relational algebra an ID is just a value. DBMSs make no difference between this column and any other primary key column(s) and they make no difference between PK indexes over strings or numbers or any other supported data type.
You're just cargo culting here instead of applying database theory or actually looking at implementations.
Even if there were a separate Departments table, who is to say that the Department Name is not its primary key? The Department name certainly is A key.
reply