Bootcamp Week 3: Projects!
- Quynh
- Jun 4, 2017
- 5 min read
Week 3 of our Bootcamp and it is Project Week! We were paired up with another team partner to create an app and present it on Friday.
The project guidelines were simple:
Either build a data analytics project using SQLite3/ActiveRecord or create a command line CRUD app. We decided to build a combination of the two: populating a database and using a CLI to read and manipulate the dataset.
And tadaa! We proudly present:
NYC EMERGENCY INCIDENTS DATABASE
"NYC Incident Database is a CLI based on a historical collection of data of emergency response incidents ranging from 05/2011 - 05/2017 from NYC Open Data.
Who is it for? Users who are interested in analyzing and manipulating the dataset for emergency response incidents.
What can it do? The app is complete with all CRUD functionality. Users can filter over 5,000+ records by neighborhood, date range, or incident types, as well as create new entries, and update/delete existing entries.
Use examples for research:
- Find out about emergency volume in certain span of months or locations to find out needs for hospitals, police presence, etc. - Find out extent of damages caused by natural catastrophes. - Enter and update new records for own purposes. - Curiosity."
Checkout the repo on GitHub:
Watch a demo of the app:
What was the most challenging part of your project?
Challenge #1 - Ideation process
NYC Open Data provides tons of datasets that are produced by the government. The challenge was to find a dataset that would meet the project's requirement to find at least three tables that have a relationship to each other (aka at least one many-to-many relationship including a join table). Most datasets were standalone lists without links to other datasets, e.g. lists of restaurants, theaters, SAT scores, etc. Finally, we found the "Emergency Response Incidents" data that provided us with three models: incident type, borough, and the entries of incidents themselves with date.
Challenge #2 - Parsing the data
After settling on the dataset for the project, the first real code related struggle was already lurking around the corner. The dataset contains 5,000+ records and comes in a csv file. So now: How to populate the database? What happens after the csv data has been parsed into a Ruby array? How to make use of the seed.rb file? Does it require Ruby, SQL, or just plain data? We went through sequences of tears and sweat, error and trial...
And then comes the moment when it suddenly works... HEUREKA! *highfivemike*
Have you ever seen 5,000 records being populated in a database? Oh, it is one of the most beautiful and mesmerizing things I've ever seen.
Challenge #3 - GitHub, oh GitHub
One of the main reasons that I started a bootcamp was to experience working with someone else on the same code. When you study alone at home with online tutorials the collaborative component is missing, which will be a huge part of a "real job" later on.
I've always wondered, "How do you work on the same files without creating a chaotic mess? How do you divvy up the work? How do you resolve merge conflicts?"
When it came to commit our work to github for the first time, I could feel an anxious tingling in my fingers. My team partner Mike had created his own copy of the files on his machine, and so had I. How do we come together? Thankfully, pair programming comes with this beautiful feature called teaching and learning. Mike had had some painful but immensely useful experience with GitHub merges, which allowed me to enter the fascinating world of merges, pulls, and pushes without getting hurt.
Challenge #4 - Keeping it DRY
The challenge is that one needs to get the app to work. And to get there one needs to overcome many obstacles aka error messages, wriggling and squirming your way through to your goal. And when the lines of code finally do what they are intend to do, one finds themselves in a deep forest of functions, methods, classes, modules, etc. At the end of the day, or rather, at the end of the project on Friday, we were proud to present a fully functioning and (almost) bug-free app.
It feels like learning to cook a three course menu for the first time. The cooks are working on multiple stoves, it is chaotic and stressful at times. But the dinner stands and is served to everyone's satisfaction. At the end of the day when you go back into the kitchen, you see the mess you've made: dirty knives and ladles everywhere, tomato sauce on the counter, flour in the air, ... So you need to clean up.
So this is another lesson learned - cleaning up the kitchen is not fun but it is necessary, especially when someone else needs to use it. For a programmer it translates to refactoring, refactoring, refactoring. Surprisingly, this step takes up a significant amount of time. That said, the rewards are cleaner code (for your later self and anyone else who wants to build on top of it) as well as good training for finding solutions with a higher level of abstraction.
What was the funnest part?
Creating something that actually DOES something!
Working with your team on something and it finally works - SUCCESS is an exhilarating feeling
A project teaches you in so many different ways than studying tutorials or solving code challenges because it throws all kinds of error messages, questions, and challenges at you. But in the end one feels extremely productive and the learning curve sky rockets.
Man, I feel like a legit DEVELOPER!
What did you learn?
Lesson #1
You can proudly solve something in three hours by yourself and your best friend Google. Or you can ask someone and potentially solve it in five minutes.
Lesson #2
GitHub - do not forget to branch off of master!
Lesson #3
No doubt, I am proud of our product - a simple but working data querying tool.
But then when final presentations came, I felt like others' projects seemed so much more exciting and tangible: apps that let you play a game, find movies around you, look up sanitation violations for restaurants (Who does not want to know if they've found roaches in the kitchen?), etc.
If I showed to my family and friends how my app can filter NYC emergency incidents by date range, would they break out into ecstatic excitement?
This made me think: In the long run, it will matter what and how something is presented to the outside world. When you look for a job, pitch to clients, you will need to sell your skills.
So the takeaway is:
Invest more time in the ideation process. Find an idea that gives you not only a satisfying "good enough" feeling but additionally a little exciting chill down your spine.
It'll make you fly even higher.
What would NYC Emergency Incidents 2.0 look like?
We can make the querying options more flexible and customizable from the start. Right now the filtering options are more or less hard coded in the menu options [1] - [6]. In 2.0 the user will be prompted with the choice to select from three filters (borough, incident type, date range) and will be able to refine the filtered results further according to his choice.
Comments