Definitely if you need to internationalize past the Anglosphere, you need to think about names that are not composed in the way that Western names are. However, note that this is driven by a change in the data that must be entered and not by considering use cases. If you only collect full name because your application is global and it's too hard to do anything else, that's fine, but "use cases" has not entered into the picture anywhere in that decision.

I don't think anything you have said has contradicted my central thesis - namely that you should collect ALL the data that is readily available and store it ATOMICALLY - and also store composites if desired.

I feel like there must be a localized name collection standard, in the manner of libphonenumber. If there isn't, there should be. I've never worked on an app where the requirements included localization beyond the Anglosphere.

First, I should be clear that I think we generally do a horrible job in Software of being inclusive in what we build. There are many people in the Anglosphere (aka immigrants and visitors) that put up with anglo-sizing of their name because they have no choice. But we should strive to be better. /end political rant.

The database is all about use cases. The raw data of 'surname' isn't important in just about anything (?)*. You said you need to store it to sort names. So you're storing data for use cases already. But instead you're doing it with a poor proxy.

I am contradicting that central thesis. Because the fields first and last name aren't going to be standard for all of your users. So are you going to create new fields for every type of name that exists? For example, the Japanese character for how the name should be sorted? The second last name? etc. etc.

It's not actually practical to store all of the atomic pieces of information for a name across major cultures (let alone across the thousands of non-major cultures). And just forcing everyone to use your form (first/last) leads to at least two bad things:

1. It forces cultures that don't follow that convention to misrepresent their name.
2. It forces business logic to continue to use first/last name as proxies for the actual use case - something that can get pretty hairy fast.


One last question, did you also lose respect for the WC3?


* Well - it may important to join to other systems - but I'm going to throw that into "makes a bad design acceptable for legacy reasons".

I should also add, I'm mostly being this passionate about this issue because:

1. It's kind of interesting.
2. It keeps me from a stupid wage gap argument in PU.

In the past I've had to put up with my name being bastardized in forms and emails because it has non-us-ascii characters. I've also had to hack a Spanish customer base on top of a first-name/surname framework resulting in an ugly hack. And I happen to come from a patronymic country, although I'm in the small percentage that has a surname due to historical reasons.

So I'd like to +1 everything that jjshabado is saying.

Are you also trying to stay away from a stupid wage gap argument?

there a quick and easy linux/raspbian way to limit ssh login attempts and block IP x for y minutes after z failed attempts?

keep seeing people recommend fail2ban, but I figure there's gotta be an easy way (relatively speaking, since this is linux after all)

I think that if you want a totally normalized version of the system, you have to do something like this:

but I think you'd have to expand those tables to specify first, middle, last, etc.

But I think a better compromise is just have a table that takes arrays in each field (assuming PostgreSQL here) of first, middle, last names. That way, you get a machine-coded separator and fast lookups.

But once again, I don't think NULL is a bad thing...

Does anyone know a website etc, where you can buy some programming teaching/coaching?

Stackoverflow is absolutely amazing site and I use it almost daily. However I'm looking for someone to have on my Skype or e-mail, who's willing to review my code and help me for $.

So this post sparked a conversation between _dave_ and myself and I wanted to bring the points into here.

FLOSS4business companies actually have great salespeople. There are lots of reasons for this, and I'm open to discussing this more if people are interested, but there are some companies that I could name off-hand who have not only great, but truly world-class sales environments.

The biggest problem I see as someone pretty deep in the industry is very simple:

Open Source vs. Proprietary solutions do not solve for the same thing. Open Source is about using technology as a competitive resource, Proprietary is about solving a specific need.

Now to use a bunch of terrible analogies and explanations:

Open Source is getting the frame and body of a car for free. This frame and body is going to be absolutely phenomenal. It is the best frame and body you can get your hands on. However, you still have to finish the car. Even with a great frame and body, you can screw up the rest if you don't know what you are doing. Or you can pay experts top dollar to build an incredible car. When those experts are done, it won't have been cheap, or quick, but you will have one of the best cars in the world. You can enter it into races and expect to win.

Proprietary is buying the entire car, getting a financing package so you pay it off monthly, and your car looks the exact same as 90% of the cars on the road. If you simply need a car to get from point A to point B, this car is going to perform solidly. It will break down occasionally, but it will do its job on an average basis. If you enter it into a race, expect to lose and likely be unqualified from even competing. The car is not interesting and will eventually need to be replaced in a few years.

