 

In October 2018 I started attending Epicodus, a code school in Portland OR. Taking the leap to learn how to code full-time was one of the most pivotal decisions I have ever made. I am extremely grateful that I made that decision. I am now working for a company that aims to make transit more efficient with mobile fares, an effort I care about deeply, and also prioritizes my professional growth. I want to share a little about my past and why I decided to make a shift into tech, as well as some things I have learned along the way. 

## Why I decided to learn how to code

My interest in coding began during my last year of undergraduate studies. I have a degree in Environmental Studies and a minor in Geospatial Studies, where I focused on mapping environmental injustice. My senior capstone was an interactive map of aerial images of prisons and an essay about the environmental issues around prison sitings. I used [Odyssey.js](https://cartodb.github.io/odyssey.js/) and [CARTO](https://carto.com/), then CartoDB, to create the map. This was my first introduction to using an API to load map tiles, and CSS to style layers.

After completing my degree, I interned at Metro, a regional government with offices in Portland, as a GIS (Geographic Information Science) intern in their transportation planning department. There, I made maps using Mapbox, and first learned about D3. Through my experiences, I could see that there were many opportunities to create wide-reaching visualizations with code. After this internship, I took some time to work in the service industry and decide what I wanted to do with my career. These small introductions to web development remained with me during my , and I decided to take the leap and enroll in code school. 

## Things I found helped me during my first year of writing code

Learning how to code was by far the most challenging thing I have ever done. Although I admire self-taught programmers and those that can balance education with work or taking care of dependents, I find that, for myself, I need to be fully immersed in something to be successful. This is why I decided to go to school full time. 

I was able to go to school full time because I received a scholarship from [Tech Rise](http://www.techrisepdx.org/), a program through Worksource Portland Metro that aims to increase racial and gender diversity in the tech industry. During the time of receiving this scholarship, I was working in the service industry and had accrued student debt from my undergraduate studies. I was not financially equipt to take on more debt, and the scholarship enabled me to avoid taking out more student loans. I am extremely grateful for what this scholarship has given me and scholarships like this deserve more support.  

Though I am a woman entering a male-dominated industry, I want to recognize that I have privileges that have helped me make such a swift transition into tech. I am a cis straight able-bodied white female with some economic privilege. I do not have any dependents, I have a steady living situation, a supporting partner and family. If I was not afforded any mix of these privileges, entering tech would have been a lot more difficult for me. 

Lastly, these are in no way revelatory or may work for everyone; they are just some things I found helped me. 

### Find a community to learn with

- The most valuable part of code school is the community that can be found among classmates. I met some amazing people at Epicodus that really helped me grow as a developer. I had people to attend meetups with to quell my social anxiety, to bounce side project ideas off of, and to empathize with how stressful of a transition it is. This community does not necessarily need to be from code school, but I found it critical for my development as a software engineer.

### Sleeping and eating well is a main priority

- I maintained a strict sleep schedule and meal prep schedule this year. Sundays were spent almost exclusively prepping food for the week and making time for my mental health. I was able to save money during school by not eating out for lunch and I had extra time on weekday evenings to attend meetups or study rather than cook dinner.

### Avoid copy and pasting whenever possible

- As a new developer, it is really easy to find an example of something similar you are trying to achieve and copy and paste it into your own code. I have found that prevents one from truly understanding what the code is doing, and makes is much harder to debug.

### Read code out loud

- Epicodus is based on pair-programming so every day I had someone to talk to about code. When my pair and I would work on an assignment I would state in plain English was a function is doing, which helped solidify my understanding. This is often referred to as "rubber duck debugging."

### Find a niche

- I decided to learn how to code because I wanted to make powerful visualizations and work on meaningful products. I targeted myself as a developer interested in transportation, urban planning, and maps because that is what I have experience in and care about. This made me stand out when applying for jobs, as I had a clear focus. It also helped me narrow down different companies that I wanted to work for.

### Create a portfolio early

- I started building my portfolio during my winter break, which was about two months into code school. I knew that this would be something that would be necessary later down the line, and having a basic setup saved me time when I needed to put together something quick. I used [Gatsby](https://www.gatsbyjs.org/), which allowed me to learn new technology like GraphQL and they have an amazing starter tutorial.

### Networking is almost as important as learning how to code

- During the second half of school, I tried to attend at least one meetup a week, participate in local hackathons and volunteer with coding organizations. At these events, I listened to what others in the community were excited about, even if I knew nothing about them at the time. I also reached out to people who held positions I was interested in for informational interviews.

### Return to the basics

- One of my mentors at my current employer lent me his copies of Kyle Simpsons [You Don't Know JS](https://www.amazon.com/gp/bookseries/B01N9EBP9V) which I have been reading over the past couple of months. During code school, you jump into learning different frameworks and libraries (React, Angular, Express, etc) that you often glaze over the nuances of the language — in my case was JavaScript. Learning the fundamentals of asynchrony or how scope works is extremely beneficial.

## Conclusion

My first year of writing code was one of the hardest and most transformative years of my life. In year two I am continuing to attend some meetups (twice a month) and would like to volunteer with other community-minded coding organizations like Code For PDX. I would also like to volunteer with I am taking more time for exercise and my personal health by exercising more.

My first year writing code


I have a project that I am passionate about building, and is simple enough that it serves as a great place to learn new things. It is a simple app that fetches data and allows the user to filter the data as well. I have been using it as a basic example of using Mapbox and d3 with React and Redux, and now React Hooks. I think that having a project like this is a great thing for a new developer to have, as they don't have to think about what kind of app they want to build when they want to learn something new, they can just create a branch and implement the feature there. 

I originally built this app using Redux, but after building out the base functionality, I realized that Redux was a bit overkill. I only had two arrays that I was storing in my global state object, and did not have many different actions that would warrent having multiple reducers. After learning about ways to manage state with React Hooks, I thought that this would be a worthy effort to compare the experience between the two. 

There are many different ways to manage state with Hooks, and I felt for my use case of a small app where several nested components need to access to a global state, a combination of `useContext` and `useReducer` would suffice. I have some ideas of some potential features I would like to add to the app, so I wanted a solution that was scaleable, but lightweight. 

Here is how I did it: 

I created a context folder  `src/context` with `ContextProvider.jsx`. 

In the ContextProvider file, I copied over my initial state from my redux file. For this project it looks like this. 

```javascript
const initialState = {
  data: {},
  filteredData: {}
}
```

I then declared my context with `export cont AppContext = createContext(initialState);` I declared my `AppContextProvider`, where my global state willreside using the `useReducer` hook. 

`const [state, dispatch] = useReducer(reducer, initialState)`

I decided that my app only needed one reducer, because I do not have many different actions taking place. However, if the app does grow I could refactor to multiple reducers easily. My simple reducer looks like the following: 
```javascript
const reducer = (state = {}, action) => {
  switch (action.type) {
    case REQUEST_DATA_SUCCESS:
      return { ...state, data: action.data }; 
    case FILTER_DATA_SUCCESS :
      return { ...state, filteredData: action.data };
    default:
      return state;
  }
}
```
In my `AppContextProvider` component, I am returning an `AppContext.Provider,` and passing in `state` and `dispatch` in the value prop so that the child components can have access to the global state and dispatch functionality. 

In Redux, you dispatch actions that dictate the switch cases in the reducer. Typically these actions are pure functions that return an object that contains and action type and the payload. To keep everything pure, and because I already had these all defined, I used my old action types and action creators. 

At this point, I have my basic set up in place and I can implement it in my app. In my `index.jsx` I had my `App` component wrapped in a `Provider`, declared my store, and my middleware. I removed all of that, and import my `AppContextProvider` component. I wrapped my top level app component in my `AppContextProvider` to create my global state. 

I searched for wherever I used Reduxes `dispatch` and `mapStateToProps` to find where I should implement my new Hook based `dispatch`. To do so, I import my `AppContext` into my components and deconstruct them like `const {state, dispatch} = useContext(AppContext)`.  I also imported my action creators into my components, and call them inside `dispatch` like `dispatch(fetchData(data))`.

One of the things I really like about Redux is the use of middleware, which are functions that are called between actions and the reducer. This is espicially helpful when logging actions, to see when they are being dispatched. With the help of this [article](https://staleclosures.dev/building-usereducer-with-logger/) I was able to implement a simple logger with my existing state management. 

One last piece that I learned during this refactor was using partial application to pass functions via context. For example, I have a function that fetches data when the user submits a form. I want this function to live in my provider because that is where I am storing all of my data fetching logic. This function needs to know about dispatch, a value in my global state, and the form input value. In my `AppContext.Provider` I pass the function via the value like:
```javascript
<AppContext.Provider value={{ state, dispatch, fetchData: fetchData(dispatch, state.data) >
```
Then, in my component I am able to import my AppContext, and only provide the final argument. 

In the end my Context provider looked like this: 
```javascript
import React, { createContext, useReducer, useEffect, useMemo, useRef } from 'react';

const REQUEST_DATA_SUCCESS = 'REQUEST_DATA_SUCCESS';
const FILTER_DATA_SUCCESS = 'FILTER_DATA_SUCCESS';

export const fetchData = data => ({ type: REQUEST_DATA_SUCCESS, data });
export const filterData = data => ({ type: FILTER_DATA_SUCCESS, data });

const reducer = (state = {}, action) => {
  switch (action.type) {
    case REQUEST_DATA_SUCCESS:
      return { ...state, data: action.data };
    case FILTER_DATA_SUCCESS:
      return { ...state, filteredData: action.data };
    default:
      return state;
  }
};

const initialState = {
  data: {},
  filteredData: {},
}

const logger = dispatch => action => {
  console.groupCollapsed('type:', action.type);
  return dispatch(action);
}

const useReducerWithLogger = (...args) => {
  let prevState = useRef(initialState);
  const [state, dispatch] = useReducer(reducer, initialState);

  const dispatchWithLogger = useMemo(() => logger(dispatch), [dispatch]);

  useEffect(() => {
    if (state !== initialState) {
      console.log("Previous state: ", prevState.current);
      console.log("Next State: ", state);
      console.groupEnd();
    }
    prevState.current = state;
  }, [state]);
  return [state, dispatchWithLogger];
}

const fetchData = async dispatch => {
  try {
    const response = await fetch('url');
    const json = await response.json();
    dispatch(fetchData(json));
  }
  catch (error) {
    console.log('An error occured', error);
  }
};

const fetchCoords = (dispatch, treeData) => {
  return async address => {
    try {
      const response = await fetch('url' + address);
      const json = await response.json();
      dispatch(filterData(json));
    }
    catch (error) {
      console.log('An error occorred', error);
    }
  }
};

export const AppContext = createContext(initialState);

const AppContextProvider = ({ children }) => {
  const [state, dispatch] = useReducerWithLogger(reducer, initialState);

  useEffect(() => {
    fetchData(dispatch);
  }, []);

  return (
    <AppContext.Provider
      value={{ state, dispatch, fetchCoords: fetchCoords(dispatch, state.data) }}
    >
      {children}
    </AppContext.Provider >
  );
};

export default AppContextProvider;
```

The benefit of using these two hooks together is that you can avoid passing callbacks though nested components and can keep a minimal state management system. I would not recommend this if your app because overly complex, or if you needed more advanced middleware. There is a rich ecosystem of Redux tooling that is extremely valuable. However, if you have a lightweight app that needs to manage state and want to get some React Hooks practice, I felt that this was a worthy exercise.

Refactoring a small Redux app to useContext and useReducer


### By Ben Kirby, Paige Williams, Phil Mass, and Tanvi Garg

#### [View post on Medium](https://medium.com/@paw145/using-the-google-maps-api-with-webpack-npm-and-a-handy-promise-returning-helper-19c9312971b0)

We are students at [Epicodus](https://www.epicodus.com/), a code school in Portland, Or.

We wanted to incorporate Google Maps into one of our projects using Webpack to sharpen our async skills. We came across some issues and had trouble finding documentation that showed a similar use case. Our simple project structure looked like this:

```
|- .env
|- .gitignore
|- package.json
|- webpack.config.js
|- src
   - index.html
   - main.js
   - map.js
   - styles.css
```

We use [dotenv-webpack](https://www.npmjs.com/package/dotenv-webpack) to protect our API key and include .env in our .gitignore file so that it is never committed to a repository. [Google’s single-page example](https://developers.google.com/maps/documentation/javascript/examples/map-simple) is helpful in understanding the basic structure of a Google Maps object, but it does not provide documentation on how to implement it in a more complex webpack application structure.

After attempting to implement Google’s example in our webpack application by adding the Google Maps script into our map.js file, we received the following error:

![alt-text](/images/_posts/blog/errormessage.png)

We needed to find a way to load the Google Maps API without the global callback in the HTML while still keeping out API keys hidden. Our search led us to the handy NPM package [load-google-maps-api](https://www.npmjs.com/package/load-google-maps-api).

## Implementation

This is how we implemented it into our project:

To install the package with NPM, run:

```
npm install --save load-google-maps-api

```

In your HTML add a div where the map will reside.

```html
<div id="map"></div>
```

Give your map a size in your CSS file.

```css
#map {
  width: 500px;
  height: 500px;
}
```

Require the NPM package in map.js and write a function to load the Google Maps API. You supply the API key as an object literal.

```javascript
const loadGoogleMapsApi = require('load-google-maps-api')
class Map {
  static loadGoogleMapsApi() {
    return loadGoogleMapsApi({ key: process.env.GOOGLEMAPS_KEY })
  }
  static createMap(googleMaps, mapElement) {
    return new googleMaps.Map(mapElement, {
      center: { lat: 45.520562, lng: -122.677438 },
      zoom: 14,
    })
  }
}
export { Map }
```

We also added a function to create the map object. Which we will get to in our next snippet.

In the main.js :

```javascript
import { Map } from './map'
import './styles.css'
document.addEventListener('DOMContentLoaded', function () {
  let mapElement = document.getElementById('map')

  Map.loadGoogleMapsApi().then(function (googleMaps) {
    Map.createMap(googleMaps, mapElement)
  })
})
```

This is basically how it works! We call the loadGoogleMapsAPI function which returns a promise. When the promise resolves, it returns an object that is the equivalent of google.map in the google maps API documentation. You can use the returned object to make the createMap function call.

Here’s a [link](https://github.com/philrmass/minimal-google-maps-api) to a repo with the minimal google maps setup. To build it:

Clone to a local directory

1. Run npm install
2. Run npm run build and check there are no errors
3. Run npm run start or npm run winstart if you’re on windows
4. It should open a tab in your browser at localhost:8000

## Conclusion

We liked this package specifically because of how clean it was and how simple it was to implement within our existing code. Additionally, it allowed us to utilize the rest of the Google Maps features alongside the package seamlessly.

Happy coding!


Blog Posts

My first year writing code

Refactoring a small Redux app to useContext and useReducer

Using the Google Maps API with Webpack, NPM, and a handy Promise-returning helper