Forem: Matt Dionis

What is the most underrated skill of great engineers?

Matt Dionis — Thu, 29 Aug 2019 20:35:39 +0000

Move Over Redux: Apollo-Client as a State Management Solution (with Hooks 🎉)

Matt Dionis — Wed, 28 Aug 2019 15:07:56 +0000

Background

On the Internal Tools team at Circle, we recently modernized a legacy PHP app by introducing React components. Just a handful of months after this initiative began we have close to one-hundred React components in this app! 😲

We recently reached a point where we found ourselves reaching for a state management solution. Note that it took many months and dozens of components before we reached this point. State management is often a tool that teams reach for well before they need it. While integrating a state management solution into an application no doubt comes with many benefits it also introduces complexity so don’t reach for it until you truly need it.

Speaking of complexity, one complaint about the typical “go-to” state management solution, Redux, is that it requires too much boilerplate and can be difficult to hit-the-ground-running with. In this post, we will look at a more lightweight solution which comes with the added benefit of providing some basic GraphQL experience for those who choose to use it.

On the Circle 🛠 team, we know that our future stack includes GraphQL. In fact, in the ideal scenario, we would have a company-wide data graph at some point and access and mutate data consistently through GraphQL. However, in the short-term, we were simply looking for a low-friction way to introduce GraphQL to a piece of the stack and allow developers to wrap their heads around this technology in a low-stress way. GraphQL as a client-side state management solution using libraries such as apollo-client felt like the perfect way to get started. Let’s take a look at the high-level implementation of a proof-of-concept for this approach!

Configuring the client

First, there are a number of packages we’ll need to pull in:

yarn add @apollo/react-hooks apollo-cache-inmemory
apollo-client graphql graphql-tag react react-dom

Below you’ll find index.js on the client in its entirety. We’ll walk through the client-side schema specific pieces next:

import React from "react";
import ReactDOM from "react-dom";

import gql from "graphql-tag";
import { ApolloClient } from "apollo-client";
import { ApolloProvider } from "@apollo/react-hooks";
import { InMemoryCache } from "apollo-cache-inmemory";

import App from "./App";
import userSettings from "./userSettings";

const typeDefs = gql`
  type AppBarColorSetting {
    id: Int!
    name: String!
    setting: String!
  }
  type Query {
    appBarColorSetting: AppBarColorSetting!
  }
  type Mutation {
    updateAppBarColorSetting(setting: String!): AppBarColorSetting!
  }
`;

const resolvers = {
  Query: {
    appBarColorSetting: () => userSettings.appBarColorSetting
  },
  Mutation: {
    updateAppBarColorSetting: (_, { setting }) => {
      userSettings.appBarColorSetting.setting = setting;
      return userSettings.appBarColorSetting;
    }
  }
};

const client = new ApolloClient({
  cache: new InMemoryCache({
    freezeResults: true
  }),
  typeDefs,
  resolvers,
  assumeImmutableResults: true
});

const TogglesApp = () => (
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
);

ReactDOM.render(<TogglesApp />, document.getElementById("root"));

First, we define typeDefs and resolvers.

The AppBarColorSetting type will have required id, name, and setting fields. This will allow us to fetch and mutate the app bar’s color through GraphQL queries and mutations!

type AppBarColorSetting {
  id: Int!
  name: String!
  setting: String!
}

Next up, we define the Query type so that we can fetch the appBarColorSetting:

type Query {
  appBarColorSetting: AppBarColorSetting!
}

Finally, you guessed it, we need to define the Mutation type so that we can update appBarColorSetting:

type Mutation {
  updateAppBarColorSetting(setting: String!): AppBarColorSetting!
}

Finally, we set up our client. Often, you will find yourself instantiating ApolloClient with a link property. However, since we have added a cache and resolvers, we do not need to add a link. We do, however, add a couple of properties that may look unfamiliar. As of apollo-client 2.6, you can set an assumeImmutableResults property to true to let apollo-client know that you are confident you are not modifying cache result objects. This can, potentially, unlock substantial performance improvements. To enforce immutability, you can also add the freezeResults property to inMemoryCache and set it to true. Mutating frozen objects will now throw a helpful exception in strict mode in non-production environments. To learn more, read the “What’s new in Apollo Client 2.6” post from Ben Newman.

