|
In difficult times like these when certain developers were assigned to port some Android apps to iOS I !@#$ Apple, iOS, Xcode and especially the webView object.
it ain’t broke, it doesn’t have enough features yet.
modified 20-Oct-19 21:02pm.
|
|
|
|
|
I know, not particularly fond of iOS myself
|
|
|
|
|
It's a pretty good editor. I use it whenever VSCode is not available and I can't install it. Very clean looking.
i cri evry tiem
|
|
|
|
|
I was using it, but switched to visual studio code.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
Over at the Kalzumeus Software website, an article was posted Falsehoods Programmers Believe About Names[^] which, in a somewhat tongue-in-cheek manner, describes some of the bad assumptions made about peoples' names that make websites difficult to use.
We, as programmers, have seen the problems with last names (surnames or family names) such as d'Agastino, O'Dell, McDonnell, Rice-Davies, !Mbeki, la Fayette, von Helstien, duBois, Peñia, Dönitz or Null (Yes, that is a real last name! ). Although not as common, similar problems exist with first names, middle names, honorifics, suffixes (Sr., Jr., II, III, et. al.)
Can we, being serious for a whole minute, come up with a set of sensible rules for handling all names of people that can be written in ASCII? — Adding rules for non-ASCII UniCode characters is an exercise best left for the future. Let's keep this to a discussion of rules and, for now, avoid the question of writing code to implement them – that belongs in other forums!
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
You know, the person could just write there name as "I am Null, from planet Krull". Problem solved. User's fault.
|
|
|
|
|
Why do you need any rules at all?
|
|
|
|
|
Because, once stored in a database, we will need to look up names and the person doing the search is not the person who entered the name. Having rules for names allows us to compare partial names to locate the records for the person we are trying to look up.
__________________
Lord, grant me the serenity to accept that there are some things I just can’t keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I’d like to, but just don’t have the damn bandwidth to handle right now.
© 2009, Rex Hammock
|
|
|
|
|
The rule is that you use nvarchar to store names in the database. You could also do away with names altogether and just assign everyone a GUID at birth. Problem solved.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
|
John Simmons / outlaw programmer wrote: You could also do away with names altogether and just assign everyone a GUID at birth. Problem solved.
|
|
|
|
|
Can I have a matching bar-code?
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein | "As far as we know, our computer has never had an undetected error." - Weisert | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
John Simmons / outlaw programmer wrote: just assign everyone a GUID
After logging in your site:
Hello, 7798eded-dfac-406c-a49b-b031a7d1afc5
This sounds so accomodating.
|
|
|
|
|
Humans' names are in no way unique nor immutable.
If your system imposes rules above and beyond those of the domain it is modelling then there will always be problems.
Better to allow fuzzy-logic searching (or use some other unique key if you are able so to do)
|
|
|
|
|
Which doesn't change original question.
But that said you want to make something deterministic which cannot be.
If the person that first entered the first name as "nine" it is unlikely to help the second person if the actually spelling of the last name is "9" or "mine" (they heard it wrong.)
The only real rules
- Name cannot start with nor end with spaces
- Name cannot consist of nothing but spaces, which is basically same as first rule.
- Name must exist.
After that work on something much more important like insuring that each person gets a bill every month and that they actually pay it.
|
|
|
|
|
So if you want to test the integrity of a system name your child "SET @Students = '<[db].><[schema].>Students TRUNCATE TABLE ' + OBJECT_NAME(@Students)
you can short by short hand call him student
So if the school he goes to registers his name and loses all their data it will be a sign that that school is not for your child
»»» <small>Loading Signature</small> «««
· · · <small>Please Wait</small> · · ·
|
|
|
|
|
jschell wrote: - Name must exist.
Why?
(see originally linked article.)
|
|
|
|
|
Mark Whybird wrote: Why?
I doubt that assertion.
If a company wants to deal with an individual as a legal entity, then that legal entity must provide their legal name. If a company wants to deal with a person as a non-legal entity then they must decide if they want to deal with the person or not. If they do then the person must have an identifier that people can deal with.
Of course in the context of the discussion one can state that if a person refuses to provide a name, regardless of whether one exists or not, and the company requires it then the company should just not do business with that person. That exceptional case would be so rare and so non-economically impactful the company should just take that option.
|
|
|
|
|
First try: Just replace any special character or space with the wildcard character, then use LIKE to compare.
Second try: Use SOUNDEX.
Third try: Write your own SOUNDEX-like function. I did this with PostgreSQL, when I realized that some foreign names did not compare well. Eventually, though, I got tired of maintaining it, and just used SOUNDEX.
|
|
|
|
|
Duncan Edwards Jones wrote: Why do you need any rules at all?
Agreed. It's one of those conclusions that seems to take devs a while to get to. Rules for names? I don't even implement rules for email addresses. If I need your email to be genuine I'll send you an activation link, otherwise I'll make it optional and couldn't care less what you put in it.
Of course I always use "int" to store phone numbers cos that's just common sense!
|
|
|
|
|
F-ES Sitecore wrote: Of course I always use "int" to store phone numbers
And ZIP codes!
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
Richard Andrew x64 wrote: And ZIP codes! Yeah ... never mind that such area codes in other countries tend to have all sorts of alpha numerics in them.
And then you get the odd guy wanting to input his phoneword instead of a number ... since that's how he remembers it.
|
|
|
|
|
The other "falsehoods" blogs are worth a read as well:
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Many of the time assumptions listed are stupid.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|