I'm working with an organization called Human Rights First and a team of four other software engineers who are all on the cusp of finishing our nine-month long code school. We are building a React App, that takes data detailing incidents of police violence and maps it against a map of the united states. A team of data scientists in our school is sourcing the data by using a predictive model to crawl Reddit and Twitter to find incidents of police violence. They then begin the process of categorizing and aggregating the evidence.
We're trying to build a platform for journalists, protesters, and lawyers to find well-sourced information on local and national incidents of police violence. The map is accompanied by a timeline view that will be part of the second release. The timeline view will have filtering options to hone in on the information and give more relevancy for targeted searches.
I've never worked with a data science team before: I was worried about how the data would look. I trust my contemporaries, but the fear of the unknown is powerful. How do you crawl Reddit and come up with a reliable source of information? The voodoo magic that they were able to procure is mind-boggling.
To start with we created user stories. We spent some time imagining what the site would look like, and then wrote user stories based on the interactions we imagined happening. The user stories were then broken down into checklists of tasks and put into a kanban on Trello.
The image above was the first user story we wanted. We understand that often the videos and images accompanying the incidents are gratuitously violent. We wanted to provide users with an opportunity to opt-out of seeing such content immediately. We also wanted the site to remember if they had opted in. We use color-coded tags to assign different teams to different cards and make sure to update checklists and kanban columns so that progress can be closely tracked.
Expecting the unexpected
In terms of engineering architecture, there were only a small amount of choices we could make. But we did our best to choose options that gave us the least amount of technical debt. One of the choices we made was which maps API we would use. We focussed on two main choices; Mapbox and Google Maps. After spending time researching the two and weighing the pros and cons, we decided on Google Maps. A multitude of reasons made themselves obvious while we were researching the two, but the most obvious one was that our data would likely contain thousands of nodes. Mapbox struggles when presented with such a large number of nodes while Google Maps handles a large amount of the processing for you.
The next step was to choose a React wrapper. We decided on google-map-react: a fairly well-maintained component. One of the challenges with google-map-react is that it doesn't have a built-in auto-complete navigation search bar. One that you can type a location and change the map viewport. Engineering that component would prove to be a difficult challenge.
To do so we had to use React references and React class components. These are two things that I personally have had not much experience with. While I am used to OOP, React class components contain hooks used in the component render lifecycle. While this is something that I know and have used in the past it was not something I was super familiar with. Likewise, I had use references for class components in the past, but I had a very basic understanding. The other challenge was understanding the Google Maps API methods and what they did. The API has a ton of power, and with that comes a myriad of different methods. Picking out the correct ones was the greatest challenge. Then knowing how to reference HTML elements and use those references to use the methods was a little easier. After about 3 days of studying and trial and error, I finally got a working viewport changer including Google Places autocomplete.
As of today, unfortunately, our project is stunted, our reliance on a data science team to provide the data means that without our Data we can't make much progress. We can definitely spend time styling, something that our project sorely needs. We've had a mobile-first focus and creating a seamless mobile experience is our main priority.
In the future, we will be developing our second release which involves creating a timeline view and using component rendering to make it so the user doesn't have to get rerouted to switch between map and timeline. The timeline feature will hopefully have filtering, once we get the data from the DS team we will have a better understanding of what can and can't be filtered.
During the development, I have found that my peers respond well to my good nature and natural leadership skills. Making the environment friendly and jovial is a skill I have practiced most of my life. This makes teamwork easy and development speedy. This project ultimately helps me understand why we make decisions as engineers and what things other engineers might expect from me. It's helped me understand my strengths and weaknesses. For instance, I do not do well when multiple people are talking to me at the same time. I like to focus on issues and solve them before moving on. I am very good at looking at implementation and identifying bugs by using an outwards-in approach, starting at the smallest change we could make to find the ultimate cause.
Overall this project has been a good summary of my studies, and a great way to recap many of the things that I have learned over the last few months. As a developer, I am aware that I have a lot to learn, but I have developed a lot of my self through the process of creating this project. I am excited to see the culmination of our efforts.
Top comments (0)