ajbrown/name-machine

Generate realistic random American male and female names.

name-machine's Issues

Repo

It must be a nice library, but it's apparently absent in Maven Central (at least it's what my error message suggests). Do you think you can include a few notes in your readme file on how to add the project's repository in one's pom.xml file?

building fails with recent Java or gradle

Used gradle init to enable building the project with JDK 11 and gradle 7
Just did a quick hack to get the project running

See my forked branch, in case anybody wants to use this project

https://github.com/omichels/name-machine/tree/upgrade-gradle-7-java-jdk-11

compile gradle

Hi,

getting this error when I sync!

dependencies {
compile 'org.ajbrown:NameMachine:0.1.1'
}

Error:Failed to resolve: org.ajbrown:NameMachine:0.1.1

Use 2000 Census Data for Surnames

The 2000 Census surnames are available, but not in the same format as the 1990 data. We'll need to convert to the same probability table as the current data:

http://www.census.gov/topics/population/genealogy/data/2000_surnames.html

Pre-format names as capitalized

Instead of capitalizing the names as they're being generated, we can save a few cycles by fixing the format in the seed files themselves.

Optimize memory usage when outputting names.

the NameGenerator builds a list of random names by the count it's provided, and then supplies that payload to NameMachine for output. That means that if I want 500k names, it has to load all 500k into memory before it can begin outputting them.

If we were to output them as they're being generated, that memory would be saved.

DepShield Deprecation Notice

Depshield will be deprecated on Monday December 12th

Please install our new product, Sonatype Lift with advanced features

Allow setting generation options on each pass

The http://namemachine.xyz API allows the specification of gender probability. Because of this, a new instance of NameGenerator has to be instantiated for each request, which means parsing the names files every since time.

This would be much more efficient if options could be specified each time. We could then keep one generator in application state.

To keep the API consistent and compatible, the current method of specifying options should set the default options that are used if options aren't specified for a particular invocation.