This is what companies should be considering when going for Open Source or Proprietary. Do you want to build a platform that offers a competitive advantage to your company? Then you should use open source. If you just need a product that "simply does A,B, and C" you should be looking at proprietary solutions. You can get started as soon as your instance is ready (in seconds, mins, hours, maybe days) vs. in open source having to build it.

Another factor other than the use case (best in class vs. just getting X done) is the risk. Open source requires a project. Projects fail enough of the time that they are risky. Proprietary (and especially SaaS) is built to onboard customers rapidly. Instead of a project, you can get started on Day 1.

The final factor is cost and financing. Open source often requires implementation, Proprietary will be served as a service and a monthly cost. It is much easier to go into the budget immediately. Over time, the open source alternative may be cheaper, but things move so fast it can be hard to get to that point.

The other part is how you are going to maintain the open source product. Thats obviously a big difference to proprietary.

In general, when I speak to a company that is considering using Open Source vs. Proprietary they are usually only doing it because they are looking at the "popular" solutions and they are asking all of the wrong questions and don't understand what they even want out of it.

What could be easier than sudo apt-get install fail2ban?

They didn't list a command line install as an option. I'll have to see if that works.

Mostly don't know how else to install stuff in Linux.

This simply is not possible to parse and get it meaningful.

Take for example a few names:

1) Madonna
2) Juan Pablo Montoya Roldan
3) Mao Zedong

GL parsing that and figuring out a last name.

(answers for those of you scoring at home):
1) None
2) Montoya or Montoya Roldan
3) Mao

TC, I meant parse for each individual name part (since that's what they were discussing storing).

The rest of your post is exactly why I'm saying storing specific name parts is 'wrong'.

Its very easy to do security right and have anonymity for every individual in school or health systems or government programs.

All you have to do, is collect from your subject some DNA by just stealing blood.
You then have a unique key about the person.

Outlaw other agencies allowing to store or exchange DNA. Make it illegal for insurance companies to ever view a person's actual DNA, so they can't gouge the person if something is wrong with them by added charges before signing up or just give out free health care to everyone.

You do not distribute this key to them but you scramble it in a way, that only you would be able to reverse, do this hundred of thousands of times but keep the results.

Example:

key: j23o23jj2-afijffjeofie-ADSFDFS-AFDADSF (whatever you get from DNA sample, i'm not into that ****)

You encrypt key and store it. Use recursion to create new key and do all that **** again, over and over (REALLY LONG).

As mathematicians get wiser, they can then use their new algorithms to encrypt the keys as time goes on, basically abandoning the old keys that they never distribute to anyone.

You're distributing the keys in an order from top down to 1. So it will take years to crack if people had to go one by one down the chain. You keep all the info in non online vaults for the decades that you unlock every hundred of years or whatever is needed to crack each key as technology gets better.

Now should this be done to track people, who knows but I think its evil unless the person gives their own OK on it by first verbally understanding and if not ok with it... They should be allowed to request everything of their encryption keys be destroyed. Very easy to do.

Also if one place every gets hacked, abandon to new key, like if you can't figure that out...
Anyway maybe it works, maybe it doesn't but I think about it, at least.

How do you parse a "part"?

And storing in this case it makes perfect sense.

Then again, you can end up with even crazier cases where people have 2 middle names.

Ugh, I really hate repeating myself. I think I explained what I meant pretty well this morning so I'll just leave it at that.

You're wrong though.

Cool.

Translation in general is still an afterthought for such a massive % of the internet.

The hacker news mobile change today is **** on android.

I want to do some reading to upskill while I'm taking time off and am looking for a good book or ebook on these topics:

- Test Driven Development and writing good unit tests in general.
- Domain Driven Design
- An advanced book on Javascript.

Suggestions welcomed.

Hacker News 2 seems fine/the same.

I liked "secrets of the javascript ninja" by John Resig/creator of jQuery. I don't think there's much out there for ES6 though.

FFS javascript. TIL an underscore each loop can hoist assignments to top of scope causing a mismatch between a console.log and a breakpoint in a browser. I didn't even know that possible. I guess I should actually use breakpoints now.