EventReporter
This project builds on the lessons learned in EventManager and MicroBlogger to focus on fundamental Ruby style/concepts.
Project Overview
Learning & Practice Goals
- Become comfortable with implementing basic classes and methods
- Demonstrate understanding of variable scope and lifecycle
- Create multiple coordinating methods and objects
- Use default and named parameters
- Utilize effective debugging techniques
Abstract
Let’s take EventManager to the next level. Based on the same data file, build an interactive query and reporting tool which fulfills the expectations below. Re-use data cleaning procedures from the original EventManager
to handle dirty input and generate beautiful output.
Data Supplied
- Source data file: event_attendees.csv
Base Expectations
As a user launching the program, I’m provided a REPL where I can issue one of several commands, described below. After each command completes, the prompt returns, waiting for another instruction.
The Queue
The program has a concept called the "queue". The queue holds the stored results from a previous search. As a user, I issue a search command to find records, then later issue another command to do work with those results. The queue is not cleared until the user runs the command queue clear
or a new find
command.
The REPL
The program must respond to the following commands:
load <filename>
Erase any loaded data and parse the specified file. If no filename is given, default to event_attendees.csv
.
help
Output a listing of the available individual commands
help <command>
Output a description of how to use the specific command. For example:
1 2 |
|
queue count
Output how many records are in the current queue
queue clear
Empty the queue
queue print
Print out a tab-delimited data table with a header row following this format:
1
|
|
queue print by <attribute>
Print the data table sorted by the specified attribute
like zipcode
.
queue save to <filename.csv>
Export the current queue to the specified filename as a CSV. The file should should include data and headers for last name, first name, email, zipcode, city, state, address, and phone number.
find <attribute> <criteria>
Load the queue with all records matching the criteria for the given attribute. Example usages:
find zipcode 20011
find last_name Johnson
find state VA
The comparison should:
- Be case insensitive, so
"Mary"
and"mary"
would be found in the same search - Be insensitive to internal whitespace, but not external:
"John"
and"John "
are considered matches"John Paul"
and"Johnpaul"
are not matches
- Not do substring matches, so a
find first_name Mary
does not find a record with first name"marybeth"
Test Cases for Base Expectations
Your program must handle the following scenarios correctly:
A. Happy Path
load event_attendees.csv
queue count
should return0
find first_name John
queue count
should return63
queue clear
queue count
should return0
help
should list the commandshelp queue count
should explain the queue count functionhelp queue print
should explain the printing function
B. Let’s Try Printing
load
queue count
should return0
find first_name John
find first_name Mary
queue print
should print out the 16 attendeesqueue print by last_name
should print the same attendees sorted alphabetically by last namequeue count
should return16
C. Saving
load
find city Salt Lake City
queue print
should display 13 attendeesqueue save to city_sample.csv
- Open the CSV and inspect that it has correct headers and the data rows from step 3.
find state DC
queue print by last_name
should print them alphabetically by last namequeue save to state_sample.csv
- Open the CSV and inspect that it has the headers, the data from step 7, but not the data previously found in step 2.
D. Reading Your Data
load
find state MD
queue save to state_sample.csv
quit
Restart the program and continue…
load state_sample.csv
find first_name John
queue count
should return4
E. Emptiness
Note that this set intentionally has no call to load
:
find last_name Johnson
queue count
should return0
queue print
should not print any attendee dataqueue clear
should not return an errorqueue print by last_name
should not print any dataqueue save to empty.csv
should output a file with only headersqueue count
should return0
Extensions
Improving queue print
- Modify your
queue print
command so it prints in left-aligned columns where the size of each column is determined by the longest entry in the column. - If the queue is more than 10 lines, pause after ten until the user hits either the spacebar or enter keys.
- Add a status line that reads like "Showing Matches 20-30 of 80"
Improving find
- Modify your
find
instruction so all searches are case insensitive - Modify your
find
instruction to allow compound searches using a singleand
such as:
1
|
|
Improving queue save to
- Modify the instruction to respect the filename extension so that:
csv
generates comma-separated valuestxt
generates tab-delimited valuesjson
generates valid, parsable JSONxml
generates valid, parsable XMLyml
generates valid YAML
Implementing Queue Math
Assuming I have results currently in the queue, implement queue math like this:
1 2 |
|
That would find me all entries for DC that are not in 20011
. Similarly:
1 2 |
|
Would load the queue with all entries from DC or the 22182
zipcode.
Nightmare-Mode find
Modify your find
method to allow multiple attribute values in parentheses like this:
1
|
|
Support an or
operation:
1
|
|
And support find
only within the queue:
1 2 |
|
Which would find only the Johnsons in 20011 or 22182.
Test Cases for Extensions
For the extensions to pass the evaluation, it must handle the following scenarios correctly.
A. Improved queue print
load
find first_name sarah
queue print
Observe the first two screens of output similar to this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 |
|
Noting that it has…
- Aligned columns
- 10 entries per screen
- A status bar displaying total records
But, the exact number of records may differ if the program does not implement the "improved find" with case-insensitive search.
B. Improved find
load
find first_name sarah and state CA
- Observe that there should only be four records in the queue
C. Improved queue save to
load
find first_name Sarah
queue save to sarah.xml
queue save to sarah.json
queue save to sarah.txt
queue save to sarah.yml
- Inspect the four output files for completeness and structure.
D. Queue Math
load
find zipcode 20011
subtract first_name william
add zipcode 20010
- Observe that there are 8 records in the queue.
E. Nightmare-Mode Find
load
find state (DC, VA, MD) and last_name johnson
- Observe that there are three records in the queue.
load
find state dc or last_name smith
- Observe that there are 270 records in the queue
queue find first_name alicia
- Observe that only 3 records remain in the queue
Evaluation Rubric
The project will be assessed with the following rubric:
1. Functional Expectations
- 4: Application fulfills all base expectations and two extensions
- 3: Application fulfills all base expectations
- 2: Application has some missing functionality but no crashes
- 1: Application crashes during normal usage
2. REPL Interface
- 4: Application’s REPL goes above and beyond expectations to improve the interface
- 3: Application’s REPL is clear and pleasant to use
- 2: Application’s REPL has some inconsistencies or rough edges
- 1: Application’s REPL has enough problems as to make play difficult
3. Test-Driven Development
- 4: Application is broken into components which are well tested in both isolation and integration
- 3: Application is well tested but does not balance isolation and integration tests
- 2: Application makes some use of tests, but the coverage is insufficient
- 1: Application does not demonstrate strong use of TDD
4. Breaking Logic into Components
- 4: Application is expertly divided into logical components such that individual pieces could be reused or replaced without difficulty
- 3: Application effectively breaks logical components apart with clear intent and usage
- 2: Application shows some effort to break logic into components, but the divisions are inconsistent or unclear
- 1: Application logic shows poor decomposition with too much logic mashed together
5. Fundamental Ruby & Style
- 4: Application demonstrates excellent knowledge of Ruby syntax, style, and refactoring
- 3: Application shows strong effort towards organization, content, and refactoring
- 2: Application runs but the code has many long methods (>8 lines) and needs significant refactoring
- 1: Application generates syntax error or crashes during execution
6. Enumerable & Collections
- 4: Application consistently makes use of the best-choice Enumerable methods
- 3: Application demonstrates comfortable use of several Enumerable techniques
- 2: Application demonstrates functional knowledge of Enumerable but only uses the most basic techniques
- 1: Application demonstrates deficiencies with Enumerable and struggles with collections