Employee Module

The employee module is where we’ll bridge the parsing of records with filtering and searching through employees. Proper isolation of concerns should make it possible for both types of users, those who create and those who consume employee data, to do everything they need without knowing about the requirements of the other.

Setting requirements

Our challenge here is to come up with an internal data representation that can easily be converted to CSV, all the while also allowing us to use employee entries the way we would handle any other data structure. Of course, we’ll want to test this with properties. Let’s start with the transformations from what the CSV parser hands to us. This was:

last_name, first_name, date_of_birth, email
Doe, John, 1982/10/14, john.doe@foobar.com
Ann, Mary, 1975/09/18, mary.ann@foobar.com

Now the thing to notice is that there are a couple of issues with the format of the document:

• The fields are messy and have extra leading spaces.
• The dates are in YYYY/MM/DD format. This is an issue because Erlang by default works with {Year, Month, Day}.

The transformation requires additional processing after the conversion from CSV, which could usually be done or handled by a framework or adapter. For example, most PostgreSQL connection libraries will convert the internal data type for dates and time to Erlang’s {{Year,Month,Day}, {H,Min,Sec}} tuple format without much of a problem. In the case of CSV, the specification is really lax, and as such, it’s our responsibility to convert from a string to the appropriate type, along with some additional validation.

We’ll define the following functionality:

• An accessor for each field (last_name/1, first_name/1, date_of_birth/1, email/1).
• A function to search employees by birthday.
• A