Coding for Good

Building the Boys & Girls Club Emotion Tracker

I recently had the opportunity to work on an agile development team as part of the full stack web development course at Lambda School. In Lambda Labs, an in-house internship, I joined a team given the task of building a new application for the Boys & Girls Club of Greater Conejo Valley. This organization meets the physical and emotional needs of over 4,000 children through its nine community clubs, providing opportunities for sports, fitness, and recreation, health and life skills, the arts, education and career enrichment, and character and leadership development. I couldn’t have been more excited to code for good.

Understanding the Goal

The purpose of our application was to allow the boys and girls attending the club to record their emotions when checking in and out of the club and at the start and end of club activities. The director shared her vision of a simple interface that would easily allow students to share how they were feeling by choosing an emoji on an iPad screen. Her goals for this site were three-fold. She knew personally that her clubs were making a difference in the lives of the boys and girls in her community but she desired a way to quantify this benefit. In addition, having access to this sentiment data would allow an adult leader to intervene at just the point of need if a student was having a particularly hard day. Her third purpose was to get feedback from students about new and existing programming.

Greenfielding the App

Our team’s role would be to lay the foundation for the application. We needed to create a desktop interface that would allow the director and club administrators to print student ids with scannable QR codes. Printing these ids should also add student members to the application's database which would allow later sentiments recorded to be associated with individual members. For student privacy, our database would only store students by member ids and would not be associated with any personal information.

Our application would need to allow administrators to upload program information that would associate a particular activity with any club at which it was offered. It was requested that both member id and program data be added to the application by the simple upload of a comma-separated value file, a CSV, that could be easily generated by administrators from a spreadsheet application. Administrators also requested the ability to print single student ids, adding one member to the database in the process.

Recognizing Opportunities to Learn

Building an application to be used in the real world was exciting. It was motivating to catch the vision for the benefits of the application to the boys and girls who would be using our app. This project wasn’t designed to directly practice a skill I had learned. Its development was sure to uncover new problems to solve and to require new knowledge to achieve its goals.

Laying Team Foundations

Our team worked together to generate user stories, wireframes, user flows, database schema, and overall engineering architecture. As a team, we brainstormed the new technologies we might need and the areas we needed to research to solve tasks in the application releases that none of us had previously completed. New tasks included working with comma-separated-value, CSV files, and generating and printing QR codes for student ids. We divided our team into front and backend teams, populated our team Trello board, and started assigning individual tasks.

Taking a Risk

I chose the backend team to have an extra opportunity to build skills in using Java Spring to create a relational database management system (RDBMS). An early team conversation centered around how to handle the CSV file. Should the front or backend parse the file? Initially, I suggested it be parsed on the frontend. JavaScript is weakly typed, not a stickler for strict variable typing, and so it seemed an easier solution to let the frontend parse and send the data in individual POST requests or package the data into something more familiar, like a JSON object, before making the POST request to add the data to the RDBMS for creating the database. Knowing Java needed a class for every data type, it was not immediately clear what type of class we would need to define to receive and manipulate the CSV data.

Several on our team insisted this was a better task for the backend and backed up their position with articles and Stack Overflow. Heading into our first weekend we decided to place the task in the backend. I jumped at the opportunity to learn something new and took on the task as my personal responsibility.

Solving a New Problem

I decided to use the engineering design process to approach the problem. The steps would involve brainstorming, researching, prototyping, and building the final solution.

The User Story

As an admin user, I can upload a CSV file with student member ids to add students to the database.

Brainstorming

This is the step we had completed as a team. We needed to generate many possible solutions without prejudging.

• Read and parse the CSV file on the frontend, send each row to the backend
• Read and parse the CSV file on the frontend, create an array of row objects, send the array as part of a JSON object to the backend
• Send the CSV file to the backend, read and parse the file on the backend

With the team selecting the last option, it was time to dive into research.

Researching

To move forward I needed to take the task, break it down into questions I needed to answer, and research all potential options to explore the solution space.

• How should I set up a REST controller to receive a CSV file?
• What type of Java class would I need to hold the data?
• How can I read and parse the data to populate tables?
• Is there already a Java Spring utility class that solves the problem?

Prototyping

Now it was time to take the information I had found and build a “quick and dirty” prototype to test if the solution was workable. I found a CSV utility class seemingly designed for such a task and a Stack Overflow post as a guide. I would need a frontend application with a CSV file input, a method to package the file, and a POST request for the backend route. On the backend, I would need the CSV utility class, a controller route to receive the request, and a repository to connect to the database model.

• I added a Jackson Dependency to the POM file.

This was great because Jackson was already part of my application. I wouldn’t need to add additional packages.

• Next, I added the CsvUtils file to the application.

• I created controller routes to GET and POST the data.

On the frontend application, I created an input form, a method to handle submission, and a POST request to my backend route.

It worked. The CsvUtils class accepted the file data inputStream and mapped it to the model class directly.

Iterating

Prototyping is an iterative process and while working with my team I discovered this first solution would not meet all our requirements. Because we were not the source of truth for the Boys & Girls club member management system, and because additions to the database were designed to be a byproduct of the id creation process, it was completely feasible that a use case might involve sending duplicate data or mixed data which had new and duplicate values. I would need to be able to read and parse the data directly.

With the new knowledge in hand from my initial prototype, I started researching the Java class types I needed to handle the data one Google search at a time. What’s an inputStream? How do I convert it into a string? What class do I need to read a file? How do I read the headers? How can I separate row data into fields? These answers informed my next prototypes as I iterated toward a solution.

Building the final solution

In the final solution, I created a new method to read and parse the file in the services class which accepted the InputStream data from the controller, created an instance of a BufferedReader to read the file line by line, stripped the headers, checked for the valid file, and then verified whether the data was new or preexisting. New data was added to the database and all the members referenced in the file were returned to the frontend application. This last step was added to prevent the front end from adding a library package to read the CSV file directly.

Using the engineering design process as a guide, the user story was complete, and solving this task enabled me to solve an additional similar task for my team. Taking the risk to solve something completely new led to so much new learning both about Java and using processes to tackle new challenges.

Passing the Baton

At the close of our lab internship, our team had successfully met our release goals.

• Super Administrator and Club Director users can log in to perform administrative functions

• Administrative users can upload members using a CSV file.

• Administrative users can generate and print QR code student ids.

• Administrative users can upload program data using a CSV file.

Future lab teams will extend our work to include the ability to capture student emoji sentiments and the data analytics and visualizations to empower administrators with actionable results.

Growing as a Software Professional

Lambda Labs was a fantastic opportunity to get hands-on experience working as part of an agile development team building a full stack application with powerful potential impact. Catching the vision from the Boys & Girls Club director motivated us all to do our best work as a team.

Working together remotely presented many challenges and opportunities for growth. Differences in personality, work styles, design, and tech choices, and even time zones created constant opportunities for conflict management and collaboration.

I’m excited about bringing these technical and teamwork skills into my role as a professional developer to continue coding for good.