const client = new ApolloClient({
  cache: new InMemoryCache({
    freezeResults: true
  }),
  typeDefs,
  resolvers,
  assumeImmutableResults: true
});

That’s it! Now, simply pass this client to ApolloProvider and we’ll be ready to write our query and mutation! 🚀

const TogglesApp = () => (
  <ApolloProvider client={client}>
    <App />
  </ApolloProvider>
);

Querying client-side data

We’re now going to query our client cache using GraphQL. Note that in this proof-of-concept, we simply define the initial state of our userSettings in a JSON blob:

{
  "appBarColorSetting": {
    "id": 1,
    "name": "App Bar Color",
    "setting": "primary",
    "__typename": "AppBarColorSetting"
  }
}

Note the need to define the type with the __typename property.

We then define our query in its own .js file. You could choose to define this in the same file the query is called from or even in a .graphql file though.

import gql from "graphql-tag";

const APP_BAR_COLOR_SETTING_QUERY = gql`
  query appBarColorSetting {
    appBarColorSetting @client {
      id
      name
      setting
    }
  }
`;

export default APP_BAR_COLOR_SETTING_QUERY;

The most important thing to notice about this query is the use of the @client directive. We simply need to add this to the appBarColorSetting query as it is client-specific. Let’s take a look at how we call this query next:

import React from "react";
import { useQuery } from "@apollo/react-hooks";

import AppBar from "@material-ui/core/AppBar";
import Toolbar from "@material-ui/core/Toolbar";
import Typography from "@material-ui/core/Typography";
import IconButton from "@material-ui/core/IconButton";
import MenuIcon from "@material-ui/icons/Menu";

import SettingsComponent from "./components/SettingsComponent";
import APP_BAR_COLOR_SETTING_QUERY from "./graphql/APP_BAR_COLOR_SETTING_QUERY";

function App() {
  const { loading, data } = useQuery(APP_BAR_COLOR_SETTING_QUERY);

  if (loading) return <h2>Loading...</h2>;
  return (
    <div>
      <AppBar position="static" color={data.appBarColorSetting.setting}>
        <Toolbar>
          <IconButton color="inherit" aria-label="Menu">
            <MenuIcon />
          </IconButton>
          <Typography variant="h6" color="inherit">
            State Management with Apollo
          </Typography>
        </Toolbar>
      </AppBar>
      <SettingsComponent
        setting={
          data.appBarColorSetting.setting === "primary"
            ? "secondary"
            : "primary"
        }
      />
    </div>
  );
}

export default App;

Note: we are using Material-UI in this app, but obviously the UI framework choice is up to you. 🤷‍♂️

const { loading, data } = useQuery(APP_BAR_COLOR_SETTING_QUERY);

We show a basic loading indicator and then render the app bar with data.appBarColorSetting.setting passed into the color attribute. If you are using the Apollo Client Developer Tools, you’ll be able to clearly see this data sitting in the cache.

Mutating client-side data and updating the cache

You may have noticed this block of code in our App component. This simply alternates the value of setting based on its current value and passes it to our SettingsComponent. We will take a look at this component and how it triggers a GraphQL mutation next.

<SettingsComponent
  setting={
    data.appBarColorSetting.setting === "primary" ? "secondary" : "primary"
  }
/>

First, let’s take a peek at our mutation:

import gql from "graphql-tag";

const UPDATE_APP_BAR_COLOR_SETTING_MUTATION = gql`
  mutation updateAppBarColorSetting($setting: String!) {
    updateAppBarColorSetting(setting: $setting) @client
  }
`;

export default UPDATE_APP_BAR_COLOR_SETTING_MUTATION;

Again, notice the use of the @client directive for our client-side updateAppBarColorSetting mutation. This mutation is very simple: pass in a required setting string and update the setting.

Below you will find all the code within our SettingsComponent which utilizes this mutation:

import React from "react";
import { useMutation } from "@apollo/react-hooks";

import Button from "@material-ui/core/Button";

import UPDATE_APP_BAR_COLOR_SETTING_MUTATION from "../graphql/UPDATE_APP_BAR_COLOR_SETTING_MUTATION";
import APP_BAR_COLOR_SETTING_QUERY from "../graphql/APP_BAR_COLOR_SETTING_QUERY";

