I'm getting an error when uploading my customized policy, which is based on Microsoft's SocialAccounts example ([tenant] is a placeholder I added):
Policy "B2C_1A_TrustFrameworkExtensions" of tenant "[tenant].onmicrosoft.com" makes a reference to ClaimType with id "client_id" but neither the policy nor any of its base policies contain such an element
I've done some customization to the file, including adding local account signon, but comparing copies of TrustFrameworkExtensions.xml in the examples, I can't see where this element is defined. It is not defined in TrustFrameworkBase.xml, which is where I would expect it.
I figured it out, although it doesn't make sense to me. Hopefully this helps someone else running into the same issue.
The TrustFrameworkBase.xml is not the same in each scenario. When Microsoft documentation said not to modify it, I assumed that meant the "base" was always the same. The implication of this design is: If you try to mix and match between scenarios then you also need to find the supporting pieces in the TrustFrameworkBase.xml and move them into your extensions document. It also means if Microsoft does provide an update to their reference policies and you want to update, you need to remember which one you implemented originally and potentially which other ones you had to pull from or do line-by-line comparison. Not end of the world, but also not how I'd design an inheritance structure.
This also explains why I had to work through previous validation errors, including missing <DisplayName> and <Protocol> elements in the <TechnicalProfile> element.
Yes - I agree that is a problem.
My suggestion is always to use the "SocialAndLocalAccountsWithMfa" scenario as the sample.
That way you will always have the correct attributes and you know which one to use if there is an update.
It's easy enough to comment out the MFA stuff in the user journeys if you don't want it.
There is one exception. If you want to use "username" instead of "email", the reads/writes etc. are only in the username sample.
I don't know if it's an appropriate place to ask this question, hope it is.
I'm looking for a way to uniquely identify a mobile operator in the world. I'm aware of the MCC/MNC tuple, unfortunately big mobile operators might have more than one MNC.
I found an identifier called TADIG(or sometimes PLMN CODE), but unfortunately GSMA standard says that there is one to one mapping between MCC/MNC tuple to TADIG identifier and again it means that one mobile operator might have more than one TADIG(of course I checked and found that it's not unique).
String comparison between mobile operator names doesn't seem like a good solution, there are different naming conventions around the internet for the same operator.
Does anyone know of any unique id that mobile operators might have?
Thanks.
The probable solution is if the MNOs (mobile carriers) publish their ip block publicly, then we can try to group them by ips and map them to MNOs. But problem is
Its not publicly available
It tends to change every now and
then and MNOs don't really care about updating them.
I tried using combination of ASN, ipslash24, MCC-MNC but they weren't really useful. Let me know if you find anything.
Working on testing a React component, I was reading the docs and found scryRenderedDOMComponentsWithClass. I'm having trouble understanding the function of this component because it's unpronounceable, so I don't understand how it's naming maps to a mental model of what it's doing. (There are a number of related names, such as scryRenderedDOMComponentsWithTag.)
What does the scry part of this method name refer to? Scary? Scurry? What concept is this name trying to illustrate?
Short answer
"Scry" in this context just means "find all". See this comment on ReactTestUtils.scryRenderedComponentsWithClass. It's a single word, not an abbreviation, and it's pronounced like "cry" but with an "s" at the beginning.
Longer (and nerdier) answer
Elsewhere in that same file, you'll see a reference to DOM.scry:
/**
* Todo: Support the entire DOM.scry query syntax. For now, these simple
* utilities will suffice for testing purposes.
* #lends ReactTestUtils
*/
zpao explains in a comment on a GitHub issue:
That's a reference to an internal Facebook module. It's basically querySelectorAll with fallback behavior for handling old browsers and special cases. It is pretty unremarkable and doesn't actually translate super well here (except maybe a scryRenderedDOMComponentsWithQSA or something, but meh). We're working on improving the testing in other ways so I don't think there's anything we really want to do with this right now.
jimfb takes it a bit further in another GitHub issue, explaining that the name is a reference to Dungeons & Dragons:
Back in the day, we had a bunch of D&D fans on the team.
For reference:
http://www.dandwiki.com/wiki/SRD:Scrying
http://www.dandwiki.com/wiki/SRD3e:Scry_Skill
https://en.wikipedia.org/wiki/Scrying
Historically, we've used scry to indicate a helper that finds a set of results. As the framework matures, we should start choosing function names based on what the functions actually do instead of fantasy words that have very little meaning to the typical developer.
Though I would agree that the word has very little meaning to most, it's worth noting that "scry" is a real English word:
scry
[skrahy]
verb (used without object), scried, scrying.
to use divination to discover hidden knowledge or future events, especially by means of a crystal ball.
Interestingly, according to the data from Google's Ngram Viewer, it seems that the word fell out of normal usage in the early 19th century and then wallowed in obscurity until the 1980s, presumably after D&D gained popularity:
So I can't say I object to jimfb calling it a "fantasy word", especially considering the kind of imagery my imagination conjures up when I hear it.
Throughout Silverlight and WPF, properties that are boolean values are prefixed with Is (almost all), for example:
IsEnabled
IsTabStop
IsHitTestVisible
In all other Microsoft frameworks (winforms, BCL, ASP.NET) Is is not used. What prompted their team to move away from the original naming convention - is it an evolution or a miss-naming that had to stick?
Personally, I always try to prefix boolean values with something that adds a little more meaning (is, has, can, etc.). My usage comes from the following Microsoft guidelines:
Do name Boolean properties with an
affirmative phrase (CanSeek instead of
CantSeek). Optionally, you can also
prefix Boolean properties with Is,
Can, or Has, but only where it adds
value.
MSDN - Names of Type Members
I don't believe this was always the case This wasn't always the case. Those practices date back to .NET 2.0. Before that, things were fair game. Cleaning up those names in newer versions of the Framework, however, would cause all kinds of headaches (hence some of the Framework code uses the convention and some doesn't).
It definitely makes things more readable though. Even using an example from your question. Which would you rather have?
// ambiguous naming, could mean many things
myTab.TabStop
or
// definitely a true/false value
myTab.IsTabStop
The Is prefix can give a hint about the fact that the property only has a get accessor, and, as Thomas and Rachel said, it's a bool. Skip the prefix if you intend to implement both get and set accessors and its type is other than bool.
The Is prefix is part of the official Microsoft Framework Design Guidelines (this does not mean that all MS products adhere to it...).
Personally, I find it useful, if consistently used. It immediately tells you that a Property is a Boolean. You might use it or not, the most important thing is to be consistent about it...
Thomas
Which naming convention do you use and why?
I like to use employeeNameTextBox, because:
It seems more natural from an English language perspective.
I find it's easier to look up with Intellisense.
The convention is similar to the convention used for events (MouseClickEvent, MouseClickEventHandler) and dependency properties (VisiblityProperty).
Note: I am using the full name rather than an abbreviation (such as "tb"), because it is in line with MS's naming conventions that say to avoid using abbreviations.
http://msdn.microsoft.com/en-us/library/ms229045.aspx
The only reason to use the control type in the name first (textBoxEmployeeName) is for easier grouping with Intellisense (All textbox controls would then show up together). Beyond that, there really is no benefit to using that way. I find the second way (employeeNameTextBox) more readable and prefer that way personally, but a lot of people will still go with the control type first, since that is the way it was done for a long time.
Naming your variables is so important. Thick client view conventions seem to be given the short end of the stick. Here are my thoughts:
Never put getters and setters for actual business values on your view. Don't do this:
public Name EmployeeName { get; set; }
To get or set an EmployeeName, your stateful code should explicitly call a method. Do it this way because it projects that the state is not stored on the view, but can be derived from or transposed to the view:
public void SetEmployeeName(Name employeeName);
public Name GetEmployeeName();
Hungarian notation is stupid. It was useful in languages <= VB6 because they used late binding of variable types. You had to protect yourself because type mismatches were runtime errors, not compile time. Only use txtEmployeeName if you also would use strEmployeeName and intEmployeeNumber.
If prefixing the pattern name isn't consistent with your naming convention, don't do it for the control type (which represents a pattern). If you wouldn't create a commandNameFormatting (instead of nameFormattingComamnd), then don't create a textBoxEmployeeName.
You'll probably need a suffix of some sort, since EmployeeName doesn't sufficiently describe the variable's purpose. An EmployeeName text box's purpose is to receive input. You could call it EmployeeNameTextBox if that makes you comfortable, but it might be better to call it EmployeNameInput. This has the added bonus that if you have a label, it's clear that EmployeeNamePrompt (or EmployeeNameLabel) is not the same as the text box. Without some sort of descriptive suffix, you don't have a good way to differentiate.
I (almost) always use [controltype][descriptive name]. I want to know right away what type of control I'm dealing with when I look at code, and if I DON'T remember the name, intellisense can help me out.
Just using a descriptive name (EmplyeeName) doesn't work for me. What type of control? Is it a label, a text box, or a combo box? Or a string? Or a file? It's important enough that the type of control or variable is always a part of it.
I propose a third option: uiEmployeName. Reasons:
It's not Hungarian. Both of the notations you mention are just flavors of Hungarian.
If you change an employee name text box over to a listbox you don't need to rename your variables.
Everything is grouped nicely in the intellisense without involving the type of the object.
The name of the object closely follows its function. It is a user-facing object that gets the employee name.
I generally try to keep the element type short, followed by a distinguishing label. I find that it quickly communicates the type and purpose of the element:
txtEmployeeName;
lblEmployeeName;
Why not EmployeeName? Seriously how does the control type as part of the name when it is already provided by your IDE assist in delivering easy to maintain code? Consider Ottenger's Rules for Variable and class Naming
K
As I read it, an article linked to in the article mentioned in the question (namely, Names of Resources) does use the control type at the end, in FileMenu (and ArgumentException though it's not a control).
My personal opinion is that this is also more readable, as it's the employee name text box and hence should be named the employeeNameTextBox, just like the words "File menu" are read in that order. (Though I substitute "Edit" for "TextBox" for brevity — I should probably kick that habit to use control names consistently with the environment name for them.)
A MUST READ is the XAML Guidelines released by Jaime:
Also read more here
WPF-specific Answer: No name at all.
Why? Because if you're developing using WPF you should not be naming your controls. If you are, you are doing something wrong.
WinForms required controls to be named because its data binding was so weak. WPF solves all that: The control itself can specify its data and behavior, so there is no need to name it.
I guess it's better to follow Microsoft's Object Naming Convention for naming your controls both in C# as well as Visual Basic.
I don't recommend hungarian notation in any form. textBoxEmployeeName is a form of hungarian notation. So I support the use of employeeNameTextBox.
Personally I don't even bother using the word TextBox, because it is not what is important about the variable. What is important is "Employee" and "Name". Not only does adding the word TextBox lock you in to a certain type, it also make it much harder to change that type, because you need to change the name to normalize your code and make it correct. Say for some reason you started this as a TextBox, but you later received a requirement to change this to a DropDownList or some other type, now you have to update all of your code and JavaScript to make it say DropDownList instead of TextBox.
It is much easier to forget about trying to type your variable names, and just simply name them. You have intellisense and compile time error checking for a reason, why not use it.
I would go with [controlType][DomainTerm] which in this case is textBoxEmployeeName. The reason is that while coding for the C# code behind you are more care about the UI controls than the domain specific terms.UI(View) side coding we need to identify/recognize the control type faster, which is little more important than the domain specific name in the View side , and since we read from 'Left to right' this naming convention is relevant.
I generally use txtEmployeeName or cmpEmployeeType , but textBox instead of txt is preferred as per MS guidelines
I have used both txtEmployeeName and employeeNameTextbox. Like many of the posts indicated, this is helpful for grouping. One groups by control types (txtEmployeeName, txtManagerName) while the other can group different related controls together (employeeNameTextbox, employeePhoneTextbox, managerNameTextBox, managerPhoneTextbox). In many cases I find the later more useful while coding.
You should do whatever it is that makes your code readable and self-documenting. Following hard and fast rules is always a mistake because they almost never cover all aspects of what needs to be done. There is nothing wrong with having guidelines (such as not using Hungarian notation), but it is more important that you are consistent and clear with your naming convention, whatever it is, than you follow some rules found on the Internet.
Ideas:
Avoid encodings/abbreviations.
The name should stand out from
similar names in the same scope.
Make the unique-most part the
left-most part. I suspect you have
several text boxes, but only one is
the employee name.
Avoid needless context. Are all the
names on this page about employees?
Is it an "employee" page? Then
EmployeeName is redundant. NameBox
or NameControl should be plenty.
Avoid needless context: do you have
names that are not controls? If so,
"Box", or "Control" is useful,
otherwise not so much.
Disclosure: I am the "ottinger" from "ottingers naming rules", which also evolved to be chapter 2 of "Clean Code". See short form at http://agileinaflash.blogspot.com/2009/02/meaningful-names.html
In VB I actually like to go with [ControlName]_[ControlType]. I can't remember how I started doing that but I suppose it's because it feels like a logical order. It also simplifies coding a bit because the code suggestions are grouped by the control description rather than the control type.
I name controls the same way in C# except I follow C#'s preference for camelCase: [controlName]_[controlType].
I also tend to use my own abbreviations for control types, though they are not vague.
Examples:
VB: Save_Btn and NewFile_MItem (menu item)
C#: save_btn and newFile_mItem
It works for me, but of course every programmer has their style.