DEV Community: Gordon Caister

Mapping Police use of Force Using React

Gordon Caister — Fri, 28 Aug 2020 16:29:58 +0000

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.

Developing a Conway's Game of Life algorithm in Javascript

Gordon Caister — Tue, 23 Jun 2020 16:49:52 +0000

First we will start with our possibilities:

Given the possibilities of a cell's neighbours where the cell is 'C' there are 8 possible neighbours as detailed in the tables below, the first table would be cardinal direction while the second table is a relative coordinate where the first digit represents x or the rows, and the second represents y or the columns. I.e. SW is relatively 1 row further than C and -1 column further than C.

NW  N  NE 
W   C  E  
SW  S  SE 

[
 [-1,-1],
 [-1,0],
 [-1,1],
 [0,-1],
 [0,0],
 [0,1],
 [1,-1],
 [1,0],
 [1,1]
]

We need to cycle through each cell in the total grid and compare each of its neighbours and see how many of its neighbours are alive.

To this end, I have represented alive with ‘1’ and dead with ‘0’ which in javascript equate to truthy and falsy respectively, while still maintaining their integer value.I am using this to my advantage.

Duplicate the existing grid.
For i in rows,
For j in columns
For x,y in possibilities
We will add the current row index (i) to the possible x value
We will add the current col index (j) to the possible y value
If the combined x is greater than or equal to 0 and less than the number of rows and the combined y is greater than or equal to 0 and less than the number of columns:
Add 1 to the total number of neighbours for the current cell
Once we’re finished finding number of neighbours: if the neighbours is greater than 3 or less than 2, set the current cells value to 0 (Rule 1 and 3)
If the current cell’s value is 0 and the number of neighbours is 3, set the current cell to 1 (alive)
All other cells should be left alone
Set the existing grid equal to the altered duplicated grid

    const tempGrid = JSON.parse(JSON.stringify(grid))

    for(let i = 0; i < rows; i++){
      for(let j = 0; j < cols; j++){
        let neighbours = 0;
        possibilities.forEach(([x,y])=> {
          const nextI = i + x;
          const nextJ = j + y;
          if(nextI >= 0 && nextI<rows && nextJ >= 0 && nextJ < cols){
            neighbours += grid[nextI][nextJ] 
          }
        });
        if (neighbours < 2 || neighbours > 3){
          tempGrid[i][j] =  0;
        } else if (grid[i][j] === 0 && neighbours === 3) {
          tempGrid[i][j] = 1;
        }
      };
    }

Given the above code requires a few other pieces of data to run I will include how they existed in my code. I was using React to run my frontend so I used the useState hook to maintain the state of my grid.


const rows = 50
const cols = 50

const possibilities = [
  [-1,-1],
  [-1,0],
  [-1,1],
  [0,1],
  [1,1],
  [1,0],
  [1,-1],
  [0,-1],
]

const zeroArray = (rows,cols)=> {

  let arr = new Array(rows);
  for(let i = 0; i < arr.length; i++){
    arr[i] = new Array(cols);
    for(let j = 0; j < rows; j++){
      arr[i][j] = 0
    }
  }
  return arr;
}

const [grid, setGrid] = useState(zeroArray)

I kept a reference to zeroArray because I wanted to include a function that cleared the board and reset all cells to 0.

New Developers: when should you be asking questions?

Gordon Caister — Fri, 22 May 2020 20:38:51 +0000

A recent twitter thread has gained a fair amount of traction. @donnacamos asks: I'm curious, can a junior developer ask for help too much? If yes, how can you tell?

Donna Amos 💗📚💻☕

@donnacamos

I'm curious, can a junior developer ask for help too much? If yes, how can you tell?

23:08 PM - 21 May 2020

76 828

The overwhelming response was: It depends. Most companies worth their salt have some form of mentor program. The mentors or senior developers are there to guide and help newer developers. You should always ask questions about things you are unsure of but not before you’ve gone through a process. One response quotes Confucius:

“The man who asks a question is a fool for a minute, the man who does not ask is a fool for life.”

― Confucius

The first thing you need to do is make sure that you know how to learn. Now theoretically you’ve gone through some form of higher education, whether that be traditional college, code bootcamp or self-study. You may still not be learning in a way that is optimal for you. Dr. Barbara Oakley with McMaster University has a free course on Coursera called “Learning How to Learn”. It is only a 4 hour long course, and is well worth the time it takes to go through, especially if you make use of playback speed increases.

The second thing you need to do is make sure that you know how to solve problems. There are many approaches to problem solving, the one that has worked for me is “Polya’s problem solving technique”. The breakdown of Polya’s book “How to Solve It” boils down to 4 core principles: understand the problem, devise a plan, carry out the plan and finally look back. The basic tenet here is that once you understand the problem and carry out your plan, regardless of whether you succeed or not you will still be able to gain insight through retrospect. Your mentors will appreciate you being able to tell them what didn’t work, and being able to show them how you approached the problem.

Finally you need to make sure you are asking good questions. There’s an adage that says “there’s no such thing as a stupid question”, that’s a stupid statement. There definitely are stupid questions. The three basic principles of a good question are: it’s specific, it’s clear and concise and you’ve put work into it.

Because you’ve approached your problem with a plan, and you know the way that you learn. You can now ask your mentors or senior developers specific questions about problems that you understand well and have investigated with a plan. You can show them what you’ve tried and what worked and what didn’t work. You can also guide the question to an answer that suits your learning style.

Your company wants you to succeed, in reality, they’ve likely spent almost half as much of your yearly salary to hire you. They want you to learn and grow and be better. So go ahead, ask those questions, but make sure you’ve followed your process first.

Final thought. If you are a JavaScript developer like me, check out 33 Concepts Every JavaScript Developer Should Know