function SettingsComponent({ setting }) {
  const [updateUserSetting] = useMutation(
    UPDATE_APP_BAR_COLOR_SETTING_MUTATION,
    {
      variables: { setting },
      update: cache => {
        const data = cache.readQuery({
          query: APP_BAR_COLOR_SETTING_QUERY
        });

        const dataClone = {
          ...data,
          appBarColorSetting: {
            ...data.appBarColorSetting,
            setting
          }
        };

        cache.writeQuery({
          query: APP_BAR_COLOR_SETTING_QUERY,
          data: dataClone
        });
      }
    }
  );
  return (
    <div style={{ marginTop: "50px" }}>
      <Button variant="outlined" color="primary" onClick={updateUserSetting}>
        Change color
      </Button>
    </div>
  );
}

export default SettingsComponent;

The interesting piece of this code that we want to focus on is the following:

const [updateUserSetting] = useMutation(
  UPDATE_APP_BAR_COLOR_SETTING_MUTATION,
  {
    variables: { setting },
    update: cache => {
      const data = cache.readQuery({
        query: APP_BAR_COLOR_SETTING_QUERY
      });

      const dataClone = {
        ...data,
        appBarColorSetting: {
          ...data.appBarColorSetting,
          setting
        }
      };

      cache.writeQuery({
        query: APP_BAR_COLOR_SETTING_QUERY,
        data: dataClone
      });
    }
  }
);

Here, we make use of the apollo/react-hooks useMutation hook, pass it our mutation and variables, then update the cache within the update method. We first read the current results for the APP_BAR_COLOR_SETTING_QUERY from the cache then update appBarColorSetting.setting to the setting passed to this component as a prop, then write the updated appBarColorSetting back to APP_BAR_COLOR_SETTING_QUERY. Notice that we do not update the data object directly, but instead make a clone of it and update setting within the clone, then write the cloned data object back to the cache. This triggers our app bar to update with the new color! We are now utilizing apollo-client as a client-side state management solution! 🚀

Takeaways

If you’d like to dig into the code further, the CodeSandbox can be found here. This is admittedly a very contrived example but it shows how easy it can be to leverage apollo-client as a state management solution. This can be an excellent way to introduce GraphQL and the Apollo suite of libraries and tools to a team who has little to no GraphQL experience. Expanding use of GraphQL is simple once this basic infrastructure is in place.

I would love to hear thoughts and feedback from everyone and I hope you learned something useful through this post!

Never Too Late to Learn: My (meandering) path to a career in software engineering

Matt Dionis — Tue, 27 Aug 2019 21:02:22 +0000

If you've ever considered pursuing a career in software engineering but thought you were too old or that your education and career path up to this point weren't a fit, think again! My path to a career in software engineering is detailed below and let's just say it was not a straight line, but it was well worth it!

The weather geek

For as long as I can remember I have been fascinated by the weather. Some of my fondest memories as a child were peering out the window as a severe thunderstorm rolled in or waking up in the morning to a raging blizzard outside. My favorite number was, and still is, 56 due to the fact that The Weather Channel was 56 on our cable package.

Old school Weather Channel logo. Oh, the memories!

Throughout my teenage years, I was the local weather spotter for Boston's ABC affiliate. I would call in local conditions and snowfall amounts during storms and would be mentioned on-air once in awhile. I knew my future career was going to be in meteorology and no one could tell me anything different.

I was a solid student throughout my childhood and decided to only apply to one school, Penn State University. Penn State has one of the best, if not the best, meteorology programs in the nation. I received my acceptance letter before Halloween of my senior year of high school. Everything was falling into place for this future meteorologist…or so I thought.

Total lines of code written by age 18: 0

Skills gained which would eventually help my engineering career: embracing a passion (meteorology) and being a self-starter in learning more about a field

A national tragedy and a change of course

Within the first month of college, my classmates and I were informed that there was a great chance none of us would graduate with a Meteorology degree. I remember all of us laughing out loud. We had all been weather geeks since we could walk. Noooo chance we would change majors.

