Doesn't seem like much work at all to me, compared to creating random users.
Then again, maybe it's just me that isn't creative enough to be able to come up with names other than "Test User", "Another User", "Somebody Else", etc. :-p
If you scroll to the bottom of the page you can see he got them from Greg Peverill-Conti's 1,000 faces project, which is licensed under Creative Commons BY-NC-SA 2.0,
I don't think so; it's pretty trivial to decode the JSON and make it a native object/array/whatever in almost any programming language.
So far I always did a "user[count]" or "user[timestamp]" thing and it was time consuming, dull and most of all didn't do the best job at presenting the app to the clients.
Neat little API. Would be cool if there were a way to generate users with a particular locale - e.g. so I could generate UK users with UK addresses, telephone numbers, etc.
Cool idea! Btw, your Ajax code snippet won't work, 'return' is a reserved keyword :) I would suggest using 'data' or 'response' instead for your variable name.
Very cool! Limited to US only though. Check out behindthename.com/api/ if you need country distribution. Had to map country codes to groups of names. Let me know if you need this data. I’ve got some scripts to generate random users, although not address or picture data.
Even though the pictures are under Creative Commons BY-NC-SA 2.0 I do feel right using them and it seems like a lot of work to parse the data into your own website, there are server side libraries that can do this for you.
So a lesson from when I was young and stupid: If you make fake data, it's often advantageous to make it obviously fake data. If, in a fit of boredom, you decide to do something clever and e.g. generate plausible names and birthdates for fake students by using government lists for the most common names and surnames for people born that year, and you e.g. hypothetically leave 6 pages of no-actual-human-involved fake data sitting on an office printer, you might hypothetically end up in a very awkward conversation with the local person in charge of regulated data breaches.
> So a lesson from when I was young and stupid: If you make fake data, it's often advantageous to make it obviously fake data.
A second one: if you make fake data, it's aways advantageous to make it edge-case fake data. Your generator should break more or less every falsehood programmers believe about names[0]
Fair enough, but it's also advantageous to make it non-obviously fake. Consider the recent stories about services faking traffic/users in order to gain real traffic/users (ebay, reddit, dating sites, etc).
You have a very fair point, but it's tangential to the one patio11 is making; creating testing data for development purposes (that's never going to be seen by users, short of an accident) and creating faked data for marketing/growth/etc purposes (which is solely for the purpose of presenting to users) are unrelated.
I guess I'm not following how they are unrelated. To really stress a system and find bugs, shouldn't you be putting it under realistic usage and load? In my mind using test data that closely matches real data is desirable for development purposes. I suppose I'm now actually disagreeing with the OP's statement -- that example was a specific circumstance where perhaps more care should've been taken, but for the general case I think it's actually desirable to use realistic data.
Plus I just think it'd be cool if you could use the same service/API for both use cases.
For Rails Rumble last year I created a Rails app for generating test data in various formats. It definitely isn't as polished as this (only had 48 hours), but allows for the user to specify their own format. After the competition I cleaned it up a bit more and converted the data generation functionality into a standalone Ruby gem. I'd appreciate any feedback...
Huh, it looks like the api is ignoring the gender option entirely. It seems to return a random gender no matter what the value of the gender parameter ....
Providing an md5 hash of the example password is just asking for bad password models in new apps! Users, don't use the provided hashes, instead run the user and password through the exact sign-up method real user data will go through.
reply