By the beginning of my sophomore year of college, I started to get bored with my meteorology courses. I loved tornados, hurricanes, blizzards but these extreme weather events do not happen very often. I remember overhearing classmates arguing about whether that night's low temperature would be 37º or 38º one day and all I was concerned with was where I was going to party that night. It was clear that I needed to make a change, but when you've been known as the "future meteorologist" since age five it can be very difficult to tell those you love that that dream is over.

I had my first Computer Science course scheduled for the fall of 2001 but after just one class I dropped it. I decided that computer science was just not for me and my time was better spent in a different class. Oh, silly 20-year-old me ;)

My sophomore year began in the fall of 2001 and on September 11 any childhood innocence I may have had left was gone. Meteorology suddenly felt even less important to me as I began to look for a major, and a future career, where I could have a greater impact.

Around this same time, I attended a free speaker series event on the University Park campus. Chuck D of Public Enemy fame was the speaker that evening. I still remember to this day when he looked out at the audience and urged us, students, not to "waste our time at a great university pursuing someone else's dream". That was the push I needed and the very next day I began filling out paperwork to change my major.

I moved to Washington D.C. after graduating from Penn State and within a year was working as a Data Analyst on an Immigration and Customs Enforcement (ICE) contract.

Total lines of code written by age 22: 0

Skills gained which would eventually help my engineering career: time management, advanced mathematics, improved logical thinking

Jaded and restless

I entered my career in Homeland Security with a vision that I would be "protecting the country from terrorists". This is not what I experienced in reality. It quickly became apparent to me that my job was mostly busy work and that the contractor I was working for was much more interested in securing more Federal contracts while appearing to "fight terrorism" than actually fighting terrorism. In my 2.5 years on the job, I can honestly admit that my work contributed to zero terrorist apprehensions.

Fitness modeling photoshoot circa 2007

I was pretty frustrated at this point but thankfully had the gym as an outlet. Every day after work I would spend a solid two hours lifting weights. I would then go home and prepare eggs, oatmeal, chicken, and sweet potatoes for the next day's meals. This lifestyle eventually led to a couple of local photoshoots and the opportunity to work with a manager to further this side career. I did some work for Under Armour and Simpson Racing and quickly got the itch to move West to Hollywood to see what I could make out of this opportunity.

Total lines of code written by age 25: 0

Skills gained which would eventually help my engineering career: even stronger self-starter skills, ability to focus on the task-at-hand and remove distractions

Hollywood dreams

I quit my stable job with great benefits while my parents were vacationing overseas and broke the news to them over the phone the day they returned. I do not recommend this strategy for breaking news like this. It did not go over well, to say the least.

The backdrop to an interesting 15 months of my life

After arriving in LA, I found a job working as a graveyard shift Front Desk Agent at a hotel on the Sunset Strip. My plan was to work nights, hit the gym in the morning, and audition for acting roles in the afternoon. This plan turned out to be very naive. I auditioned for a grand total of zero roles as I had failed to take sleep into consideration. I never really got accustomed to the overnight shift and felt like a zombie most days.

I made the decision to move back to my hometown in late 2008 just as the economy was collapsing.

Total lines of code written by age 26: 0

Skills gained which would eventually help my engineering career: the ability to fight through adversity, communication skills, "debugging" (in this case in support of solving hotel guest issues)

Return to the East Coast

I moved back to the East Coast at the very end of 2008 when the economy had hit rock bottom. It took me almost a full year to find another job. In hindsight, I wish I had begun learning to code at this point but it never crossed my mind.

I worked as a Data Analyst on a temporary contract for a little over a year. I had no benefits: no healthcare, zero vacation days, no opportunity to advance. Thankfully, my wife encouraged me to pursue a career in actuarial science. I had a solid math background and actuarial careers pay well so I started studying!

Total lines of code written by age 29: 0

Skills gained which would eventually help my engineering career: analytical skills

Avoiding risk

I passed the first two actuarial exams on my own which led to an opportunity to work at a local insurance company. This was a huge step up from my prior temp role. This position is where I began to dabble in some "programming" in a way. Most of my days were spent in massive Microsoft Excel files updating and improving macros. I found that I really enjoyed this work although it still felt fairly tedious.

A sample problem from an actuarial exam. I do not miss those days!

I struggled mightily with the third actuarial exam and ended up transitioning off of the exam track and into an actuarial technician role. This role afforded me the opportunity to begin working with SQL Server. I took to this from day one and had a lot of fun learning SQL.

Total lines of code written by age 32: 0 (unless you count Excel macros and SQL)

Skills gained which would eventually help my engineering career: "programming" Excel macros, SQL

Embracing risk

Around this same time, one of my best friends from high school and I decided to work on a health and fitness startup. The basic idea was to connect the millions of health and fitness-related photos shared on social media (meals, supplements, workouts, etc.) to health and fitness companies. You can think of it as a healthy living rewards platform. We called it ConquerFit.

An early prototype of the ConquerFit app

We outsourced development of the ConquerFit app to a local dev team and they delivered exactly what we wanted for our MVP. We quickly realized, however, that our friends and family funding had been blown through and we had a lot of features that needed to be added to the app before it was ready for general public release.

I decided to teach myself to code in order to build the "v2" version of our app.

I dove in head first starting with Codecademy which I found to be an excellent first resource. After working through all of the JavaScript, HTML, CSS, and SQL material on Codecademy, I moved on to Treehouse.

I felt confident at this point and began hacking on some small sample projects. I cannot stress enough how important it is to begin working on an actual project early on in your learning journey. Working through tutorials is one thing, building an app is quite another. You'll quickly get familiar with git and GitHub, npm, browser dev tools, and much more.

The sample project I spent most of my time on was something I called "MobSeen". This application focused on sports events and allowed users to view Instagram photos shared in and around sporting events in near real-time. In order to build this app, I needed to gain a deeper understanding of Node.JS, AngularJS and setting up and managing a database. This turned out to be a great learning experience!

The MobSeen app showing photos at Super Bowl XLIX!

I loved the process of learning, building, stumbling, learning some more, and repeating over and over again. What I found that I did not love was running a startup and thinking about fundraising, marketing, accounting, etc. ConquerFit would fade away but my newfound passion for web development would propel my career forward.

Total lines of code written by age 32: many 😁

Skills gained which would eventually help my engineering career: HTML, CSS, JavaScript, git, GitHub, npm, browser dev tools, debugging

Given a chance

I was very hesitant to apply for software engineering jobs at first as I never quite felt "ready". Thankfully, my wife urged me to go for it and I followed her advice. I was able to get on the Hired platform in the spring of 2015. I originally was only interested in jobs in Central Massachusetts as I wanted to avoid a commute. My recruiter, however, convinced me to expand my search area to Boston and I am so thankful that I did. I interviewed with a half dozen companies before receiving and accepting an offer from Circle.

My first role in this field was as a Software Engineer on the internal tools team at Circle. I was, and continue to be, incredibly grateful to the team at Circle for giving me a chance. I had an awesome manager and was surrounded by an intelligent, hard-working and collaborative team from day one. I can't say enough about how comfortable they made me feel and how much I learned over those first couple of weeks, months, and years in the industry.

Total lines of PRODUCTION code written by age 34: many 😁

Giving back

I have spent the last eighteen months in Tech Lead/Engineering Manager roles which have allowed me to further improve my communication, prioritization, planning and management skills. I am focused on giving back to more junior developers and career-changers at this point through blogging, speaking at conferences, building video courses, and mentorship.

Take it from me: you are not too old to start coding, and your seemingly unrelated career path to this point will help you to be a better engineer in the long run. Start learning, start building, and never stop asking questions! In fact, feel free to reach out to me @mattdionis or mattdionis@gmail.com with any and all questions.

Resources that have helped me (and could help you)

Learning platforms

Codecademy (solid for beginners)
Treehouse (great next step after Codecademy)
Pluralsight (more advanced, deep dives into frameworks/libraries)
Egghead.io (awesome JavaScript content)

Instructors/bloggers

Samer Buna (especially love his Node.JS material)
Dan Abramov (incredible deep dives into React)
The Apollo GraphQL blog (great for beginner and experienced GraphQL devs alike)

Twitter follows

Sarah Drasner (animations, VueJS, and so much more)
Shirley Wu (data visualization awesomeness)
Nadieh Bremer (⬆️ ditto)
Shawn Wang (JAMstack!)
John Papa (Angular!)

Podcasts

Good luck!!! 👨‍💻