We Learn Code

A Complete Guide to the Amplify React Authentication Components

Mon, 10 Jan 2022 00:00:00 GMT

A few weeks ago, the team I work on, AWS Amplify, launched brand new authentication components for React, Vue, and Angular. I want to give you a quick tour of what you can do with these components from enabling backend authentication to simple frontend flows, to more complex, customized setups.

Enable Authentication

You can enable authentication via Amplify in two ways: first through Amplify Studio and secondly through the Amplify CLI. I'll show you how to do so through Studio; however, here are instructions for doing so through the command line if that better fits your workflows.

First, head to the Amplify Console. Then click "New app" and select "Build an app". Then choose a name for your project -- for example "amplify-authenticator-demo". Once your app deploys, click "Launch studio". From there, click "Enable authentication" on the Studio landing page.

Here, choose your desired authentication setup. I'll go with the defaults, but you can add multi-factor authentication, different attributes you want to get from your users, and different login mechanisms including social providers.

Once you have your setup, click "Deploy". Now you have backend authentication enabled for your app!

App setup

I'm going to create a React app to demonstrate the authentication components; however, it's also compatible with Vue and Angular with more frameworks on the way!

I'll create a new React app:

npx create-react-app amplify-authenticator
cd amplify-authenticator

Then, if you go back to Studio and click "Deployment successful - click for next steps" on the upper right of the page, you'll see an amplify pull command with your app id. Run that command to sync your backend with your frontend. If you get a confirmation browser window, accept and then answer the questions in your CLI. The defaults should be sufficient for almost all of the questions!

Then, install the Amplify libraries and React components:

npm i aws-amplify @aws-amplify/ui-react

Open your app up in your text editor, and then add the following to your src/index.js file:

import Amplify from 'aws-amplify'
import config from './aws-exports'

Amplify.configure(config)

This will configure Amplify within your app! Now add in the Amplify CSS file and the AmplifyProvider component.

import '@aws-amplify/ui-react/styles.css'
import { AmplifyProvider } from '@aws-amplify/ui-react'

Then, add an instance of the AmplifyProvider as the top level of your React app.

ReactDOM.render(
  <AmplifyProvider>
    <App />
  </AmplifyProvider>,
  document.getElementById('root')
)

This will add Amplify's default styling to your app.

The withAuthenticator component

Let's add a full authentication flow to our app with the withAuthenticator higher order component. First, import it:

import { withAuthenticator } from '@aws-amplify/ui-react'

Then, wrap your App export:

export default withAuthenticator(App)

If you run your application server, you'll notice that you have a full authentication flow with sign in, sign up, and forgot password. Try it out!

Once you have created a user and signed in successfully, then you'll see the contents of your component. In my case "Hello, world!". You could also use this flow on a different page of your application, for example a form so that anyone could visit a landing page, but only authenticated users could access that form.

This component automatically detects your authentication setup, so if you had social providers enabled, they would show up as options on the form as well. You can, however, also pass arguments to the withAuthenticator in order to override these defaults. For example the following will display sign in with Apple even if you don't have it configured for your app.

export default withAuthenticator(App, {
  socialProviders: ['apple']
})

Add sign out and display user info

Let's add sign out to our application, and display the user on the homepage. The signOut function and the user object are passed to our component by the Authenticator component, so we can destructure them and then use them in our app! For example:

function App({ signOut, user }) {
  return (
    <div>
      <h1>Hey, {user.attributes.email}</h1>
      <button onClick={signOut}>Sign out</button>
    </div>
  )
}

Customize your flows with the Authenticator

You can further customize your flows, fields, text, and more by using the Authenticator component. You can even add internationalization so that your text displays as you want across the globe.

Here's the full documentation to learn more.

Add a Theme to your UI

You can also add a theme to your Authenticator component. You can do so via CSS variables, a JavaScript object, or design tokens. I'll create a JavaScript object:

const theme = {
  name: 'pretty-princess',
  tokens: {
    colors: {
      background: {
        primary: { value: 'hotpink' }
      }
    }
  }
}

Then, I'll pass it as a prop to the AmplifyProvider

<AmplifyProvider theme={theme}>

Now, my component is hot pink!

Learn more about theming in the documentation.

Conclusion

Head to the Amplify Console in order to create your own application, I'd love to see what you build. If you have any feedback, feel free to message me, join our Discord, or leave a GitHub Issue.

Build a Vacation Rental Site with Amplify Studio

Mon, 13 Dec 2021 00:00:00 GMT

What is Amplify Studio?

One of the most exciting projects I've worked on in my career, AWS Amplify Studio, just launched at Re:Invent in public preview. With Amplify Studio you can quickly go from a designer’s vision to a full stack, cloud connected app that scales with your needs. You can create components in Figma, import them into Amplify Studio, and then connect them to your AWS-backed data models. Then, Studio can export your UI components to human-readable React code that you can extend yourself. Let's go step by step through how you would build an app with Amplify Studio.

Create a Data Model

Head to the Amplify Sandbox. Once there, change the dropdown after Build a to "Blank", then click Get Started.

On the Data Modeling page, add a "Rental" model with the fields "name", "image", "price" (an integer), and "location".

Then click the "Deploy to AWS" button on the upper right of the page.

If you're new to Amplify's data modeling, you can check out this tutorial to learn more!

Deploy to AWS

On the deployment page, choose whether or not you have an AWS account (create one if you don't have one yet!) and then choose an app name and deployment region.

Create Data in the Data Manager

Once your app finishes deploying, click the Launch Studio button.

Now, head to the content tab on the left side. This gives you an admin panel where you can perform full CRUD actions for your models -- create a few rental properties! Click Create rental then use the form to create new entries.

Amplify Figma File

If you go back to the home page for studio, you'll see an option on the Amplify Studio home page to "Accelerate UI development" - click the Build UI button underneath. On the UI Library home page, there will be a Get started button that once clicked asks you for a link to your Figma file.

Amplify launched a UI Kit on Figma. You can duplicate this file and then make any modifications that you want and create your own components! Do this in the components Figma page.

I'll modify the appearance of CardA to round the corners, bold some text, and remove the background color.

This UI kit correlates with the Amplify UI Components, which Studio will be using under the hood when it generates your Figma components to React.

Import Figma to Studio

Speaking of, let's import our Figma components into Studio. Copy your Figma file's URL and paste it into Studio. Then click "Continue". Your components will be loaded into Studio.

From there, you can accept or reject your components, and you can view their variants. I'll go ahead and "Accept all".

Link Data

Now, I've created a data model and UI components. I now need to link my data to the UI. I'll choose my CardA component and then click Configure.

Then, create a prop using the component properties form. Choose a name and then use the dropdown to find the model you created! This will pass the data from that model to the component.

From there, select the elements you would like to populate with your data and choose the attribute you'd like to use. I'll click the "image" which right now is a placeholder, then I'll set the src prop to rental.image.

For the spot that currently says "Classic Long Sleeve T-Shirt", set the label to rental.name. Finally, for the price, I'll set what currently says $99 to the price from my data model. I'll also concatenate that with a "$" and "/night".

Now, my component renders my live data!

Create a Collection

I want to display all my rentals, instead of just one. So, I'll create a collection from my component. Click "Create Collection" on the right side of the page. Then choose a name for your collection, I'll go with RentalCollection. Once on the collection page, you can choose whether your cards render in a grid or list, the number of columns, padding between, and the direction of the collection.

I'll create a grid, then switch to four columns and add 4px in between each one.

You can also modify the data set that goes into the collection. You can sort the items, or add a filter by clicking "View/Edit" next to "Data set".

Pull to Studio

If you're new to React, check out this tutorial before continuing!

Now we have components created with data bound to them, let's use those components in an app! I'll create a React app:

$ npx create-react-app amplify-studio-tutorial
$ cd amplify-studio-tutorial

Then, I'll install the Amplify JavaScript libraries and React components.

$ npm i aws-amplify @aws-amplify/ui-react

Then, I'll run the Amplify pull command to run code generation in my app. You can find the amplify pull command specific to your app by clicking "local setup instructions" in Studio.

Run this command in your React app, and you'll see quite a few files generated including /src/ui-components -- this contains all of your React components! You can open them up and see what's inside.

Now, let's set our app up. First, in your index.js file, configure amplify by pasting in these three lines of code:

import config from './aws-exports'
import Amplify from 'aws-amplify'

Amplify.configure(config)

These will tie your frontend to your Amplify-created backend.

Now, head to your App.js, and clear out the existing return ().

Import the AmplifyProvider component, and the Amplify CSS file:

import { AmplifyProvider } from '@aws-amplify/ui-react'
import '@aws-amplify/ui-react/styles.css'

Then, add the AmplifyProvider at the top level of your return. This will provide styling to all of its child components.

function App () {
  return (
    <AmplifyProvider>
    </AmplifyProvider>
  )
}

export default App

Now, let's render our RentalCollection! First, import it:

import { RentalCollection } from './ui-components'

Then, add it to the render:

function App () {
  return (
    <AmplifyProvider>
+      <RentalCollection  />
    </AmplifyProvider>
  )
}

export default App

If you run your React server and check out your page, you'll have your rentals collection!

Amplify doesn't load a font in for you automatically, so you'll probably want to add your own. For example, you could add Inter to your App.css file:

@import url('https://fonts.googleapis.com/css2?family=Inter:slnt,wght@-10..0,100..900&display=swap');

Use a Prop

You can customize these React components in your own code. First, you can use props in order to modify your components. If you wanted to make your grid of rentals into a list, for example, you could pass the prop type="list" to your RentalCollection.

<RentalCollection type="list" />

You can find a list of all props in the Amplify UI docs.

Use an Override

Sometimes, you'll want to modify child components instead of the top level one. You can use overrides in order to do so!

Right now, the images are kind of wonky due to my styling in Figma. Let's change the object-fit to cover for the image via overrides to fix that.

Open up the code for the RentalCollection component. Inside each of its child components, you'll notice a line of code like this: {...getOverrideProps(overrides, "Collection.CardA[0]")}. The second value is a key you can use to specify which component you want to add an override to.

In this case we'll add the following to our RentalCollection instance:

<RentalCollection
 type='list' overrides={{
   'Collection.CardA[0]': {
   }
 }}
/>

This will add overrides to the CardA component. In this case, though, we want to override the Image component inside of CardA. Open up the code for that component, and you'll see similar overrides for each of its child components.

We'll pass a second override object to the CardA override. Then we'll set the key to the override key for our Image. Then we'll set the objectFit prop to cover.

<RentalCollection
 type='list' overrides={{
   'Collection.CardA[0]': {
       overrides: {
        'Flex.Image[0]': { objectFit: 'cover' }
       }
    }
 }}
/>

You can use this to add almost any customization you need to your components!

Note that if you re-run amplify pull your components will regenerate. Because of this, you won't want to modify the components in the ui-components directory directly. If you decided you wanted to modify the code in a component file, you could drag it out of that directory and it would no longer get overwritten by amplify pull!

Theming

You may want to add a theme to your UI components so that they match your brand. You can do this via a JavaScript object, CSS variables, or through the Amplify Theme Editor Figma Plugin.

Install the plugin, then choose it from the Figma plugin dropdown.

You'll be prompted to enter your app's Amplify Studio URL, and then to sign into your app. In order to get your sign in, you can create a user within the AWS Amplify Console for your app.

Note: make sure to reset your new user's password before using it to log into the Figma Plugin!

You can then change any of the colors for your app, change your brand colors, and any of the components' colors. You can apply them to the Figma file and to your Studio app. Once you sync with Studio, the next time you run amplify pull, you'll have a theme object that you can pass as a prop to AmplifyProvider which will apply your theme to your app!

Learn more about theming in the docs.

Update from Figma

If at any point you want to update a component, you can do so within Figma and then click "Sync with Figma" in Studio. Then, you'll be able to observe your changes compared to what you have now, and either accept or reject your changes.

Use the rest of the Amplify Ecosystem

You can use the whole Amplify ecosystem with an app that you create with Amplify Studio. You can add frontend hosting, additional backend resources like authentication, storage, and serverless functions, and then extend your project outside of what Amplify natively offers with CDK.

Conclusion

I can't wait for you to build your own app with Amplify Studio out. If you have any feedback, please leave a GitHub issue or join our Discord Community!

What is the Cloud?

Mon, 01 Nov 2021 00:00:00 GMT

Frontend developers! Have you ever wondered why to choose a certain type of database for a project, how to create an API, how to deploy to AWS, or what a container is? You're in the right place! This series will teach you all about backend development specifically targeted at frontend developers: you know how to code, you may have heard certain backend terminology, but you don't consider yourself fullstack. You'll learn backend concepts and how to implement them using AWS.

In this first post of the series, we'll start off by defining what the backend is, what difficulties there are within backend development, and then we'll discuss what the cloud is and how it relates to backend development.

What is Backend Development?

Traditionally, the definition for a frontend vs. backend developer is that frontend developers work on the client side -- they build the interface that users interact with. Backend developers work on server side code. That can include building APIs, database interaction, and dealing with server configuration. I started my career as a backend developer, working mostly on building data science systems -- I had to think a lot about scalability, how to handle and analyze large amounts of data, and how to deploy those systems in dependable ways.

Some of the questions a backend developer may have to answer include: How do you scale a system for a million users? More than a million? How much data needs to be stored? How fast does it need to be accessed? Are there long running jobs that need to be managed? There are so many trade offs that must be weighed when building these systems. We'll talk about a bunch of them in this series.

One big evolution in backend development is the cloud -- though it's impacting almost everyone online, not just backend devs.

What is the Cloud?

The cloud allows you to access computer resources on-demand. You may have used Google Drive or iCloud to store your files online rather than your own computer or phone wo that you have more storage space. This is a perfect example of how the cloud is used.

Many companies also use the cloud for their server infrastructure. You've probably heard of servers before, they're essentially computers that send information to other computers. We use them to handle the request/response cycle for websites -- they take a request and based on it handle business logic, database queries, etc. and then send a response back to the client.

In comes data centers -- these hold all the needed servers for a company, and they buy more and more servers as the company grows. They would have staff to manage the data center and they'd need to install software on and maintain the servers yourself.

The cloud allows you to access the provider's servers and use them instead of needing to manage the data centers yourself. This provides a lot of benefits to the company, first you only need to pay for what you use instead of all the servers you buy for a data center. You also have global availability with most cloud providers, you don't need to have data centers all over the world to speed up your response time globally -- the cloud provider does that for you. And, you don't need to pay for the data centers or data center staff yourself, instead that's done by the cloud provider. AWS has a whitepaper explaining these benefits in further detail.

There are different families of cloud services.

Infrastructure as a service (IaaS) is the lowest level where you have more control over the operating system and runtime for your services. Examples include Amazon EC2 and Digital Ocean.
Platform as a service (PaaS) - provides cloud components where you manage the application logic and data but not the servers or anything low level. Examples include Heroku and AWS Elastic Beanstock.
Software as a service (SaaS) - cloud services an end user directly uses with no cloud management needed. Some examples include Dropbox, iCloud, and Slack.
Function as a service (FaaS) - allows you to deploy just a function into the cloud, you don't need to do server management or anything like that. AWS Lambda is a great example of this.

On that note, AWS, or Amazon Web Services, is a cloud provider (and my employer) who has over 200 different cloud services. We'll be chatting about a bunch of these services throughout this series.

Conclusion

Next time, we'll go a little deeper into the logistics of using the cloud. How can you set up an AWS account with a billing alarm and an IAM user? If you have topics you'd like to see answered in this series, please let me know in the comments or via twitter.

Three New Next.js Features and How to Use Them

Tue, 21 Sep 2021 00:00:00 GMT

AWS Amplify recently added support for Next.js 10 features, including incremental static regeneration, optional catch all routes, and image optimization. In this post, we'll dig into what each of these features is, how to implement a fullstack app using them, and how to deploy them to AWS! Let's dive in.

Please note that I work as a Developer Advocate on the AWS Amplify team, if you have any feedback or questions about it, please reach out to me or ask on our Discord - discord.gg/amplify!

If you're new to Next.js, check out this tutorial first to get you started! I also wrote this tutorial on creating a fullstack Next.js app if you want to check that out.

Setup

First, let's create a Next.js app:

npx create-next-app next10-blog

Now, let's create our app backend. Head to the Amplify Sandbox and then "get started". Choose "data" on the next page, and start with the blog schema.

I deleted the "Blog" model and added the "content" field to the Post model.

Then, you can skip the "Test locally in your app" page and go straight to deploying with your AWS account. Follow the guided steps to deploy your app!

Once your backend has deployed, enter the Admin UI for your app and then click on "Local setup instructions" on the top right. Run the Amplify pull command into the Next app you created. Also, install the AWS Amplify libraries as well as TypeScript -- you don't need TypeScript for your code it's just for the generated DataStore models.

amplify pull --appId your-appID --envName staging
npm install aws-amplify typescript

I'm also going to generate some blog posts for my app. Click on "Manage app content" within the Amplify Admin UI. Under the "Actions" drop down you'll see an option to "Auto-generate data". Go ahead and generate 10 blog posts. You'll see titles and descriptions pop up!

Now it's code time! Open up the Next.js app that you generated a few steps ago. Open the _app.js file and ad the following. This will make it so that Amplify's frontend libraries are automatically tied to your backend resources that you created! We'll also enable server-side rendering.

import Amplify from 'aws-amplify'
import awsconfig from '../src/aws-exports'
Amplify.configure({ ...awsconfig, ssr: true })

Now, we'll implement the index.js route -- this home page will list all of our blog posts and link them to a secondary page that will display one post. We'll use SSR for this route.

First, I'll import my data model from the generated src/models directory. I'll also import the withSSRContext function from Amplify -- this will allow us to run our query on the server side.

import { withSSRContext } from 'aws-amplify'
import { Post } from '../src/models'

Now, create a getServerSideProps function. Then we'll allow Amplify to run on the server with withSSRContext, we'll provide it the request information as well. Then we'll run a query to get all of our blog posts! Finally, we'll return an object that provides our models as props! You can either convert to JSON manually or use the serializeModel function from Amplify.

export async function getServerSideProps (context) {
  const SSR = withSSRContext(context.req)
  const models = await SSR.DataStore.query(Post)

  return {
    props: {
      models: JSON.parse(JSON.stringify(models))
    }
  }
}

Now we can map through the posts and render them on the page!

export default function Home ({ posts }) {
  return (
    <div>
      <Head>
        <title>Amplify + Next</title>
        <meta name='description' content='Amplify + Next!' />
      </Head>

      <main>
        {posts.map(post => (
          <div key={post.id}>
            <a href={`/post/${post.id}`}>
              <h2>{post.title}</h2>
            </a>
          </div>
        ))}
      </main>
    </div>
  )
}

ISR

Now on to the new Next 10 features! First, we'll implement ISR, or incremental static regeneration. Normally when you use static site generation, the site builds once when you deploy your app. But in a lot of cases you want your static pages to update when your data changes. ISR enables that -- you provide a revalidation time to your getStaticProps and then once that time window is reached the page will regenerate. Essentially, the pages are statically generated initially, and the initial users that hit the page before the provided regeneration time get served that statically generated site. Then, the next request to that page after the regeneration time is hit triggers the page to rebuild in the background -- the user that triggered the regeneration gets served the old version of the page but subsequent users get the new version. This is especially helpful in e-commerce scenarios, and in our case, a blog that you don't need to re-deploy every time you want to add a new post!

We'll create a page that displays one blog post. First, we'll create a post/[post].js page component in the /pages/ directory. Let's start with the imports we'll need.

import { withSSRContext } from 'aws-amplify'
import { useRouter } from 'next/router'

import { Post } from '../../src/models'

Now, we'll create a getStaticPaths function that will generate a static page for each post. We'll query all of our posts, map through them and then return them from the function. We'll also provide a fallback: true here which will make it so that instead of immediately giving a 404 when a non-generated route is hit, Next.js will instead try and generate the page in the background and then render it.

export async function getStaticPaths() {
  const SSR = withSSRContext()
  const posts = await SSR.DataStore.query(Post)
  const paths = posts.map(post => ({
    params: { post: post.id }
  }))

  return {
    paths, fallback: true
  }
}

Now, we'll implement our getStaticProps. We'll this time query for just one post using its id. Then we'll return the post in the props object, and we'll also add the revalidate key. This will implement ISR for our page! I'll provide 10 which will make the revalidation time 10 seconds. You could change this value depending on your use case!

export async function getStaticProps(context) {
  const SSR = withSSRContext(context.req)
  const post = await SSR.DataStore.query(Post, context.params.post)
  return {
    props: {
      post: JSON.parse(JSON.stringify(post))
    },
    revalidate: 10
  }
}

Now, we'll render the post on the page! I'll use the router.isFallback to render the loading indicator if a non-generated path is hit -- I only did this because I used fallback: true!

export default function PostPage({ post }) {
  const router = useRouter()

  if (router.isFallback) {
    return <div>Loading...</div>
  }

  return (
    <div>
      <h2>{post.title}</h2>
      <p>{post.content}</p>
    </div>
  )
}

Then I'll push my code to GitHub. Then, I'll go back to the AWS Console page for my app. You should see the backend environments page populated with your Admin UI link. Head over to the frontend environments tab and you'll have the option to deploy your app!

Follow the guided deployment steps, you should be able to select your branch from GitHub and use the default build scripts detected from your package.json! You'll also see information about what was deployed -- in this case you'll have a Lambda@Edge function that will handle ISR for you!

Optional Catch All Routes

We have two more much quicker features to chat about, first optional catch all routes. These allow you to create a route that can have any parameters after it. We'll create one for an about page. /about should render the page, but so should /about/hi and /about/ali/spittel. We can do this by creating a page component and then putting it in double brackets and adding three dots before it.

First, create the file for the page:

/pages/about/[[...about.js]]

Now, I'll implement the compnent. I'll use useRouter from Next to get information about the route, then I'll render the route parameters on the page! Try /about, /about/hi and /about/ali/spittel and see how this changes!

import { useRouter } from 'next/router'
import React from 'react'

export default function About(props) {
  const routeData = useRouter()
  return (
    <div>
      {JSON.stringify(routeData.query)}
    </div>
  )
}

Now push your code to GitHub and Amplify will automatically redeploy your frontend with the new about page!

Image Component

Finally, let's try out the Next.js Image component. This component automatically enables image optimization with resizing, optimization, and serving different image types like webp when browsers support them. I added a picture of my dog Blair to the /public directory.

Then, I imported the Image component in the index.js file

import Image from 'next/image'

Then, I rendered her picture on the page!

 <Image src='/blair.jpeg' alt='Fluffy white dog lying on a couch' height={200} width={150} />

I again pushed to GitHub to redeploy the site!

Conclusion

I hope this tutorial helped you implement a few of the new Next.js features and deploy them to AWS Amplify. If you want to take down your app, you can run amplify delete from your CLI and your code will persist locally but it will no longer be deployed to the cloud. If you have any feedback on AWS Amplify or this tutorial, please let me know!

A Complete Beginner's Guide to GraphQL

Mon, 30 Aug 2021 00:00:00 GMT

I first used GraphQL on a project right after its launch in 2015, and to be honest I didn't understand why we were using it. Over the years, I've grown to love GraphQL - you can quickly create APIs with managed services such as AWS AppSync and Hasura, and it lessens the friction between frontend and backend development. In this post, we'll chat about what GraphQL is, why to use it as well as when it may not be the best option, and then create a full recipe app using a GraphQL API.

Please note that I work as a Developer Advocate on the AWS Amplify team, if you have any feedback or questions about it, please reach out to me or ask on our discord - discord.gg/amplify!

If you're new to APIs, I would recommend reading this blog post about them first! If you're new to the idea of REST, I'd also recommend reading this first; this post will often compare GraphQL to REST. I'll also be using React for some pieces of the frontend -- I'd recommend skimming a tutorial on that before this post.

Also, a few vocabulary terms we'll be using throughout this post:

Schema: this is a representation of how data is structured.
Fields: these are attributes associated with a piece of data.

What is GraphQL?

According to its documentation, "GraphQL is a query language for your API, and a server-side runtime for executing queries using a type system you define for your data." GraphQL itself is a specification, meaning that there's a document outlining what GraphQL queries look like and how client-server interaction works with it; however, it can be used with any programming language or data layer for your app.

In practice, this allows frontend developers to send queries asking for the data they need -- including nested data -- to the backend. This allows backend developers to create one endpoint instead of the many needed for a REST API. You can send mutations to change data and queries to retrieve data all to one place.

Why use GraphQL?

There are a lot of reasons why GraphQL is popular. The first is that it simplifies the communication between frontend and backend developers much less difficult -- instead of frontend developers needing to ask for a new endpoint once their requirements change, they can instead just update their GraphQL query. This becomes even more helpful if you have multiple frontends requiring the same backend data. Frontend developers can get exactly the data they need -- no under or over fetching of fields or items.

Since frontend developers can request nested data using one query, network requests are also minimized -- for example if you query for a blog post, you can also get that post's comments in that one query instead of doing a second request to get them. This also may reduce the amount of frontend code needed and make that code easier to understand.

GraphQL also enforces a typed data schema, so each item's fields will have to match those types. This makes data more consistent and manageable -- instead of having to loop through blog posts and figure out if each title is a string or a boolean, GraphQL will enforce that each title is a string.

When is GraphQL not so good?

As with anything in software engineering, there are also drawbacks to using GraphQL. Firstly, I started using GraphQL way back when it came out in around 2015, and I hated it. I was a fullstack engineer on a small team, and building the backend was more work and the frontend needed to be more verbose. GraphQL queries are often long, whereas with many REST APIs you can just provide a url. In addition, many backend frameworks and languages have much less mature support for GraphQL APIs compared to REST. You may have to do more work and navigate through a less used library to get your GraphQL Api. If you're the one creating the endpoints and consuming them, building a REST API may be quicker -- especially if you're using a programming language or framework with less mature GraphQL support.

GraphQL shines with larger teams where a frontend team is developing the client side and a separate team is developing the server. In addition, there have been more and more managed GraphQL services, like Hasura and AWS AppSync. These allow you to generate a GraphQL backend using their services and then consume it on the frontend -- this usually speeds up the rate of backend development considerably when compared to writing a GraphQL server from scratch.

Finally, many developers are taught how to use and create a REST API from early on in their careers and may have less institutional knowledge around GraphQL. Getting a full team up to speed may be an investment that you need to consider.

Create a GraphQL API

Now for the fun part, let's write some code! We're going to use AWS Amplify to create a GraphQL backend -- this will speed up the process and allow us to just focus on the GraphQL rather than the rest of backend development.

First, I'll create a React app -- there isn't much React code in here, but the setup will be quicker than creating a Vanilla JS app with a bundler.

In your terminal, run:

npx create-react-app graphql-playground
cd graphql-playground

Note: you'll need Node installed for this step.

Next, we'll initialize Amplify in our project.

amplify init

Note: you'll need Amplify installed for this step.

Then, you'll be prompted to answer a few questions. You can type in "y" to get the default React configuration, and then choose your AWS profile (see the above tutorial if you don't have one!)

Project information
| Name: graphqldemo
| Environment: dev
| Default editor: Visual Studio Code
| App type: javascript
| Javascript framework: react
| Source Directory Path: src
| Distribution Directory Path: dist
| Build Command: npm run-script build
| Start Command: npm run-script start

? Initialize the project with the above configuration? Yes
Using default provider  awscloudformation
? Select the authentication method you want to use: AWS profile

For more information on AWS Profiles, see:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html

? Please choose the profile you want to use default

Now, we'll create a GraphQL API. Run:

amplify add api

You'll again be asked a few questions! First, select GraphQL, then name your API, for example graphql demo. You can then press enter twice to accept the defaults for API keys. Then, you can select no for the GraphQL API and no for the GraphQL schema. Choose the "One-to-many relationship" template and yes to editing the schema now.

? Please select from one of the below mentioned services: GraphQL
? Provide API name: graphqldemo
? Choose the default authorization type for the API API key
? Enter a description for the API key:
? After how many days from now the API key should expire (1-365): 7
? Do you want to configure advanced settings for the GraphQL API No, I am done.
? Do you have an annotated GraphQL schema? No
? Choose a schema template: One-to-many relationship (e.g., “Blogs” with “Posts” and “Comments”)
? Do you want to edit the schema now? Yes
? Choose your default editor: Visual Studio Code

You'll see a pre-generated schema pop up, let's talk about the Blog model.

type Blog @model {
  id: ID!
  name: String!
  posts: [Post] @connection(keyName: "byBlog", fields: ["id"])
}

TODO: add list of scalar types

type - The word type is used to represent a type of object you may get back from your API -- in this case a blog!

Blog - This is the name of the type

@model - The @ sign in GraphQl defines a directive, which means that a field or type has custom logic associated with it. Amplify provides quite a few of these you can use. The @model directive makes it so that the data for the Blog is stored in our database.

id, name, and posts - these are fields or pieces of data that each blog will have

ID and String - these are types, they define that id's will be of the type id and names will be strings. These fields are scalar which means that they are singular pieces of data -- one id and one name rather than having a collection of names for each blog post.

! - The exclamation point after types means that the field is non-nullable, or you always need to provide a value for that field. In this case every blog must have an id and name!

[Post] - Firstly, the [] make it so that it's an array field. Each blog can have an array of posts associated with it. You can also do this with the scalar types as well, so [String] would allow for an array of strings. In this case, we're referring to the Post model which is also declared in this file, so the two data types are related to one another.

@connection - this is another directive, in this case it allows us to relate one model to another. You'll need to provide some data to it, in this case keyName and fields

keyName - This is the name of the index that should be queried to get the related posts. You'll notice on the Post model that a @key directive is defined with a name. The name of that key will match the keyName here. You'll need to define a @key whenever you have a one to many field in Amplify and then use the keyName to reference it.

fields - This is the field that can be queried to get connected objects.

Now let's trade this out for our schema. We'll create a recipe book of sorts. Let's first create three models, Recipe, Ingredient, and Instruction.

type Recipe @model {
}

type Ingredient @model {
}

type Instruction @model {
}

Now, let's add fields to each. Each model will need an id, which will be a mandatory ID field. Then, we'll add names to Recipe and Ingredient. Ingredient will also have a quantity and Instruction will have info.

type Recipe @model {
  id: ID!
  name: String!
}

type Ingredient @model {
  id: ID!
  name: String!
  quantity: String!
}

type Instruction @model{
  id: ID!
  info: String!
}

Now, we need to connect our models. First, we'll add @key directives to both of our child models - Ingredient and Instruction since Recipes will have both! We want to be able to access Ingredients and Instructions by which recipe each belongs to. Each will have a recipeID which will refer to the recipe each belongs to. Then we'll create a connection to the Recipe model based on that recipeID. Finally, we'll set up a @key on each model that will allow us to access the group of ingredients or instructions that belongs to a recipe.

type Ingredient @model @key(name: "byRecipe", fields: ["recipeID"]) {
  id: ID!
  name: String!
  quantity: String!
  recipeID: ID!
  recipe: Recipe @connection(fields: ["recipeID"])
}

type Instruction @model @key(name: "byRecipe", fields: ["recipeID"]) {
  id: ID!
  info: String!
  recipeID: ID!
  recipe: Recipe @connection(fields: ["recipeID"])
}

Finally, we'll add connections from the Recipe model to each of the ingredients and instructions.

type Recipe @model {
  id: ID!
  name: String!
  ingredients: [Ingredient] @connection(keyName: "byRecipe", fields: ["id"])
  instructions: [Instruction] @connection(keyName: "byRecipe", fields: ["id"])
}

Now, we need to deploy our data! Running amplify push will create a GraphQL API in the cloud for us.

amplify push -y

Queries and Mutations!

Okay, we've setup a GraphQL. Now let's interact with it! We'll create data using mutations. We'll also retrieve our data using queries.

From your command line, run:

amplify console api

Then choose graphql. AWS AppSync's console will open in the browser. AppSync is the underlying service we're using to create our GraphQL API, and using its console we can test out queries using a visual interface.

Once you're in the AppSync interface, choose Mutation in drop down, then click the plus button.

Underneath, you'll see some actions to choose from. Select "createRecipe" and then click the checkbox next to name under input.

Type in a name for your recipe. I chose mac n cheese!

Press the orange run button, and you'll have a recipe ✨! You can create a few different ones if you'd like -- change the name of the recipe and press the orange button for each recipe you'd like to make.

Now let's see the recipes we created. Switch the dropdown back to Query instead of Mutation. Then choose listRecipes below it. Select the attributes you'd like to see, like name under items. Also note that you can

Repeat the same processes you used to create a Recipe to create a few ingredients and instructions. Use your recipe's id for the recipeID (hint: you can get this using the listRecipes query!) You can also create a Recipe with ingredients and instructions in one mutation if you select their fields and populate them as well!

Now, rerun the listRecipes query with the ingredients and instructions and you'll see everything connected. This is the beauty of GraphQL -- you can get whatever data you need back without changing an endpoint, you can just change the fields you interact with!

The Anatomy of a GraphQL Query

We've written GraphQL queries and mutations using this visual interface, but let's also dive into their syntax so you can write and understand them from scratch.

Here's an example query we could use on our API.

query MyQuery {
  # This is a comment!
  listRecipes {
    items {
      name
      id
      createdAt
      instructions {
        items {
          id
          info
        }
      }
      ingredients {
        items {
          id
          name
          quantity
        }
      }
    }
  }
}

query - This is the type of operation we're performing with our data.query is to retrieve data, mutation is to change data, and subscription is to listen for changes in our data. We'll use all three in the rest of this tutorial!

MyQuery - This is the name of the query, ideally these would be descriptive like ListRecipes

listRecipes - AppSync generates GraphQL resolvers which allow us to get data.

items - this syntactically represents that we get multiple recipes back

name, id, createdAt - fields we want to get back about our data. createdAt and updatedAt are added automatically for us.

instructions and ingredients - we also want to get the data about the related instructions and ingredients back! Then their fields are inside their queries to get these back.

You can add or remove whichever fields you want to in the query!

Some queries will also require arguments. For example, if you want to get just one Recipe, you may provide the id of the one you want. The same is true for mutations.

query GetRecipe($id: ID!) {
  getRecipe(id: $id) {
    id
    name
  }
}

Now, let's query our newly created API in our app!

How to run those queries on a frontend

Now we've tried out mutations and queries, how do we integrate these into our app? First, let's try this out without using any libraries. We can use a normal Fetch request that we'd use for a REST API call.

Go to your App.js component. First, import the object from the aws-exports.js file. You can go in and check out that file, but it essentially has all the configuration information your frontend will need about your Amplify-generated backend. Also, import useEffect from React.

import config from './aws-exports'
import { useEffect } from 'react'

Now, we'll create a useEffect hook that will make a fetch request on page load (if you were using vanilla JavaScript you'd most likely write this same code without the useEffect inside a page load event).

Inside the fetch request, we'll need to specify the endpoint, which we can get from the aws-exports object. Then we'll need to customize the request by adding the request method POST. We'll also provide the API key from the aws-exports file. Then the request body will contain the query that we used before! We'll need to use the JSON.stringify method to convert our object to a string. Just like with any other fetch request we'll need to convert the data to JSON, then you can view it!

function App() {
  useEffect(() => {
    const pullData = async () => {
      let data = await fetch(config.aws_appsync_graphqlEndpoint, {
        method: 'POST',
        headers: {
          'Content-Type': 'application/json',
          Accept: 'application/json',
          'X-Api-Key': config.aws_appsync_apiKey
        },
        body: JSON.stringify({
          query: `query MyQuery {
          listRecipes {
            items {
              name
              id
              createdAt
              instructions {
                items {
                  id
                  info
                }
              }
              ingredients {
                items {
                  id
                  name
                  quantity
                }
              }
            }
          }
        }
        `
        })
      })
      data = await data.json()
      console.log(data)
    }
    pullData()
  }, [])

  return <h1>Hello GraphQL!</h1>
}

Okay so now we can get data from our API, but this is a little clunky and a lot of code. If you go into your graphql/ directory that was generated by Amplify, you'll see files that have subscriptions, queries, and mutations in them for all common operations! We'll import these and use them in our code. Also, Amplify provides helper functions to abstract away the HTTP request.

In the root of your project, run:

npm i aws-amplify

This will install the Amplify libraries which will help out with making the GraphQL queries more concise.

We'll configure Amplify tying our frontend and backend together in the index.js file. Add this in at the top:

// index.js
import { Amplify } from 'aws-amplify'
import config from './aws-exports'

Amplify.configure(config)

Now, head back to the App.js file. We'll import a few things from the aws-amplify libraries.

import { API } from 'aws-amplify'

We'll also import the listRecipes query from the Amplify generated queries. You can check out the code for it in the 'graphql/queries.js' file.

import { listRecipes } from './graphql/queries'

Let's revise our useEffect code. Replace your pullData function with the following:

useEffect(() => {
  const pullData = async () => {
    const data = await API.graphql({ query: listRecipes })
    console.log(data)
  }
  pullData()
}, [])

The API.graphql() method runs an API request to our app's configured GraphQL API. We'll pass the query in an object as the argument. Much less code than before!

Now, we'll run a mutation to create a new recipe when a button is clicked. We'll also prompt the user to input the recipe's name. Replace your return statement in the App.js component with the following, a button that runs an event listener on click.

return (
  <div className='App'>
    <button onClick={createNewRecipe}>create recipe</button>
  </div>
)

Make sure to import the mutation we'll need:

import { createRecipe } from './graphql/mutations'

Now, we'll implement the createNewRecipe function. Add this to your component. We'll first ask the user to name the recipe. Then we'll run a GraphQL request, this time with the createRecipe mutation. This mutation also takes variables: in this case the name of the recipe. We'll provide that in an object as well!

const createNewRecipe = async () => {
  const name = prompt('what is the recipe name?')
  const newRecipe = await API.graphql({ query: createRecipe, variables: { input: { name } }}))
  console.log(newRecipe)
}

If you refresh the page, you'll now see that your array of recipes has the new one you created! But how can we make it so the query reruns automatically whenever a new recipe is created? Subscriptions!

Subscriptions

Subscriptions allow you to "subscribe" to events via GraphQL, so whenever your data updates you can run code. In our case, we'll make it so that we refetch all the recipes whenever a new one is created.

First, import the subscription:

import { onCreateRecipe } from './graphql/subscriptions'

Then, we'll update our useEffect. Keep the first few lines that pull the recipes from the API. Below that create a subscription. This looks similar to the other API requests we've made, but in this case we'll add the .subscribe method onto it. We'll pass an object with next and error. Error will run if there's an error with the subscription. Next will run after the subscription triggers. In our case we want to re-run pullData!

Finally, make sure to unsubscribe from updates by returning a function that cleans up the subscription.

useEffect(() => {
  const pullData = async () => {
    const data = await API.graphql(graphqlOperation(listRecipes))
    console.log(data)
  }
  pullData()

  const subscription = API.graphql(
    { query: onCreateRecipe }
  ).subscribe({
    next: (recipeData) => {
      pullData()
    },
    error: (err) => {
      console.log(err)
    }
  })

  return () => subscription.unsubscribe()
}, [])

Conclusion

In this post we learned about GraphQL and it's benefits as well as why you may not want to use it! We also created an API and then used it in a frontend app. If you want to take down your API you can run amplify delete from your CLI and your code will persist locally but it will no longer be deployed to the cloud!

Add Sign in with Apple to your React App!

Thu, 05 Aug 2021 00:00:00 GMT

AWS Amplify added support for implementing Sign in with Apple to your apps! In this tutorial we'll start from zero by creating an Apple Developer account, then enable Sign in with Apple using the Amplify Admin UI, finally we'll add it to a React app!

Create an Apple Developer account - note that this costs $99 and takes up to 48 hours! You also may need to create a development certificate in your account.
Go to the AWS Amplify Console and create a new backend app. Choose a name for your project, and then open up the Admin UI once your project is initialized.
Click "Enable authentication" in the Admin UI. Under "Add a Login Mechanism" choose "Sign in with Apple". Don't fill anything out yet though!
Then, go back to the Apple Developer Portal and under your profile choose "Certificates, Identifiers & Profiles." Go to the identifiers page through the left-hand navigation bar and then click the plus button.
On the "Register a new identifier" page, keep the selection on "App IDs", then click continue. Then choose "App" on the next page and continue again. Choose a description for your app, for example "Amplify Sign in with Apple Practice App" and then use one of your domains under the Bundle ID, for example com.welearncode.siwa. Scroll down and select "Sign in with Apple". Then "Continue". Finally, review and register.
Now, we'll register a service ID. Go back to the Identifiers page, then on the righthand dropdown choose "Services IDs" and click the plus button. On the next page, keep "Services IDs" selected, then click "Continue". Choose a description for your service, for example "Amplify Sign in with Apple Practice App". Under "Identifier" use what you used for Bundle ID above, but this time with a .sid at the end - for example com.welearncode.siwa.sid. Then click register on the next page.
Go back to the "Services IDs" page (you should be redirected there!) and click on your created service ID. Check the box under "Enabled", then click the "Configure" button. On your Amplify Admin UI page where you're configuring Sign in with Apple, you should see a redirect URL. Copy and paste it into both "Domains and Subdomains" and "Return URLs". In the first box, "Domains and Subdomains" remove the "https://" and "/oauth2/idpresponse" from the url, just leaving the subdomains and amazoncognito.com. Then click "Next" and "Done".

Last thing to register on the Apple side -- a Key! Select "Key" on the left-hand dropdown and then click the plus button. Name your key and select "Sign in with Apple" below. Click the "configure" button next to "Sign in with Apple". Choose your App ID, then click save. Then continue, and register. Download the key and save it to a place you'll remember, because we'll need to use it in the future!
Now we'll go back to the Admin UI. We'll now fill out the form here! Your Team ID is the App ID you created -- if you go to the "Identifiers" page and select your app, choose the App ID Prefix on your app's page. Your Key ID can be found by navigating to the Key page, selecting your key, and then it will be under "Key ID". Finally your Private Key certificate is that file you downloaded in the last step -- go ahead and upload that. Finally choose a redirect URL -- in development "http://localhost:3000" or similar for your chosen port should work! Then deploy!
Now you can integrate Sign in with Apple into your app. We'll create a very bare bones React app for the sake of this tutorial. First, create a React app.

npx create-react-app siwa-test

Then, install the AWS Amplify libraries.

npm i aws-amplify

Pull down your Amplify app -- you can find the command to do this for your app on the upper right-hand side of the Admin UI under "Local setup instructions".

amplify pull --appId your-app-id --envName staging

You may be asked some questions about your app which you should be able to answer with all the defaults!

In your index.js file, add the following in order to configure your project.

// index.js
import awsconfig from './aws-exports'
import Amplify from 'aws-amplify'
Amplify.configure(awsconfig)

Now, clear out the default App.js file, and replace it with an empty React component.

import './App.css'
import { useEffect, useState } from 'react'

function App () {
  return <h1>Hello world!</h1>
}

export default App

Let's implement the UI first: we'll add a conditional based on if a user is signed in or not and render either a sign in or sign out button. We'll import Auth from 'aws-amplify' which will help us implement the functionality.

We'll create a user in state that's set to null to start out. Then if that user is signed in, we'll add a sign out button and render information about that user. If there isn't a user, we'll render a sign in button. We'll use Amplify's federatedSignIn with SignInWithApple. Right now we aren't setting a user, but you can go ahead and sign in with just this code!

import './App.css'
import { useState, useEffect } from 'react'
import { Auth } from 'aws-amplify'

function App () {
  const [user, setUser] = useState(null)

  if (user) {
    return (
      <div>
        <p>User: {JSON.stringify(user.attributes)}</p>
        <button onClick={() => Auth.signOut()}>Sign Out</button>
      </div>
    )
  } else {
    return (
      <button onClick={() => Auth.federatedSignIn({
        provider: 'SignInWithApple'
      })}
      >
        Sign In with Apple
      </button>
    )
  }
}

Now, above the returns we'll add two more functions above the conditional. First, a getUser function that returns the current user. Second, inside a useEffect we'll listen for auth to change, for example if someone signs in or out. If the user signs in using the hosted UI, then we'll get the user and set state with it.

If they sign out, we'll set the user back to null.

function getUser () {
 return Auth.currentAuthenticatedUser()
}

useEffect(() => {
 Hub.listen('auth', ({ payload: { event, data } }) => {
   if (event === 'cognitoHostedUI') {
     getUser().then(userData => setUser(userData))
   } else if (event === 'signOut') {
     setUser(null)
   } else if (event === 'cognitoHostedUI_failure') {
     console.error('Sign in failure')
   }
 })
})

Now we've implemented Sign in with Apple on a React app using Amplify 🍎✨!

Build a Serverless Subscription Site with Stripe

Wed, 04 Aug 2021 00:00:00 GMT

In this tutorial, we'll be building out a site that uses Stripe to create a checkout system, then that triggers an AWS Lambda Function provisioned through AWS Amplify which creates a user for the purchaser. Then, the user can log in and see paywalled content! This pattern would work for a membership or course site where you want a user to pay for access to content. You could slightly modify the code to send digital products to customers via email as well!

This tutorial assumes intermediate React, AWS Amplify, and Node.js knowledge, though you could use the Node.js code with any frontend stack.

The first step, is to create a Stripe account and confirm your email. You'll need this to generate an API Key. Also, at the bottom of the Checkout Settings page enable client-only checkout. You could implement fullstack checkout if you want to build your own form and such, but this will allow you to move a little faster initially.

Then, create a product using the Stripe dashboard. On the left-hand navigation, select "Products" then "+ Add product". Fill out the form! I made mine into a subscription that was $20/mo.

Now, create a React app.

npx create-react-app membership-site
cd membership-site

Then install the Amplify libraries and Stripe's JavaScript SDK.

npm i aws-amplify @stripe/stripe.js

Clear out the App.js component's return statement so that it just returns an empty <div> for now.

Create two new empty React component files, one named SignIn.js and one called Subscribe.js.

Let's first implement Subscribe.js. Import loadStripe from the Stripe SDK.

import { loadStripe } from '@stripe/stripe-js'

Create a button that fires an event listener on click.

export default function Subscribe () {
  const handleClick = async e => {
  }

  return <button onClick={handleClick}>Get Course Access</button>
}

Inside of that event listener, use the loadStripe function with your Stripe Publishable key as an argument to it. You can find your Stripe Publishable key at the top of the home page under "Get your API Keys".

Then, run Stripe's redirectToCheckout method with your information -- first the lineItems. If you had multiple items that the user could choose from, you'd want to implement some sort of cart checkout that adds items and their quantities to this array. In this case, for a simple app, we'll set the quantity to one and use the price key for our item. You can find the price key by going to your product and then copying the API ID next to the price.

If you made your item a subscription, put that as your mode, otherwise use "product" or whatever you created. Then have a success and cancel URL -- I redirected them back to home if they were successful! I didn't implement an error page, but you could.

const handleClick = async e => {
  const stripe = await loadStripe('your_stripe_publishable_key')
  const { error } = await stripe.redirectToCheckout({
    lineItems: [{
      price: 'price_key',
      quantity: 1
    }],
    mode: 'subscription',
    successUrl: 'http://localhost:3000/',
    cancelUrl: 'http://localhost:3000/cancel'
  })
}

Render this component within your App component.

import './App.css'

import Subscribe from './Subscribe'

function App () {
  return (
    <div className='App'>
      <h1>My Fancy Subscription Site</h1>
      <Subscribe />
    </div>
  )
}

export default App

Try this out -- you should be able to "buy" an item using this form! You can use the credit card number "4242 4242 4242 4242" to test Stripe without actually paying. Now we've implemented step one of this tutorial: checkout!

Now let's move on to the webhook handler that will create a new user once the item is purchased.

First, initialize Amplify for your project.

amplify init

Press enter to accept the suggested configuration. Then we'll initialize auth.

amplify add auth

Press enter for each question that pops up to accept the default authentication setup. Now we'll add an API so that the webhook can make a request to a URL.

amplify add api

Answer the first few questions like so:

? Please select from one of the below mentioned services: REST
? Would you like to add a new path to an existing REST API: No
? Provide a friendly name for your resource to be used as a label for this category in the project: apib104bfb8
? Provide a path (e.g., /book/{isbn}): /webhook

Then, we'll also create an AWS Lambda function. Answer this set of questions with the following:

? Choose a Lambda source Create a new Lambda function
? Provide an AWS Lambda function name: stripedemofunction
? Choose the runtime that you want to use: NodeJS
? Choose the function template that you want to use: Serverless ExpressJS function (Integration with
 API Gateway)

We do want to enable advanced settings for this project. Answer yes to that question.

? Do you want to configure advanced settings? Yes

First, we'll want to access auth from our Lambda function.

? Select the categories you want this function to have access to. auth
? Select the operations you want to permit on stripedemo: create, read, update, delete

Answer no to the following three questions:

? Do you want to invoke this function on a recurring schedule? No
? Do you want to enable Lambda layers for this function? No
? Do you want to configure environment variables for this function? No

We will; however, configure secret values that our function can access. For your secret name, choose "stripe_key" and then enter your Stripe secret key. This will be under where you found your Publishable key above -- you'll have to click "Reveal test key" to see it.

? Enter a secret name (this is the key used to look up the secret value): stripe_key
? Enter the value for stripe_key: [hidden]
? What do you want to do? I'm done

Then run amplify push to deploy all of your provisioned resources to the cloud!

Change into the directory that your function is located in and install the AWS SDK and the Stripe Node SDK.

cd /amplify/backend/function/stripedemofunction/src
npm i aws-sdk stripe

Now we get to write the logic!

First, delete everything below the comments in your app.js file for your Lambda function and then paste in the following. Most of this will already be in the file. It will set up Express for your serverless application.

const express = require('express')
const bodyParser = require('body-parser')
const awsServerlessExpressMiddleware = require('aws-serverless-express/middleware')
const aws = require('aws-sdk')

// declare a new express app
const app = express()
app.use(bodyParser.json({
  verify: function (req, res, buf) {
    req.rawBody = buf.toString()
  }
}))
app.use(awsServerlessExpressMiddleware.eventContext())

// Enable CORS for all methods
app.use(function (req, res, next) {
  res.header('Access-Control-Allow-Origin', '*')
  res.header('Access-Control-Allow-Headers', '*')
  next()
})

app.listen(3000, function () {
  console.log('App started')
})

Now we'll write a function that will retrieve our Stripe secret key. If you look at the top of your app.js file you'll see this already generated there!


const getStripeKey = async () => {
  const { Parameters } = await (new aws.SSM())
    .getParameters({
      Names: ['stripe_key'].map(secretName => process.env[secretName]),
      WithDecryption: true
    })
    .promise()
  return Parameters[0].Value
}

Now we'll create a route that will handle a post request to the /webhook route that we setup.

First we'll get our Stripe key and then configure Stripe to use it. You would also want to make sure the request is properly signed from Stripe in a production app.

We'll use the customer id that's sent to us in Stripe's request body to get the customer's email.

Then, we'll instantiate the AWS Cognito SDK and use it to create a user with the admin API. You can get your UserPoolId in the comments at the top of your the app.js file. It will be slightly different than the one in my code. Then, we'll make sure that the user account is sent via email and uses that email to create the account.

If we're successful, we'll send a 200 response.

app.post('/webhook', async function (req, res) {
  const stripeKey = await getStripeKey()
  const stripe = require('stripe')(stripeKey)
  console.log(stripeKey)

  const customer = await stripe.customers.retrieve(
    req.body.data.object.customer
  )

  const userEmail = customer.email

  const cognito = new aws.CognitoIdentityServiceProvider({ apiVersion: '2016-04-18' })

  cognito.adminCreateUser({
    UserPoolId: process.env.AUTH_STRIPEDEMO1C66A4D4_USERPOOLID,
    Username: userEmail,
    DesiredDeliveryMediums: [
      'EMAIL'
    ],

    UserAttributes: [
      {
        Name: 'email',
        Value: userEmail
      }],
    ValidationData: [
      {
        Name: 'email',
        Value: userEmail
      }
    ]
  }, function (err, data) {
    if (err) console.log(err, err.stack) // an error occurred
    else {
      console.log(data)
      res.sendStatus(200)
    } // successful response
  })
})

Now we need to trigger the Lambda function whenever a user completes a purchase. We'll first need the URL for the app. If you go into your aws-exports.js file which is in your src/ directory, you'll see an endpoint key. For example, mine looks like this "https://rw7cx5fyn3.execute-api.us-east-1.amazonaws.com/dev". Also, add /webhook to the end of the url, for example "https://rw7cx5fyn3.execute-api.us-east-1.amazonaws.com/dev/webhook".

Then, go into your Stripe Dashboard and click "Developers" on the left-hand navigation. Then click "Webhooks" under that. Click the "+ Add endpoint" button on the top right. Paste in your URL from above and then choose "payment_intent.succeeded" as the event to listen for.

Your event should work! Test out checkout again and then check your email for a login!

Now for the presentational code -- let's add a sign in form and then render some paywalled content once they are!

In your <SignIn> component, add the following React form that triggers Amplify's sign in method once submitted.

import { useState } from 'react'
import { Auth } from 'aws-amplify'

export default function SignIn ({ setUser }) {
  async function logIn (e) {
    e.preventDefault()
    try {
      const user = await Auth.signIn(username, password)
      setUser(user)
    } catch (error) {
      console.log('error signing in', error)
    }
  }
  const [username, setUsername] = useState('')
  const [password, setPassword] = useState('')
  return (
    <form onSubmit={logIn}>
      <input type='text' placeholder='username' onChange={e => setUsername(e.target.value)} />
      <input type='password' placeholder='password' onChange={e => setPassword(e.target.value)} />
      <input type='submit' value='log in' />
    </form>
  )
}

Now we'll finish up the App component! We'll create a user state attribute that is updated once the user signs in. We'll render paywalled content if the user is signed in, otherwise we'll show the sign in form.

import './App.css'

import Subscribe from './Subscribe'
import SignIn from './SignIn'
import { Auth } from 'aws-amplify'
import { useState } from 'react'

function App () {
  const [user, setUser] = useState(null)
  return (
    <div className='App'>
      <h1>My Fancy Subscription Site</h1>
      <Subscribe />
      {user
        ? <h1>Paywalled content!</h1>
        : <SignIn setUser={setUser} />}
    </div>
  )
}

export default App

If you want to take this demo down, you can run amplify delete to deprovision the cloud resources!

And we're done! In this tutorial we created a Stripe checkout system that triggers an account being created. Once signed in, a user can view paywalled content! If you have any feedback on AWS Amplify or this tutorial, please let me know!

Build a React App with Authorization and Authentication

Thu, 08 Jul 2021 00:00:00 GMT

In this tutorial, we'll be talking about authorization and how to implement it with AWS Amplify's DataStore. First, let's get on the same page with what authorization and authentication are:

Authorization - Different users have different actions that they can perform. Authentication - making sure someone is who they say they are, for example through making them enter a password.

This tutorial will be bypassing teaching React and AWS Amplify - check out this React tutorial and this Amplify Admin UI tutorial if you're new to either. You'll also need to know React Router.

I created a repo with some starter code in order to get to the relevant pieces of the tutorial. Go ahead and clone it down if you want to follow along. Run npm i within the cloned directory to get all the needed packages installed.

We'll be building a blogging platform with a frontend and backend authentication system with admin roles and certain actions restricted to content's creators. We'll first have blogs -- similar to Medium publications or Blogger blogs. Only admin users will be able to create new blogs, though anybody can view a list of the blogs. Blogs will have posts within them that anyone can view, but only the person who created the blog will be able to update or delete blogs.

Create a Blog using the Admin UI

First, we'll need to create the data models for our app. You can go to the Amplify Sandbox in order to get started. We'll create two models, a Blog and a Post. The Blog will be a publication that has a collection of Posts attached to it. The Blog will just have a name, and then Blog will have a title, and content. All fields will be strings, I also made name and title required fields. There will also be a 1:n relationship between the two models.

Now, go ahead and deploy your data models by following the guided process the Admin UI offers. Once it deploys, go into the Admin UI and create a few blogs and a few posts.

Then, we'll add authentication. In the Admin UI, click on "Authentication" tab and then configure auth. I deployed with the default options.

Once your authentication is deployed, add in authorization rules. First, click on the Blog model and on the right-hand panel, configure authorization. Uncheck create, update, and delete from under "Anyone authenticated with API Key can..." -- we'll allow anyone to view a blog but only admins to mutate them. Then, click the add an authorization rule dropdown. From here click "Create new" under "Specific Group", and name your group "admin". Allow admin users to perform all actions.

Now we'll configure authorization for posts. Select that model, and again change the permissions for "Anyone authenticated with API Key" to "Read" a post. Then toggle the "Enable owner authorization" to the on state. Under "Deny other authenticated users to perform these operations on an owner’s record:" select "Update" and "Delete" -- we want anyone to be able to read a post, but only the post's owner should be able to mutate existing posts. We also need to allow someone to be able to create posts! Under "add authorization rule" and then "Any signed-in users authenticated using" and then choose "Cognito".

Back in your code's directory, run Amplify pull with your app id -- you can find this command under "local setup instructions" in the Admin UI. If you're not using the cloned repository from above, install the Amplify JavaScript and React libraries.

$ npm i aws-amplify @aws-amplify/ui-react

You'll also need to configure Amplify in your index.js file so that your frontend is linked to your Amplify configuration. You'll also need to configure multi-auth within this step.

import Amplify, { AuthModeStrategyType } from 'aws-amplify'
import awsconfig from './aws-exports'

Amplify.configure({
  ...awsconfig,
  DataStore: {
    authModeStrategyType: AuthModeStrategyType.MULTI_AUTH
  }
})

Implement Authentication

First, we'll need to implement authentication for our site so that users can log in and different accounts can perform different actions. I created a <SignIn> component with a route to it. Then, add the withAuthenticator higher order component to implement a user authentication flow!

// SignIn.js

import { withAuthenticator } from '@aws-amplify/ui-react'
import React from 'react'

import { Link } from 'react-router-dom'

function SignIn () {
  return (
    <div>
      <h1>Hello!</h1>
      <Link to='/'>home</Link>
    </div>
  )
}

+ export default withAuthenticator(SignIn)

Then, we'll load all the blogs on to the home page of the app. I'm starting with the following code that will implement different routes for my app. If you're using the cloned boilerplate, you'll already have this in your code. You'll also want to create React components for BlogPage, PostPage, and BlogCreate -- these can just be empty components for now.

import './App.css'

import { Auth } from 'aws-amplify'
import { DataStore } from '@aws-amplify/datastore'
import { useEffect, useState } from 'react'
import { Switch, Route, Link } from 'react-router-dom'

import BlogPage from './BlogPage'
import PostPage from './PostPage'
import BlogCreate from './BlogCreate'
import SignIn from './SignIn'

import { Blog } from './models'

function App () {
  const [blogs, setBlogs] = useState([])

  return (
    <div className='App'>
      <Switch>
        <Route path='/sign-in'>
          <SignIn />
        </Route>
        <Route path='/blog/create'>
          <BlogCreate isAdmin={isAdmin} />
        </Route>
        <Route path='/blog/:name'>
          <BlogPage user={user} />
        </Route>
        <Route path='/post/:name'>
          <PostPage user={user} />
        </Route>
        <Route path='/' exact>
          <h1>Blogs</h1>
          {blogs.map(blog => (
            <Link to={`/blog/${blog.name}`} key={blog.id}>
              <h2>{blog.name}</h2>
            </Link>
          ))}
        </Route>
      </Switch>
    </div>
  )
}

export default App

In the <App> component, first import the Blog model.

import { Blog } from './models'

Then, create a useEffect which will be used to pull data to that component.

// create a state variable for the blogs to be stored in
const [blogs, setBlogs] = useState([])

useEffect(() => {
  const getData = async () => {
    try {
      // query for all blog posts, then store them in state
      const blogData = await DataStore.query(Blog)
      setBlogs(blogData)
    } catch (err) {
      console.error(err)
    }
  }
  getData()
}, [])

Then, we'll want to fetch the current user if there is one. We'll also want to check and see if that user is an admin.

const [blogs, setBlogs] = useState([])
+ const [isAdmin, setIsAdmin] = useState(false)
+ const [user, setUser] = useState({})

useEffect(() => {w
  const getData = async () => {
    try {
      const blogData = await DataStore.query(Blog)
      setBlogs(blogData)
      // fetch the current signed in user
+ const user = await Auth.currentAuthenticatedUser()
      // check to see if they're a member of the admin user group
+ setIsAdmin(user.signInUserSession.accessToken.payload['cognito:groups'].includes('admin'))
+ setUser(user)
    } catch (err) {
      console.error(err)
    }
  }
  getData()
}, [])

Finally, we'll want to render different information depending if the user is signed in or not. First, if the user is signed in, we'll want to show a sign out button. If they're logged out, we'll want to give them a link to the sign in form. We can do this with the following ternary:

{user.attributes 
  ? <button onClick={async () => await Auth.signOut()}>Sign Out</button> 
  : <Link to='/sign-in'>Sign In</Link>}

You can also add this snippet to make it so that admin users have a link to create a new blog.

{isAdmin && <Link to='/blog/create'>Create a Blog</Link>}

I added both lines to the home route for my site.

  <Route path='/' exact>
    <h1>Blogs</h1>
+ {user.attributes 
+ ? <button onClick={async () => await Auth.signOut()}>Sign Out</button> 
+ : <Link to='/sign-in'>Sign In</Link>}
+ {isAdmin && <Link to='/blog/create'>Create a Blog</Link>}
    {blogs.map(blog => (
      <Link to={`/blog/${blog.name}`} key={blog.id}>
        <h2>{blog.name}</h2>
      </Link>
    ))}
  </Route>

Here is the completed code for the App component.

Blog Page

Now, we'll implement the component that shows one blog. We'll first query to get the blog's information, then get the posts attached to it. In my app, I used React Router to create blog detail pages for each blog that follow the url pattern /blog/:blogName. I'll then use the :blogName to get all of that blog's information.

I'll start with a page that renders each post. I'll also add a button to create a new post, but only if there's a user:

import { DataStore } from 'aws-amplify'
import { useEffect, useState } from 'react'
import { useParams, Link } from 'react-router-dom'

import { Post, Blog } from './models'

export default function BlogPage ({ user }) {
  const { name } = useParams()

  const createPost = async () => {
  }

  return (
    <div>
      <h1>{name}</h1>
      {user && <button onClick={createPost}>create new post</button>}
      {
        posts.map(post => (
          <h2 key={post.id}>
            <Link to={`/post/${post.title}`}>
              {post.title}
            </Link>
          </h2>)
        )
    }
    </div>
  )
}

Then, I'll add this useEffect in order to load all the posts.

// body of BlogPage component inside BlogPage.js
  const [blog, setBlog] = useState({})
  const [posts, setPosts] = useState([])
  useEffect(() => {
    const getData = async () => {
      // find the blog whose name equals the one in the url
      const data = await DataStore.query(Blog, p => p.name('eq', name))
      setBlog(data[0].id)
      // find all the posts whose blogID matches the above post's id
      const posts = await DataStore.query(Post, p => p.blogID('eq', data[0].id))
      setPosts(posts)
    }
    getData()
  }, [])

Let's also add functionality to the "create new post" button that allows you to create a new post on click! The owner field will autopopulate with the current logged in user.

const createPost = async () => {
   const title = window.prompt('title')
   const content = window.prompt('content')

   const newPost = await DataStore.save(new Post({
      title,
      content,
      blogID: blog.id
    }))
}

Final code for the BlogPage component.

Blog Create

Let's also make it so that people can create a new blog. Inside of the <BlogCreate> component. First, create a standard React form that will allow a user to create a new blog.

import { DataStore } from 'aws-amplify'
import { useState } from 'react'

import { Blog } from './models'

export default function BlogCreate ({ isAdmin }) {
  const [name, setName] = useState('')

  const createBlog = async e => {
    e.preventDefault()
  }

    return (
      <form onSubmit={createBlog}>
        <h2>Create a Blog</h2>
        <label htmlFor='name'>Name</label>
        <input type='text' id='name' onChange={e => setName(e.target.value)} />
        <input type='submit' value='create' />
      </form>
    )
}

Now, implement the createBlog function by adding the following:

const createBlog = async e => {
  e.preventDefault()
  // create a new blog instance and save it to DataStore
  const newBlog = await DataStore.save(new Blog({
    name
  }))
  console.log(newBlog)
}

Finally, add a conditional around the form - we only want to render it if the user is an admin!

  if (!isAdmin) {
    return <h2>You aren't allowed on this page!</h2>
  } else {
    return (
      <form>
       ...
      </form>
    )
  }

Here's this component all together.

Post Page

Last component to implement! This one's the post detail page. We'll implement an edit form so that content owners can edit their posts. First, create a React form for the post. We'll again use React Router to send the name of the post to the component.

import { DataStore } from 'aws-amplify'
import { useEffect, useState } from 'react'
import { useParams, Link } from 'react-router-dom'

import { Post } from './models'

export default function PostPage ({ user }) {
  const { name } = useParams()

  const [post, setPost] = useState([])
  const [title, setTitle] = useState('')
  const [content, setContent] = useState('')

  const handleSubmit = async e => {
    e.preventDefault()
  }
  return (
    <div>
      <h1>{name}</h1>
      <form onSubmit={handleSubmit}>
        <label>Title</label>
        <input type='text' value={title} onChange={e => setTitle(e.target.value)} />
        <label>Content</label>
        <input type='text' value={content} onChange={e => setContent(e.target.value)} />
        <input type='submit' value='update' />
      </form>
    </div>
  )
}

Then we'll create a useEffect that will get the information about the post from DataStore and render it in the form. Note that this won't work well if you have two posts with the same name! In a larger-scale app you'd want to have some differentiator in the urls for each post.

useEffect(() => {
  const getData = async () => {
    const posts = await DataStore.query(Post, p => p.title('eq', name))
    setPost(posts[0])
    setTitle(posts[0].title)
    setContent(posts[0].content)
  }
  getData()
}, [])

Then, we'll need to implement the handleSubmit. We'll want to copy the original post, update the needed attributes and save them to DataStore.

const handleSubmit = async e => {
  e.preventDefault()
  await DataStore.save(Post.copyOf(post, updated => {
    updated.title = title
    updated.content = content
  }))
}

Finally, within the return, we'll only want to render the form if the user owns the post. Outside the form, add the following conditional to only render it if the post owner is that user! Amplify automatically creates the owner field for us. Every time that you create a new post, it will be populated for you too!

 {user.attributes && (post.owner === user.attributes.email) && (
   <form onSubmit={handleSubmit}>
   ...
   </form>
 )}

Here's the component's final code.

Conclusion

In this post, we use Amplify's DataStore multi-auth to implement different permissions based on the user's role and ownership of content. You could keep extending this with more forms, styling, and data rendering. I'd love to hear your thoughts on this app and this new Amplify feature!

Create a Fullstack Next.js App with Authentication, Data, and Storage

Thu, 08 Jul 2021 00:00:00 GMT

Next.js is one of my favorite tools for web development -- but it's a frontend framework. How can you build a fullstack application with it? In this tutorial, we'll build a Server-side Rendered Next.js app with a database-backed backend, static image storage, and authentication. It'll be National Park themed -- signed in users will be able to create new parks, and everyone will be able to view all added parks.

If you're new to Next.js, I wrote a tutorial on how to get started with it. If you're new to AWS Amplify, here's a tutorial on that as well!

Create your app Backend

First, create a new Next app:

npx create-next-app national-parks

Make sure you have the Amplify CLI installed, if not follow these instructions!

Then, initialize Amplify for your project. You should be able to accept the configuration it generates for you and then select your AWS profile or enter your access keys.

amplify init

Then we'll configure the needed services. First we'll add authentication.

amplify add auth

Answer the ensuing questions like so:

Do you want to use the default authentication and security configuration? Default configuration
How do you want users to be able to sign in? Username
Do you want to configure advanced settings? No, I am done.

Now we'll add storage to our app. Select the default configuration options for all questions other than who should have access -- there, give authenticated users access to all actions and unauthenticated users the ability to read data.

amplify add storage

? Please select from one of the below mentioned services: Content (Images, audio, video, etc.)
? Please provide a friendly name for your resource that will be used to label this category in the project: s37cd140d1
? Please provide bucket name: nationalparkbrowser248f6fd94d4f46f99a951df475e8
? Who should have access: Auth and guest users
? What kind of access do you want for Authenticated users? create/update, read, delete
? What kind of access do you want for Guest users? read
? Do you want to add a Lambda Trigger for your S3 Bucket? No

Finally we'll create an API. We'll select GraphQL and use an API key for authorization. Open up the GraphQL schema in your text editor.

amplify add api

? Please select from one of the below mentioned services: GraphQL
? Provide API name: nationalparks
? Choose the default authorization type for the API API key
? Enter a description for the API key:
? After how many days from now the API key should expire (1-365): 7
? Do you want to configure advanced settings for the GraphQL API No, I am done.
? Do you have an annotated GraphQL schema? No
? Choose a schema template: Single object with fields (e.g., “Todo” with ID, name, description)

If your schema.graphql file didn't open in your text editor, open it up. It will be under amplify/backend/api/nationalparks. There will be a sample GraphQL schema already in there, but we'll edit it to have the data format we need.

We'll create two models: S3Object and Park. Park will store our parks -- each park will have an id, a name, and an image. That image will reference an image stored in Amazon S3 (we created a bucket when we ran amplify add storage). The S3Object will have information about the image stored on S3 -- it's bucket, region, and key. We'll use the key to access the images in our app.

type S3Object {
  bucket: String!
  region: String!
  key: String!
}

type Park @model {
  id: ID!
  name: String!
  image: S3Object
}

Now run amplify push to deploy your resources to the cloud! You now have a fully deployed backend.

Install the Amplify libraries. These will allow us to use JavaScript helper code and React components to expedite our frontend development.

npm i aws-amplify @aws-amplify/ui-react

Once our backend is deployed, we'll need to link our frontend to our backend using Amplify.configure(). We'll use the configuration information in the src/aws-exports.js file that's automatically generated by Amplify and also make sure to set the ssr flag to true so that we can pull from our API on the server.

Add this to the top of your pages/_app.js:

import Amplify from 'aws-amplify'
import config from '../src/aws-exports'

Amplify.configure({ ...config, ssr: true })

Frontend Logic

Phew! Done with configuration code, now we can write our frontend React logic. Let's first create a form in order to create a new park. Create a file pages/create-park.js that will house a page that will render our form. Create a React component in the file.

// create-park.js
function CreatePark () {
  return <h1>Create Park</h1>
}

export default CreatePark

Then, we'll use the withAuthenticator higher-order component to require sign in before going to the /create-park page. It will also enable sign up and require account confirmation.

// create-park.js
import { withAuthenticator } from '@aws-amplify/ui-react'

function CreatePark () {
  return <h1>Create Park</h1>
}

export default withAuthenticator(CreatePark)

Now we'll create a React form where a user can input the name of the park and an image.

// create-park.js
import { useState } from 'react'
import { withAuthenticator } from '@aws-amplify/ui-react'

function CreatePark () {
  const [name, setName] = useState('')
  const [image, setImage] = useState('')

  const handleSubmit = async () => {

  }

  return (
    <form onSubmit={handleSubmit}>
      <h2>Create a Park</h2>
      <label htmlFor='name'>Name</label>
      <input type='text' id='name' onChange={e => setName(e.target.value)} />
      <label htmlFor='image'>Image</label>
      <input type='file' id='image' onChange={e => setImage(e.target.files[0])} />
      <input type='submit' value='create' />
    </form>
  )
}

export default withAuthenticator(CreatePark)

Finally, we'll implement the handleSubmit function which will upload the user's image to S3 and then store our newly created park in our data base using our GraphQL API. We'll import the configuration information from the aws-exports.js again and one of the GraphQL mutations that Amplify generated in the src/graphql directory.

Then, we'll upload the image using Storage.put() with the image's name as the key and the image itself as the value. Then, we'll use API.graphql to run the graphQL mutation with the user's inputted data and configuration information about the S3 bucket.

// create-park.js
import { useState } from 'react'
import { API, Storage } from 'aws-amplify'
import { withAuthenticator } from '@aws-amplify/ui-react'

import { createPark } from '../src/graphql/mutations'
import config from '../src/aws-exports'

function CreatePark () {
  const [name, setName] = useState('')
  const [image, setImage] = useState('')

  const handleSubmit = async e => {
    e.preventDefault()
    // upload the image to S3
    const uploadedImage = await Storage.put(image.name, image)
    console.log(uploadedImage)
    // submit the GraphQL query 
    const newPark = await API.graphql({
      query: createPark,
      variables: {
        input: {
          name,
          image: {
            // use the image's region and bucket (from aws-exports) as well as the key from the uploaded image
            region: config.aws_user_files_s3_bucket_region,
            bucket: config.aws_user_files_s3_bucket,
            key: uploadedImage.key
          }
        }
      }
    })
    console.log(newPark)
  }

  return (
    <form onSubmit={handleSubmit}>
      <h2>Create a Park</h2>
      <label htmlFor='name'>Name</label>
      <input type='text' id='name' onChange={e => setName(e.target.value)} />
      <label htmlFor='image'>Image</label>
      <input type='file' id='image' onChange={e => setImage(e.target.files[0])} />
      <input type='submit' value='create' />
    </form>
  )
}

export default withAuthenticator(CreatePark)

If you want, here are a few lines of CSS you can paste into the styles/globals.css file to make the app look a little more presentable.

amplify-s3-image {
  --width: 70%;
  overflow: hidden;
  margin: 0 auto;
}

.container {
  max-width: 1000px;
  margin: 0 auto;
  padding: 0 2rem;
  text-align: center;
}

.img-square img h2 {
  margin: 0 auto;
  text-align: center;
}

Finally, we'll list all of the parks on the index page. We'll use the listParks graphql query that was generated in src/graphql/queries.js to fetch the parks and the AmplifyS3Image component to render the images on the page. We'll fetch the parks on the server-side so that our app will dynamically update when new parks are added.

import Head from 'next/head'
import { withSSRContext } from 'aws-amplify'
import { listParks } from '../src/graphql/queries'
import { AmplifyS3Image } from '@aws-amplify/ui-react'
import Link from 'next/link'

export async function getServerSideProps () {
  const SSR = withSSRContext()
  const { data } = await SSR.API.graphql({ query: listParks })
  return {
    props: {
      parks: data.listParks.items
    }
  }
}

export default function Home ({ parks }) {
  return (
    <div>
      <Head>
        <title>National Parks</title>
      </Head>
      <div className='container'>
        <h1>National Parks <Link href='/create-park'>(+)</Link></h1>
        <div className='img-grid'>
          {parks.map(park => {
            return (
              <div key={park.id} className='img-square'>
                <h2>{park.name}</h2>
                {/* use the AmplifyS3Image component to render the park's image using its S3 key */}
                <AmplifyS3Image imgKey={park.image.key} height='200px' />
              </div>
            )
          })}
        </div>
      </div>
    </div>
  )
}

Frontend Deployment

Now our app has a complete frontend! Let's deploy it via Amplify hosting. Push your code to a GitHub repository, then open up the Amplify Console for your app. Click on the frontend environments tab and then the connect app button. Choose your repository, use the auto generated configuration, and save and deploy. It'll take a few minutes and then your app will be live!

No extra configuration is needed, Amplify will infer that you're creating a SSR Next.js app and deploy the needed hosting resources for your app. Here's more information if you're interested!

Cleanup

You may not want to keep the app deployed, in which case you can click the delete app button in the AWS console or run amplify delete from your command line. This will de-provision your backend resources from your AWS account!

AWS Amplify allows you to make your Next.js app fullstack with data, image storage, and authentication without having to have heavy knowledge of the cloud or fullstack development.

Deploy a Next.js App to AWS Amplify

Wed, 19 May 2021 00:00:00 GMT

AWS Amplify just announced server-side rendering deployment support for Next.js! Here's a quick guide on how to deploy both an SSR and an SSG Next.js app.

Note: if you're new to Next.js check out this tutorial!

SSG

For a statically generated Next.js app, you'll first need to edit your package.json file. You'll need to change your build to next build && next export instead of just next build.

"scripts": {
  "dev": "next dev",
+  "build": "next build && next export",
  "start": "next start"
},

SSR

You don't need to change anything in your package.json for a server-side rendered app! Just keep the one that was generated by create-next-app.

Hybrid SSG + SSR

If you have an app with both SSR and SSG pages, also keep the default package.json, same as a fully SSR app!

For Both

Then, create a repository on your git provider of choice, and push your code to it.

Create an AWS account if you don't already have one.
Navigate to the Amplify Console
Click on the orange connect app button.
Choose GitHub in the From your existing code menu, and click continue

Type in the name of your GitHub repo you just created (it should autofill!) and then click next

The build settings will auto-populate, and so you can just click next on the Configure build settings
Click Save and deploy.

Pricing

Behind the scenes, Amplify creates AWS resources used to deploy your app -- first an Amazon S3 bucket to store your app's static assets, then an Amazon CloudFront to serve your app itself, finally a Lambda@Edge function to SSR pages. The links to each service in this paragraph leads to info about the pricing for it.

Multi-branch Deployments

In order to deploy multiple branches to AWS Amplify, you can click the orange "Connect branch" button on the Amplify Console page for your app. So, if you want to test deployments of features before they go live to the main branch, you can do so in clicks!

Pull Request Previews

You can also enable automatic pull request preview deployments. This will enable Amplify to deploy a preview of each pull request to a project so that you can click a link and see what the pull request does to the site!

First click on previews on the left side bar.

Then, click Enable previews.

Add a Custom Domain

You can also connect your domain name to your site by visiting Domain management and then add domain -- you'll see instructions for different domain providers or be able to buy one through Amazon Route53.

Conclusion

These are just some of the things you can do when you deploy an app to AWS Amplify Hosting! There are also ways to add testing, monitoring, custom headers, access control and more. I hope this guide was helpful for those of you looking to deploy a Next.js app to Amplify.

A Complete Beginner's Guide to Next.js

Wed, 19 May 2021 00:00:00 GMT

I've used Create React App non-stop to scaffold React apps, and I love it. Recently, though, I've been using Next.js for more and more of them. It has a bunch of great features like routing and server-side rendering that offer amazing experiences for both end-users and developers.

Next.js is a React metaframework, which means that it's a framework built on top of React that enforces more structure and gives you additional capabilities: like server-side rendering, routing, bundling, and more. In this post, we'll go through how to get started with Next.js, SSR vs. SSG, and routing.

If you haven't used React before, read my getting started with React tutorial and then come back here to do this tutorial! You'll need a React foundation first.

Create a Next.js App

We're going to create an app that lists colors on the home page. Each one links to a color page that displays that color's information!

First, we'll initialize a Next.js app using the CLI. This works like most app initialization scripts where it generates a bunch of starter files for you.

$ npx create-next-app color-pages
$ cd color-pages

Then, we'll start the development server -- it has hot reloading built-in and links to the docs on the generated home page.

$ npm run dev

Now, we can start writing code! We're going to create a static json file with the colors first. Create a directory for the colors, then add a colors file inside. Then add the colors!

mkdir data
touch data/colors.json

I used a bunch of Pantone colors of the year to create this one, feel free to copy it! If you make your own, make sure to use this structure so the rest of the code works.

// data/colors.json
[
  { "name": "Illuminating", "hex": "#F5DF4D" },
  { "name": "Classic Blue", "hex": "#0f4c81" },
  { "name": "Living Coral", "hex": "#FA7268" },
  { "name": "Ultra Violet", "hex": "#5f4b8b" },
  { "name": "Greenery", "hex": "#88b04b" },
  { "name": "Rose Quartz", "hex": "#F7CAC9" },
  { "name": "Marsala", "hex": "#B57170" },
  { "name": "Radiant Orchid", "hex": "#b067a1" }
]

Routing

Now, we'll work on the color pages. With Next.js, if you create a file within the pages folder, it makes that into a route. So, you could create about.js to get a /about page -- the exception in index.js which routes to /. You can make folders to create routes like /blog/my-post-title too. If you put the file name in [], then the name inside the brackets becomes a parameter name. We want to create routes for each color in our array above, so we will create a file called [color].js -- this will allow us to dynamically create a page for 'Classic Blue', 'Ultra Violet', etc. all at one -- no need to create a separate .js file for each one.

$ touch pages/[color].js

getStaticPaths

Now, let's create our getStaticPaths() function. Next.js looks for this function in order to generate all the static pages for that template -- in our case our colors. We want to build a page for each of our colors following the same format but without having to hardcode each page.

First, will import our colors array. Then, inside our function, we'll loop through them and name the route params for each. In this case, our route parameter is color to match the parameter name inside of the [] in our file name. We want the color in our route to match each color name -- so /Marsala will render the page that displays Marsala!

Finally, we'll return all of our colors in the format that Next.js is looking for. We'll put them in an object with fallback set to false -- this will make it so that if you go to /hotpink (a color not in our array) you'll get a 404 page!

// [color].js
// import the colors array
import colors from '../data/colors.json'

export async function getStaticPaths() {
  // loop through the colors array
  const paths = colors.map(color => ({
    // return an object with params.color set to the color's name
    params: { color: color.name }
  }))

  // Paths will look like this:
  // [
  //   { params: { color: 'Marsala' } },
  //   { params: { color: 'Illuminating'} }
  //   ...
  // ]
  return { paths, fallback: false }
}

In most larger use cases, you may want to read files from your file system (such as markdown files for blog posts) or fetch data from an external API. You could do either task within getStaticPaths to generate paths for your app.

getStaticProps

Now, we'll define the getStaticProps function which Next.js is looking for. This function will provide props to the React component for the page. In our use case, we'll want just the information about the color on the current page. So, the page for /Marsala gets the data { "name": "Marsala", "hex": "#B57170" } -- not all the other colors!

The getStaticProps function gets the params passed to it, in our case the color name. For the page /Marsala params would look like { color: 'Marsala' } -- just like we created in the getStaticPaths function. In our case, we'll find just the color in our array whose name matches the color in the params. Then we'll return the data -- Next.js requires the return to be nested within { props }.

// [color].js
export async function getStaticProps({ params }) {
  // find the info for just one color
  const color = colors.find(color => color.name === params.color)
  // return it in the necessary format.
  return { props: { color } }
}

Within a larger app, you may pull from an API in getStaticProps in order to get the information about one item, or you may need to fetch just one markdown file to render a blog post.

Template the Page

Now we're on to the fun part! Creating the React component to template the page! The props object we created in getStaticProps will be passed to the component by Next.js -- we just need to render the data on the page! We'll use the hex code to add a background color to the page, and render the color name.

// [color.js]
export default function Color({ color }) {
  return <div className='color-page' style={{ backgroundColor: color.hex }}>
    <h1>{color.name}</h1>
  </div>
}

I replaced the CSS file with the following to make the page look a little better.

/* global.css */
html,
body, #__next, .color-page {
  padding: 0;
  margin: 0;
  height: 100%;
  width: 100%;
  top: 0px;
  position: absolute;
  display: block;
  font-family: -apple-system, BlinkMacSystemFont, Segoe UI, Roboto, Oxygen,
    Ubuntu, Cantarell, Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
}

.color-page {
  display: flex;
  justify-content: center;
  align-items: center;
}

Link Component

Now, all we need to do is use the Link component to link to each color's page from the home page. We'll update index.js with the list of colors.

We'll use two Next.js specific components in this Home component -- Link and Head. <Link> allows you to do client-side route transitions, which will make page transitions smoother for users. We'll use it in place of and otherwise just like an a tag.

The <Head> component allows us to insert data into the html head tag from within the component. We'll update the page title and meta tags from there!

// index.js
import Head from 'next/head'
import Link from 'next/link'

import colors from '../data/colors.json'

export default function Home() {
  return (
    <div>
      <Head>
        <title>Colors!</title>
        <meta name="description" content="App that displays pretty colors to learn Next!" />
      </Head>
      {colors.map(color => (
        <Link href={`/${color.name}`}>
        <h2>{color.name}</h2>
        </Link>
      ))}
    </div>
  )
}

SSR vs. SSG

We just built a statically generated Next.js app -- what that means is data is only fetched at build time. If our colors were coming from an API and we had our site built and deployed, our app would not update with any API changes (say the 2022 color of the year was added). For many apps this is totally fine! A blog doesn't need to update too often with content.

SSG (static site generation) allows Next.js to generate HTML for each page when the site is being built. Those pages can then be cached by a CDN and lead to a super performant site.

That being said, sometimes you need a site that updates dynamically, and that's where server-side rendering comes in. SSR (server-side-rendering) allows you to still render HTML on the server-side but do that for each request made by a user to the page instead of at build time.

In order to use SSR instead of SSG, we would replace our getStaticProps and getStaticPaths with just getServerSideProps. Note that the below example will not work because we did not actually create an API!

export async function getServerSideProps({ params }) {
  // Make a request to get data about the color via our API
  const res = await fetch(`http://www.color-api.com/${params.color}`)
  const color = await fetch.json()
  // return the data as props that will be passed to the Color component
  return { props: { color } }
}

If you want to read more about SSR vs. SSG, I have a full blog post about the difference!

Deployment

Now that you have a Next.js app written, you need to get it live online. AWS Amplify supports deploying both SSR and SSG Next.js apps without any additional configuration on your end.

If you're creating a statically generated Next.js app, go to your package.json file and change your build script to next build && next export. If you're instead creating a server-side rendered app, you don't need to change a thing! The scripts Next.js generated for you will be what you need.

"scripts": {
  "dev": "next dev",
+  "build": "next build && next export",
  "start": "next start"
},

Then, create a repository on your git provider of choice, and push your code to it.

Create an AWS account if you don't already have one.
Navigate to the Amplify Console
Click on the orange connect app button.
Choose GitHub in the From your existing code menu, and click continue

Type in the name of your GitHub repo you just created (it should autofill!) and then click next

The build settings will auto-populate, and so you can just click next on the Configure build settings
Click Save and deploy.

Conclusion

Next.js has an amazing developer experience. It has great error messages, comprehensive and understandable documentation, and is super powerful for just a little bit more work than a normal React app. I hope this tutorial was helpful!

Breaking Down the Acronyms: SSR vs. SSG

Wed, 19 May 2021 00:00:00 GMT

Acronyms are always fun -- they're helpful for reducing the effort of saying out a full long-winded technical term, but they can also look like alphabet soup and be really confusing to newbies! I want to use this post to explain two terms that are often seen in tandem and start with the same two letters, but are pretty different concepts. Static Site Generation (SSG) and Server-Side Rendering (SSR) are both (back to being) hot topics in web development, but what are they? And why are they so widely talked about?

SSG

Static-site generators enable developers to create many pages all at once using templates with content plugged into them. For example, you may have a blog page for your application, each one has a header, title, the author's name and image, and the content itself all using the same layout from post to post. You don't want to code a new HTML page for each blog post. Instead, each blog post could be written in a markdown file and then plugged into the correct template format so that each web page is standardized using a static-site generator. This pattern is much faster for the developer than writing out an HTML boilerplate for each web page. The site is generated at build time meaning that you have a script that plugs every single piece of content into a template generating the HTML needed to properly render the page.

This is awesome for performance -- whenever the user goes to the page they are served a static HTML page -- the data is already plugged in and won't need to be plugged in by the server. BUT there's a catch -- since the process is done at build time, the site must have the build script re-run and re-deployed whenever you want to make changes. Say you write a new blog post, you'd need to re-build and re-deply the site. There are ways to automate this, like web hooks, but it's still not as flexible as a dynamically generated site.

SSR

Server-side-rendering has been a common pattern in web development for years. Frameworks like Ruby on Rails and Django used it to dynamically populate HTML templates with variable content. If the user navigated to /blog-post/2, for example, the server-side logic would plug the correct title, content, and author information into an HTML page and then send that back to the user. So, with SSR, the templating process happens at the time of the request instead of on build.

This pattern fell out of favor as more logic got pushed to the client side, and front-end frameworks became more predominant. That being said, server-side rendering still has many benefits, such as end user performance since JavaScript can be used much more minimally. Also, search engines often struggle with parsing JavaScript generated web-pages.

Recently, more JavaScript libraries have swung back in the server-side-rendering direction, Next.js being one of the most notable! That being said, React has also discussed adding server-side rendered components directly within the library itself.

With these modern web frameworks, you get the developer experience that comes with a library like React, but you can serve HTML to your end user giving them a potential performance boost.

Conclusion

I hope this blog post helped to break down the differences between SSR and SSG and when you would use each in your app! In one sentence, SSR fetches data when the user requests the content, and SSG fetches data when you build a site.

How I Manage my Life with Trello

Tue, 04 May 2021 00:00:00 GMT

Like many things, productivity systems are deeply personal and subjective. But, I've learned so much from other people's posts on their systems (like Andreas Klinger's email system) that I thought I would post my daily Trello setup in the hopes it may help someone else feel more in control of their routine.

My whole system is inspired by Atomic Habits and Tiny Habits -- having instant gratification whenever I complete a task and making habits and routines mindless by autopopulating them on my todo list is so helpful. I try to put as much into routines as possible so that I can habitually get things done each day, both for myself and for my job.

I have a lot to manage, between managing a team, speaking events, creating content, and my life outside of work. I use Trello as my personal dashboard to manage all of it.

I also have a more general post if you want to read more about my thoughts on productivity.

The Columns

I have columns setup within Trello to store different categories of information. The first column is "Today" which lists all the things I need to work on that day. I then have "Tomorrow" which works like "Today" except for the next day. Then there's "This Week" which stores all the things I need to do that week. These are relatively straightforward, and I'll dive into the types of cards that I use later in this article. In the morning, one of my tasks is to organize the cards for the day, so I move cards around as needed.

Then, I have "Waiting." This stores tasks I'm waiting on others to complete or that I'm blocked on for some reason. Often I'm waiting for a clarifying email before working on the task, but I even put laundry when it's in process on there!

Then, I have the "Affirmations" column. This stores motivational quotes and inspiration. I normally create these in Canva from quotes I run across while reading or elsewhere! I like seeing these positive messages whenever I look at my todos.

Then, I have the "Done!" column. This stores completed tasks, and I archive all cards on it each week. I also have some automations set up to give me a checkmark sticker and remove due dates on cards when they're moved to "Done!"

Then, I have the "Inbox" column. This stores all untriaged notes and future todos. So, todo list items that won't be done this week, or loose ideas that I haven't cleaned up yet.

Then comes "Ideas." These are normally things that I'm working on, feedback people have given me recently that I'm working on, high level notes for myself, etc.

After that, I have a "Take Notes" column. This contains other peoples' content that I want to read or watch but haven't had time to yet. I normally make time to watch a conference talk length video at lunch each day, and I pull those from here and take notes while watching!

Finally, I have a "Content ideas" column which contains topics for blog posts and YouTube videos which I haven't gotten to yet. I write these ideas down as I have them so that I don't get writers block when I'm trying to think of a new content idea.

Cards

I have cards for most of the things I need to do everyday, from meetings to speaking events, to tasks. For larger tasks, I have checklists to break up subtasks.

For meetings, I beforehand write any notes or discussion points I have. Then during the meeting, I write down on the same card any action items or notes that I have. I then organize those after the fact.

Repeating Cards

I have routine cards that autopopulate on my "Today" column every day. Right now these include:

Morning Routine
Start of Workday
Lunch
Dinner
Bedtime

There are certain things I need to do everyday at these times. I use "Repeats" to generate these cards. They all have checklists for the things I need to do at these times! If you're interested in the things in these lists, let me know and I can write another blog post on that.

I also have other recurring todos that autopopulate.

I use cards for both work and personal tasks -- I like keeping everything in one place.

Templates

I also have card templates for types of content. There are certain actions I need to do every time I film a YouTube video, for example. So, I have a checklist that I copy for each video -- Trello has a really nice interface for this workflow where you can have template cards.

Labels

I have labels for different categories of tasks, like types of content, and how much energy a task will take. This helps me to visually organize tasks and take care of tasks when I have the energy for them. I also have a "me" label for prioritizing self-care tasks like meditation and working out.

Conclusion

Again, productivity systems are deeply personal and what works for me may not work for you; however, this helps me to keep me on track, productive, and not overwhelmed. I can have all of the things I need to do in one place as my personal dashboard.

Building an Offline-Ready Form With Vanilla JavaScript

Mon, 19 Apr 2021 00:00:00 GMT

I recently had a conversation with some colleagues about whether I as a web developer often needed to have data available both offline and online. My initial answer was no, I couldn't think of many instances of needing offline data other than an offline page for a progressive web app I worked on. On further prompting, I realized I had implemented offline data patterns in more instances than I'd thought -- namely in creating forms that autosave with an offline fallback.

Having an autosave fallback is an increasingly common pattern in forms that require a lot of writing, like GitHub issues and blog editors. I have closed a tab or accidentally refreshed a form to lose fifteen minutes of work many times in my life, and it's annoying to say the least. This comes even more into play for people in areas without consistent internet or cell service, they may flicker on and offline and need to have their data persisted even if they lose internet. In certain circumstances such as medical systems, finance, and mining data loss could have dire consequences.

In this tutorial, we'll be building an online offline note editor. When a user exits the page, their partially completed form data will be saved and load back into the form automatically when they come back to the page. We will differentiate between the post loaded into the editor and the completed notes by flagging the in-progress Note as a draft. Here is the completed code for the tutorial.

Normally, this is implemented through storing data in localStorage on page exit. LocalStorage’s API is developer-friendly, in large part because it’s synchronous, and it saves data across browser sessions. So the user has one draft stored per device, which is great for simple use cases, but it becomes very complex very fast if the user updates data via another device -- which version of the data loads for them? The offline/online data problem is more complex than initially one might think: you're essentially creating a distributed system. You're using localStorage for some data and your database for the rest of it. Also, there are limits to how much data localStorage can store and its synchronicity blocks the main thread.

When you have distributed data, the CAP theorem comes into play, which states that a system can only have two out of the three: partition tolerance, consistency, and availability. Partition tolerance means that a system continues to run if there are outages, availability means that every request gets a response on success or failure, and consistency means that all replications have the same data at the same time. For an app with a frontend, partition tolerance is a necessity: you have one server and a client or two partitions at the very minimum. We also have already stated that we want our data available online and offline. So, full consistency is the branch sacrificed and "eventual consistency" is enacted instead.

Eventual consistency can make the programming logic more difficult for developers. When you create data and it’s successful, you want to get that data back in your query. If you need to account for situations where you get stale data back this can easily introduce bugs, leading to a poor experience for app users. In this tutorial, we'll use AWS Amplify DataStore which handles these merging issues for us.

With our offline/online editor, when the user goes offline, there will be different local and global data until the user goes back online. It's local first which means when you run a query or mutation on data you'll first update data in IndexedDB, the default DataStore on-device storage engine. It's similar to localStorage but allows for much more data and asynchronous updating in exchange for a more complex API, which we won’t need to worry about since we are using DataStore to abstract it away. Then, if you enable online storage your data will sync to your AWS database of choice, which defaults to DynamoDB.

Create a data model

First, we'll create a data model using the Amplify Admin UI.

Head to https://sandbox.amplifyapp.com and then click Get started under Create an app backend
Select Data as the feature to setup, and choose start with a blank schema.
On the top left, click model.
Name the model "Note".
Add the fields title, draft and body.
Select title and draft and then click required on the right hand menu.
Set the type of draft to boolean.

Then, click the "Next: Test locally in your app" button. Note that you don't need to have an AWS account to test this out, you'll only need one if you choose to deploy a database in the future.

Create a project

Now, we'll create a frontend app for our project. There's instructions on that page for various types of applications, but we'll ignore these and create our own since we won't be using a framework for this application. Click "next" twice.

If you'd like to follow along, I normally use this starter template. You do need a development server to work with Amplify since it uses ES Modules and DataStore requires a TypeScript transpiler, so it isn't as simple as creating an HTML file.

Then, use the generated commands to install the Amplify CLI and to pull the data model into your application. Note that you will need to use your individual sandbox id, which is in the generated command on step 3 on the "Test locally in your app" page.

$ curl -sL https://aws-amplify.github.io/amplify-cli/install | bash && $SHELL 
$ amplify pull --sandboxId your-sandbox-id

Then install the aws-amplify JavaScript library and TypeScript.

$ npm i aws-amplify typescript

Now, configure Amplify in your JavaScript file:

import { Amplify, DataStore } from 'aws-amplify'
import awsconfig from './aws-exports'

import { Note } from './models'

Amplify.configure(awsconfig)

We'll also import the Note model for future use.

Create a form

First, create a form in your HTML file to allow a user to create a new note. We'll just include the title and body fields. The draft field will be managed just in our code, not by the end user.

<form class="create-form">
   <label for="title">Title</label>
   <input type="text" name="title" id="title">
   <label for="body">Body</label>
   <textarea type="text" name="body" id="body"></textarea>
   <input type="submit" value="Create">
</form>

We'll also need to create a new Note object when the form is submitted. We'll add an event listener to it, and then create a new note in DataStore which captures the user's inputted title and body. Since it's submitted, it won't be a draft.

document.querySelector('.create-form').addEventListener('submit', async e => {
   try {
     e.preventDefault()
     const title = document.querySelector('#title').value
     const body = document.querySelector('#body').value

     const newNote = await DataStore.save(
       new Note({
         title,
         body,
         draft: false
       })
     )
     console.log(newNote)
   } catch (err) {
     console.error(err)
   }
})

Create an empty draft

So far we've created a standard form that saves our new note on form submission. Now, we need to add in the autosave functionality.

How this is going to work is that we'll always have one note that's a draft. When the page loads, we'll query DataStore to see if a draft exists. If it does, then we'll load its title and body into the form as the starting point. If one doesn't exist, then we'll create a new empty draft note that will be saved when the person exits the page.

When the page loads, we'll query DataStore to find notes that are drafts using DataStore's query language. We'll also create a variable to store the current draft the user is working on.

let draft = {}

window.addEventListener('load', async () => {
  const drafts = await DataStore.query(Note, note => note.draft('eq', true))
})

We'll also create a function that makes a new blank draft. This will set that global draft variable to a new blank draft note.

async function createNewDraft () {
  try {
    draft = await DataStore.save(
      new Note({
        title: '',
        body: '',
        draft: true
      })
    )
  } catch (err) {
    console.error(err)
  }
}

Now, we'll add a conditional that checks to see how many drafts there are. If there's more than one, we'll want to throw an error -- this should never happen.

If there isn't currently a draft in DataStore, we'll need to create a new one. If there is a draft, then we'll update the tile and body in the form with the current draft's information.

let draft = {}

window.addEventListener('load', async () => {
  const drafts = await DataStore.query(Note, note => note.draft('eq', true))
  if (drafts.length === 0) {
    createNewDraft()
  } else if (drafts.length === 1) {
    draft = drafts[0]
    document.querySelector('#title').value = draft.title
    document.querySelector('#body').value = draft.body
  } else {
    alert('weird! you have multiple drafts!')
  } 
})

Fill the draft on page exit

Now that we have a draft, we want to automatically save that draft whenever the user navigates away from the page or refreshes the tab. We'll add an event listener to the page that listens for the beforeunload event.

DataStore.save() is used for both create (which we've used previously) and for update. In order to update a currently stored Note, we'll create a copy of it and update the attributes we want to change.

window.addEventListener('beforeunload', async () => {
  try {
    const title = document.querySelector('#title').value
    const body = document.querySelector('#body').value
     
    await DataStore.save(Note.copyOf(draft, updatedNote => {
      updatedNote.title = title
      updatedNote.body = body
    }))
  } catch (err) {
    console.error(err)
  }
})

Submit the form

We're almost there! The final step needed is to change the submission function for the form. Instead of creating a new note, we'll modify our draft note with the form title and body and then set draft to false.

document.querySelector('.create-form').addEventListener('submit', async e => {
  try {
    e.preventDefault()
    const title = document.querySelector('#title').value
    const body = document.querySelector('#body').value

    const newNote = await DataStore.save(Note.copyOf(draft, updatedNote => {
      updatedNote.title = title
      updatedNote.body = body
      updatedNote.draft = false
    }))

    console.log(newNote)
  } catch (err) {
    console.error(err)
  }
})

We'll also need to create a new blank draft so that the user can start typing a new note. We'll also need to reset the form.

document.querySelector('.create-form').addEventListener('submit', async e => {
  try {
    e.preventDefault()
    const title = document.querySelector('#title').value
    const body = document.querySelector('#body').value

    const newNote = await DataStore.save(Note.copyOf(draft, updatedNote => {
      updatedNote.title = title
      updatedNote.body = body
      updatedNote.draft = false
    }))
    console.log(newNote)
+   createNewDraft()

+   document.querySelector('#title').value = draft.title
+   document.querySelector('#body').value = draft.body
  } catch (err) {
    console.error(err)
  }
})

Deployment

Right now with the test version of the app, we're just storing data locally on the device instead of syncing it to a cloud database. In order to enable the online/offline sync, you can go back to the sandbox in the browser and deploy your backend. You don't need to do anything else in your code other than re-run Amplify pull to get the link to your database.

There’s a lot more that can be done for this editor as well. In a production use case, you'd want to have users that each have a draft instead of one global draft that's loaded into the editor. You also may want to tweak the collision rules for what happens, for example, if the user edits data on another device before they come back online.

Another potential feature could be saving each draft version. A possible implementation would be to store one Note parent model that has multiple child Versions. Each Version would have an order number attached to it so that they could be accessed sequentially. The final version would also have a published flag to differentiate it. There are many ways you could change this pattern to fit a more complex use case.

Conclusion

Autosave forms and apps that have data available even when offline helps to assuage user annoyance and leads to better experience for users in areas with spotty internet and mobile connection. Having a performant offline available app is important for global accessibility. Amplify DataStore helps enable this in applications without a large developer lift.

The Case for Lower Code

Wed, 24 Mar 2021 00:00:00 GMT

Many developers don't like the idea of low or no code, yet they use tooling to dramatically lower the amount of code they need to write. They're hesitant about graphical user interfaces, yet live in Visual Studio Code which has had widespread success due to its visual interface.

Let's first discuss what low code, no code, and full code are and their strengths and weaknesses and then I'll go all thought leader and give my thoughts on their future: what will make them successful and why developers should embrace these tools.

No Code

First off, no code. No code is when you build an application with, as the name implies, no traditional code. You instead use a graphical user interface where you click, drag, or fill out a form to build websites, apps, or automation flows. Some examples of no code tools include Squarespace, Notion, and Zapier.

These tools are great for building something that fits within what features they support, but if you want to create something custom or go outside their boundaries, it isn't really possible. They are great for their purpose: allowing non-coders to build quickly, but they are limited in customization and scaling.

Full Code

I'm a software engineer, so my career has focused on building full code solutions to problems. Code is when you give a computer a sequence of written instructions and the computer executes those commands. You use a programming language, like Python, Java, or JavaScript to do this.

This means the product built is completely custom, or at least that was true historically. You can build whatever features you want or need. Scalability and extensibility are possible with full code solutions.

That being said, code is difficult and expensive. Programming is a career and takes a long time to learn. One person most likely won't be able to be the sole developer on a large-scale application, and developers are a relatively high paid role. Plus code needs to be maintained and updated, which means even more time and money over time.

Low Code

Low code is a hybrid of these two types of solutions -- it falls somewhere in between no code and full code. So, maybe you scaffold an application using a graphical user interface instead of traditional code, but then you can extend that application using code to make all the extra features you need.

That being said, developers are often hesitant about low code solutions, and for good reason. Historically, many of these tools have thought of developers second and so the code was poor quality and the interfaces were clunky.

Second, I think developers fear that low code will make their jobs irrelevant. I think this is misguided: first these solutions are backed by code and extended by code. Code isn't going away anytime soon, and in the best case scenario low code will just make the annoying parts of our job less annoying.

The line between low and no code is often blurred and pedantic. In fact, tools I would personally categorize as low code brand themselves as no code. I mostly agree with this post by Shawn Wang: the categorization doesn't really matter.

The Lower Code Evolution

Code has already evolved to be a lot lower code than it originally was. You used to have to write all the code for an application from scratch, which is no longer the case.

When you start a Ruby on Rails app, thousands of lines of code are pre-written for you, and you can famously build something useable in 15 minutes. Ruby on Rails depends on "convention over configuration" which essentially means that trades developer decision making for increased productivity. If you follow the framework, you to write less code in return.

In addition, you can use a Gatsby or Next.js template to have a full app you only need to tweak or add features to. There are also managed services that can be used to add something like authentication or comments to your application in a few clicks and a few lines of code.

Most developers embrace these solutions in part because the amount of self-written code is much less than you historically needed. These tools prioritize developers as part of the solution instead of attempting to go around them. They meet developers where they're at.

Serverless has also done something similar for the cloud computing industry -- you no longer need to jump through hoops or be a DevOps engineer to get an application deployed in a scalable way. Tools like AWS Amplify and the Serverless Framework enable frontend developers to build full-stack cloud apps without having to know a ton about infrastructure or a secondary backend language. Serverless doesn't actually mean no servers, it just means that the server is mostly abstracted away from the developer, making their jobs easier and safer.

But, low code attempts to expand who can build software: non-coders are comfortable in different environments than coders. Teaching a new developer how to use a CLI instead of a GUI is a large task. At first it feels much more difficult to use a CLI. But most developers feel more productive inside a CLI -- it is faster for them since they have commands memorized and are comfortable in that environment.

The truth is that under the hood, low code and no code solutions are code. They're built by programmers and though they may allow for most or all of the stuff we think of as code to be abstracted away, they contribute to the same goal most programmers have: building applications and sites for end users. Just because the code looks different or is more understandable to a wider group of people doesn't make it less valid or less useful.

In many cases, what a programmer used to be able to do in hundreds of lines of code is now doable in one. This is a good thing: it leads to increased productivity, less maintenance of repeated codebases, and the barrier to building on the web is lowered.

What will make a low code solution viable

My thesis is that low code solutions need to prioritize the developer, the non-coder, and designers. Right now, building a full scale software product with no code isn't feasible. It should be possible for a non-technical founder to prototype a product with no code, put it out as a proof of concept, and then pass that off to a designer and developer. They shouldn't need to start from scratch, they should be able to extend the prototype using the environments they are most comfortable in. For designers this will most likely be design tools like Figma and Sketch, and for developers it will be in their text editor with a common programming language like JavaScript.

I think tools like this are on the horizon, but in the short term, tools that enable more people to become developers or enable existing developers to be more productive are growing quickly. The idea that what used to require 100 lines of code or more is now able to be one line of code has been accepted by developers. For example, managed authentication services like Amazon Cognito, UI component libraries like Chakra UI, or payment management systems like Stripe.

In addition, the code should be readily available to those who need it. It should be fully generated instead of just having partial generation for a few features or having slots to insert custom code like some tools have. At least in the short term while these types of tools are gaining trust.

I've been working on the AWS Amplify Admin UI for the last few months, and I am impressed by its ability to simplify developer workflows via a visual interface despite being a tool completely aimed towards developers. It's low code in practice but not in positioning.

The same is true for the visual Git integrations in VS Code and the increasing integration of component libraries with design software. These are visual (i.e. low code) solutions that developers use in our workflows. They aren't branded in this way, so we're more accepting of them. Maybe this is also needed to win over developers in the short term, but I hope instead that we can embrace this progression instead of shunning it. Increased productivity on the boring stuff means more time to work on challenges and innovation.

Webflow has proven that low and no code tools can be a multi-billion dollar industry. I'm eager to see what comes next in this space, and I'm really excited about the possibility to allow more people to be developers and product builders.

My Desk Setup

Tue, 12 Jan 2021 00:00:00 GMT

Whenever I post a picture of my desk, I get asked what's on it, so I thought I should write it all down!

First, here's a picture of the stuff on my desk -- I do a ton of video content, streaming,and podcasting, so I have a lot of gear. I want to say that this is just my setup -- it's taken years to build this up and is completely unnecessary for most people. I find reading other people's setups interesting, so I hope this is helpful!

This post contains affiliate links. If you buy something through those links I may earn a small commission at no cost to you. This helps pay for the costs associated with running We Learn Code. I promise to only recommend products I use and love!

Computer

For the past ~7 years, I've used work-issued MacBook Pro's. I also have a personal one that I purchased from one of my previous employers. They aren't perfect, I'll be honest, but the UI is nice and I'm so used to them and the software that runs on them that I'm pretty stuck in my ways here. Next year, I want to upgrade my personal machine to an M1 desktop.

I use this laptop stand. It's pretty nice to have my laptop closer to eye-level and a more similar height to my monitor. This stand is reliable and does what I need it to -- I'm not sure if there's a huge difference between laptop stands though. Definitely not my area of expertise.

My monitor is similar to this Acer one. I got it nearly a decade ago on a Black Friday sale. It's dependable and does what I need it too, but it isn't anything fancy.

My keyboard is my favorite part of my setup -- it's so cute! I use this keyboard with these Astrolokeys keycaps. They match my fairyfloss VS Code setup perfectly.

I also have a Magic Mouse that I rarely use -- I normally just use my keyboard and laptop trackpad.

I also have seemingly dozens of USB to USB-C adapters. I just buy them in bulk at this point -- I don't have any that are better than others to be honest. I just buy whichever are cheap and have the number of ports I need.

Audio

My audio setup is mostly for the Ladybug Podcast, though I also use it for virtual speaking and YouTube videos. I will say this is overkill for most people, especially if you're just getting started. I started off with a Blue Snowball and moved to a Blue Yeti -- I think these are much easier to use and much more affordable.

Right now, I use a Shure SM7B with a Focusrite Scarlett Solo USB. There's also a popfilter on it and it's on a boom.

Video

I use a Sony ZV-1 for filming videos and as my webcam. I use Sony's Imaging Edge Desktop to connect my camera to my computer -- it works for video calls and streaming. Again, it isn't perfect and I wish I knew how to use it better, but it looks a ton better than my computer webcam and is pretty straightforward to use.

I use ScreenFlow for editing screen capture video and iMovie to edit face to camera stuff. That being said, Chris Enns does most of my editing, both video and the podcast. He's awesome and makes my life so much easier.

I also use OBS for streaming and recording videos. I hate the interface, but it's the only thing I've found that's full-featured and doesn't break as long as I don't mess it up.

Lighting

I have colored lights setup to make my background a little more interesting in videos. I use these under my desk, I usually have them set to purple. I also have this Hue light that is on my desk pointing at the wall. Finally, this galaxy light is so fun -- I usually have it pointed at the ceiling when I watch movies too.

I also have an Elgato Ring Light pointed at my face while I film -- I really like the look of having a ring light on my face when filming, and this one has a lower profile than many which helps make my office prettier!

Desk

I have two of this desk that I have put together in an L-shape. One is 55" and one is 63". I like having the extra space since I have so much gear, and I can leave books, water, and writing tools on the second table. I'll probably get a nicer one that's real wood and a little sturdier at some point, but these are a bargain (I got them on sale so they were under $100 each).

I have this Autonomous.ai chair that they gifted me. It's really comfortable, but I'll probably get something that's more aesthetically my style down the road.

Desktop Software

I use Sketch and Canva for design work, including thumbnails and visual assets for posts. I use ConvertKit for my email list. I also use Magnet for window management -- it's the first thing I install on any computer.

Other than that, I use VS Code, Google Drive, and iTerm for pretty much everything. I take notes mostly in Markdown and host them on private GitHub repositories.

Other Stuff on my Desk

I also use the BestSelf Journal as my daily and quarterly planner.

I also run on Dunkin' Iced Coffee, so you'll see that in a lot of my pictures 😀 -- I'm a New Englander through and through. I always order mine with skim milk and caramel swirl -- it's been my order for over a decade and I don't see it changing any time soon.

That's my full setup! If you have any questions, feel free to reach out via Twitter!

Introducing the AWS Amplify Admin UI: Create an Application Backend in Clicks

Thu, 03 Dec 2020 00:00:00 GMT

I am so, so excited about the brand new Amplify Admin UI, which the team that I'm on at work launched this week. You can create and configure a backend for an application in minutes, start building it without an AWS account, create a schema in clicks, add authentication, and easily deploy to AWS. You don't need to know backend development or AWS to use it -- I think it's an awesome tool for new developers looking to get started in these domains. In this tutorial, we'll build out a backend for a blog with comments, and add user authentication.

First head to the Amplify Admin UI homepage. Then, click "Get Started" under "Create an app backend."

Create a Data Model

Choose "data" and then "blank schema" on the next page. You can also start with a sample schema in the future if you want, but for this tutorial, we'll start from scratch! Under the hood, the data model utilizes DataStore, which will allow your data to be available both offline and online and across your application's users.

Then, click "create new schema". We'll add two models: Post and Comment.

Click the add button, then add model.

Name your model "Comment" and then add two fields: text and author. Both will be strings.

Add the "Post" model. This one will have two more fields: title and content.

We'll also add a relationship so that each post has comments attached to it.

Click "Add a relationship" under the "Post" model. Select "Comment" as your related model, and choose "one Post to many Comment" since we want each post to be able to have multiple comments.

I also made all the fields required. If you focus on a field, a panel shows up on the right-hand side of the screen where you can make a field required. In this view, you can also create array fields which would help if you wanted to add an array of tags to your blog posts!

Then click the orange "Next: Test locally in your app" button.

Test your data

Then, you can test out your data model in an app to make sure it works the way you want it to.

On this screen, you'll see options for what type of app you're setting up and how to do so -- you can choose a web, iOS, or Android app. I'm going to pick Web as my platform and React as my framework for the sake of the tutorial. Once you choose, there will be instructions for creating your app.

If you're just starting out with React, here's a tutorial on getting started with it! I'm going to move fast through this part since I want to focus this post on the Admin UI.

Run the following command to create a React app and move into its directory.

$ npx create-react-app blog
$ cd blog

Then, install the Amplify CLI.

$ curl -sL https://aws-amplify.github.io/amplify-cli/install | bash && $SHELL

Also, pull down your newly created backend in order to test it out locally.

amplify pull --sandboxId your-app-id

We'll need to install a few packages, first typescript since DataStore uses it for your generated models, and the Amplify libraries which will give us utilities for using and extending our backend.

npm install aws-amplify typescript

Then, open up your index.js file and add the following piece of code to configure Amplify in your project:

import Amplify from 'aws-amplify'
import awsconfig from './aws-exports'

Amplify.configure(awsconfig)

Then, we can write our React code! For this tutorial, we'll create a post and list all of our posts on the page. Let's create components for each:

touch src/PostList.js
touch src/CreatePost.js

First, we'll create a standard React form for creating a new blog post.

// CreatePost.js
import { useState } from 'react'

export default function CreatePost () {
  const [title, setTitle] = useState('')
  const [content, setContent] = useState('')

  const handleSubmit = async e => {
    // When the form is submitted, prevent the default form behavior (don't refresh the page)
    e.preventDefault()

    // set the tile and content back to empty strings
    setTitle('')
    setContent('')
  }

  return (
    <form onSubmit={handleSubmit}>
      <div>
        <label htmlFor='title'>Title</label>
        {/* Update the title in state every time the title field is changed */}
        <input type='text' name='title' id='title' value={title} onChange={e => setTitle(e.target.value)} />
      </div>
      <div>
        <label htmlFor='content'>Content</label>
        {/* Update the content in state every time the content field is changed */}
        <textarea id='content' name='content' type='text' value={content} onChange={e => setContent(e.target.value)} />
      </div>
      <input type='submit' value='create' />
    </form>
  )
}

We'll then add the Amplify code for saving our data to DataStore.

// Import data store and the Post model
+ import { DataStore } from '@aws-amplify/datastore'
+ import { Post } from './models'

...
  const handleSubmit = async e => {
    e.preventDefault()

    // Save our Post using the title and content the user inputted.
+   await DataStore.save(
+      new Post({
+  		  title,
+  		  content
+  	  })
+   )
    setTitle('')
    setContent('')
  }
...

Then, we'll create a component to display each post.

// PostList.js

import { useEffect, useState } from 'react'
import { Link } from 'react-router-dom'
import { DataStore } from '@aws-amplify/datastore'

import { Post } from './models'

export default function PostList () {
  const [posts, setPosts] = useState([])
  useEffect(() => {
    const getData = async () => {
      // Get all of our posts and update state with them
      const postData = await DataStore.query(Post)
      setPosts(postData)
    }
    getData()
  }, [])

  // Loop through  
  return (
    <div>
      {posts.map(post => (
        <div key={post.id}>
          <h2>{post.title}</h2>
          <p>{post.content.substring(0, 300)}...</p>
        </div>
      ))}
    </div>

  )
}

Finally, link both components in the App component:

import CreatePost from './CreatePost'
import PostList from './PostList'

function App () {
  return (
    <div>
      <CreatePost />
      <PostList />
    </div>
  )
}

export default App

For the sake of tutorial length, I'll skip over the rest of the components since this shows how to get data and add it, but my full application code will be linked at the end of the tutorial.

You should be able to create posts and then see them on the page!

If you want to make any changes to your schema, you can click the 'model' tab and make edits. You will then need to pull your changes by re running the amplify pull --sandboxId your-sandbox-id command.

Also, if you don't want to test your app before deploying it, you can skip the testing page and move on to the "Deploy" one.

Deploy

Right now, your data is only local. We need to deploy our backend to AWS in order to make it available to a wider user base.

On the deploy page, you can either signup for a new AWS account or sign into one you already have.

Choose one, and you will be taken to a "Create App Backend" page. Enter any name for your app, and choose an AWS region to deploy to. You'll normally want to pick a region that will be closest to the majority of your users. I'll pick us-east-1 since I'm in the United States on the east coast. In the future, you can make your app multi-region to better support users across the world. Here's a map of all the regions if you want to learn more!

It'll take a few minutes to initialize your backend environment, but once it does, you can click the "Backend environments" tab and then "Open admin UI."

From this view, you'll be able to edit your schema, manage your application content, add authentication to your app, and to extend your app with any of the other Amplify services.

First, click the "Local setup instructions" on the top right for another amplify pull command -- this one will hook your app up to your deployed API instead of the sandbox one.

$ amplify pull --appId your-live-app-id --envName staging

Manage App Content

If you click on the "Manage app content" button, you'll be taken to a dashboard where you can create, edit, and delete your app's data. Switch to your "Post" table and click "Create post". You can then add a title and content -- click "Edit in markdown" to launch a markdown preview tool for your blog posts!

You can also add a comment directly to your post. This is a great way to add initial data to your application, and it makes it so that you don't need to write an admin panel for your application yourself!

Admin UI Access

You can give people without an AWS account access to the Admin UI -- you can allow non-technical team members to just interact with app content, and give full access to your developers. to do this, head back to your app's homepage in the AWS console. You can go to this link and then click on your app if you moved off of that page!

Click "Admin UI management" and then you can click the "Invite users" button to invite users to the admin UI via email.

Add Authentication

Back in the admin UI, you can initialize authentication for your application in clicks. You can configure both the sign up and login requirements for your users, including social and multi-factor authentication. Click "Enable authentication" to get started.

Once you've deployed your authentication, you can manage users and create user groups on the "Manage groups" page, so if you wanted.

Then, back on the data model page, you can add authorization roles to your tables. Change the authorization mode to Cognito User Pools and then only signed in users will be able to access and manipulate data, and you can make it so that only certain groups or owners can perform actions on data.

You can also use IAM users if you want to allow public read access but only signed in users to manipulate data.

You can use the Amplify UI React Components to add your configured authentication to your app.

First, install the React components:

$ npm i @aws-amplify/ui-react

Then we could add authentication to the whole application by wrapping your component in the withAuthenticator higher order component:

import { withAuthenticator } from '@aws-amplify/ui-react'
...
export default withAuthenticator(App)

Use the Existing Amplify Commands

You can use Amplify's command line interface in tandem with the Amplify UI -- so you can still utilize the GraphQL APIs, S3 storage, Lambda functions, etc. You can view the instructions for adding these by clicking the items in the lefthand menu or via the documentation.

Deploy Frontend

Once you have your frontend code written, you can deploy it via Amplify as well. Here's a tutorial on how.

Conclusion

I can't wait for you to try this tool out! If you do, please feel free to message me with any feedback you have or requests for future tutorials.

Here is a link to my full code!

How to Teach Code

Tue, 27 Oct 2020 00:00:00 GMT

Teaching code has been a large part of my life -- I was an education minor in college before I left to become a software engineer, and I've since taught code fulltime as a bootcamp instructor and as a developer advocate. I've feel so lucky to have been able to have been a part of many developers' coding journeys in one format or another: from teaching thousands of students through workshops and the bootcamp I used to work at to millions through writing blog posts like this online. In this post I want to address the ways you can teach code, discuss how to coach students on a learning mindset, go over the mechanics of teaching a lesson, and give oodles of tips for teaching.

Note: It may be helpful to also read my post on how we learn

You probably already teach

You may have read the first paragraph and wondered, "is this post relevant to me, I don't teach code in a classroom." My answer is yes: you probably already teach code in some format, whether that be answering questions online, mentoring a junior developer, creating content, managing people, speaking at conferences, etc. If you participate in any of these activities, you are a teacher! And, some of the pieces of advice listed here will benefit you.

Why should you teach?

There are also so many reasons why you should teach. You can reinforce your knowledge on topics -- you have to learn something really in-depth in order to communicate it simply to someone else. In addition, it can be an opportunity to learn new things: I had to teach myself many topics in order to effectively teach them to students. You can become regarded as an "expert" in your field through teaching. At work, it can help you delegate tasks if you teach others to do tasks. And, it's also beneficial for the student to be given information in an understandable way.

The Mindset Behind Teaching

Learning anything is hard, especially code. I know this personally, I dropped out of computer science during my junior year of college because I thought coding wasn't for me. Put yourself into your students' shoes -- what are the stumbling points for learning what they are trying to learn. And how can you enable them to embrace the challenge of learning that subject. Having a growth mindset towards learning new things makes learning much more achievable. I think celebrating students' wins helps with this -- celebrate the little things and the bigger ones in the classroom. Celebrate the function that works successfully for the student that is struggling, a student asking a great question, and the mindblowingly great project.

In addition, think of your students' lives outside of the classroom. Now, especially with health concerns, political unrest, white supremacist escalations, and rapidly changing life circumstances, students' basic needs aren't being met, which means that learning becomes especially hard. Maslow's heirarchy of needs states that safety needs to be fulfilled in order for someone to achieve their full potential. As educators, we need to recognize that and create accommodations to help as much as we can. During the peak of the Black Lives Matter protests, I pushed back deadlines, lessened requirements for students, and made it clear students could work on projects on their own schedule as one example.

Creating a classroom culture needs to be an intentional activity as well. Set norms for students, establish a code of conduct, and make sure that no one student dominates conversation. Encourage students to take space and give space -- and that will look different for everyone. I'm naturally a very quiet student myself. It takes me time to process on my own before coming back with questions and answering on the spot gives me anxiety. That's pretty normal, as are students who have more immediate questions. Have strategies to make everyone comfortable contributing to the class, but also allow students to process before putting them on the spot. I prefer warm calling to cold calling -- "Can someone in this row answer this question" or "can someone who was in breakout room 3 explain x again to the class".

It's also important to know your audience. If you're doing a one off workshop, doing a quick poll at the beginning can be helpful to tailor your lesson. If you're teaching a full course, I like having student profiles before the class starts to know of accommodations, backgrounds, and previous experience with the subject matter.

Another important mindset to have is that the best thing you can teach students is to teach themselves. Yes, initially teaching a curriculum is important to guide students and to address any misconceptions. But also show them how to debug errors, how to research for answers, and challenge themselves to extend what they've learned to topics outside of the course subject matter.

The Mechanics of a Lesson

Now that we've discussed some of the key behaviors you should have as an educator and encourage in your students, let's discuss what a lesson actually looks like.

First, have Learning Objectives these are tangible takeaways for what students should learn in your lesson. For example, students should be able to define what React components, JSX, and the virtual dom are; students should be able to explain why React is helpful in developing applications; and students should be able to create a React component. When you're creating a lesson, these are helpful for staying on topic and scaffolding your lesson. For students, especially adult learners, knowing what they are going to learn helps relieve anxiety and pushes off pre-emptive questions. They also know what they need to especially focus on during the lesson.

Then comes Framing, which is when you explain the background for a topic and why it's important. You're hooking the learners into the lesson and telling them why they need to pay attention. You're setting the scene for the rest of the lesson here. In a React lesson, the framing could include the history of React, statistics on how widely it is used, and how it makes development easier. You could also include personal stories about creating applications with React.

Then comes the "body" of the lesson. I rotate through three steps repeatedly in this phase: "I do, we do, you do". I do is when I explain a topic to students - "A React component is X" for example. We do is when I write code and expect students to do the same on their computers if possible. So we may build a simple React component together. Finally, a you do is an activity for students to complete. I prefer to do these activities in groups if possible, then students can use each other as resources in addition to asking the instructor questions. Each of these sections shouldn't be too long. Rotating through keeps attention and students never have to wait too long before practicing with something themselves. When you have them do exercises emphasize that this is about the process more than the results, they won't necessarily always be able to get what they are aiming to each time, but hopefully they learn something for the next time they use that subject.

Traditional lectures are a flawed teaching model. People's attention spans are usually 11-13 minutes long, so if you are talking for much longer than that, people will be tuning out. Vary your teaching model. I really like flipped classrooms where students do a reading or watch a topic and then we come together to discuss. As well as repeated practice. Writing code is the best way to learn how to code.

Another reality is that students will be at different levels -- topics will click quickly for some and slower for others. Also, everyone is coming into a classroom from a different background. I'd recommend focusing your lessons on the middle of the class's ability level. You may lose some students and not challenge others enough, and that's where 1-1 attention comes in for those students. You can recommend additional resources, have 1:1 office hours, and tier activities so that everyone has something to work on. Your lessons should be reaching the vast majority of the class, but make sure to also reach those who may struggle or excel with a topic.

When you're teaching something you know really well it can be tempting to teach everything about that subject. But often times that overwhelms newbies. Teach what’s necessary, not for your ego.

I also incorporate Checks for Understanding every few minutes to make sure the class is following along with what I'm teaching. These can take multiple formats, from Slack polls and questions to writing on whiteboards, to answering questions verbally.

Finally, review at the end. Recap what you went over, linking back to the learning objectives.

Teaching Tips

Now, I want to transition into giving a bunch of teaching advice.

Set clear expectations. Students will do best if you have a clear agenda and success criteria. I always give a syllabus or outline beforehand, have a code of conduct for the classroom, and make my lessons available ahead of lesson time so students can review them before class if they want. Don't make your lesson be the first time they see the material. Assign readings ahead of class, and make slides or lesson materials available ahead of time if possible. Repetition of material is key.

Create a safe place to fail. Have safeguards in place so if a student doesn't finish something or doesn't get the correct answer it isn't devastating. I normally have a resubmission process outlined, allow for some missed assignments, and grade for effort not correctness.

Along similar lines, if your students have an extrinsic motivator for learning, i.e. they want to get a programming job, adding number or letter grades is often ineffective or harmful. Certain students, cough me in college, care more about that success measurement instead of actually learning. I would focus on giving good feedback rather than trying to put a contrived grading rubric together. I normally have criteria for graduation, but most assignments are given passing/not passing for assignments that are way off the mark (sections that haven't been attempted, very clear lack of effort, large chunks of code copied from the internet, etc).

Mirror the career world in the classroom, again mostly for adult learners. For example, having standups to discuss progress, use pull requests for submitting homework, or using issues for class questions. Get students used to using the platforms they will be using throughout their careers.

Use best practices. Please don't use foo/baz/bar examples. They aren't helpful. But do format your code properly, use good variable names, etc. Model what you want your students to do.

Link new information to what they already know. Learning in isolation is really difficult. Instead, put it in context of what they've already learned. Making those links explicit can be really helpful even if those links may seem very clear to someone with more experience. For example: a variable in code is very similar to the variables you may have learned about in algebra class.

Appeal to multiple learning styles. The idea of different people learning with different learning styles has been discredited, but make sure to have visuals, audio, additional readings students can do, and more exercises so that students can extend their knowledge on their terms. Diagrams are just good for learning anyways! Bonus tip for content creators: you can reuse content by creating it in multiple formats. I usually use my blog posts as scripts for my YouTube videos.

Break down jargon. I often see and hear that you shouldn't use jargon when teaching. I actually disagree with this -- students are going to need to use the terminology of the field in their work. Being able to talk like a programmer is crucial for interviews and communicating with others. That being said, make sure to explain yourself when you use jargon. Define new terms repeatedly verbally and in writing.

Emphasize the unimportance of memorization. In many subjects, rote memorization is critical. In programming, the difficult part is the problem solving, and students will be able to use resources on the job. Explaining this is super important so that students don't feel the need to memorize entire APIs. In addition, show gaps in your knowledge. If you forget the name of an array method, that's probably better for students to see than if you had it off the top of your head. Show them how you find the correct method name using the documentation.

It’s okay to not know something. When you're in front of a classroom it may feel like you need to know everything on a topic, but you don't. It's important to prepare extensively for lessons, but having a typo or a bug and debugging that live is so helpful for students. And sometimes their questions are really out of left field -- like when I was asked what would happen if you broke out of the window object in JavaScript. You can say you don't know, or show them how you would research the answer to their question.

Some of my favorite teaching resources

Conclusion

One of my favorite quotes is, "When one teaches, two learn" by Robert Heinlein. I have learned so much from teaching, and I feel so lucky to have been a part of people's learning journey. If you have any questions or follow up topics, please tweet them at me.

Create Custom GraphQL Queries in AWS Amplify

Tue, 20 Oct 2020 00:00:00 GMT

AWS Amplify uses code generation to create GraphQL queries for you when you add an API. This is super handy, but say you want to add a custom query. What do you do?

The trick here is that when you change your schema, the GraphQL files are re-created for you, overwritting what is already in there -- so you can't add the query in the generated files without having to re-add them whenever you update your schema.

There are two options for how you can add your own queries.

First, if it's not a query you want to reuse much, you can write it inline:

  const gifs = await API.graphql(graphqlOperation(` 
  query GetGifs {
    listGifs {
      items {
        altText
        id
        url
      }
    }
  }
`))

If you want the query to be more reusable, you can create another file in the graphql directory -- for example custom-queries.js and mirror the formatting of the queries in the queries.js file.

Create a Git Diff in Markdown

Tue, 20 Oct 2020 00:00:00 GMT

One of my favorite blogging tips is using diff formatting in GitHub flavored markdown. I use this to show what has changed in code snippets. This works for code snippets in most markdown packages and on Dev.to.

View on EggheadIf I wanted to show that I was changing a function from one thing to another, I could add a snippet that looks like this!

function addTwoNumbers (num1, num2) {
-  return 1 + 2
+  return num1 + num2
}

First, instead of specifying the programming language, use diff after the backticks. Then at the beginning of any lines of code you want to show as removed, add a -. At the beginning of any lines of code you want to show as added, add a +.

The code would look like this:

```diff
function addTwoNumbers (num1, num2) {
-  return 1 + 2
+  return num1 + num2
}
```

I have used this in tons of my coding tutorials, such as this one. It makes it a lot easier for readers to see what is changing from snippet to snippet.

Create Multiple Files at Once with Brace Expansion

Tue, 20 Oct 2020 00:00:00 GMT

Did you know that you can create multiple files with the same name but different extensions all at once using the CLI? Bash/Zsh/Fish etc. have Brace Expansion. So, you can do something like this:

$ echo hi{Ali,Friend,Buddy}hi
> hiAlihi hiFriendhi hiBuddyhi

In this case we're echo-ing (printing) out the text before and after the braces three times, once fo reach of the items in the braces.

This is pretty handy when it comes to making files:

$ touch Button{.js,.css,.stories.js,.test.js}

This also works with number ranges, so if you wanted to create 30 files you could do:

$ touch my-file-{1..30}.txt

I use this all the time when I'm working on React apps.

Using Children in React

Tue, 20 Oct 2020 00:00:00 GMT

You can use props.children in React in order to access and utilize what you put inside the open and closing tags when you are creating an instance of a component.

For example, if I have a Button component, I can create an instance of it like this: <Button>HI!<Button> and then inside of the Button component, I could access that text with props.children. You can also use this to create components that wrap other components -- <Container><Button /></Container> for example.

function Button (props) {
  return <button>{props.children}</button>
}

I can then instantiate the component with <Button>Click Me!</Button> and then a button with the text click me would display on the page.

For a layout, I could do something like:

function Container ({ children }) {
  return <div style={{ maxWidth: 800px, margin: 0 auto }}>{children}</div>
}

Note: in this example, I'm destructuring the props object, so I can use children directly.

And then to instantiate it I could do:

<Container>
  <h1>Welcome to my App</h1>
  <p>Hello, hi, this is my paragraph</p>
</Container>

Normally in order to pass props from one component to another, you need to do <Button label="hello" /> and then use props.label in the component, but React children is more flexible and allows you to mirror HTML more closely within your JSX.

Getting Started with Storybook: How to Develop React Components Without an App

Tue, 20 Oct 2020 00:00:00 GMT

I wanted to write up some thoughts and a quick tutorial on one of my favorite development tools, Storybook. You can use Storybook which allows you to develop user interface components in isolation. It can also aid in development and documentation of design systems -- which are sets of components and design standards that companies develop to be used across their apps.

What is a Design System

Large companies normally have multiple applications -- external facing, internal facing, and cross-platform. It can be difficult to unify the design across these platforms. So, many companies are implementing design systems to help create unified design across all of their products and platforms. Here is a great example of how Airbnb implements their design system.

You may have heard of a component library before -- these are collections of components that you can import and use in your projects. A design system extends this to also include style and content guidelines and other rules for future design work. This is a great post about how design systems go beyond component libraries.

How does Storybook help?

Storybook really helps with the development process of design systems and component libraries. Here is an example of Grommet, an accessible React component library's, full Storybook. Normally, you'd have to build out a whole app in order to see your components as you create them. Storybook allows you to develop components independently so you can focus on styling and interaction. You can use it with many different frontend libraries such as React, Angular, Vue, or even just with HTML.

Tutorial

In this tutorial, we'll use React to build out a mini-component library that has a few different types of buttons to see how Storybook works! If you're new to React, check out this post to get up to speed before continuing on with this tutorial.

First, create a React app: npx create-react-app storybook-tutorial. Then, change into its directory: cd storybook-tutorial.

Now, install storybook and initialize it: npx -p @storybook/cli sb init.

This command adds a .storybook folder with configuration information about your project. It also adds a /stories folder inside your /src directory that shows a demo Storybook project. We'll go ahead and delete that folder, but you can take a peek at the code if you want!

Run: npm run storybook to get Storybook up and running -- it should pop up in your browser and give you a message about no stories being found.

Now, we'll go ahead and create a Button directory: mkdir Button and add three files inside of it, one for the component, one for the CSS, and one for the stories: touch Button.{js,css,stories.js} (here's a blog post on how this brace expansion works).

Here's a recap of all the steps from above:

$ npx create-react-app storybook-tutorial
$ cd storybook-tutorial
$ npx -p @storybook/cli sb init
$ rm -rf /src/stories
$ npm run storybook
$ mkdir /src/Button
$ touch /src/Button/Button.{js,css,stories.js,test.js}

Now, we'll make a React component in the Button.js file -- it will just render a button and use the children prop for text. This allows us to instantiate our button component like <Button>my text</Button> and then our component would render a button element with my text on it! Here's more on props.children if this is the first time you're seeing it.

// Button.js
import React from 'react'
import './Button.css'

export default function Button({ children }) {
  return (
    <button>{children}</button>
  )
}

Now we'll go ahead and create a couple stories. A story is a display of a state of a component. We'll have collections of stories for different types of elements. For example, we can have a collection of different versions of our Button component.

We'll go ahead and add our Button stories to Button.stories.js. First, we need to import React so we can use JSX in the file. Then we'll import our Button component.

Next, we'll add a default export from this file which will have metadata about our collection. In this case, I'm titling the collection Button. This will render on our Storybook UI as almost a directory name.

We'll also export two functions that instantiate our Button component with different text on it.

All together, our code will look like this!

// Button.stories.js

import React from 'react'
import Button from './Button'

export default {
  title: 'Button'
}

export const DefaultButton = () => <Button>hi!</Button>
export const SecondButton = () => <Button>hello!</Button>

If you check back on your Storybook window, it should look like this:

There's a Button collection label with two different buttons: Default and Second. You can click between the buttons and see each one's different text. If we were just using React, we would need to build an app to view the component -- here we can develop them independently just by creating stories.

Let's think of the different types of buttons we may have in our design system. Maybe a default outlined one, a disabled one, a primary button and then maybe different states -- hover and click for example. We may also have different sizes of buttons. What we can do is add props that differentiate these different factors and then based on those props add CSS classes to our buttons.

We'll first make it so that we have an outline button and a default button.

First, add the following CSS:

/* Button.css */
button {
  background-color: #FF389C;
  color: white;
  font-size: 20px;
  padding: 10px;
  border: none;
  border-radius: 4px;
}

button:focus {
  outline: 2px solid pink;
}

.outline {
  background-color: white;
  color: #FF389C;
  border: 2px solid #FF389C;
}

Then, we'll tweak our storybook file to export a default button and an outline button instead of the default and second button that we have now:

export const DefaultButton = () => <Button>click me!</Button>
export const OutlineButton = () => <Button outline>click me!</Button>

Then, we need to conditionally add the outline class to our button if it has the outline prop:

import React from 'react'
import './Button.css'

export default function Button ({ children, outline }) {
  let classes = ''
  if (outline) classes += 'outline '
  return (
    <button className={classes}>{children}</button>
  )
}

Now, if you look at Storybook the two buttons reflect our two different types of buttons!

Let's also make it so that we can have small and large buttons.

/* Button.css */
.small {
  font-size: 10px;
  padding: 6px;
}

.large {
  font-size: 20px;
  padding: 10px;
}

We'll add two more button stories:

export const SmallButton = () => <Button size='small'>click me!</Button>
export const LargeButton = () => <Button size='large'>click me!</Button>

If you wanted, you could add small and large outline buttons too!

We'll also add the size to the classes:

import React from 'react'
import './Button.css'

+ export default function Button ({ children, outline, size }) {
  let classes = ''
  if (outline) classes += 'outline '
+  classes += size
  return (
    <button className={classes}>{children}</button>
  )
}

Now you should have four stories!

There are a couple things you could do now: you could use actions to test out event handling. You could use your Button in an app by importing it into a page of a React app -- you could also deploy it to npm so that you could use it in projects more easily in the future. You can also deploy your storybook so that other people can visit it by running npm run build-storybook and then using static site hosting for the folder that is produced from that command.

Storybook is such a great development tool, especially if you're a design-focused frontend developer. I hope that this was a helpful tutorial, feel free to tweet at me with what you'd like to see a tutorial on next!

Build a Music Sharing App with Amazon S3 and AWS Amplify

Tue, 13 Oct 2020 00:00:00 GMT

Amazon S3 was the first AWS service I ever used, which I would guess is a pretty common occurrence -- it's pretty simple and allows you to store files such as images or videos on your site.

S3 stands for Simple Storage Service. It's used for Object storage. This means you can store flat files -- videos, images, and text files that don't change often.

In S3, Data is organized in buckets, which are like folders. Objects inside those buckets have keys, file names, and values, bytes with data.

We're going to go ahead and build a music sharing app where users can upload .mp3 files and then other users can listen to them!

Security

Before we start, it's important to discuss security on an app like this. Amazon S3 has a free tier for the first year of your account; however, if you allow anyone to upload to your S3 bucket, a bad actor could upload a bunch of files to your account leading to fees on your end.

Therefore, it's best practice to follow the least privilege principle and limit uploads to only those who need access.

For this quick demo, my app will allow anyone to upload and download files so that we don't need to cover authentication. In a production application, think carefully about who needs to be able to upload files and only give them access.

Setup

We'll first initialize AWS Amplify, which is a suite of tools that aid front-end and mobile development on AWS.

First, install and configure the Amplify CLI.

Then, create a project or move into one you've already created. I'm going to be starting out with a HTML/CSS/Vanilla JavaScript project with Parcel for bundling. You can follow the "Setup" instructions on this tutorial or download this code and run npm install to get my setup if you want!

Then, we can run $ amplify init to initialize an AWS Amplify project. You will then be prompted to answer some questions -- you may need to tweak the answers a little bit for your setup if you're using a different text editor, but here are the settings I chose! Many of these are the defaults.

? Enter a name for the project: tunelify
? Enter a name for the environment: dev
? Choose your default editor: Visual Studio Code
? Choose the type of app that you're building: javascript
? What javascript framework are you using: none
? Source Directory Path:  src
? Distribution Directory Path: dist
? Build Command:  npm run-script build
? Start Command: npm run-script start
? Do you want to use an AWS profile: Yes
? Please choose the profile you want to use: aspittel

Then, we will use AWS Amplify to add authentication to our app, we won't actually use it for this project but under the hood it will be used for our S3 permissions.

$ amplify add auth

Do you want to use the default authentication and security configuration: Default configuration
How do you want users to be able to sign in: Username
Do you want to configure advanced settings: No, I am done.

Only one more configuration step, I promise! This time, we'll add S3 storage. For this demo, anyone can create and read data. In production you would most likely want to limit who can upload files!

$ amplify add storage

? Please select from one of the below mentioned services: Content (Images, audio, video, etc.)
? Please provide a friendly name for your resource that will be used to label this category in the project: tunelify
? Please provide bucket name: tunes
? Who should have access: Auth and guest users
? What kind of access do you want for Authenticated users: create/update, read
? What kind of access do you want for Guest users: create/update, read
? Do you want to add a Lambda Trigger for your S3 Bucket: No

Now, run $ amplify push to deploy your changes!

The Code

Now that we've done all the configuration for our app, we only need a little bit of our own code to create an image upload form and to display our tunes.

Let's install the AWS Amplify library:

$ npm i aws-amplify

Now, we'll configure Amplify on our frontend. In your script.js add:

import Amplify, { Storage } from 'aws-amplify'
import awsconfig from './aws-exports'

Amplify.configure(awsconfig)

In your HTML, add the following form:

<form id="upload-form">
  <input type="file" name="filename" id="file-upload" accept=".mp3">
  <input type="submit" value="Upload">
</form>

This will allow the user to upload a file, only allowing those with a .mp3 extension.

Then, in your JavaScript add:

// select the upload form we created, and listen for a submit event on it
document.getElementById('upload-form').addEventListener('submit', e => {
  // don't refresh the page on submit
  e.preventDefault()
  // get the file from the file upload element, this will be an array.
  // we only want the first element
  const file = document.getElementById('file-upload').files[0]
  // put our file in storage, use the file's name as its S3 Key
  Storage.put(file.name, file)
    .then(item => {
      console.log(item)
    })
    .catch(err => console.error(err))
})

🎉 Just like that we've uploaded our file to S3!

Now, let's list all the files that are in our bucket:

Storage.list('')
  .then(result => {
    result.forEach(item => console.log(item))
  })
  .catch(err => console.error(err))

You could change the argument to .list() in order to only get files with a certain prefix.

Let's make it so that we can play our audio files on the page! Change the console.log(item) in the two above snippets of code to createAudioPlayer(item) and add the following code to add an audio element to the page:

const createAudioPlayer = track => {
  // Get the track from S3
  Storage.get(track.key).then(result => {
    // create an audio element and add a source element to it
    const audio = document.createElement('audio')
    const source = document.createElement('source')
    audio.appendChild(source)
    // add controls to the audio element
    audio.setAttribute('controls', '')
    // add the track source and type
    source.setAttribute('src', result)
    source.setAttribute('type', 'audio/mpeg')
    // add the item to the page
    document.querySelector('.tracks').appendChild(audio)
  })
}

I also ended up adding some styling to my app to make the end product look like this:

The completed code is on my GitHub if you'd like to take a look! I also have a tutorial here on re-creating the rainbow text 🌈.

Conclusion

I hope this was a fun demo on how to get up and running with Amazon S3 using AWS Amplify. If you'd like to learn more, here is a tutorial on creating a CRUD app with AWS Amplify, here is an extended demo on Amplify, S3, and Svelte, and here is a post on using an existing S3 bucket in AWS Amplify.

Create Rainbow Text with CSS: Three Different Methods

Tue, 13 Oct 2020 00:00:00 GMT

I really like adding rainbow text to my apps 🌈. There are three methods I usually use for this, so I thought I'd aggregate them into one post.

Text Shadow

See the Pen Text Shadow Rainbow Text by Ali Spittel (@aspittel) on CodePen.

One method for adding a rainbow is to do stacked text shadows. In this example, I have 9 different text shadows all offset by 4px. For example, the first shadow is -4px 4px #ef3550,. The first negative value places the shadow to the left of the letter. The second positive value puts the shadow 4px below the letter. Then, we have the color! The next shadow is -8px 8px #f48fb1 which offsets the shadow by 4 additional pixels in each direction.

Rainbow Letters

See the Pen Rainbow Letters by Ali Spittel (@aspittel) on CodePen.

Another method is to make each letter a different color. For this one, there's a catch: you need to make each letter into its own HTML element. In this case, I used a span. I then used the :nth-child selector to apply different colors to each span.

For my portfolio site, I have 10 colors I rotate through -- so I use multiples of 10. :nth-child(10n). I then need to add an offset to all but the first color -- :nth-child(10n + 2) for example. This will still apply the color to each 10th element, but starting at the second element instead of the first. This makes it so that the 2nd, 12th, 22nd and so on character have that color applied.

I would think about accessibility when using this method -- screen readers are going to read each letter as a letter instead of putting them together to form a word. So, you may want to hide the rainbow letters to the screen reader and then have another header on the page that is hidden for users reading the page.

Rainbow Gradient

See the Pen Rainbow Gradient by Ali Spittel (@aspittel) on CodePen.

The third method is to create a CSS gradient! I am hopeless at creating these by hand, so I use tools like this to help out.

Hope this will help add some fun 🌈s to your apps!

Read from a File with Python

Fri, 09 Oct 2020 00:00:00 GMT

You can read from a text file in Python using the open function.

View on Egghead

First, create a file with some text in it. Mine is named input.txt and has five lines of lorem ipsum text in it.

We'll, use the open function to open our file: open("input.txt"). This function takes the path to the file as an argument.

We will also use the with keyword, which will automatically close our file at the end of the code block.

The as keyword will allow us to save the file contents to a variable name.

The full line of code to open the file will be:

with open("input.txt") as text:
    pass

Now, we can loop through the lines of text in our "input.txt" file!

with open("input.txt") as text:
    for line in text:
        print("-------")
        print(line)

🎉 Now we have successfully read the contents of a file in Python!

Here is the full code.

Center an Element Horizontally and Vertically with Flexbox

Thu, 08 Oct 2020 00:00:00 GMT

Did you know that you can center an HTML element horizontally and vertically in just a few lines of code using CSS Flexbox?

View on Egghead

First, we need a parent HTML element with some child elements inside it. For example, this main element with a section inside of it.

<main>
  <section class="content">
    <h1>Hi! 👋</h1>
    <p>
      Lorem ipsum dolor sit amet consectetur adipisicing elit. Dolor
      perferendis mollitia saepe harum praesentium libero unde reprehenderit
      dolorum inventore veritatis dolorem nostrum, tempora sapiente optio,
      sed maxime consectetur assumenda est.
    </p>
  </section>
</main>

We need to make sure the main element takes up the height of the page, as well as its parent elements:

html,
body,
main {
  height: 100%;
  width: 100%;
}

Then, we need to make the main element into a flex container by adding display: flex;. The flex container should be the immediate parent element to the element we want to center.

Then, we'll add justify-content: center; to center the content along the main flex axis, which in this case is horizontally. We'll also use align-items: center; to center the child element along the cross axis, which in this case is vertical.

main {
  display: flex;
  align-items: center;
  justify-content: center;
}

🎉 Now our content is centered!

See the Pen center element with flexbox by Ali Spittel (@aspittel) on CodePen.

Create a Card Layout with CSS Grid

Thu, 08 Oct 2020 00:00:00 GMT

You can create a card layout with just a few lines of CSS Grid code!

View on Egghead

First, we need a parent HTML element with some child elements inside it. For example, this main element with six card divs within it.

<main class="card-container">
  <div class="card">
    <p>hi</p>
  </div>
  <div class="card">
    <p>hi</p>
  </div>
  <div class="card">
    <p>hi</p>
  </div>
  <div class="card">
    <p>hi</p>
  </div>
  <div class="card">
    <p>hi</p>
  </div>
  <div class="card">
    <p>hi</p>
  </div>
</main>

We will add some CSS to our cards to make them stand out on the white background:

.card {
  background-color: #006b80;
  color: white;
  width: 100%;
}

Then, we'll make the .card-container element into a grid container by adding display: grid; to it.

Then, we will use the fr fractional units that CSS Grid introduces. If we do grid-template-columns: 1fr 2fr 1fr;, then the first card will take up 1/4 of the page, the second 2/4, and the third 1/4 since 1 + 2 + 1 = 4.

In the end product, we want cards that take up 1/3 of the page. So, we would use grid-template-columns: 1fr 1fr 1fr; instead. We could also write this as grid-template-columns: repeat(3, 1fr); to say that we have 1fr repeated 3 times.

We can also have a grid-gap to add a gutter between each card.

.card-container {
  display: grid;
  grid-gap: 10px;
  grid-template-columns: repeat(3, 1fr);
}

🎉 Now we have a card layout!

See the Pen center element with flexbox by Ali Spittel (@aspittel) on CodePen.

A Complete Beginner's Guide to Web Development

Tue, 06 Oct 2020 00:00:00 GMT

You most likely visit websites almost every day, whether to interact with friends on social media, to shop, to do work, or thousands of other activities. But, how are websites made? This post will take you from beginner to creating a website that anyone on the web can visit!

If you're brand new to programming, you may also want to read this post!

How the Browser Works

If you're reading this article, you've used a web browser before. Browsers like Google Chrome, Mozilla Firefox, Microsoft Edge, and Apple Safari allow you to access the internet.

First, a user chooses a URL they want to go to - for example, they could type "https://twitter.com" into the URL bar and press enter, or they could click a link somewhere else online. This makes a request to a server.

A server is a computer that can handle these requests and then return information to the browser. This data is called the response. Often, that response contains an HTML page that the browser can display to that user.

This process is called the request-response cycle.

An Example: Twitter

Let's dive a little deeper with an example. First, the user makes a request to Twitter by typing "https://twitter.com" in the URL bar. Then, a Twitter server decides what information should be returned to the requester.

Let's discuss the URL a little more: "https://twitter.com" returns the home feed page. If the user navigated to "https://twitter.com/aspittel" instead, they'd expect to see my profile and tweets instead. The server is responsible for obtaining the appropriate information based on the user's request. The website data, such as Tweets and users, are stored in a database. The server queries that database for the appropriate data for the page and performs other logic to manipulate that data.

Finally, the server responds with the response, which will be an HTML page with the correct data plugged into it.

Want more advice on learning to code?

Download my free Ebook!

Frontend vs. Backend Development

Let's talk a little about the technologies that go into web development. We normally divide development into Frontend and Backend. Frontend developers work on the user interface side of websites, so how the page looks, displaying the content, and how the user interacts with the site. Backend developers work on the server-side -- they write the logic that decides which data is sent to the user.

Frontend developers normally use HTML, CSS, and JavaScript -- which we will discuss more in this post. Backend developers have a lot more languages to choose from such as Python, PHP, Java, and C#.

To get started, let's write a frontend website.

Frontend Technologies

Three primary languages go into websites: HTML, CSS, and JavaScript.

HTML is responsible for the content of web pages -- things like text, images, videos, and headings are controlled by HTML.

CSS is for styling websites, so colors, fonts, and the positioning of elements. We can use CSS to style the content we create with HTML.

Finally, JavaScript makes web pages interactive. Some examples would be popups and data that changes. You can also use JavaScript to write or update HTML, so some websites are written entirely in JavaScript now!

Let's learn the basics of these frontend languages, and build an "about me" site with HTML and CSS.

Let's Create a Website

The first thing we need to do is download a text editor, which will allow us to write code. There are a lot of options on which to use, but my favorite is Visual Studio Code. Go ahead and download it on your computer.

Once it's downloaded, open the application. Also, create a folder on your computer. On a Mac, you can open up the finder application and then click file > new folder. On a Windows computer, you can do similar with the File Explorer app. Call the folder about-me or whatever you want to call it!

Now, navigate back to VS Code. Click on the Open folder... link under Start. Then, select the folder you just created.

Now, we'll create two files, index.html and style.css. You can do this in VS Code by clicking on the icon that looks like two pieces of paper on the left-hand bar.

Then click on the new file button next to the name of the folder. You may need to hover over the explorer section on the left that opened when you clicked the two pieces of paper button. Then enter the name of the file and press the enter key.

You can also create the files in your finder or file explorer if you're more comfortable with that!

HTML

We write HTML using tags that describe what type of content is between them. For example:

<h1>Hello World</h1>

<h1> is the open tag, it denotes that Hello World, our content, is a first level header. </h1> is the close tag, which ends the header.

Let's go ahead and add code to our website.

In VS Code, click on the index.html file you created to open it up.

In the file, add the following code:

<html></html>

These tags say that anything between them is HTML -- this may be obvious to us, but it's good practice to tell the browser that too.

Let's go ahead and add a <head> and a <body> tag inside of the <html> tags:

<html>
  <head></head>
  <body></body>
</html>

The body tags will contain all our page content -- the stuff that will show up to the user. The head tags will contain configuration information about the page.

Inside the head tags, we'll add a title tag and inside the body tag we'll add an h1 tag.

<html>
  <head>
    <title>About Me</title>
  </head>
  <body>
    <h1>Hello World</h1>
  </body>
</html>

Now, save the file. You can do this using the shortcut cmd + s or ctrl + s or by clicking file > save on the menu bar of your computer.

Now, let's open up this website on your computer. In your finder, right-click on the file and click open with > Chrome or your browser of choice. On a Mac, you can also double click the file.

Your browser should open up with a web page:

The Hello World comes from your h1 tag, and the text on the tab comes from the title tag. Let's add some more information!

<html>
  <head>
    <title>About Blair</title>
  </head>
  <body>
    <h1>About Blair</h1>
    <p>
      Blair is a very sweet mini double doodle. 
      She likes chasing balls and eating peanut butter.
      She also likes napping on her mama's lap while she works.
    </p>
    <img src="https://pbs.twimg.com/media/EiAQnwXX0AESbgZ.jpg">
  </body>
</html>

Save your file again, and then refresh your HTML page in the browser! New information!

Let's discuss the two new tags. The p tag is for paragraphs. The img tag is a little different. First, it's a self-closing tag which means that we don't need a close tag for it. It also has an attribute. Attributes are additional information that we can add to tags. The src attribute holds the URL for an image. You can pick any image on the web!

Let's add a second attribute to our img tag -- alt.

<img src="https://pbs.twimg.com/media/EiAQnwXX0AESbgZ.jpg" alt="Blair lying on her back on her bed">

Alt-text is what will be read to users utilizing screen readers, it's really important to focus on making your HTML accessible by using tools like alt text.

This is just a small sampling of the things we can do with HTML, here is a list of more resources you can explore.

CSS

Our web page works, but it isn't very pretty yet -- it's just black text on a white background. Let's add some CSS to style our page!

First, we need to link our style sheet to our HTML page. We will do that inside of our head tag:

<head>
  <title>About Blair</title>
  <link rel="stylesheet" href="style.css">
</head>

This links our CSS sheet to our HTML page, so we can now write some code to style our page. Save your HTML file and then open up the style.css file in VS Code.

With CSS, we select elements from our HTML and add styling to them. Let's make our image a little smaller:

img {
  height: 200px;
}

The img says that we are adding styling to our <img> tags. Everything inside the {} will apply to the imgs. Then, height: 200px; is a rule. In this case, we are saying that our images will be 200 pixels tall.

Let's also add a background color to our page:

body {
  background-color: lightpink;
}

Play around with adding some more styles -- color and font may be good to try!

I also wrote this full guide to CSS if you want to dive into it deeper.

Deployment

Now we have a website, but we can only access it on our computer. We need to use a server to make it available to other users on the web. Managing our own server would be quite a bit of work and pretty expensive. We'll instead use a cloud-based server via AWS. This means that you can just upload your files and AWS will host them for you, it'll also be free for the first year. After that, the pricing will look like this.

First, create an AWS account. Then, navigate to the AWS Amplify Console. Click the Connect app button, then select Deploy without Git provider (the last option) on the next page.

We will also need to zip our files. In your finder or file explorer, right-click on the about-me folder and click compress folder. Then, drag and drop the generated zip file to AWS.

Finally, click the save and deploy button. On the next page, you may need to wait a few seconds for your site to finish building. Once it does, you'll see a URL that you can send to anyone! Here is mine.

Conclusion

Web development is an awesome career path, and there is so much you can learn within it. Hopefully, this tutorial got you interested in learning more! Here are some of my favorite resources for getting started.

Learning Tips for Programmers

Tue, 29 Sep 2020 00:00:00 GMT

One of the most challenging but exciting parts of being a programmer is that the field is constantly evolving and the learning is never done. Learning is a topic near and dear to my heart: I'm a mostly self-taught developer, I studied education in college, and I taught at a bootcamp for years. I wanted to write down some of my tips for learning in hopes that these may help you in your process.

Planning

The first stage of learning is the planning phase: what should you learn in the first place. For those just starting out, figuring out what you need to know will be the first step. For those more established in the field, you'll probably have a topic that you need to learn for some reason or another.

If you're just starting out, I recommend exploring first -- try writing some code, following some tutorials (here are some of my favorites), and figuring out what you enjoy. Then figure out what your learning goal is: do you want to become a professional developer, do it as a hobby, or add an additional tool to your skill-set?

Once you have a list of skills you need to learn, create a learning plan. This may evolve over time as you learn more about the topic, but having an outline of what you need to learn will help you allocate time and structure your materials. Here is a great video on how to create a learning plan.

Stay on Track!

You may be tempted to completely pivot topics, especially if your current one gets difficult. But, only pivot as an absolute last resort. There are usually peaks and valleys in learning, and you need to get through the difficult parts to really learn something.

It's also important to not get shiny object syndrome where you see a new tool come out or see someone discussing a technology and you decide to abandon everything and go in that direction. Stay steady in what you're learning, depth of knowledge in an area is much better than being able to write "hello world" in 20 languages.

Build a Habit

I feel like I bring up Atomic Habits in half of my blog posts, but it's just that good! There are groups like #100DaysOfCode that can help you build up the programming habit, or you could use a habit tracker like Done.

Don't Just Use Tutorials

I have written about this extensively in the past, but make sure to actually build things yourself. Problem solving is the most important skill to build as a programmer.

When I teach classes, I follow the format "I do, we do, you do" in which I conceptually explain something, then we do a code along where I write code on a projector and everyone follows along on their computers, finally the students do an exercise on the same topic. You could re-create this process independently by watching or reading a tutorial, following along with the code pieces, and then challenging yourself to build an app or feature with what you've learned. Then test yourself again in another context!

There are studies that lectures and reading alone are not good for making learning stick. Tutorials follow the same model. Make sure to test yourself by building applications, taking notes, and quizzing yourself on concepts.

As with learning a new spoken language or an instrument, practicing is key. When you start learning a new topic, the neural pattern for it is weak. When you have it down cold, that neural pattern will be more permanent. Practicing a bunch is the best thing you can do. Reading about riding a bike will help to a certain extent, but at some point you just have to ride it to get better. Write code as much as possible, and challenge yourself to solve difficult patterns.

Learning Styles

I'm sure you've been asked at some point "what's your learning style?" or been told to really prioritize that when you're learning something new. It turns out that the idea of learning strategies, where some people learn best visually, others through text, others through hearing is mostly debunked. It turns out, it's advantageous to learn the same topic in multiple modalities or to use the best modality for the topic. So, use strategies and resources that work well for you, but also switch things up and try learning in different ways.

Strategies

Take Notes

There is a ton of research that taking notes when you're learning is beneficial, especially if those notes are hand-written. I normally use my iPad to write my inital notes while I'm going through a course. Then, I use Foam to further organize those thoughts and make them into something I can come back to. If you're artistic, sketch notes are so cool and the drawings will help you build connections.

Put Your Learning in Context

It's much better to learn new information in context of what you already know. I remember when I was learning React, there was a tutorial showing how to do things in both JQuery, which I knew, and React. It was so helpful to see both the familiar and unfamiliar way of doing something. Make explicit links from something you already know to something new. You can use tools like mindmapping to do this, or you could just be mindful about noting links in your normal notes!

Learning in Public

One of my favorite quotes is, "When one teaches, two learn." by Robert Heinlein. One of the best ways to solidify your knowledge on a topic is to teach it to someone else. You can create resources for the public, like blog posts or videos, or you can explain your learnings to a friend or even a meetup or conference! Here's a great resource on why and how to learn in public.

Quiz Yourself

Make it Stick is an awesome book about how to solidify concepts in your memory. I generally believe that understanding is more important than memorization for most developers, but if you're studying for interviews or tests you may need to focus more on memorization. The authors of "Make it Stick" recommend quizzing yourself to build up recall. You could build up a flashcard deck on the topic you're learning or challenge yourself to create something or solve a code challenge without any resources.

Come Back to Topics

Instead of learning a topic all at once, come back to it continuously. Spaced repetition is when you have shorter study blocks with breaks in between your sessions. So, you may start learning a topic one week, then come back to it a week later, and then a week after that. This time in between will force you to review and recall your new knowledge, solidifying the neural patterns for retrieving the information. Have you been told that cramming for tests is a bad strategy? This is why!

A potential plan that utilizes spaced repetition may look like this:

Day one: Learn CSS fundamentals
A week later: Learn a CSS concept that builds on the fundamentals
A week after that: Build a project that uses both concepts

You don't necessarily need to re-read the same tutorial, but make yourself review topics so that they become more and more familiar. Learning something once usually doesn't make it stick.

Take Breaks

I cannot recommend the Coursera Learning how to Learn course enough. One of their main focuses is on the two types of thinking: focused and diffuse. Focused is when you're concentrating on learning something or solving a problem. Diffuse is when you're in a more relaxed state. Often times, the diffuse mode is where links are made from one topic to another and knowledge is solidified. You may have heard the trope of "solving a bug in the shower", and it holds a lot of truth! Make sure to take breaks and step away from your computer. It's so important for learning and life balance!

In addition, sleep and exercise help with learning as well -- make sure you're taking care of yourself and not just coding all the time!

Fixed Vs. Growth Mindset

Believing that you can learn something is a huge part of actually being able to learn it. Carol Dweck's book "Mindset" focuses on the fixed vs. growth mindsets. In a fixed mindset, you believe that your attributes are static and that they will be unable to learn or improve their talents. In a growth mindset, people believe that they can improve and learn. People with a growth mindset are much more likely to put the time and effort needed into learning new material, and they're much more likely to enjoy learning. There are many factors that go into a growth vs. fixed mindset, such as upbringing and educational environment, but if you find yourself in a fixed mindset work on growing a growth mindset.

Ness Labs has a bunch of amazing posts on neuroscience, and this post has a bunch of strategies for moving into a growth mindset. Some include: acknowledging the research that brain structure is not fixed, appreciating criticism, and putting a positive framing on failure.

Believing in yourself is such an undervalued yet important piece of learning!

The Levels of Learning

Bloom's Taxonomy provides an awesome framework for assessing your knowledge and expertise on a topic. First is factual knowledge, then conceptual, then procedural, and finally metacognitive.

Factual knowledge would be something like "CSS uses curly braces and text", conceptual knowledge would be "CSS is used to style web pages, you use selectors to choose which element or groups of elements to style", procedural knowledge would be the ability to style a web page with CSS, finally metacognitive would be knowing your strong points and weaknesses with CSS and being able to fit it into the bigger picture of web development.

Adding reflections into your learning process will help you progress within Bloom's taxonomy -- fit your new knowledge into context of all your learning and self-assess your progress and topics you're unclear on or haven't learned yet.

Building a Full Stack Application with AWS Amplify: A Beginner-Friendly Guide

Tue, 22 Sep 2020 00:00:00 GMT

A few weeks ago, I joined the AWS Amplify team as a Senior Developer Advocate. I am really excited to be working on a product that makes the power of AWS much more accessible to frontend and mobile developers. I want to do a beginner-friendly introduction to building a fullstack application with AWS Amplify.

First, before you get started make sure you are familiar with HTML, CSS, Git and Github, APIs, and JavaScript without a framework (Vanilla JavaScript).

What We'll Build

In this tutorial, we're going to build a Gif display app where a user can view gifs, add new ones, edit existing ones, and delete them.

Setup

We are going to setup our files, install the necessary software, and configure babel. If you want to jump right into the code, here is a branch with these steps already done, all you'd need to do is the software installation, download the files, and then run $ npm install in the folder you downloaded.

Note: The commands that start with $ are meant to be run in the command line, but omit the $ when you copy the command!

Follow this documentation and video for installing the Amplify CLI. Note: you will need an AWS account and to install Node!
Install Parcel by running this command in the terminal $ npm install -g parcel-bundler
Create the files needed for your project by running the following commands:
1. Create a directory called giphlify: $ mkdir giphlify
2. Change into that directory: $ cd giphlify
3. Create a src directory: $ mkdir src
4. Create a JS file in that directory: $ touch src/script.js
5. Create a css folder: $ mkdir css
6. Create HTML and CSS files: $ touch index.html css/style.css
7. Create a Babel config file: $ touch .babelrc
Initialize your project:
1. Setup a npm project (the --y will accept the default configuration!): $ npm init --y
2. Initialize a git project: $ git init
3. Install AWS Amplify: $ npm i aws-amplify
4. Install Babel: $ npm i --save-dev babel-core
5. Install Parcel locally (this is for when we deploy our app): $ npm i --save-dev parcel-bundler
Setup your Babel config: In your .babelrc file, copy and paste the following

{
  "presets": [
    ["env", {
      "targets": {
        "browsers": ["last 2 Chrome versions"]
      }
    }]
  ]
}

Your file tree should look like this!

This will allow us to use all the AWS Amplify and Parcel features we need.

In your package.json file that was created in the npm init step, update your scripts object to contain two more items, start and build:

 "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
+   "start": "parcel index.html",
+   "build":  "build index.html "
  },

Note: remove the plus signs from the beginning of each line if your copying and pasting 😊

😅 Okay, now your application is setup! It may feel like a lot, but we also did a lot of installation. Next time you create an AWS Amplify app, you can skip the first few steps. Also, using Parcel will be way simpler than a lot of the alternatives, and it will give us a bunch of helpful features!

⏱ Here is what your code should look like at this point!

Add an API

The next thing that we need to do is initialize AWS Amplify.

We'll first run the command $ amplify init. You will then be asked some questions about your project:

? Enter a name for the project (giphlify) press enter to accept the recommended giphliphy!
? Enter a name for the environment press enter to accept the recommended dev since we are in development mode.
? Choose your default editor: choose your text editor, mine is Visual Studio Code so I would use my up and down arrow keys to select it and then press enter to continue.
? Choose the type of app that you're building use your up and down arrow keys to navigate to javascript and then press enter (it will probably already be selected).
? What javascript framework are you using select none
? Source Directory Path: press enter to select the default, src
? Distribution Directory Path: press enter to select the default, dist
? Build Command: press enter to select the default, npm run-script build
? Start Command: press enter to select the default, npm run-script start
? Do you want to use an AWS profile? press y for yes
? Please choose the profile you want to use select your AWS profile

Now you have an AWS Amplify project 🎉

We also want to add an API to the project so that we can store our data in a database and utilize it. APIs allow us to interact with and manipulate our data. Four common actions are create, read, update, and delete, which are often referred to as the CRUD actions. We will integrate all four into our application!

You can initialize an API by running the command $ amplify add api. Similar to when we initialized AWS Amplify, it will ask a couple questions in order to build the best possible API for you! Here's how to answer them for our Giphlify app:

? Please select from one of the below mentioned services: Select GraphQL.
? Provide API name: Use the default provided, giphlify.
? Choose the default authorization type for the API Select API key.
? Enter a description for the API key: You can just press enter here.
? After how many days from now the API key should expire (1-365): Type 365 (or shorter if you want a close expiration date)
? Do you want to configure advanced settings for the GraphQL API Choose "No, I am done."
? Do you have an annotated GraphQL schema? Type "n" for No
? Choose a schema template: Select "Single object with fields (e.g., “Todo” with ID, name, description)"
? Do you want to edit the schema now? (y/N) type y to open your text editor!

The last command should open up the file /amplify/backend/api/giphlify/schema.graphql in your text editor. That file should already have some code in it, the schema for a Todo if you were to build a Todo list app! We will delete the schema that's there and add a new one.

type Gif @model {
  id: ID!
  altText: String!
  url: String!
}

GraphQL is a "query language for your API." It will allow us to get exactly the data we need from our API and modify it in the ways we need. In this code snippet, we are creating a data type, a Gif. The @model tells AWS Amplify to add this data to our database. Then the three lines inside the braces are the fields we want each gif to have. The id will be added automatically and will be unique for each gif, the altText will describe the image for users with screen readers and search engines, and then the url will be a link to the image. Each field also has its data type after the :. The id is an ID type and the other two are Strings. The !'s say that the field is mandatory for each image.

Configuring and initializing our API generated a bunch of files for you, most of which we won't need to worry about -- we'll use some in the future!

Finally, we'll run the command:

$ amplify push --y

This will modify our API and deploy it! Just like that our app's backend is complete. Now it's time to talk about the frontend!

Code Setup

Open your text editor up with your project, for me that command is $ code .. We will start out with creating our index.html. Open that file up, and add boilerplate HTML code. Also, link you JavaScript and CSS files.

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Document</title>
  <link rel="stylesheet" href="./css/style.css">
</head>
<body>
  <h1>Giphlify</h1>
  <script src="./src/script.js"></script>
</body>
</html>

Go ahead and run the command $ npm run start in your terminal. This will use Parcel to hot reload your code, allow you to use modules, and will run Babel. Keep this server running as we write more code, it'll keep updating it for you! If you need to exit the server, run ctrl + c to shut it down. Also, Parcel will create files in a folder called dist/ which are already in your .gitignore. These are the bundled versions of the files that Parcel has created and is actually hosting.

Navigate to localhost:1234 in your browser of choice to see your application!

Now, go to your src/script.js file. In here, we'll add:

import Amplify from '@aws-amplify/api'
import awsConfig from './aws-exports'

Amplify.configure(awsConfig)

This will use the configuration information in the src/aws-exports.js file to configure AWS Amplify for our frontend application!

Note: if you haven't seen the import syntax before, check out this resource. Parcel is also helping us here!

Also, add .cache/ to the end of your .gitignore. These are files that Parcel creates that we don't want to store in our repository.

⏱ Here is what your code should look like at this point!

Create Form

Now, the first feature we need to implement is a create form to add new gifs. Let's add some HTML first, we will make a form with two fields, one for the gif's url and one for its altText. We'll also add a submit button and labels for each form field.

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Document</title>
  <link rel="stylesheet" href="./css/style.css">
</head>
<body>
  <h1>Giphlify</h1>
+  <form id="create-form">
+    <h2>Create a New Gif</h2>
+    <label for="altText">Alt Text</label>
+    <input type="text" name="altText" id="altText">
+    <label for="url">URL</label>
+    <input type="text" name="url" id="url">
+    <input type="submit" value="Create">
+  </form>
  <script src="./src/script.js"></script>
</body>
</html>

Now we'll write the JavaScript code to make our form work.

First, modify the import on line one to also import API and graphqlOperation from AWS Amplify:

import Amplify, { API, graphqlOperation } from '@aws-amplify/api'

When we pushed our API to AWS Amplify, it also generated some GraphQL queries that we can use in our code. Checkout the files in /src/graphql. You'll see queries, which will allow us to select data to display on our application, mutations, which will allow us to change our data, and subscriptions, which will allow us to "listen" for changes in our application. For now, import the createGif mutation!

import Amplify, { API, graphqlOperation } from '@aws-amplify/api'
import awsConfig from './aws-exports'

+ import { createGif }  from './graphql/mutations'

Now, we'll add an event that listens for the create-form to be submitted. We will grab the user's form inputs and put them in an object. Then, we will use AWS Amplify's API features to run our createGif mutation with the data the user provided. Check out the commented code below!

// create an async function: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
const createNewGif = async e => {
  e.preventDefault() // don't refresh the page after form submit

  const gif = {
    // grab the value of the `altText` field
    altText: document.getElementById('altText').value,
    // grab the value of the `url` field
    url: document.getElementById('url').value
  }

  try {
    // Make the API request: provide the createGif operation, provide the user's gif data
    const newGif = await API.graphql(graphqlOperation(createGif, { input: gif }))
    // Print the data to the console once it comes back
    console.log(newGif)
    // Reset the form (make the fields blank again)
    document.getElementById('create-form').reset()
  } catch (err) {
    // If the request fails, print the error message to the console
    console.error(err)
  }
}

// run our createNewGif function when the form is submitted
document.getElementById('create-form').addEventListener('submit', createNewGif)

Try and type the following data in your form:

altText: excited black lab jumping up and down
url: https://media.giphy.com/media/eLpO6JFWmTximd6608/giphy.gif

Note: to get more gifs, you can go to Giphy and select any gif link. Make sure to grab the url with the .gif extension so our img tags will work properly. Also, any image on the internet should also work!

⏱ Here is what your code should look like at this point.

What the interface should look like:

And what should appear in the console when you click create:

Amazing, now we can create a gif! Now let's display them all on the page!

Display all Gifs

First, let's add an HTML element that will contain all our gifs:

...
<body>
  <h1>Giphlify</h1>
+ <div class="container"></div>
  <form>
...

Let's import the GraphQL query to list all of our gifs:

import Amplify, { API, graphqlOperation } from '@aws-amplify/api'
import awsConfig from './aws-exports'

import { createGif }  from './graphql/mutations'
+ import { listGifs } from './graphql/queries'

We will also add a function that runs on page load that gets all the gifs and displays them:

const getGifs = async () => {
  // select the container element
  const container = document.querySelector('.container')
  // reset its current contents
  container.innerHTML = ''
  // make a request to get all our gifs
  const gifs = await API.graphql(graphqlOperation(listGifs))
  // loop through our gifs and 
  gifs.data.listGifs.items.map(gif => {
    // create a new image element
    const img = document.createElement('img')
    // add the src attribute to the img
    img.setAttribute('src', gif.url)
    // add the alt attribute to the img
    img.setAttribute('alt', gif.altText)
    // add the image to the container
    document.querySelector('.container').appendChild(img)
  })
}

// run this function on page load
getGifs()

Let's also re-fetch all the gifs once we create a new one:

const createNewGif = async e => {
  ...
  try {
    const newGif = await API.graphql(graphqlOperation(createGif, { input: gif }))
+   getGifs()    
    document.getElementById('create-form').reset()
  }
  ...
}

Your app should now look like this and should update when you add a new gif!

⏱ Here is what your code should look like at this point.

Edit a Gif

Now we're done with two of the CRUD actions: create and read! Now we need to add edit and delete. I'm going to create a second form that allows me to edit a gif. When I click on any gif, it will populate the edit form with the gif that was clicked on.

Let's add an edit form after the create form:

<h2 id="edit-title">Update </h2>
<form id="edit-form">
  <label for="altText">Alt Text</label>
  <input type="text" name="altText" id="edit-altText">
  <label for="url">URL</label>
  <input type="text" name="url" id="edit-url">
  <input type="submit" value="Edit">  
</form>

Let's add an event listener to each image, so that when we click on one it populates the edit form with that gif's information. We will also add a global variable that stores which gif is currently being edited.

+ let currentGifId = ''
...
const getGifs = async () => {
  ...
  gifs.data.listGifs.items.map(gif => {
    const img = document.createElement('img')
    img.setAttribute('src', gif.url)
    img.setAttribute('alt', gif.altText)
+   img.addEventListener('click', () => {
+     currentGifId = gif.id
+     document.getElementById('edit-altText').value = gif.altText
+     document.getElementById('edit-url').value = gif.url
+     document.getElementById('edit-title').innerText = `Update ${gif.altText}`
+   }) 
    document.querySelector('.container').appendChild(img)
  })
  ...

Let's import the updateGif mutation:

import Amplify, { API, graphqlOperation } from '@aws-amplify/api'
import awsConfig from './aws-exports'

+ import { createGif, updateGif } from './graphql/mutations'

When the user submits the edit form, we will need to run this mutation with the user submitted data:

const editGif = async e => {
  e.preventDefault()

  try {
    return await API.graphql(graphqlOperation(updateGif, {
      input: {
        id: currentGifId,
        altText: document.getElementById('edit-altText').value,
        url: document.getElementById('edit-url').value
      }
    }))
  } catch (err) {
    console.error(err)
  }
  getGifs()
}

document.getElementById('edit-form').addEventListener('submit', editGif)

Note that this time we need to include the id of the gif we want to edit so that our API edits the correct Gif!

⏱ Here is what your code should look like at this point.

Here is a gif of how this feature should work:

Delete a Gif

Finally, we need to add the ability to delete a gif. We will make one delete button that will delete the gif with the id currently stored in currentGifId, so the user will click on a gif and then click the delete button to remove it.

...
<h2 id="edit-title">Update </h2>
+ <button id="delete-button">Delete</button>
<form id="edit-form">
...

Let's import the delete mutation:

import Amplify, { API, graphqlOperation } from '@aws-amplify/api'
import awsConfig from './aws-exports'

+ import { createGif, deleteGif, updateGif } from './graphql/mutations'

Now, we'll add an event listener so that when the user clicks the delete button the gif is deleted!

const removeGif = async () => {
  await API.graphql(graphqlOperation(deleteGif, {
    input: { id: currentGifId }
  }))
  getGifs()
}

document.getElementById('delete-button').addEventListener('click', removeGif)

Now we have a fullstack CRUD app 🎉🎉🎉

⏱ Here is what your code should look like at this point.

Styling

Okay, this app is functional but not the prettiest. Feel free to style the app however you want; however, here is my app with finished styling. I also made it so that the application has modals for the forms, and I refactored the JavaScript code a little bit to be more modular and readable.

Deploy the Site

Finally, we need to add hosting to deploy our frontend.

First, we need to push this tutorial code to GitHub by:

creating a new repository by clicking the plus button on the top right of the page.
choose a repository name and click create repository
Then, copy the commands from …or push an existing repository from the command line and run them in your terminal.
Run git add . && git commit -m "tutorial complete" && git push in your terminal to send your latest changes.

Then, you can run the command: $ amplify add hosting. Select Continuous deployment (Git-based deployments) for the first question and then head to the Amplify Console when it pops up.

Choose GitHub in the From your existing code menu, and click continue
Type in the name of your GitHub repo you just created (it should autofill!) and then click next.
The build settings will auto-populate, though you need to click edit and change the baseDirectory under artifacts to dist:

...
artifacts:
  baseDirectory: dist

Click save and deploy

It may take a few minutes, but then you'll have your application up and ready for anyone to visit.

For the first 12 months of your AWS account existing, Amplify and Appsync, which we're using for the api, has a free tier that will most likely cover your hosting. After that, here is more information about API hosting and here is more information about static site hosting!

Conclusion

In this tutorial, we built a fullstack CRUD app with JavaScript, HTML, CSS, and AWS Amplify. We were able to use AWS Amplify's generated GraphQL queries and mutations to interact with our data. We also deployed the frontend to AWS Amplify Hosting. A few next steps could be to add user authentication or allow users to upload their images instead of just posting links. If you have any questions about this tutorial, please tweet me!

A Complete Beginner's Guide to React: Hooks Edition

Tue, 15 Sep 2020 00:00:00 GMT

A few years ago, I wrote an introductory React tutorial based on a workshop I taught. Since that point in history, I've taught hundreds of new web developers React, and the library has evolved significantly. I thought it was time to come back to the fundamentals and discuss learning React from absolute zero in the era of Hooks.

Some pre-requisites for the tutorial in this blog post: HTML, CSS, and JavaScript fundamentals.

React is a JavaScript library which was written by Facebook in 2013. It speeds up and simplifies the frontend development process. It has many key features that aid in the development of user interfaces, such as JSX, components, and the virtual DOM. It's almost inescapable in the current era of frontend development. In this tutorial, we'll learn about the React fundamentals, use Create React App to scaffold a project, build out an app with React state and props, and then deploy it to AWS Amplify.

Components

You may have learned very early on in your programming journey to "separate concerns" or put your HTML, CSS, and JS in separate files. React flips this on its head. We will instead break our webpages into chunks called components and write all of their display and logic code all in one. This will increase the modularity of our user interfaces, and we can compose components in infinite combinations and reuse them over and over again.

In many web pages, you will have similar user interface components over and over again -- think, for example, of Facebook's like button. It's on posts, videos, and pictures. If you were using standard HTML, each one of those buttons would need to be written separately, given a class to add styling to them, and then JavaScript code would need to be written to implement their behaviors. If you needed to update these buttons, code would likely need to be changed in many places.

React's component-based architecture allows us to instead reuse that button over and over again and only update code in one place if needed.

Let's see how a Facebook status may be broken down into components:

We can also have subcomponents which are components within a parent component.

For example, the three buttons at the bottom of the status could be broken into their own components.

There are a bunch of ways you could break down these components and subcomponents depending on your application's needs.

Installation && Setup

First, install Node.js. If you haven't encountered Node.js, it is a runtime that allows you to write JavaScript outside the browser. In this case, we'll be using it to make development on our React application as easy as possible.

Once you have Node installed, open up your command line and run: npx create-react-app color-switcher. Heads up, this command may take a few minutes to run.

npx is a tool that comes with Node that allows you to run commands without installing them first.
We are using it to run create-react-app which does what the name implies! It scaffolds a React application for us and sets up Babel and Webpack, two super important tools we'll come back to later in the tutorial.
Finally color-switcher is the name of our application, you will need to re-run the npx create-react-app your-app-name command for each app you build.

Once your app is created cd into the directory that create-react-app created for us.

cd color-switcher

Create React App Generated Files

Open up the directory in your text editor of choice, and check out the files that were created.

There are a bunch! But don't be intimidated, let's do a quick run-through of the files create-react-app generated. The ones highlighted are the important ones for us:

node_modules/ - the Node modules we are using for our project, essentially other people's code that's going to make our life easier.
public/
- favicon.ico - the icon that shows up when you favorite a site
- index.html - the file our JavaScript attaches to
- logo.png files - different icons for our app
- manifest.json - allows us to make our app into a progressive web app, we won't make our app into one today.
- robots.txt - declares the rules for bots on our site
src/
- App.css - Where our App component's styling will go
- App.js - Where our App component will be written
- App.test.js - A file where you can write automated tests for your App component
- index.css - A file for global styles for your application
- index.js - Configuration for your React application
- logo.svg - a React logo
- serviceWorker.js - code to configure
- setupTests.js - configuration for automated testing
.gitignore - files you want to keep local and hide from git
package.json - holds project metadata
package-lock.json - auto-generated file to track dependencies

There are a bunch of files created, but we only need to worry about a very few of them.

The index.js File

Let's break down what's in the index.js first:

import React from 'react' - import the React library. We need this in every file where we use JSX syntax. import ReactDOM from 'react-dom' - ReactDOM allows us to use React in the browser import './index.css' - apply the global styles import App from './App' - import the App component

Now for the important code! We are going to take our <App> component and attach it to an element with the id #root. You can find that element in the public/index.html file. This allows our React code to actually render on the page.

React utilizes the virtual DOM, which is a virtual representation of the DOM that you would normally interact within Vanilla JavaScript or JQuery. This reactDOM.render renders this virtual DOM to the actual DOM. Behind the scenes, React does a lot of work to efficiently edit and re-render the DOM when something on the interface needs to change.

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

The <React.StrictMode> component is a tool that will give you extra warnings about issues that may exist in your code.

Again, we'll just ignore the service worker code, it goes above and beyond what we need to do.

You don't need to change anything in the index.js file, I just wanted to run through it since it is so key to making our application work.

A React Hello World

Now for the fun part, writing the code! Open up your App.js file. This will be our top-level, or root, component for our application.

Inside that file we already have some code written. We are again importing React (which we need to do in every file that we use React in), the React logo, and the CSS file specific to this App component.

We also have a function, App that returns a bunch of what looks like HTML -- this is actually JSX.

Finally, we are exporting the component so we can import it into other files, in this case, our index.js that was generated for us.

Let's go ahead and remove the logo import and change the JSX code so that it only returns <h1>Hello, World</h1>

import React from 'react'
- import logo from './logo.svg'
import './App.css'

function App () {
  return (
+    <h1>Hello world!</h1>
  )
}

export default App

JSX is an extension of JavaScript that allows you to write what looks like HTML directly in your JavaScript code. You can't natively use JSX in the browser, but we will use a library called Babel to transpile (or convert) our JSX into regular JavaScript so that the browser can understand it. JSX is actually optional in React, but you'll see it used in the vast majority of cases.

Okay, now you've written your first React code, but how do you see the output? Go back to your CLI and run npm run start. A webpage should pop up that displays your React app. It will hot reload, so every time you change your code and save those changes, your application will show those changes automatically. In order to exit out of the server, you can press ctrl + c. It may be helpful to have two terminal windows or tabs open while you're developing React apps because you can't write additional commands in the session where the server is running.

React Color Switcher

First, we're going to build a color picker application -- the background of the page will change color based on a button the user selects.

The first step is to build out the static user interface. First, we'll add an enclosing div which will be the top-level element of our React application. Then, we'll add another div inside of that one that will allow our content to be centered on the page. We'll also add a header to title our page and three buttons. We are also going to add some className attributes to our elements. In JavaScript, a class is for creating classes in object-oriented programming, so, React can't use the word class to add class names for styling groups of elements. So, it uses className instead.

We will add the following classNames to our elements:

import React from 'react'
import './App.css'

function App () {
  return (
    <div className='react-root'>
      <div className='centered'>
        <h1>Color Picker</h1>
        <button className='red'>red</button>
        <button className='blue'>blue</button>
        <button className='yellow'>yellow</button>
      </div>
    </div>
  )
}

export default App

Since this tutorial is focused on React, we'll just copy some CSS code into your App.css. Remove what's in there and replace it with:

html, body, #root, .react-root {
  height: 100%;
  width: 100%;
  background-color: white;
  color: black;
  display: flex;
  justify-content: center;
  align-items: center;
}

.centered {
  text-align: center;
}

button {
  padding: 10px;
  margin: 5px;
  border: 2px solid white;
  color: white;
  font-size: 20px;
}

.red {
  background-color: red;
  color: white;
}

.blue {
  background-color: blue;
  color: white;
}

.yellow {
  background-color: yellow;
  color: black;
}

Now, your app should look like this:

Now we need to actually make it do something!

Any variables we want to have changed while our application is running need to be stored in state. This will cause React to automatically update our component's appearance each time a state variable updates.

React State

In order to utilize state, we will import the useState hook from React.

Hooks are new to React -- they were introduced near the end of 2018. React looks very different from when I learned it five years ago. ES6 wasn't fully implemented yet, so we wrote components using objects and the React.createClass function. Then there was the era of JavaScript classes, and most recently, React has implemented Hooks, which allow us to write components using just functions. This makes React's syntax simpler and less verbose. According to the React docs, "Hooks are functions that allow us to 'hook into' React features."

In our App.js component, we will update our first line of code.

+ import React, { useState } from 'react'
import './App.css'

The useState hook takes one argument: what the initial value of state will be. It then returns two values in an array. The first is the value of the state variable, the second is a function that will allow us to update state. We will use array destructuring to set both of the items returned to their own variables.

import React, { useState } from 'react'
import './App.css'

function App () {
+  const [color, setColor] = useState('')
  return (
    <div className='react-root'>
      <div className='centered'>
        <h1>Color Picker</h1>
        <button className='red'>red</button>
        <button className='blue'>blue</button>
        <button className='yellow'>yellow</button>
      </div>
    </div>
  )
}

export default App

If you console log each item, you'll see color is an empty string because we provided useState the argument ''. If you changed that empty string to 'blue' then color will then store the value blue! setColor is a function, which we will use to update the color variable.

Now, we need to add an event listener so that when a user clicks on our buttons, the color stored in state updates.

First, we will display the current value of color on the interface. We can do this by writing the color variable in curly braces, this tells React that any code inside the curlies is JavaScript code.

We will also add an onClick attribute to our first button, after that onClick we will add a function that will run when the event fires. This is how we write event listeners in React. For now, we will just console.log('clicked').

import React, { useState } from 'react'
import './App.css'

function App () {
  const [color, setColor] = useState('')
  return (
    <div className='react-root'>
      <div className='centered'>
        <h1>Color Picker</h1>
+        {color}
+       <button className='red' onClick={() => console.log('clicked')}>
          red
        </button>
        <button className='blue'>blue</button>
        <button className='yellow'>yellow</button>
      </div>
    </div>
  )
}

export default App

Check out your JavaScript console and see what's happening!

Now we'll change the event listener function to instead change the color state variable. We can do so by using the setColor function that useState gave us.

<button className='red' onClick={() => setColor('red')}>
  red
</button>

Now, you can see that when you click on the button the word "red" displays on the page! Now let's make both of the other buttons work as well.

<button className='blue' onClick={() => setColor('blue')}>blue</button>
<button className='yellow' onClick={() => setColor('yellow')}>yellow</button>

The last thing that we need to do is actually change the color of the page instead of just displaying the color's name on the page. In our CSS file, we already have three classes for our colors -- yellow, red, and blue. What we need to do is add those classes onto our react-root element so that it changes color to match our color variable. We need to make our className take JavaScript code instead of just a string, and then we will use string interpolation to add our color class to the element.

<div className={`react-root ${color}`}>

Our final code should look like this:

import React, { useState } from 'react'
import './App.css'

function App () {
  const [color, setColor] = useState('')

  return (
    <div className={`react-root ${color}`}>
      <div className='centered'>
        <h1>Color Picker</h1>
        <button className='red' onClick={() => setColor('red')}>red</button>
        <button className='blue' onClick={() => setColor('blue')}>blue</button>
        <button className='yellow' onClick={() => setColor('yellow')}>yellow</button>
      </div>
    </div>
  )
}

export default App

React Props

Now we've used some of React's most important features: JSX and state. There are two more that I want to show you: components and props.

Right now we are actually using a component: App. But, we want to make our components small and reusable. Right now, our buttons follow a pattern. Each displays text, has a className, and has an onClick event. We will make a second ColorChangeButton component so that we can reuse as much code as possible, and if we want to update the buttons in the future we can do so more easily.

The first step is to create another file in your src/ folder called ColorChangeButton.js.

Now, we will create a second React component in this file.

// ColorChangeButton.js
import React from 'react'

function ColorChangeButton () {
  return (
    <button>Hi!</button>
  )
}

export default ColorChangeButton

We'll now go back to our App.js and import our ColorChangeButton:

// App.js

import React, { useState } from 'react'
import './App.css'
+ import ColorChangeButton from './ColorChangeButton'

In our JSX code, we will create three instances of our ColorChangeButton.

 // App.js
  return (
    <div className={`react-root ${color}`}>
      <div className='centered'>
        <h1>Color Picker</h1>
+        <ColorChangeButton />
+        <ColorChangeButton />
+        <ColorChangeButton />
        <button className='red' onClick={() => setColor('red')}>red</button>
        <button className='blue' onClick={() => setColor('blue')}>blue</button>
        <button className='yellow' onClick={() => setColor('yellow')}>yellow</button>
      </div>
    </div>
  )

Boom! Now you should have three more buttons that show up on the page that all say Hi!. This is how we create and include a second component in React.

But, right now our components are pretty boring. They all say the same thing. We want these to eventually replace the three color-changing buttons we have written, so we need to allow our button to be a different color and to have different text.

React uses unidirectional data flow, which means we can only pass data from a parent component to a child component. We will use props to pass data from one component to another.

 // App.js
  return (
    <div className={`react-root ${color}`}>
      <div className='centered'>
        <h1>Color Picker</h1>
+        <ColorChangeButton color='red' />
+        <ColorChangeButton color='blue' />
+        <ColorChangeButton color='yellow' />
        <button className='red' onClick={() => setColor('red')}>red</button>
        <button className='blue' onClick={() => setColor('blue')}>blue</button>
        <button className='yellow' onClick={() => setColor('yellow')}>yellow</button>
      </div>
    </div>
  )

In our parent component, App, we can use what looks like an HTML attribute to send props. In this case, color is the name of our prop and then the value comes after the equals sign, 'red' for the first component, 'blue' for the second, and 'yellow' for the third.

Now, we need to use those props in our child component. Switch over to ColorChangeButton.js. First, we will make our function take the parameter props.

// ColorChangeButton.js
function ColorChangeButton (props) {
  ...
}

Then, you can console.log props before the return to see what's there:

{ color: 'red' } { color: 'blue' } { color: 'yellow' }

It's an object! React combines each prop we send from the parent component into an object with each key and value in the child. So, to access our color in our child component, we would do props.color. Let's make our button display our color as its text and also add the color as a class to the button so that the correct color displays.

// ColorChangeButton.js
import React from 'react'

function ColorChangeButton (props) {
  return (
+    <button className={props.color}>{props.color}</button>
  )
}

export default ColorChangeButton

Now our buttons look the way they are supposed to! The last thing that we need to do is make the click event work. In our App.js, we wrote this code to change the current color:

<button className='red' onClick={() => setColor('red')}>red</button>

The one issue we have is that setColor is defined in our App component, so we don't have access to it ColorChangeButton. Good news though: we have a way to pass data from a parent component to a child component that we learned in the past step: props! Let's pass the setColor function down as a prop to our ColorChangeButton component.

I'm also going to delete our three original buttons since we no longer need them.

 // App.js
  return (
    <div className={`react-root ${color}`}>
      <div className='centered'>
        <h1>Color Picker</h1>
+        <ColorChangeButton color='red' setColor={setColor} />
+        <ColorChangeButton color='blue' setColor={setColor} />
+        <ColorChangeButton color='yellow' setColor={setColor} />
      </div>
    </div>
  )

Now, if you go back to the ColorChangeButton and console.log what the props are, you'll see that you have a second item in the object, for example:

{
  color: "red"
  setColor: ƒ ()
}

Let's use that setColor function:

function ColorChangeButton(props) {
  return (
+   <button className={props.color} onClick={() => props.setColor(props.color)}>
      {props.color}
    </button>
  )
}

export default ColorChangeButton

Now each button should work as expected! This pattern of passing the state change function down from parent to child components is called inverse data flow. It allows us to circumvent the unidirectional data flow nature of React.

Deployment

Amazing, now our application is complete. One small problem though: our application is only accessible locally, meaning that we can't send the localhost URL to friends for them to see the application. We need to deploy our application so that anybody on the web can see it. We will use AWS Amplify to do so with just a few clicks.

First, we need to push this tutorial code to GitHub by:

creating a new repository by clicking the plus button on the top right of the page.
choose a repository name and click create repository
Then, copy the commands from …or push an existing repository from the command line and run them in your terminal.
Run git add . && git commit -m "tutorial complete" && git push in your terminal to send your latest changes.

Then to get it deployed:

Create an AWS account if you don't already have one.
Navigate to the Amplify Console
Click on the orange connect app button.
Choose GitHub in the From your existing code menu, and click continue

Type in the name of your GitHub repo you just created (it should autofill!) and then click next

The build settings will auto-populate, and so you can just click next on the Configure build settings
Click Save and deploy.

For the first 12 months of your AWS account existing, Amplify has a free tier that will most likely cover your hosting. After that, here is more information about pricing!

It may take a few minutes for your app to build, but once it does you will get a URL that anyone can visit! You can visit mine at this url.

Next Steps

This tutorial took you through the basics of React data flow, components, and project setup. Here are some awesome resources for learning more:

In addition, I did a live stream with the content from this tutorial if you'd prefer to view it that way. If you extend what you built, please share it with me on twitter!

Working Remote for Those Who Struggle with It

Tue, 08 Sep 2020 00:00:00 GMT

I have been open about the fact that remote work is very difficult for me. I'm an extrovert, and the social environment at work helps to motivate me and get me through the day. That being said, due to COVID and the evolving nature of tech work, I've been working remote for almost two years. There are a lot of benefits to it, like no commute time, the ability to live wherever, more flexibility, and accessibility. Also, I know it's a huge privilege to be able to work remote during this time, and so few of my non-tech friends have that ability. But, for me, working remote doesn't come naturally. So, I wanted to write down my strategies for making it as enjoyable as possible.

I also want to note before starting that right now many of us are working through the stress of a pandemic, shifting to new modalities at work, struggling with economic instability and unemployment, shifting childcare responsibilities, and dealing with health concerns for ourselves and our families. None of this is normal, make sure to take time for yourself and it's okay to not be okay.

Fake a Commute

This may sound super corny, but mentally having some sort of "commute" to work in the morning and after work in the evening creates some separation in your day. I have a dog, which makes this even easier -- I walk her at the beginning of the day before work and then take her to the park at the end of the day. I also have time to sneak in a bit of a podcast or an audiobook too.

Live with Someone else

When I started working remote, I lived alone. It made work from home really hard because if I didn't actively make plans, I could go days without talking to another human. Earlier this year, I moved in with my partner. Now, I am guaranteed to talk to someone pretty much every day, and I feel much less isolated.

Even if living with another person isn't a reality, having a pet really helps. Having Blair, my dog, makes me get out of the house, and I still have someone with me all day, even if she isn't human. I get cuddles during my breaks, and I even sometimes get a ball thrown at me!

Have a Separate Place to Work

When I started working remote, I lived in an apartment that had essentially been my crash pad before. It was in a perfect location, but wasn't very large and was very old -- it didn't even have a real kitchen! I worked out of a desk in my bedroom. So, I was pretty much in that room for 22+ hours a day. It wasn't great for me mentally to not have a separate workspace, and there wasn't much separation between my work and the rest of my life. I know it isn't realistic for everyone, especially those with families or who live in cities with high rent and low square footage, but having a dedicated workspace that you can close off at the end of the day is so nice and helps you really separate work and the rest of your life.

Upgrade your Place

Earlier this year when the pandemic hit, I lived in a very old studio apartment in NYC, and while it was in the perfect location, it also had a horrible mouse problem, the temperature was always off, and I was pretty much in the same room 24 hours a day. It was miserable.

Moving out of that environment has made working from home much more bearable. Especially since my company has a work from home budget. Getting a comfortable chair, a monitor setup that works for me, and customizations that fit my personality make my workday so much more enjoyable. It has also become a lot more important for me to live in a nice space, and instead of prioritizing living close to work or right downtown, I'm more concerned with living somewhere that's updated, doesn't have a lot of issues, and has space to move around.

Move Around

Even though I think it's really helpful to have a dedicated workspace, I also move throughout my apartment throughout the day. I do a few hours of work at my desk, then take calls from the couch or the dining room table if I don't need a monitor. It's nice to change the scenery and have a different chair at some point in the day. It helps me re-focus as the day goes on.

Remote Lunches with Friends

One of my favorite parts of working in an office is the ability to grab or eat lunch with work friends each day. Something I do at least once a week is schedule a lunchtime video call with a friend, whether they are inside of my company or external. It really breaks up the day, recharges me, and keeps those connections intact.

Schedule Your Day to Work for You

One of the really nice parts of working remote is that other than calls, you can normally schedule your day to fit your schedule and how you work best rather than being standardized to a 9-5. I often read the advice to always get ready for work. I instead normally put on makeup and get dressed nicely mid-day when I don't have early meetings. I also sometimes take runs during my lunch break, and I often work a 7-3 or 8-4 day instead of 9-5. Use the flexibility to your advantage and work a schedule that fits your needs.

Plan Activities after Work

This is much less relevant now since there's a pandemic going on, but I think it's so important to still socialize with friends and do things outside of your house. It can be tempting to become a hermit since you have to actively leave your house to do things after work, but you still need social interaction and to experience life outside your living space. I find making plans with friends makes me more accountable and likely to do things. Even now, setting up virtual or park hangouts adds some variety to the day!

Co-Work with Friends

This is, again, more of a post-pandemic recommendation, but before COVID I used to do co-working days with friends who also work remote. I would either have them over, or we would meet at a coffee shop and we would work together on each of our work tasks. It's a great opportunity to catch up and have the opportunity to have someone to chat with throughout the day.

Schedule Watercooler time with your co-workers

One of the things I miss most about working in an office is unstructured discussion time with colleagues. Most remote calls have a structure and an agenda, but so much valuable brainstorming comes from free-flowing discussions. On past teams, we've scheduled watercooler time or virtual team happy hours, and it's been great to get to know one another and come up with ideas.

Find Online Communities

Even though most things are remote now, having a community who understands what you do and who you can learn from is so important. I love so many Discord and Slack groups in addition to public forums like DEV and Twitter. They allow me to stay involved with the larger developer community.

Conclusion

Remote work is an increasing piece of work in tech, and I know that it's a really amazing thing for a lot of people, especially parents and those who are disabled. There are many nice pieces of it, like being able to live wherever, no commute times, and the flexibility. That being said, the decrease in work/life separation and the decrease in social time also makes it difficult. Also, this year we aren't just working remote, we are working during a pandemic -- and many people have additional responsibilities as a result. I hope these tips are helpful!

On Being a Digital Nomad

Fri, 04 Sep 2020 00:00:00 GMT

Almost two years ago, I donated almost everything I owned and left DC. I was at a job I was unhappy at, and I didn't know my future. I decided that rather than signing a new lease, I'd instead mostly live at tech conferences for the summer and crash at my parents' in between, and then start living out of AirBnBs in the Fall. I ended up retiring from the digital nomad lifestyle in order to work in an office gain (started 3 days before the COVID shutdown lol). That being said, I think this is a pretty unique experience, but more people may be able to do the same as remote work becomes more popular and (hopefully) the pandemic starts to subside. So, I wanted to write down my thoughts and advice on the experience.

As far as logistics go, I personally chose to live out of AirBnBs. The longer you book a place, the more discount you get normally. So, I'd book a place for a month at a time. The cost for AirBnB pluses ended up being less than my DC rent most months. The van life idea is so appealing to me, but the mechanical knowledge needed and the potential lack of internet intimidates me. I also personally stayed in the United States because of my dog, I didn't want to quarantine her which you need to do with most international countries.

I travelled from city to city in my car, which was super nice. I was able to visit a bunch of sites nearby cities instead of just staying downtown, which I may have had to without a car.

I chose cities by expense, activities available, and their proximity to National Parks. My biggest bucket list item is to visit all of the National Parks, so this very much helped in that goal. I loved being able to experience different areas, taste test different restaurants, and to never get bored of my surroundings. I also was using it as a way to vet cities before settling down -- I didn't know where I wanted to move longterm, so this was a way of trying out different cities.

There were two really difficult attributes of travel for me: the first was loneliness, the second was the lack of a routine. It's pretty tough to get to know people when you aren't staying in a city for long. Something I would probably prioritize if I did this again would be to go to cities with a big tech scene so I could go to meetups and potentially speak at them. I was also single at the time, so doing this with a partner or a family would probably help in that regard. As far as having a routine, I was changing where I lived every month. So it's difficult to get too settled. Part of that was nice, I would go on hikes every morning with my dog in Asheville and would go to a neighborhood coffee shop in Nashville. But, I definitely missed having a set workday schedule.

Taxes can get so complicated if you're moving around a bunch, especially if you move internationally or are self-employed (or just have side gigs like me). I hired an accountant who specializes in digital nomads, and it's such a weight off my chest. Here is his site in case you're interested.

Overall, it's an experience I really enjoyed and would highly recommend if your work and life situations allow it. I would probably go back to being a digital nomad once the country re-opens and my partner was able to work remote. If you're interested in moving internationally, check out this Ladybug episode. Please Tweet any questions to me, I'd love to help out!

Managing Imposter Syndrome

Tue, 01 Sep 2020 00:00:00 GMT

Have you ever felt like you just aren’t smart enough or like you’re incapable of being a programmer? Have you ever felt like an imposter and that someone’s going to figure out you aren’t actually qualified to do what you do? You may be struggling with imposter syndrome.

What is Imposter Syndrome

Imposter syndrome is the feeling of "inadequacy that persists despite evident success." People struggling with imposter syndrome often minimize their accomplishments and feel a lot of self-doubts even when they are objectively are good at what they do.

Almost all developers struggle with imposter syndrome at some point in their careers, especially those who are members of underrepresented groups in tech. It’s natural with the amount there is to learn, the diverse educational experience of people in the field, and the ever-evolving landscape of programming. Knowing that imposter syndrome is widespread is part of the battle -- you aren’t alone in this, and it doesn’t mean you are actually unqualified.

I'm years into my programming career, have held multiple senior titles, and I still worry that I know way less than everyone else. To be honest, being visible on social media exacerbates that feeling of fraudulence. So does moving into a new role or receiving new opportunities.

Tips for Overcoming It

Reframing your thoughts to blame imposter syndrome rather than that you’re actually incapable is one strategy for managing it. In fact, imposter syndrome may act as a motivator for you and drive you to keep learning. Sharing your experiences may help as well, chances are the person you share your feelings with has felt something similar and can empathize with you.

Also, only compare yourself to your previous self. Nobody else. Focus on your growth. Everyone else is starting with different base knowledge and experience. It’s unfair to hold yourself to anyone else’s speed or level of knowledge. You’re different, and that should be celebrated. You have awesome skills and experiences that are unique to you.

It can be helpful to keep track of your progress. There are a few strategies for doing this. One is to look back on old projects: how much has your code improved? Probably a lot. Or, keep track of your wins. I keep a document on my computer with accomplishments, screenshots of nice things people have said, and positive performance reviews. You can then look back on that when you have a tough day. It’s so important to remember your successes, especially when you’re at a difficult point in your learning or at work.

In addition, work on facilitating a growth mindset, a term coined by Dr. Carol Dweck. It’s pretty cool that as programmers we can keep challenging ourselves and learning new things all the time. Your knowledge level isn’t fixed - you can keep expanding it and learning more. Believing that is a huge part of the battle. Be persistent through challenges and when programming gets hard, that’s how you grow. If you aren’t challenging yourself, you probably aren’t growing. Having that mindset can be another way to push through imposter syndrome.

Imposter syndrome often leads to a fear of failure. But, in programming, failure is necessary. There isn't a developer out there who hasn't programmed a bug at some point, and red error messages are nearly constant. I remember when I started coding thinking that I was messing up every time I got one. Nobody is perfect, and your error messages are

Therapy and mental health professionals can also help with overcoming these feelings, especially if they are significantly impacting your mental health or your career.

Programming is hard, finding the right answer won’t always be immediate. Getting used to failing, getting stuck, seeing error messages, and battling with a difficult bug is all a huge challenge. So is navigating an industry where everyone’s knowledge is different and always expanding. imposter syndrome is very widespread, you aren't the first or last person to struggle with it. Come up with strategies to help you cope with it, and be kind to yourself ♥️.

What Productivity Looks Like to Me

Wed, 20 May 2020 00:00:00 GMT

First off, productivity is all about balance. You will not be fully productive if you don't take breaks, don't get enough sleep, or you don't take care of yourself. I do not work all the time whatsoever. I work a very standard 40 hour work week and then do 10-20 hours of side work per week. I do not do it all, I don't work non-stop, I'm not perfect.

I also have a life that allows me to dedicate a lot to my side-work. I live with just my dog, I don't have children, I've been working remote for the last year and a half, and I've been single for most of my time doing side-work. I also am at a place in my career where putting in a 40 hour workweek most weeks at my day job is sufficient. It's a huge privilege that I'm able to be in the position that I am, and I know that my life will shift a lot in the future.

Early in my career, I worked a lot more than I do now -- I don't even want to do the math on how much, but it was a lot. I didn't have much balance in my life, and I let my social media-life consume me. I wanted to do it all, which wasn't possible. I ended up getting super burnt out, anxious, and unable to be as productive as I wanted to be. Balance is so important. I can't overstate that enough. If you're dealing with burnout, Becoming Super Woman was a super helpful read to see how bad burnout can really become and how to be more balanced.

I highly prioritize time with friends and family, runs with my dog, reading non-work related books, and being a total foodie in addition to my day job and the company I run. I am more than my work, and I don't want to lose my other identities.

Here are some things that I've learned that help me be my most productive. This will look different for everybody, but I hope some of this is helpful.

Health

First off, take care of yourself. Sleeping the optimal amount for you will make you more alert and focused throughout the day. The same thing is true for drinking enough water. I also try to eat protein, fat, and carb balanced meals frequently throughout the day. I run most days and try to do other strength-based workouts too. Plus, I take a spa night on Sundays where I do face and hair masks and teeth whitening.

Don't take health advice from me -- it's not what I do. Still, I do think prioritizing your health is one of the most important things you can do for your productivity and overall well-being.

Scheduling

As far as scheduling goes, I live by my Google Calendars. I put everything on there - I'm the person that sends my friends GCal invites for every hangout session. Otherwise, I'll forget. It's as simple as that.

I have three calendars, one for my personal life, one for We Learn Code (my company), and one for my day job. Sometimes, I'll forward events to my personal calendar, so they're all in one place. If I'm super overwhelmed, I'll calendar block everything. So, I will have every minute of my day, even free time scheduled in. I don't do this often now, but it used to be really helpful for me to see my schedule upfront.

Note: this was a week where I was in between jobs and had a lot I wanted to get done. I was also on vacation for the second half of the week.

Prioritization

In order to prioritize what I am going to work on, I first ask myself if it's something I'm passionate about. If it is, then I think about the time commitment and what I wouldn't be able to do if I decided to take on the new task. So, if I were to pick up a new freelance client, I would have to postpone working on an ebook, for example.

My greater goals and priorities have shifted over time. I initially wanted to build a bigger audience, and the activities I took on were correlated to that. Now, my financial situation has changed a bit, and I rely on my side-work being a larger portion of my income. In the future, I may prioritize more free time, which will change things again!

To help me prioritize, I use toggl to track my time spent on every project I do -- not just paid ones. I'm even timing myself writing this post right now. I do this so that I can see where my time goes, which inefficiencies exist, and the payoff of each activity.

For example, here's my Toggl report for the week I'm writing this. Each of my projects is color-coded, and different views show my hours worked per day and listings of each activity by time.

I also ask myself, "What are the three most important things for me to get done?". For my side work, I have three big to-do items for the week. For my day job, I do three per day. I use a pinned Google Keep sticky to keep track of these things, and I have another sticky with any time-sensitive tasks I need to do that day. Mostly things that won't take long, but need to get done then and there. Having just a few essential things to work on helps me to stay focused. I try to only work on what I've set out to do at the beginning of the week. I'm pretty dedicated to getting these few tasks done and worry a lot less about everything else.

I read the book Essentialism recently. It got pretty repetitive at some points, but it does a great job at explaining how to prioritize and why prioritization matters so much. Just do what's essential, nothing more nothing less.

Also, I do not do it all myself. If there's something that makes sense for me to have someone else do, I will hire a service to handle those tasks. I do wash and fold for my laundry, I used to hire a cleaning service for my apartment, and a large portion of my diet is take-out. I'm in a privileged position to be able to outsource some of these pieces of my life, but it allows me to do more of the work that fires me up: teaching code.

Motivation

Motivation is also a challenging piece of doing side work, and I'm so imperfect at always being motivated. I give myself lots of breaks, and I remind myself that this I'm choosing to do. I do have some advice for getting and staying motivated.

First, I love having groups of friends that I "mastermind" with. We inspire each other with our work, commiserate over the hard parts, and discuss strategies for growth. I love working with other people, and working on projects with other people or at least talking to them about those projects is a huge source of motivation for me.

I also utilize the two-minute rule -- if something takes two minutes or less, I just have to get it done. Having one thing crossed off of my to-do list starts the ball rolling, and I usually get more done.

Sometimes, I set a timer and timebox how long I'll spend on something -- "I don't feel like writing right now, but if I spend five minutes on it, I'll be closer to where I want to be." I rarely want to stop at the end of those five minutes, but it's a great trick for getting me started on something.

I also am really motivated by finishing things -- leaving them half-done really bothers me. So I usually break tasks into smaller and smaller sub-tasks and focus on completing sub-tasks. This makes me feel more accomplished and like I'm making progress, so I'll be much less likely to abandon the project.

Communication

One of the most difficult things to handle when my social media following grew was the non-stop messages. From people requesting advice to spam to lovely comments about my work, I was all the sudden getting hundreds of communications a day. I receive, on average, 100 mentions on Twitter a day, 15-20 Twitter direct messages, and 50-70 emails. It's a lot.

At first, I would respond to everything. With a lot of thought and care -- essentially writing personalized blog posts for anyone who asked me a question. It wasn't scalable. I still feel some guilt, but I don't respond to everything anymore. I have so much content that's open to the public, which scales so much better than offering 1:1 advice. I also mute my own tweets after a little while if they get a lot of attention, and I have filters so I don't get any notifications from social media. I do, however, have Tweetdeck set up to show me all mentions and quote tweets so that I can quickly mass respond to people.

I also have a system for my emails. I have three folders in my inboxes: today, this week, and this month. When an email comes in, I delete it or put it in one of these folders. I respond to today emails every weekday, this week emails on Mondays, and this month emails at the end of the month. I also add emails that will take some time to my to-do list so that I can allot that time better. I'm also really interested in implementing this email system down the road. It seems awesome, it just takes some time to get used to.

Note Taking

I take notes on everything. I take short-term notes that I won't keep forever in Google Keep. Then I can archive stickies when I'm done with them. If they're something I want long term, I take notes in markdown and upload them to GitHub. I take notes during meetings I'm in, on books I read, on courses I take, etc. It's good for learning, and it gives me a synthesized version of the material to come back to.

If I have an idea for a project or a blog post, I write that thought down, otherwise, I'll forget it. I even have a notebook next to my bed for this reason!

Related to notes, I also have checklists for everything I do -- for blog posts before I publish, for recording Egghead videos, for my morning and evening routines, etc. Making a checklist makes it so I don't have to think, I can refer to the list. I am not very detail-oriented, so having the steps for something written out is so helpful, so I don't forget anything.

My morning and evening routines are all written in large text on a whiteboard sticker on my fridge -- even just brushing my teeth is on there! I have my weekly workout schedule and chores list on there too.

For large projects, I usually use Trello to stay organized and motivated. I'll have checklists for each sub-task on each card. Breaking an enormous task into smaller ones helps me keep motivated and feel like I'm making progress.

I've heard great things about The Checklist Manifesto, a book all about keeping checklists for everything. I haven't read the full text, but reading a summary of it inspired me to start creating these checklists.

Habits

If I can convince you to do one thing after reading this article, it would be to pick up Atomic Habits. This book changed so much for me. Instead of focusing on goals, I try and focus on building up habits that make me who I want to become.

I use Done habit-tracker to keep track of habits I'm trying to build. Some things I have on there include: reading a chapter of a career-focused book each day, drinking enough water, and cleaning my apartment for at least 5 minutes. There's the immediate reward of having the habit change colors after it's completed, and there's an incentive to keep the habit chain going!

Organization

As far as file management goes, I keep everything on Google Drive. That way, if my laptop dies or something, I'll still have a backup. I also only keep files I'm using frequently on my computer to keep that organized. I have folders for projects and for life stuff! I also try to keep my personal and We Learn Code drives separate. Gotta keep work/side-hustle/life balance!

I also keep my browser bookmarks super organized in folders. I only keep things I need, otherwise, I'll save links elsewhere -- like Pinterest or in my notes about something. Bookmarks are for links I frequently come back to. I also have a to-read folder filled with articles that I want to read. I try to allocate some time to get through these from time to time too!

Work-Life Balance

I think the term work-life balance is imperfect, but I work to make sure that I'm not working all the time. I'm someone who very much has a tendency to work a huge number of hours and to abandon other aspects of my life and health to do more work. This isn't good, and I actively work to not do this, especially since I have been much more prone to burnout recently.

First of all, I don't have work email or Slack on my phone. I only have them on my work computer, which I don't touch outside of work hours.

I also try to make my bedroom a technology-free zone. I will say this is way easier when I'm not working from home -- quarantine has made this pretty much impossible. But, I find I sleep so much better if I put my phone and my computer in my living room before I sleep. I also think having dedicated workspaces when you do work from home is so helpful, and it's something I wish that I could more fully implement in my own life (darn city rent prices!).

Concentration

I am someone who works best without interruption and with long blocks of time. I don't do well with random 15-minute slots to work, rather I'd prefer to have one long afternoon to work. I used to do all of my blogging from the same restaurant in DC, Busboys and Poets. I'd go there every Sunday afternoon and crank out a post. Having that routine and that long block of time was perfect for me.

I also work best in the afternoon as compared to mornings or nights, though in college, late nights were my everything. I usually do side work immediately after my normal workday ends and on weekend afternoons. Everyone is going to be so different with this -- experiment and find times that work best for you!

I know that the Pomodoro technique works really well for some people, but I work best in long focused blocks. I tend to follow the Flowtime Technique instead. I take breaks when I need to or when I finish a task, but frequent breaks aren't helpful for me, nor do I need them.

Sometimes, I have a tendency to get distracted. Especially by social media and the internet more generally. During times like that, I'll use the SelfControl app to avoid distracting sites. Sometimes I'll even shut off the internet in my apartment if I really want to get some writing done.

Batching

One additional productivity system I find super helpful is batching. Batching is when you do a bunch of similar activities at once. So, for example, when I did Instagram I would write all my captions for the month at one time, and I'd pre-create graphics and find images. Or when I'm filming videos, I'll do multiple at once. When you're in one headspace it can be optimal to keep doing similar tasks instead of changing your focus to something else. Amy Porterfield has some excellent content on why batching is so great.

Conclusion

My productivity system is just that -- my system. Don't feel like you need to adopt all of this or follow any of it. I just hope it's helpful to have a peek into my life and the things that help me. Remember -- balance is so important and looks different for everyone. I'm so far from perfect, and I think it can seem like I do so much more than I actually do on social media. I am also in a place in my life where I can spend time on side-work, and I love doing it. Please let me know if you have any questions, or I can answer any questions on Twitter!

Hasura 101: Building a Realtime Game with Graphql and React

Wed, 13 May 2020 00:00:00 GMT

My favorite technology discovery of 2019 was Hasura. It makes getting up and running with a full Postgres + GraphQL backend a breeze -- you can pretty much click some things, and then you have a fully interactive database-explorer and editor and GraphQL endpoints you can test with GraphIQL. I want to share a tutorial on building a realtime game (with websockets!!!!) on Hasura based on a workshop I did with them earlier this year.

We'll talk about what GraphQL even is, what Hasura is, how to set up Hasura and a database, and then build a full React app on top of it. We'll build a drawing app that looks something like this:

Here is a deployed version of it! (Note: it's using the Heroku free tier so it may take a few seconds to boot up)

What is GraphQl

Well, according to its documentation, "GraphQL is a query language for APIs." Traditionally, with a REST API, you have all sorts of endpoints where you get access to different data or can change the data in some way. That can become pretty bulky pretty fast, and can also become a bottleneck if you're working with separate frontend and backend teams. GraphQL becomes really helpful as our apps evolve over time and need to display different data.

Sacha Grief wrote an awesome analogy in their article "So what’s this GraphQL thing I keep hearing about?".

The old REST model is like ordering pizza, then getting groceries delivered, then calling your dry cleaner to get your clothes. Three shops, three phone calls.

GraphQL on the other hand is like having a personal assistant: once you’ve given them the addresses to all three places, you can simply ask for what you want (“get me my dry cleaning, a large pizza, and two dozen eggs”) and wait for them to return.

GraphQL is also language agnostic (i.e. you can use GraphQL with any programming language), and it lives between your client and your data sources, so it's super flexible!

What is Hasura

Hasura allows you to build a GraphQL backend at lightning speed -- you can just click buttons and make some pretty awesome things.

Hasura:

Gives you an instant real time GraphQL API on a new or existing database.
It comes with dashboard that helps you set up your API and database.
You can react to changes in your database with web hooks, external APIs, or serverless functions on demand.
You can also stitch together custom GraphQL APIs and other data sources into a unified GraphQL API.

Get Up and Running with Hasura

Go to this url
Log in to Heroku (create an account if you haven't, don't worry it's free!)
Pick a (unique) name for your application
Click Deploy app
✨Magic✨! You've got a deployed Hasura instance up and running!

Set Up the Database

We're using a PostgreSQL database for our application, but Hasura gives us a super nice interface for interacting with that database.

Go to your Hasura app, which should look something like this:

Click on the data tab, and then the create table button next to the Schema header.

We'll create a pixels table in our database to store the coordinates and colors of each pixel.

We will also create two columns in that table: id, which will be an auto-incremented integer that Postgres handles for us, and color which will store the color each pixel should take on.

Also, set id as the primary key.

Here's what your form should look like!

Then, scroll down to the bottom and click the add table button!

We now have a database with the columns we need 🎉!

Adding our Initial Data

The very first time our app loads, we want each pixel to just be a white box until people start coloring them in. To make our future code easier, we'll seed the database with 400 values that all have the color white, since the grid is a 20x20 grid.

Note: you could also store row, column, and color for each pixel, but I've found it easier to just store all 400 pixels and order them by ID on the user interface.

Within the Hasura dashboard, we can run SQL queries by clicking on the SQL link under the tables listing.

You can add your SQL to the text box that pops up and then press run!

Here is the query I ran to populate the initial database. You can copy and paste the same one to add 400 white pixels to the database!

GraphQL Queries

Now that we have data loaded into our database, we can use GraphQL to query that data. We don't need to do any more setup! You can go to the GraphIQL tab of your Hasura dashboard and play with your data.

GraphIQL is an in-browser IDE for exploring GraphQL queries. It will help you write queries to fetch and manipulate your data.

The syntax for a GraphQL query is super different from the SQL queries you may be used to -- they look more similar to JavaScript objects.

For example, to fetch all of our data, our query would look like this:

query GetPixels {
  pixels {
    id
    color
  }
}

First, we name our query GetPixels. Then, we specify that we want to get data from our pixels table. We also say we want the data from the id and color columns. If you omitted one, you'd just get the data from that column back.

We can also change the query so that it always orders the pixels by their id's:

query GetPixels {
  pixels(order_by: { id: asc }) {
    id
    color
  }
}

We can also write subscriptions which are queries that also subscribe to changes in the data via websockets.

Changing the word query to subscription in the above example will allow us to pull new data as it updates.

In addition, GraphQL has mutations which allow us to update data.

For example the following query will allow us to update a pixel's color given its id:

mutation changePixelColor($id: Int!, $color: String!) {
  update_pixels(where: { id: { _eq: $id } }, _set: { color: $color }) {
    returning {
      color
      id
    }
  }
}

This mutation is named changePixelColor, like a programming function, mutations (and queries) can take arguments. In this case, it takes id, which is an integer, and color which is a string. We need to specify the table to query, in this case pixels, which we can do by saying update_pixels. Then, we add a where clause -- we are only going to update the item in the database whose id matches the one specified. Then we specify the _set, where we say that we will set our row's color to the one specified.

Then we add a returning with the data we want sent back to our application once our query is done executing.

I would highly recommend testing out these queries in GraphIQL and using it to build custom queries -- it does a ton for you!

Here is GraphQL's documentation if you want to dive deeper on it, it's awesome!

Integration with React Code

Since this tutorial is focused more on integrating Hasura and GraphQL with an existing application, we'll start with some pre-written React code. This repository has the code we'll be building off of. Right now, it is a static version of the drawing app. One person can make pixel art, but it doesn't connect to a backend, so the drawings don't persist and people can't draw collaboratively.

If you clone down the repository, run npm install to install all of its dependencies. Give the code a quick look through to see what's going on.

Apollo Setup

We'll be using Apollo to make writing our frontend GraphQL connection easier.

In the Connection.js file add the following code:

import { HttpLink } from "apollo-link-http"
import { ApolloClient } from "apollo-client"
import { InMemoryCache } from "apollo-cache-inmemory"

export default new ApolloClient({
  cache: new InMemoryCache(),
  link: new HttpLink({
    uri: "your-endpoint.herokuapp.com",
  }),
})

For the uri, use the GraphQL endpoint at the top of the GraphIQL tab.

This sets up the Apollo client so our GraphQL queries will point to our endpoint we created.

We also need to add a few lines of code to index.js.

import React from "react";
import ReactDOM from "react-dom";
+import { ApolloProvider } from "@apollo/react-hooks";

import "./index.css";
import App from "./App";
import * as serviceWorker from "./serviceWorker";
import connection from "./Connection";

ReactDOM.render(
+  <ApolloProvider client={connection}>
    <App />
+  </ApolloProvider>,
  document.getElementById("root")
);

// If you want your app to work offline and load faster, you can change
// unregister() to register() below. Note this comes with some pitfalls.
// Learn more about service workers: https://bit.ly/CRA-PWA
serviceWorker.unregister();

This gives our whole application access to the GraphQL connection we created. Our queries will automatically go to the right place now.

Query Setup

We need to hit our GraphQL endpoint whenever we go to our application in order to fetch which color each pixel should be. We'll add some code to our App.js file in order to make our application fetch the data we created instead of the static data it's using now!

First, we'll import the gql template tag. This will allow us to write GraphQL queries in our JavaScript code. We'll use our query we wrote earlier to fetch all the the pixels.

const GET_PIXELS = gql`
  query GetPixels {
    pixels(order_by: { id: asc }) {
      color
      id
    }
  }
`

Then, we'll use the useQuery hook that Apollo provides in order to fetch our data.

const { loading, error, data } = useQuery(GET_PIXELS);

This snippet of code will run our query when our component loads.

This hook gives us three values: whether or not the query is still running (loading), the error message if one exists, and the data that comes back from the query.

Before we get our data back, we probably want some sort of loading indicator, so we'll add a condition to our component that does so:

if (loading) {
  return <h2>Loading...</h2>
}

We will also change our map to use the live data instead of the hard coded pixels that we're currently creating on line 5.

data.pixels.map(pixel => <Pixel {...pixel} key={pixel.id} newColor={color} />)

All in all, here's what changed in our App.js:

import React, { useState } from "react";
+ import { useQuery } from "@apollo/react-hooks";
+ import gql from "graphql-tag";
import Pixel from "./Pixel";
import ColorPicker from "./ColorPicker";

- const pixels = new Array(400).fill("white");

+ const GET_PIXELS = gql`
+  query GetPixels {
+    pixels(order_by: { id: asc }) {
+      color
+      id
+    }
+  }
+`;

function App() {
+  const { loading, error, data } = useQuery(GET_PIXELS);
  const [color, changeColor] = useState("white");

+  if (loading) {
+    return <h2>Loading...<h2/>;
+  }

  return (
    <div className="content">
      <div className="logo">Draw</div>
      <p>Pick a Color</p>
      <ColorPicker changeColor={changeColor} />
      <p>Click a Pixel</p>
      <div className="container">
+        {data.pixels.map(pixel => (
+          <Pixel {...pixel} key={pixel.id} newColor={color} />
+        ))}
      </div>
    </div>
  );
}

export default App;

Mutation Setup

Now, let's make it so that our Pixel component runs our mutation to change the pixel's color when we click on a pixel. This will make it so that our change persists across users and sessions.

We'll use our gql template tag again, and put our mutation inside it.

const UPDATE_COLOR = gql`
  mutation ChangePixelColor($id: Int!, $color: String!) {
    update_pixels(where: { id: { _eq: $id } }, _set: { color: $color }) {
      returning {
        x
        y
        color
        id
      }
    }
  }
`

Apollo also has a useMutation hook, so we'll import that and use it.

const [updatePixelColor] = useMutation(UPDATE_COLOR)

We'll also update our onClick handler to run our mutation when the user clicks on the pixel.

onClick={() => {
    changeColor(color);
    updatePixelColor({ variables: { id, color: newColor } });
}}

Here's what our Pixel.js will look like when we finish converting it:

import React from "react";
+ import gql from "graphql-tag";
+ import { useMutation } from "@apollo/react-hooks";

+ const UPDATE_COLOR = gql`
+   mutation ChangePixelColor($id: Int!, $color: String!) {
+     update_pixels(where: { id: { _eq: $id } }, _set: { color: $color }) {
+       returning {
+         color
+         id
+       }
+     }
+   }
+ `;

const Pixel = ({ id, color, newColor }) => {
+  const [updatePixelColor] = useMutation(UPDATE_COLOR);

  return (
    <span
      className="pixel"
      onClick={() => {
         changeColor(color);
+        updatePixelColor({ variables: { id, color: newColor } });
      }}
      style={{ backgroundColor: color }}
    ></span>
  );
};

export default Pixel;

Woo! 🙌🏻 Now our application connects to our GraphQL endpoint and pulls the correct data. Here's the solution code if you want to see it in its entirety!

Making it Real Time

Right now, our application pulls from our GraphQL endpoint on page load, but it doesn't real-time update when another user clicks on a pixel. We want our users to be able to draw in real time with their friends. You can try this by opening up the deployed app in two tabs -- if you update a pixel in one tab, the other should update too.

We just need to update our App.js to use a GraphQL subscription instead of a query.

We'll use Apollo's useSubscription hook instead of useQuery and change the word query in our query to subscription. Magic 🧙🏻‍♂️!

Here's a diff showing what changed! (Note: much of the file is omitted since not much changed)

import React, { useState } from "react";
+ import { useSubscription } from "@apollo/react-hooks";
import gql from "graphql-tag";

import Pixel from "./Pixel";
import ColorPicker from "./ColorPicker";

const pixels = new Array(400).fill("white");

const GET_PIXELS = gql`
+  subscription GetPixels {
    pixels(order_by: { id: asc }) {
      color
      id
    }
  }
`;


function App() {
  const [color, changeColor] = useState("white");
+  const { loading, error, data } = useSubscription(GET_PIXELS);

...

Here is the full code with subscriptions!

Next Steps

You could add some custom backend game logic with Hasura Actions.
If you want to learn more about GraphQL, here's an awesome course.
If you want to dive deeper into building a backend with Hasura here's another course.
There are a ton more tutorials on Hasura's site.

Conclusion

I have so much fun building applications with this stack -- it allows me to focus solely on the frontend code for simple applications. I can create an application that allows two users to interact in realtime with very little friction. Traditionally, writing a full backend with a GraphQL layer is a pretty extensive process that requires a lot of maintenance. With Hasura, we can do this with a couple clicks. This is my new go-to stack for building quick apps.

Can't wait to see what you create!

My Favorite Books

Sun, 05 Jan 2020 00:00:00 GMT

I absolutely love reading. At the time of writing this, I've read 25 books so far this year. Since reading is such a big part of my self-education, I thought it would be good to have a page listing some of my favorite books.

Oh also, please be my friend on GoodReads

Books about Programming

Practical Object Oriented Design in Ruby - Sandi Metz

I learned so much from this book about how to structure code and the theories behind object oriented design, but, beyond that, Metz's love for programming jumps through the pages. It made me fall in love with programming all over again.

Fluent Python - Luciano Ramalho

I initially bought this book because it was the only resource I could find that went in-depth on meta-programming in Python. I found a Codewars problem I just could not figure out that required metaprogramming, and this book helped me over the hurtle! In addition, it's a great book for advanced Python programmers in general -- a more difficult demographic to find resources for.

Learning JavaScript Design Patterns - Addy Osmani

This book is awesome. It explains common design patterns in JavaScript -- it's one of the only resources I know of that does so. It has a ton of code and graphics to look at, which really helps me to understand concepts.

Cracking the Coding Interview - Gail Laakmann McDowell

I'm not going to lie, I have mixed feelings about this book. I don't think job interviews should focus on the things McDowell focuses on, I don't normally write Java day to day, and I've seen arguments that this book has actually made interviewing worse. That being said, I wouldn't at all be where I am without this book. It made data structures and algorithms click for me, and it coached me through some tough interviews. Part of me wishes it was just a book about data structures instead of an interview prep guide.

Books about Productivity

### Atomic Habits - James Clear

If I can recommend one book to you to read now, it would be this one. It's changed my life and the way I think about productivity. Instead of making goals, build habits to get you to where you want to be. I've been following Clear's systems this year, and I've never felt more in-control and productive.

### Make it Stick - Peter C. Brown

This book is all about the science of learning. It's a great read if you're looking to acquire a new skill or teach someone. I came out of this book with a long list of things I wanted to put into action at the end, which is the marker of a great book.

### Becoming Super Woman - Nicole Lapin

I saw this book at the airport when travelling to yet another conference. It came at the perfect time. I so needed Nicole's story and advice for overcoming burnout and balancing productivity with time for self-care. It's actionable, persuasive, and the kick in the butt I needed to slow down a little.

Other Non-fiction Books

### Resilient Management - Lara Hogan

As an aspiring engineering manager, this book is everything I could want. It has visual guides for everything, is super to the point, and has reflection questions at the end of each chapter. You can fly through it, but I took so many notes that it took me as long as a book three times as long!

### Feminism is for Everybody - bell hooks

I have form responses I sometimes send to internet bullies in order to try and educate them. In one of those responses, I have this book. It's such an important read on intersectional feminism, plus it's short and easy to understand.

Non-Career Related Books

### Bad Blood - John Carreyrou

This story takes so many twists and turns, and the level of manipulation and incompetence at Theranos is completely absurd. I listened to the audiobook, which was great.

### The Hate U Give - Angie Thomas

I read this whole book on a flight, and publicly sobbed in my seat for quite a bit of it. It's heart breaking, beautifully written, and unfortunately constantly timely.

### Daisy Jones & The Six - Taylor Jenkins Reid

If you do an audio book for one book, let it be this one. There's a full cast and crew, and I'm going to be honest I one hundred percent thought this was non-fiction until well into the book. I completely lost myself into the story, it felt like a super long movie more than a book. I can't recommend this one highly enough. I also love Reid's book "The Seven Husbands of Evely Hugo", and I would definitely pick it up.

### Little Fires Everywhere - Celeste Ng

This book is so damn complicated, I had no idea what to think for large chunks of it. It hits on so many important issues, and the characters are so well-written. I love "Everything I never Told You", Ng's other book, too so if you've already gotten through this one, pick that one up too.

### Looking for Alaska - John Green

I just re-read this book as an adult to make sure it was as good as it was when I was a teenager, and it may have been better now. The characters are awesome, the setting is fun to imagine, and my heart completely shattered in the middle of the book. It's such a portrayal of the emotions of teenage-hood, such a great read.

### Modern Love - Daniel Jones

This is a collection of stories from the New York Times' "Modern Love" column. If you want a bunch of uplifting, funny, and heartbreaking stories that are all pretty quick, this is a great read. I laughed, I cried, and (at the time of reading) felt way too single.

### American Predator - Maureen Callahan

I hate to admit it, but sometimes I love a true crime book. This is one of the best. Israel Keyes is terrifying, the story-telling comes from a fascinating angle, and the fact that many of his potential crimes are still undiscovered makes this book even more interesting.

### American Royals - Katharine McGee

This book is peak light-hearted beach read. It follows the premise "What if America had a royal family?", following the teenage princesses and princes around in their lives. It's fun, somewhat trashy, and has so many romance tropes bundled into one book. I can't wait for the next books in the series.

### Know My Name - Chanel Miller

This is easily the 2019 book of the year. Miller tells her story of being Emily Doe in the Brock Turner sexual assault case in a way that is honest, heartbreaking, but somehow also uplifiting. It may have gone on a few more pages than needed, but it tells such an important story of the judicial system and recovering from trauma.

### Verity - Colleen Hoover

This book is terrifying, wild, and has twists and turns galore. If you want to sleep, this may not be the book to read, but I couldn't put it down. I came into this book thinking it was a normal love story, and boy was I wrong. It's a psychological thriller that has the wildest ending I've ever read.

### In Cold Blood - Truman Capote

This book got me into True Crime. The nuance in this book is incredible -- it shows two cold blooded murderers in a human light. It shows their good sides and their bad sides, something you don't often see. The meta-story behind it is also fascinating, if you watch the movie Capote. Definitely a must-read, classic piece of literature.

The Career Advice I Wish I Had

Mon, 21 Oct 2019 00:00:00 GMT

There are so many things I wish I knew before I became a professional developer. Or a professional at all. I know I'm in a position of privilege as a white, college educated woman who is mid-career and doesn't have much outside-of-work obligations, but I hope most of this advice reaches wider than just me. I wasn't a computer science major, I was a 19 year-old Government major when I got my first programming job. And I've made a lot of career mistakes: I've trusted the wrong people, taken the wrong jobs, worked in toxic environments, and been way underpaid and undertitled for most of my career. But I've also done some stuff right, which is probably why you're reading this right now. In addition, I've done a lot of hiring and worked with a lot of bootcamp students, so I've been a witness to a lot of other people's careers too.

You do not need to do everything on this list. Nor do you need to do any of it. I wish I at least knew that some of these things existed and were things people do earlier in my career, even if I wasn't doing them. So I wrote them down for you in hopes that it may give you a leg up.

Advice for the Job Search

Find the right niche for you

There are a bunch of subfields within programming, from video games to websites to desktop apps to sending people into space, not to mention management and teaching. Find what fires you up and makes the most sense to you. There isn't a single path to success -- whatever success even means. If you're interested in hearing about more, here's a podcast episode discussing a bunch of different career paths.

Prioritize what you value

Success looks incredibly different to everyone. Some people enjoy recognition, others want to make tons of money, others want really good work life balance. What's most important to you will not be the same as the person next to you. Don't compare yourself to anyone else, and don't hold yourself to anyone's standards. Your priorities are valid. Find work places that align with your values and priorities.

Write down your goals and your non-negotiables

What do you want in the future? What's important to you? Is it a certain salary? Or work life balance? Or a certain title? What times do you work best? What culture is best for you? These things may evolve over time, but having them on paper means you can come back and revisit over time. Then you can focus on doing things that get you closer to your goals. Also, remind yourself of those non-negotiables when you get an offer so you can make sure you're going to be in a situation to succeed.

Find employers who want you to succeed

Good management that prioritizes your interests and goals is so important for creating a career where you're growing and thriving. Management makes or breaks roles. Find a manager, and a team, who is looking out for you and wants you to succeed. It will lead to a more functional team and to an environment where you're probably happier.

Just because there aren't jobs listed doesn't mean they don't exist

Just because the perfect job for you doesn't exist on a company's website doesn't mean it doesn't exist. I got my first tech job through cold emailing a startup asking if they had internships

Online applications can be a black hole

Online application portals are notoriously hard to break through. I remember hiring for a single position that had hundreds of online applications. Getting through that process without a connection is incredibly difficult -- possible, but difficult. I would advise trying to make connections or working with recruiters so that you can move to the front of the line.

Make a portfolio that stands out

Portfolios show your abilities and interests as well as your creativity. As someone who has done a lot of hiring, if someone has a portfolio site, I focus on looking through that way more than a resume. It doesn't have to have a bunch of side projects or anything like that -- just spin up a landing page with a bio, some experience, and links to other places on the web -- or your resume. It's a more dynamic way to show what you're about and what you're interested in. I still keep mine updated even though I'm not looking for a job, but I use it mostly for speaking opportunities, which are also helpful for your career!

Searching page

I've seen a few people create "searching" pages when they're looking for new roles that feature their requirements and interests in a new position. Almost like a job description but from the perspective of the employee instead of the employer. I haven't done this myself yet, but if I do a job search at some point I definitely will.

Want more advice on learning to code?

Download my free Ebook!

Advice for Interviews

Toxic interviews probably signal a toxic company

If a company seems toxic, is disorganized, or makes you jump through a million hoops in the interview process, the company is probably similar to work for. Interviews are a two way street, and you should both be courting each other. Make sure you actually want to work for them too. What does 18 rounds of whiteboarding interviews really say about the company? They're selective or inefficient and nitpicky?

Spin what you don't know

If you get asked a question like "Do you know React?" and you don't, be honest. Don't lie and say you know something you don't -- it will be easy for them to figure out you're being dishonest. That being said, don't just say "I don't know it" and leave it at that. You can instead say, "I don't know React yet, but I do know Vue and I know that they both have similar component architectures", or "I don't know React yet, but I love learning new things and would be excited to learn on the job". Admit what you don't know, but express your willingness to learn.

Show how you think

Most interview questions are there to see how you think. So show that! Explain your thought process, draw diagrams, write out the intermediary code, explain pitfalls in your approach, etc! Be vocal, and ask clarifying questions. That's part of being a good developer after all!

Negotiate

Negotiate everything you can. Job offers, content creation, work hours, remote days, job duties, benefits, compensation, etc. can all be negotiated. Use your wins to give you confidence and as a tangible list of accomplishments. The format I normally use is:

Thanking them for the initial offer, telling them I'm excited about it
Telling them what I want to negotiate
Listing my "wins" that lead to me getting what I am negotiating for
How I plan to help the company in the future
Sign off

It has worked really well for me.

Don't tell prospective employers how much you make

On a related note, you may get asked in interviews how much money you currently make. Don't answer this question, in fact it's illegal in a lot of states. You can spin and answer it with "Here's the number I'm looking for in my next position." instead. If they push, tell them you don't answer that question.

Don't undervalue your non-tech experiences

You have experiences outside of tech that are valuable, contribute to who you are, and can contribute to a company as well. Your customer service skills translate to client management, your teaching experience makes you a better mentor, your previous career in the insurance industry will give you subject matter expertise to help make the product better. I can keep going!

Don't undervalue your previous experience, sell it. If you can find a job that hybridizes your interests or previous career and code, you'll be a huge step ahead. Your non-programming skills are incredibly important, don't ignore them.

Advice for Code Challenges

Read the instructions

Read through the full instructions, take notes if you need to, and read them again before you submit the challenge. Make sure you're doing everything required and you're not missing anything. Show your attention to detail!

Go above and beyond

Even if the challenge doesn't ask you to add tests or styling, or x or y feature, if you have time add those things. They will make your challenge stand out.

Follow best practices

This probably goes without saying, but write clean code that is well documented and follows the best practices for what you're working in. Use a linter, add some comments if needed, and delete or .gitignore unused files.

Advice for on the Job

Keep a knowledge repository

I have a private GitHub repository where I take notes on everything I can. It allows me to create a searchable knowledge base that I can come back to instead of searching over and over again or just purely forgetting. I know a lot of other people also create engineering journals where they write about what they do each day and what they learn, I used to do something similar and I made a cron job on my computer to populate parts of it everyday.

Track your wins

Similar to tracking your knowledge, track your wins. First, if you're having a bout of impostor syndrome, you can come back to them and think of all the awesome things you've done. And you can compare your current wins to your old ones -- you've probably come pretty far.

I keep a document cool things I've done at work, side projects, speaking and writing gigs, positive feedback on my job performance, nice letters from students, screen shots of nice comments on my blog posts, etc.

On the other hand, when you're negotiating at a new job or for an internal raise or promotion, it will come in handy to have a list of the things that make you a great candidate.

Find ways to challenge yourself

I think programmers in general like to be challenged -- we enjoy learning new things and using our problem solving skills. I personally struggle when I'm not learning new things or stretching my brain. So, I make sure I'm still challenging myself to grow code-wise. At one job where I had a lot of ownership of my projects, I made rules for myself for each project, like implementing Sandi Metz's rules or doing strict test driven development. I've also made myself blog about learning new technologies or solved code challenges everyday to keep myself consistently learning. Keep growing and expanding your skill set, both for your career and for yourself.

Don't tolerate bullshit

The tech industry can be really toxic, especially for people who are members of underrepresented groups. Know that people treating you poorly isn't your fault. The job search process can suck, but it is worth it to try and move in order to get out of a work situation where you're being treated poorly. Changing things internally is really hard, and most companies you want to work for aren't going to judge you for a short stint somewhere. Your mental health and safety is more important than loyalty to a company that isn't showing that back to you. Do what you need to do to get out, if at all possible, and don't let people minimize your experiences.

I know that this is easier said than done, and finding a new job is hard. If you're in this position please reach out to me and I'll do what I can to help. Or just be a person to vent to.

Burnout is real... and can happen to you

I thought that burnout was impossible for me, I'd been working wild hours since my teens and hadn't felt it at all. Until relatively recently. It can be spurred by different things for different people. For me, it was feeling like my work didn't matter and wasn't being acknowledged. Have a life outside of work: hobbies, friends, and families are all important. You'll probably be able to get more done with more balance too. And that balance will look different at different points in your life. You're not weak because of it, and you can still be successful without working all the time. I just read "Becoming Super Woman" by Nicole Lapin, and I really enjoyed it -- it has a bunch of exercises to work through and everything.

Advice for Professional Development

Get involved in the community

If there's one thing that I wish I had done earlier in my career, its getting involved in the tech community. I started coding in a computer science classroom where I didn't feel like I belonged, but getting involved in the wider industry through blogging, attending meetups, and social media has made me feel so much more included. In addition, it can help with establishing a "brand" and demonstrate your knowledge. Not to mention how much it can help others.

I wrote a lot more extensively on how to get involved with the tech community here.

Teach

The best way to really learn something is to teach it to someone else. You have to know something in-depth to explain it well -- it's much harder than you may think. Plus teaching can help you meet other developers and display your own knowledge! It's a win win!

Make a portfolio that stands out

Your portfolio is key to communicating who you are and what you've done. They are super helpful if you're looking for your first job, so you can show off the projects you've built and what you're interested in. If you're looking for speaking opportunities or to advance in your career, they're great for that -- it's what I use mine for now. Plus, they're a fun creative outlet. Do something fun if you can, it will stand out more. If you're looking to make one, here's more of my advice!

Make friendships in the industry when you're not looking for a job

Getting referred for jobs makes it much easier to get in the door at companies. I have gotten almost all of my jobs through people I know. Online applications when you don't have a reference are usually a lottery -- there are tons of applicants and filtering them is incredibly difficult. It's really important to network and use your connections to find jobs.

Along the same lines, it is much better to make mutual relationships that are not just about a certain position, the person will be more likely to vouch for you, not to mention the other benefits of genuine friendships! One-sided relationships aren’t likely to be long lasting and overly rewarding. Both parties should be engaged and benefit from the relationship.

Go to meetups, go to industry events, interact on social media, and build a network before you're looking for a job so that network will be there to support you once you're ready.

Plus you'll have new friends -- some of my closest ones are from this industry now.

T-Shape your knowledge

It can be tempting to learn all the shiny new things that come out, but it isn’t necessary. Learn one thing in depth, and then from there carry that knowledge over to other topics. Instead of learning trying to learn everything, a better strategy is to focus on T-shaping your knowledge: go really in-depth on one thing and become an expert on it and then from there build more knowledge in less depth on other topics.

I hope some of the advice above was helpful, you don't have to do all of it. Or any of it! But, these are things I wish I knew before I started out in the industry. Know that different people take different paths and that's okay. I teach people to code at a bootcamp, which is often thought down on by other programmers. But I love it, and it's a job that's fufilling to me. That matters to me more than any prestige that may come from a fancy title at a big tech firm. Prioritize what matters to you.

A Complete Beginner's Guide to Programming

Wed, 27 Mar 2019 00:00:00 GMT

This post may seem out of place on a site for programmers, but I wanted to write something from zero. What even is programming? And, what are the building blocks of programming?

This post is going to start out by discussing what computers are at a conceptual level, and then discuss the programming fundamentals. We'll use Python in this post, but a lot of the building blocks work across programming languages, so this will still help even if you are interested in learning a different language at first.

What is programming?

You probably interact with computers on a daily basis, but let's define concretely what we mean when we talk about computers in relation to programming. A computer is a machine that processes and stores information.

Programming is telling the computer how to ingest, process, and then store that data. When someone writes a program, that person is giving the computer a set of commands that it must follow.

When we write programs, we are writing instructions that the computer will follow. Computers are very literal -- they will take our instructions and follow them exactly, but we must lay them out in a very detailed way so that they understand us.

Programming, at its core, is taking a big problem and breaking it into smaller and smaller problems until they are small enough that we can tell the computer to solve that problem.

Where can you see programs in use?

Everywhere! From your operating system on your computer through complex websites, all are written using code! Older (and newer!) cell phones, fancy coffee machines, self-driving cars, Facebook, Amazon, an ATM, the Lyft App, metro card reloaders, supermarket scanners, and most TVs use code to run in addition to your desktop or laptop computer.

What are programming languages?

Computers can't understand natural language by default, though they are getting closer and closer to being able to!

At their root, computers run on a series of microscopic on and off switches, and when we write code we are toggling them on and off -- just like a light switch! Computers use a numerical system called binary to use these on and off switches. Binary is a numerical system comprised of 1s and 0s in countrast to our decimal system which uses 0-9.

Thankfully, a lot of really smart people before our time thought of a way that we can talk to our computers without zeros and ones. Instead, we use programming languages which can be interpreted by our computer, similar to how language interpreters can translate Spanish to English or even English to sign language. These look a lot more like English than binary, but they still have a lot more symbols and fewer ways of doing things than natural language.

There are tons of programming languages out there, similar to how there are lots of languages spoken around the world. Some, like Assembly or C are very low level and don't really resemble how we speak. Others, like Python and Ruby closely resemble human language. These languages are used for different tasks, for example HTML, CSS, and JavaScript are used to write websites whereas C is used to write your operating system. These have evolved a lot over time -- old programmers used to have to use punch cards and feed them to the computer instead of typing out code on their computers! There are trade-offs between performance and ease of use, but when you learn how to code I would highly recommend one that is closer to normal language!

The Key Fundamentals for Programming

There are some fundamental concepts that move with us from programming language to programming language. We'll use Python, but pretty much every language know of has these fundamentals, though they may be written differently (outside of HTML and CSS which are pretty different).

Brief aside, you can run Python in your web browser using Repl.it. You can create a Python project by pressing the new repl button, and selecting Python. Then, type in the area under main.py. You then can run your code with the green run button.

You can also install Python on your computer by downloading it, and then using a text editor -- my favorite is VS Code. You would then run the code via the command line. You would create a file with a .py extension, then write your code in your editor, finally, you would run the file by running python your_file_name.py.

Hello World

When you learn a new programming language, it's a tradition to write a hello world program. So let's write one in Python!

There's a function in Python that allows us to write text to wherever we're running our code -- so if you're using the command line, it will print out there, if you're using Repl.it, it will print out on the right-hand side of your screen.

We'll talk about what functions are in a bit!

print("Hello, World!")

All of the code samples are also available in repl.its, but are linked instead of embedded

Variables

Variables are a very important piece of programming. Variables store a piece of information that you can use over and over again. If you remember variables from algebra class, they're the same thing conceptually!

In Python, in order to set a variable, we'll write a variable name (in this case name and age), then use an equals sign to set that variable to a value -- in the example "Ali" and 24.

If we use letters, we need to put them in quotes. If we want a number instead, then we'll keep them out of quotes.

name = "Ali"
age = 24

print(name)
print(age)

Now, whenever we can use name or age wherever in our code!

Repl.it

Remember from above, programming languages are for humans, not just the computer. If we were just talking to the computer, then we'd just use 0's and 1's and write binary! So, remember to use variable names that will make sense to future you -- or another programmer who reads your code in the future.

Rule of thumb for variables: If you're going to use a value over and over, create a variable for it!

Data Types

There are different types of data that we can use when programming. Some common ones are integers, floats, booleans, and strings.

Integers

Integers are another math class term - they're basically numbers without decimals. So 1, 0, -100, 200, etc.

We can use integers in Python by just typing numbers!

We can store them in variables, like we saw above, so that we can use them over and over again.

my_favorite_number = 22

We can also do math with them! The four basic symbols are * for multiplication, + for addition, - for subtraction, and / for division.

print(22 + 10)

pieces_of_candy = 20 - 5
print(pieces_of_candy)

Repl.it

Floats

Floats are numbers with decimals -- so 4.0, 4.5, -19.6 etc. They work like numbers otherwise!

Booleans

Booleans are True and False in Python -- these are mostly used to say "yes" or "no" -- remember how computers are a bunch of on and off switches? Booleans are similar!

We can set variables to booleans, but it's usually more useful to compare values and see the results as booleans. One common use is checking equality. Is some variable equal to some value? We use double equals signs to check equality since we use one equals sign to set a variable.

age = 22
print(age == 22) # True

We can also check greater than or less than -- or all those mathematical checks. We use > for greater, < for less, >= for greater or equal, and <= for less or equal!

print(5 > 10) # False
print(10 >= 10) # True

We can also store booleans to variables!

is_greater = 5 > 10
print(is_greater) # False

Things after hashtags in Python are comments -- they're ignored by the computer and are there as notes for yourself or other developers!

Strings

Strings are text in Python. We wrap them in quotation marks!

my_string = "This is a string!"
print(my_string)

Lists

Sometimes, we want to store more than one value in a variable -- say a collection of numbers, the names of the people in a room, the most recent tweets on twitter, or the prices of the items in our shop.

We can store these values in lists in Python!

items_in_store = [5, 10, 15, 8]
dev_employees = ["Ali", "Jess", "Ben", "Peter", "Andy", "Mac", "Liana", "Michael", "Anna", "Mario"]

Rule of thumb for lists: If you have a group of similar things, put them in a list

Conditionals

Another key part of programming is conditionals. These allow us to run blocks of code sometimes and other blocks other times.

So, if a condition is True, run a block of code. Maybe, if something else is true, run a different block of code. Finally, if all the other ones aren't True, run this other block of code.

In Python, blocks of code are indented, so "if this thing is True, run the indented code after it"

name = "Ali"

if name == "Ali":
    print("Hi, Ali!")

Repl.it

Now let's add a condition that will run if the first condition is False. We'll use the else keyword for this!

password = "hello!"
correct_password = "hi"

if password == correct_password:
    print("Welcome to the website!")
else:
    print("Permission denied")

Repl.it

We can also check multiple conditions using elif:

age = 50

if age > 100:
    print("you are old")
elif age < 20 and age >= 13:
    print("You are a teenager")
elif age < 13:
    print("You are a child")
else:
    print("You are an adult")

Put in different values for age and see what changes!

You can use and to check multiple conditions at once! Or or to check if one things is True or a different thing is True.

Repl.it

Rule of thumb for conditionals: If you want certain code to run sometimes, and other code to run other times: use a conditional!

Loops

Loops allow us to run the same block of code over and over again for different values. The most common situation is to loop over a list.

There are two main types of lists -- the first is a for loop. They follow the formula For item in list: do something. The item can be anything -- it's a variable name that changes with each loop.

For example:

dev_employees = ["Ali", "Jess", "Ben", "Peter", "Andy", "Mac", "Liana", "Michael", "Anna", "Mario"]

for employee in dev_employees:
    print("Hi" + employee + "!") # We can join multiple strings together with `+` signs!

At first, employee is Ali, then it moves to Jess, then Ben, etc.

While loops also exist, but they're a bit more rare and have some tricks to them, so we'll skip over them for now!

Repl.it

Rule of thumb for loops: If you want the same code to run over and over again, use a loop!

Functions

Quick jargon breakdown before I start explaining functions:

Arguments - passed into a function each time you call (aka invoke) it.

Parameters - the variables in the function definition.

In def myFunction(x, y), x and y are the parameters. When we run that function by saying myFunction(1, 3), 1 and 3 are the arguments.

When I teach functions, I try to teach them in two ways in order to make sense to two different types of thinkers. The first is a reusable chunk of code that you can plug values into to make your code more versatile and allow for less repeated code. In this case, arguments are the "dynamic" pieces of information that are plugged into the chunk of code. So, when you call the function, that value may change. Pretty much a variable that is different each time you run the function.

I also like explaining functions as a series of inputs and outputs -- kind of like a little machine. You put something into the machine and something comes out based on that. The arguments are the things you are feeding into the machine, and the return value is what is outputted. This matches the algebraic definition of functions more closely -- if you remember f(x) = 2x + 1 from school math, those are functions just written on paper instead of written programmatically.

In Python, the order of the arguments being passed into the function corresponds to the order of the parameters in the function declaration. So, if my function declaration looks like def add(x, y) and I then call the function with add(1, 2), in the function 1 will be x and 2 will be y. If I instead ran add(100, 50), x will be 100 and y will be 50. Since x is my first parameter, the first argument I pass into the function will be x, and since y is second, the second value I pass will be y. Sometimes it's helpful to diagram this out.

Anything after the return keyword is the output for the function.

def subtract(x, y):
  return x - y

print(subtract(5, 2)) # 3, 5 is x, 2 is y
print(subtract(200, 50)) # 150, 200 is x, 50 is y
print(subtract(20, 70)) # -50, 20 is x, 70 is y

five = subtract(10, 5)
print(five)

x	y	subtract(x, y)
5	2	3
200	50	150
20	70	-50

Repl.it

Another example:

def say_hi(person):
    print("Hi " + person)
    return person

ali = say_hi("Ali")
print(ali)

Repl.it

This function outputs person (which is the same as the input), but it also performs another action -- printing out the person's name with hi. That first action doesn't affect the output -- or what's returned from the function. If you print out ali it's "Ali"!

Rule of thumb for functions: If you want to reuse a chunk of code, potentially with different data, use a function!

Next Steps for Learning how to Code

These are some really important fundamental concepts for programming, but there are so many more! Two important ones are debugging and problem solving.

When you're writing code, the computer is really smart in that it does exactly what it tells you too. But, if you have a typo or any incorrect code, your code is going to throw an error! Learn to work through those errors and love them for telling you what's going on rather than fearing them! They're so helpful!

Problem solving comes in when we try to put the pieces of the puzzle together to make different programs. I'm actually working on a series about that now!

Also, if you want more free resources for learning programming, here's some great ones!

A Complete Beginner's Guide to Vue

Tue, 19 Mar 2019 00:00:00 GMT

Vue.js is a frontend framework that is optimized for progressive integration. That means you can have a large app with only a couple Vue components integrated -- or you could start from scratch and work completely within the Vue ecosystem.

Another thing that sets Vue apart is the lower learning curve compared to a lot of frameworks. Instead of having to understand complex topics, if you know HTML, CSS, and JavaScript, you're already pretty close!

Like any framework, it adds a structure and utilities to your frontend so that your app is easier to extend as it grows, is more organized, and you don't have to "reinvent the wheel" as often.

Vue is also really cool because it's ecosystem is really well integrated -- a lot of the utilities that would normally be 3rd party libraries are built by the Vue core maintainers, like Vue Router and Vuex.

Throughout this post, we'll explore the key features of Vue, and create an app together!

Here's what we'll be building, though with some more interactive features. The like button will toggle from the heart outline to the red heart based on user clicks. Also, the character number will count down when someone types in the text box.

Go ahead and check out the HTML and CSS code above, we'll be building off of the HTML with our Vue code.

Setting up a Vue App

For now, we'll use a Vue CDN -- we want a minimalist setup. In the future, you may want a more extensive environment, in which case you can use the Vue CLI.

Go to the settings button on Codepen, switch to the JavaScript tab, and search for Vue on CDNjs. This adds the Vue library to our project, so we can use all of the methods and features that Vue gives us.

Now, we need to create a Vue instance and attach it to our HTML in order to fully integrate Vue!

Let's create a const that stores our Vue instance.

const app = new Vue()

We're going to pass an object when we create this Vue app, it'll have all our configuration and application logic for now.

The first thing we're going to add to that object is el -- which is the element that we want to be the base of our Vue app. In this case the element with the status class.

const app = new Vue({
  el: ".status"
})

Then, we'll add our data. To test this out, let's add the tweetText as data -- so where we have Hello World! right now will become a variable. Down the road we're going to make more tweets with different text, so it makes sense to make that piece of the tweet dynamic.

const app = new Vue({
    el: ".status",
    data: {
        tweetText: "Hello World!"
    }
})

When we want to add more dynamic data (or data that will change within our Vue app) we'll add more attributes to this data object.

Now, we can use our newly created data in our HTML and plug in the variables that way! If you've ever used Handlebars or another templating language, it's kind of like that.

If you go to the hardcoded "Hello World!" in the HTML, we can now replace it with {{tweetText}} which will pull from our Vue data!

<p class="tweet-text">
  {{ tweetText }}
</p>

Try to change your tweetText in Vue, and it'll change in your output as well!

Let's brainstorm for a second on what other data we have that will change within the course of our app.

The heart will toggle between liked and unliked
Our characters remaining will decrease when we type in the

Let's go ahead and add attributes for those in our data object.

data: {
    tweetText: "Hello World!",
+    charactersRemaining: 280,
+    liked: false
}

We'll also make charactersRemaining dynamic in the HTML.

<span class="characters-remaining">
  {{ charactersRemaining }} characters remaining
</span>

We'll hold off on the liked attribute for now, we'll come back to that in a second.

Methods

Now that we have our data, we need to make it update based on user actions.

We're going to add another attribute to our Vue object -- this one will store our methods.

const app = new Vue({
    el: ".status",
    data: {
        tweetText: "Hello World!",
        charactersRemaining: 280,
        liked: false
    },
    methods: {}
})

We have two "actions" for our app -- toggling the like and changing the characters remaining number when the user types. Let's work on the character counting first.

We'll add a function to our methods object first:

methods: {
    countCharacters: function() {

    }
}

Let's think about the logic for this function: we need to count how many characters the user has typed into the textarea. Then, we need to subtract that count from 280 (or our character limit).

Let's create a data attribute for the comment text, and then update that every time the user types in the textarea.

  data: {
    tweetText: 'Hello World!',
    charactersRemaining: 280,
+    commentText: '',
    liked: false
  },

<textarea placeholder="tweet your reply" v-model="commentText"></textarea>

v-model is a directive that syncs our data attribute with what the user has typed into the textarea. So no matter how much or little they have typed in, commentText will match what they've typed. To take one quick step back, directives are HTML attributes that are provided by Vue, they're prefixed by v-.

Okay, now back to our method. We can access our data in our methods with this.myDataAttribute (here's a great reference on JavaScript's this).

So, we can update the charactersRemaining with the following logic:

methods: {
    countCharacters: function() {
        this.charactersRemaining = 280 - this.commentText.length
    }
}

Now, we need to make sure that countCharacters runs every time the user types in the textarea.

Luckily, Vue has the v-on directive, and we can add the event after it so that we run the method each time that event takes place. In this case, v-on:input="countCharacters" will run the countCharacters method each time the user types in the textarea.

<textarea
  placeholder="tweet your reply"
  v-model="commentText"
  v-on:input="countCharacters"
></textarea>

Okay, now let's step back and work on our toggleLike method.

We first need to add the method to our methods object.

methods: {
    ...
    toggleLike: function () {

    }
}

The body of the method should change this.liked to the opposite of what it currently is. So:

toggleLike: function () {
    this.liked = !this.liked
}

Now we need to make that action run.

On our reactions div, let's add an event listener.

<div class="reactions like" v-on:click="toggleLike">
  ...
</div>

It's time to introduce another Vue feature: conditionals!

Conditionals

Vue allows us to conditionally render data with the v-if directive.

Let's add the following span-wrapped emoji within our reactions div:

<span v-if="liked">♥️</span>

Now, our red heart emoji only shows up if liked is true. Let's also add a v-else to our heart outline emoji, so that it only renders if liked is false.

<span v-if="liked">♥️</span> <span v-else>♡</span>

Yay! Now our likes work!

If you had any issues with the above steps, here's a Codepen with what we have so far.

Now that we have our interaction down, how would we create a bunch more tweets with the same functionality but different data? Components!

Components

Similar to other frontend frameworks, Vue apps are broken down into components. We compose components together in order to create full user interfaces. A good rule of thumb is that if a chunk of the user interface is used multiple times, it should be broken into a component.

In a production application, our tweet would probably be broken into subcomponents -- we may have a component for the comment text area, one for the like functionality, one for the profile picture, etc. But, for now, we will just make the full tweet into a component so that we can easily create a bunch more tweets.

First, let's move the logic from our Vue instance into a component.

The first argument to Vue.component is the name of the component, in this case "tweet". We're also turning data into a function that returns an object. This allows us to have multiple tweet component instance, each with separate data.

Vue.component("tweet", {
  data: function() {
    return {
      charactersRemaining: 280,
      commentText: "",
      liked: false
    }
  },
  methods: {
    countCharacters: function() {
      this.charactersRemaining = 280 - this.commentText.length
    },
    toggleLike: function() {
      this.liked = !this.liked
    }
  }
})

We also need the template for the component -- or the HTML that the component will render. We're going to grab all of the existing HTML and paste into a template attribute on our component.

template: `<div class="status">
  <div class="tweet-content">
    <img src="https://pbs.twimg.com/profile_images/1070775214370373633/borvu2Xx_400x400.jpg" class="logo" alt="Vue Vixens DC logo">
    <div class="tweet">
      <a href="https://twitter.com/vuevixensdc">Vue Vixens DC</a>
      <span>@VueVixensDC · Mar 20</span>
      <p class="tweet-text">
        {{ tweetText }}
      </p>
      <div class="reactions">
        <span v-on:click="toggleLike" class="like">
          <span v-if="liked">♥️</span>
          <span v-else>♡</span>
        </span>
      </div>
    </div>
  </div>
  <div class="comment-bar">
    <textarea placeholder="tweet your reply" v-model="commentText" v-on:input="countCharacters">
    </textarea>
    <span class="characters-remaining">
      {{ charactersRemaining }} characters remaining
    </span>
  </div>
</div>`

Now, we have a Vue component!

One other quick thing we need to add: the tweet text is going to be different from tweet to tweet. We'll pass in different tweet text for each individual tweet through props -- which allow us to pass data to a component from outside of that component. For now, we'll just specify that our component has a prop associated with it.

Vue.component('tweet', {
  props: ['tweetText'],
...
})

We still have to have a Vue app though, so let's add that back into our JavaScript:

new Vue({ el: "#app" })

Cool, now our JavaScript is set, we just have to handle our HTML. In our Vue instance, we're looking for an element with the id app now, so let's create that.

<div id="app"></div>

And, inside of our new Vue app, we'll add some instances of our tweet component.

<div id="app">
  <tweet tweet-text="hello world!"></tweet>
  <tweet tweet-text="hi!"></tweet>
</div>

Notice how we're passing in our tweetText prop -- Vue converts the JavaScript camel case to kebab case in HTML. Outside of that change, our props look like HTML attributes.

Now our component should be good to go!

One more quick thing though, usually instead of hardcoding each tweet in the HTML, we're going to want to loop through a data structure and create a tweet component for each of those items. Let's look at how to do that in Vue!

We're going to go into our Vue app instance and add some tweet data.

new Vue({
  el: "#app",
  data: {
    tweets: [
        { id: 1, tweetText: "hello world!" }, 
        { id: 2, tweetText: "hi!" }
    ]
  }
})

Now we'll use another Vue directive, v-for in order to loop through the tweets array and create a tweet instance for each!

<div id="app">
  <tweet
    v-for="tweet in tweets"
    v-bind:key="tweet.id"
    v-bind:tweet-text="tweet.tweetText"
  ></tweet>
</div>

Notice that we use v-bind twice here -- it allows us to dynamically update html attributes (or use variables within them). Keys are recommended whenever you use v-for -- it allows Vue to identify the child elements better (more).

Awesome! Now we can create more tweets by adding an element to the tweets array!

Here's all of that code together.

More Resources to Learn Vue

First, there's a lot of cool features that you can add to the widget we just built. You can make the profile pictures different from tweet to tweet, along with the date and user data. You can also disable or highlight overflow text in our textarea. You could even use the Twitter API to use real tweets and even make the comment posting work!

Here are some more awesome resources for continuing to learn Vue:

And, if you're interested in more "Beginner's Guides" like this one, I have them for CSS and React as well!

A Complete Beginner's Guide to CSS

Tue, 29 Jan 2019 00:00:00 GMT

CSS defines the way things look on your websites. HTML is your content, JavaScript adds interaction, but the appearance comes down to CSS. CSS is super powerful, and has a ton of awesome stuff built in. This post will take you from introductory syntax through creating layouts and making sites responsive!

Syntax

CSS is comprised of selectors and declarations. Selectors are how we tell CSS which elements to apply styles to. Declarations are the actual styles that will be applied for that element, i.e. they are everything within the braces. Within those declarations, we have properties and values. The properties are the type of style we are applying, the value is what we are actually applying.

The above CSS is saying, make the font color for all h1's blue. The h1 is the selector, the declaration is everything between the braces, the property is color, and the value is blue.

One final piece of CSS syntax is comments - these are ignored by the browser -- they are just there for humans to document their code. In CSS these look like the following:

/* this is a comment */

Selectors

In CSS, we will use selectors to specify which HTML elements we want to style. Sometimes, this will be every element on the page. Other times, we will only want to select certain elements.

Sometimes, we will want to select each instance of an element on the page, for example, all h2's. We can select elements with their names!

h2 {
  color: blue;
  font-family: sans-serif;
}

Sometimes, we will instead want to select groups of elements -- say we only want certain paragraphs to be bolded, we can use classes to differentiate between those paragraphs.

<h2 class="center">Hello World</h2>
<h2 class="center">Hello World</h2>
<h2>Hello World</h2>

We differentiate element and class selectors by putting a . before the class name in CSS -- that way CSS knows we are looking for a class named center instead of an element!

.center {
  text-align: center;
}

Now, the first two h2 tags with the center class on them will be centered, and the third, without that class, will still look normal.

There are also some more complex selectors, such as:

h1, h2, h3 {
  /* The commas allow you to group selectors! In this case, all h1-h3's will be blue */
  color: blue;
}

h3:hover {
  /* pseudo-classes allow us to select elements in certain states. So, in this case, when an h3 is hovered, it will be pink! */
  color: pink;
}

Here's more about pseudo-classes, and here's an awesome game to practice with more complex selectors.

You may have used IDs for JavaScript code or other web development; however, I don't recommend using them for CSS, since they are only on one element and you want your code to be reusable!

Properties

Let's talk about the basic properties in CSS and how you can use them! We'll go into layout, which tends to be a little trickier, further down in this post, but for now, we'll go over color and text styling!

Color

There are a couple ways you can add color to a document using CSS, including text and backgrounds. Also, there are a couple of ways to represent colors in CSS.

The first is using named colors. There are 140 colors with names in CSS, these allow you to just put in a name and use them!

.red {
  background-color: tomato;
}

But — there are a lot more than 140 colors out there, so we also have a few more complex ways to represent more colors as well. These are based on the amount of red, green, and blue that comprise a color. Imagine you had three lights, one of each of these colors, and a background. If all three lights were off, then the background would be black. If all three were turned all the way up, the background would be white. And, if one of the lights was turned all the way up but not the others, the background would be that color. Then, the lights can be turned up in combination to create any color.

The RGB, RGBA, and hexadecimal colors are all derived from the above color combinations. Each color of the red, green, and blue "lights" can be given a value from 0 to 255, so that each value can be stored in one byte. In RGB and RGBA, you use base 10 numbers to represent the values, and in hex values, you use the hexadecimal system. RGBA values also have "alpha" values, which are the opacity of the color.

You can color text, backgrounds, borders and more with the above system!

Text

Another really important CSS feature is styling text. You can choose fonts, text spacing, and sizing.

There are some fonts that are built into most computers, which are referred to as web safe fonts. You can also add fancy fonts by including a font file. You can use sites like Google Fonts to find ones that you like for your sites.

body {
  /* if the user's computer has Arial, use that, if not Helvetica, 
  then fall back to the operating system's default sans-serif font */
    font-family: Arial, Helvetica, sans-serif;
}

You can also change the size of text in a couple different ways — the first is pixels — which is usually the most beginner-friendly, then there's also ems and rems, which allow you to scale fonts differently. You can read more about those here.

The Box Model

CSS operates with the box model. First, you have your content. If you want to add spacing around that content within the background or border around it, you use padding. Then, you can add a border, which will normally be colored differently and patterned. Finally, outside of the background and border is the margin — this will be spacing between our element and other elements on the page.

One quick helpful margin snippet is margin: 0 auto;, which allows you to center most elements horizontally. The 0 value means that there is no margin on the top and bottom of the element. Auto adds equal margin to both sides of the element, centering it in its container.

Display

One of the more important CSS attributes is display. There are a few values you can use here. The first is none which hides the content. This can be helpful for hiding some content on different size screens or due to JavaScript events. inline removes linebreaks after elements, and it also means that adding height and width won't have an effect. blockmeans that the next element will be on the next line. inline-block is similar to inline, though you can apply height and width to the element. Fixed and sticky displays make elements stay in positions These are generally the most used and most traditional display properties, however, two more recent ones have really changed the layout game.

Layouts

Usually one of the trickier parts of CSS is creating layouts for your webpages. Getting things aligned properly used to be much more difficult than it is now, due to CSS Grid and Flexbox, two newer CSS display attributes . If you would like to learn them in more depth, CSS Tricks has great guides for both Grid and Flexbox. I'll go over a few tricks here too!

In order to center an element horizontally, you can normally use either text-align: center; or margin: 0 auto;. But — vertical centering used to be more difficult. Good news! Flexbox made it a lot easier. The following snippet placed on the parent of the element you're trying to center will center it both horizontally and vertically.

parent {
  display: flex;
  align-items: center;
  justify-content: center;
}

Bonus: here's a video version of this example!

You can create rows of elements with CSS grid really nicely.

.cards {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  grid-gap: 10px;
}

The above code generates three columns of equal size on the page. The grid gap adds spacing between each column.

Bonus: here's a video version of this example!

In addition, they make the "holy grail" three column plus header and footer layout a lot easier — check out this post for a couple ways on how to acheieve it with CSS Grid!

Defaults

Sometimes, there may be styling on your page that seems to be coming from nowhere. The browser actually has some styles pre-written for you. For example, there's an 8px margin on the body, a 2px border on table blocks, and headers have larger fonts. Sometimes you don't want these pre-loaded styles, so you can override them!

Cascade

One of the more notorious and occasionally controversial CSS features is the cascade. This mimics inheritance in object-oriented programming, and it defines how styles override one another. If developers use a CSS library, such as Bootstrap, this may be more difficult to navigate.

CSS selectors have various levels of specificity which define how styles are overridden when more styles are applied.

If, for example, we have the following CSS code:

body {
  font-family: sans-serif;
}

All of the text with in our body tags will be sans-serif — even if they are also within a h1 or p or any other tag. But, sometimes we'll want h1's to be serif instead, which we can add like so:

h1 {
  font-family: serif;
}

Now our h1's have a serif font, all other tags within the body are still sans-serif.

Also, different selectors have different levels of specificity. ID's are the most specific, though I generally don't use them for CSS since using them isn't very modular, then classes, then elements themselves, then their parent elements. So, if I add styling to a class, it will override styles added to the element. Using the cascade can be tricky, but it makes your CSS more reusable.

Media Queries

Sometimes you will want certain attributes to change depending on screen size. You can do this using media queries.

The following CSS selectors will only apply when the screen is smaller than 800px across. You can change to min-width for mobile first!

@media only screen and (max-width: 800px) {
  body {
     background-color: MediumOrchid;
  }
}

Animations

CSS allows users to create animations with keyframes. You can specify attributes at certain points in the animation, how long that animation will take, and the timing function performed.

In addition, you can add transforms that are applied when a pseudo-selector is added, such as an element is hovered over. These are super performant!

This post is barely scratching the surface of all the things you can do with CSS, it's super powerful and a very important part of the web. Here are some resources where you can dive a little deeper

The Most Important Non-Programming Skills for Programmers

Mon, 15 Oct 2018 00:00:00 GMT

When I think about who I would like to work with as a programmer, I think so much more about non-technical skills than technical skills that make somebody a good co-worker. In fact, all of the skills that are in this post contribute to writing good code that improves technical projects. Most of them are really helpful for careers outside of programming too, but I'm going to focus on why they're useful for programmers specifically.

Empathy

To build a great product, you must put yourself in the shoes of your users. How will they be using your product? What features will be helpful for them? How can your program help them or improve their lives? And -- conversely -- how could it harm them or negatively impact their lives? What are the ethical implications of your application?

Empathy is essential for so many pieces of your programs -- if they aren't secure then your user's information could be used negatively by a third party. If they aren't accessible, then you are limiting the number of people that can use your project. If they run slowly or needs huge amounts of bandwidth to run, then users will leave and people in areas with slow internet or mobile users won't be able to run them. It seems like every day an article comes out with some harmful algorithm a company has implemented, like the YouTube algorithm radicalizing the alt-right, Amazon creating a sexist hiring algorithm (which they didn't end up using), or AI misgendering black women. Think about everybody when you are writing your code!

Also, empathy is helpful for being a team member and a mentor. Put yourself in your manager or another developer's shoes. Why are they making their decisions? What can you do to help them? Having empathy will definitely improve your ability to be an effective teammate. If you're an employer, you can retain your employees for longer, and they will be more effective workers if you display empathy (src).

Have patience for other programmers, especially ones that are learning new things. Remind yourself of something that was really hard for you to learn and how that felt. They probably feel similarly. Being rude to them, diminishing their progress, or being pedantic will only be harmful and make that process harder for them.

Your words and actions have real consequences -- you can use that to enact positive change or hurt somebody. That doesn't end with in-person communication -- online communication counts too. You may think you're being funny or just letting off steam, but you may actually causing a very negative impact on someone's life. It's up to you to decide how to act, and how to apologize if you hurt someone to undo some of that harm.

Problem Solving

When I teach people to code, I see a lot more people struggling with problem-solving than the code itself. The ability to break a problem into smaller ones and then solve all of those smaller problems takes a lot of practice. Getting good at problem-solving can help you become a much stronger programmer.

Also, for most problems, there will be more than one solution. A large part of our jobs as software developers is to think through those different solutions and choose the one that is best. Is one faster to implement? Or does it run more efficiently? Or will it be less expensive? All of these are important questions, and picking the correct solution is a challenging but important part of software development.

Collaboration

Chances are very high that you with other people as a programmer. You will have to work with other developers, business people, managers, open source contributors, stakeholders, and countless other people even if you are a freelancer or entrepreneur. Learning how to work well with different people and their personalities is critical.

There are so many things that contribute to good collaboration. The first is knowing that one person can't do everything, or at least do everything well. Different people have different skills, points of view, and life experiences that are more powerful in combination than isolation. Don't feel like you always need to "put the team on your back" or be everything to everybody. You can be a lot better if you allow other people to contribute too.

Ask other people for help, and be willing to help people in return. You don't need to be an expert in everything, and different people will be experts in different things. Rely on other people, and if you are stuck on something make sure to ask for help so that you don't stay stuck for too long. When somebody asks you for help, be willing to help them. You can learn a lot by explaining things well, and you will be able to reinforce your knowledge of the topic. If you're in a management position, make sure to give people time for mentorship and effective collaboration!

Along the same lines, don't talk over people or immediately dismiss their viewpoints. They will probably be much less likely to contribute in the future if their opinions aren't valued or taken into account. Actively listen when people share their ideas -- instead of thinking about your response or why your idea is better while they are talking, try to think about why their approach is also good or how it could be implemented.

Then, once you implement their awesome ideas, give them credit for those ideas. Nothing has made me less effective as an employee as being on a team where my ideas were dismissed, under-valued, and un-credited by other people on my team.

Communication

When you are working with other people, whether those people are co-workers, clients, the people who use your projects, managers, or people you manage, good communication is crucial. Give honest updates on how things are going, where projects currently stand, and your opinions on things honestly but kindly. People will be less receptive to feedback if you are rude or unconstructive. But, if you are dishonest or sugar-coat the truth, then you may not see a positive change. There's definitely a fine line here.

One real life example from my life: I had somebody who read one of my blog posts write a very long letter about how dumb I sound because of the tone I take. I usually use a lot of exclamation points and try to sound exciting in my posts -- and that's very intentional to try and make topics that can be intimidating or boring more fun. The person got pretty sexist in this email and said some pretty hurtful things. That being said, I probably could scale back on the exclamation points and still get people excited about programming. I would have been a lot more receptive to that point if the person had framed the criticism more constructively.

If things are not going well, make sure to say so. Be honest about needing a deadline pushed back, or how something isn't going well at work. You will have a much better chance at changing it and making the environment better for yourself if you speak up.

Inclusiveness

I used to work as a rock climbing instructor and counselor at a summer camp, and the age group I worked with most were middle school girls. They were some of my favorite people I've ever worked with, but, that being said, middle schoolers aren't usually the most accepting of difference or that clique-adverse. We used to run a game where we started out in one large circle, and then one counselor would tell people they were "out of the circle", and they would have to leave the game based on some characteristic that they weren't informed of and couldn't control. The people still inside the circle would play a game, and the people outside of the circle were excluded and just had to watch from afar.

This activity was super effective in showing these girls what it was like to be left out for reasons outside of your control, and I still think back on it a lot. As adults, we still leave people out of the circle and exclude them based on certain characteristics outside their control, but if we let them back into the circle and allow them to contribute then our products draw on more diverse experiences and are better. There's a lot of research on more diverse teams performing better, but from an individual perspective, think about what it feels like to be left out of the circle and try to make your circle larger, not smaller. Chances are, a lot of your users may be people that have traditionally been left out of the circle in tech. I can tell you from my own experience, that it's really difficult to be the only person like you on a team as someone who's been on a team with another woman for ~5% of my programming career.

This also links into empathy -- make sure that you are making your programs for a wide variety of users. Not just the able-bodied or those with cutting-edge internet or technologies. You will be able to reach more people.

Patience

The first person that you need to have patience with when you are programming is yourself. Programming is hard and sometimes you will have bugs or difficult problems to overcome. If it's always easy, then you aren't challenging yourself, and you aren't growing as a programmer. Have the tenacity to keep working through a problem and not give up when it gets hard. But, also, know that you can take a break and come back to the problem in a little while. Maybe taking a break will help you solve the problem more efficiently or to see it differently when you come back to it.

Also, be patient with other people. Things can take a while to learn and people are not perfect. Making mistakes and failing can be some of the most important experiences in the learning process, so allow for that instead of creating an environment where it isn't safe to take risks or grow. Understand that different things click more easily for different people, and know that learning can take a while.

Creativity

My favorite thing about being a programmer is that I get to use my creative energy to build things that other people can then benefit from. You get to think outside of the box to create really cool things.

Having creative ideas is important for coming up with new features, interfaces, and applications. I had somebody buy a license for a product that I built for a company in large part because of the creative interface, and my portfolio site has gotten traction because of its creativity.

In addition to that, a lot of problems require creativity to solve. There is more than one solution to almost every programming problem, and coming up with creative approaches to solving them can often lead to an optimized solution.

Humility

You can learn so much from other programmers -- one person cannot know everything or anything close to it in the world of code. Be receptive to constructive criticism instead of defensive. You can improve your code and yourself from feedback, and being stuck in your ways doesn't lead to growth. You aren't always right, and you should be receptive to other people's ideas.

Confidence

On the flip side, also be confident. I'll admit that this is probably the most difficult one for me as someone with a lot of imposter's syndrome, and it has been my #1 thing to improve on every performance review I've had in my career. I can (and probably will) write an entire blog post on this topic alone, but believing in yourself and being confident in your abilities is really important.

First, have confidence that you can take projects on. Don't relegate yourself to easier projects or doubt yourself when you are assigned something difficult. Try to solve as much of it as you can, and then ask for help to get through the hardest parts.

Also, don't feel the need to research everything as a first resort. Trust yourself to try a couple things before Googling the answer. Or Google part of the problem instead of the whole thing. If you're doing everything correctly, you are hurting nothing by trying a couple things out in development and seeing if they work. You may be surprised by how much you know.

Another thing that I do is keep track of my wins. I have a document on my computer with cool things that I've done, and really nice things people have said about me. When I'm having a tough day or doubting myself, I'll come back to it and usually feel more confident in what I'm doing.

Adaptability

Programming is still a new world, and it is evolving super fast. Being able to adapt when things change is critical. When a new framework, library, or language comes out that takes over, it's important to be able to learn it (within reason of course). Our industry would look dramatically different if we were all still writing code in Fortran; we need to be able to evolve and adapt when things change.

Also, the goal posts and features for projects will often change, especially with client work. When that happens, we have to adapt and incorporate those requests (again, within reason).

Community Participation

The community is so important for programming -- conferences, blog posts, social media, and meetups are important for learning and growing. Also, open source software and the communities that surround them are the lifeblood of this industry. Being able to network and make connections with people is so important for education, relating your experiences, and finding new opportunities.

Even if you are an introvert or don't love in-person socializing, there are a ton of awesome online communities that you can learn a lot from. And, even inside of companies, having a team with a strong bond will help people work better together.

Conclusion

These skills are often referred to as "soft skills", but I feel like that's reductive. These skills help so much with both writing code and being a good co-worker. They are so much more important than knowing a specific language, library, or framework and they go far even outside of tech.

All of these skills are really important to work on as programmers and as people. That being said -- nobody is perfect, and everyone has room to grow. So keep growing, and trying to make small steps to be better at these non-programming skills and I will too!

My Blog Post Workflow: from Topic to Publication

Wed, 05 Sep 2018 00:00:00 GMT

Writing blog posts can be pretty tricky -- it's hard to come up with a topic to write about let alone actually create the content. I've been blogging more and more, and I wanted to give my advice for writing posts -- from the topic through pressing the post button! If you're interested in my advice for starting a blog, I also have a post on that here.

1. Finding a topic

Sometimes, finding a topic for a blog post is one of the hardest parts of creating it! Here are a few tips for finding topics:

Don't worry too much about having a totally unique topic -- definitely don't plagiarize somebody else's post or copy their ideas, but people still read my React intro even though that topic has been done a bunch of times. I had a different outlook on the subject, so I decided to write it anyways.
Write the blog post that would have helped past you. When you're searching for something and not finding it, or you're finding tutorials that aren't helping very much, take note of it so that you can write your own take later. Thank you so much to LaQuita for suggesting this one!
One thing I do, is to reach out to your network and see what posts people want. I'll occasionally post a Tweet asking what types of posts people want. People also reach out to me on a pretty frequent basis asking for my advice or opinions on things. I take note of ones that I find especially interesting or relevant to a broader audience. You can also look at sites like Quora or Reddit and see what people are posting there. If a question is especially interesting to you, you could write a long-form response to it.
You have a unique story -- so share it! Share your backstory and how you started writing code, or the story of your career progression, or even just a problem that you solved. It can be tough to be personal and to share your story online, but it can really help people.
I firmly believe that creativity can stem from constraint. I always dress better when I have a dress code at work because I have to think creatively to fit within the guidelines instead of just throwing on whatever. When I started blogging, I followed the theme of writing a post each week about an app I built with a technology that was new to me. There were so many technologies that I wanted to learn, that I always had something to write about -- the only thing that made me stop was time constraints! Vaidehi Joshi's wildly successful BaseCS series is another excellent example of closely following a theme.

I keep a running list of blog post ideas using TickTick - which is the to-do list app I use. Writing down topics when I think of them is important -- I will totally forget them if I don't. At the beginning of the month, I make a content calendar with what posts I actually want to write that month. I don't always stick to the content calendar, but its good to know what I want to write in advance and to know that there's a balance of different topics and genres.

2. First Draft

Once I have a topic, I usually just start writing any thoughts that I about it. My process is really disorganized here -- I'll jump from place to place in the post, outlining some parts and then writing paragraphs in others. I let myself be really creative, and I jot down whatever I'm thinking. As I write this, the current paragraph is entirely written out, but the beginning of the post is just a set of phrases like "creativity from constraint" and "Share your story." Other people are probably more methodical, but this works well for me.

Then, I go through and make sure that I've completely written out each part, and that I'm happy with the post.

There are a couple things I focus on about the content:

That it is accurate - of course with technical content, the facts need to be correct, and the code needs to work. I usually copy and paste code from complete apps I've written, so that I for sure know that it will work.
That it is understandable and fits my target audience - another essential thing to do with your blog posts is to identify your target audience and gear your writing towards them. Is your target reader a Node developer that wants to learn the SQL library Knex? Or, is your reader a complete newbie who will need the concept of a function explained while you're building your Node app. You want your post, generally, to appeal to a pretty broad audience, so I usually gear my posts towards people who know the fundamentals but don't know the specific tool I'm talking about. You usually want to target your posts to a relatively similar audience so that people are interested in your work from post to post.
I don't use walls of text. On the internet, people are used to short blocks of text broken up with visuals that are easy to scan. Add bullet points, images, and subheaders to your posts to add more visual interest. My posts are generally in between 2,000 and 3,000 words, but they don't feel like that much because there aren't huge blocks of text.

I write my content using my text editor VS Code. The Markdown support is fantastic, and I have a spellchecker to catch issues as I go. It has a preview tool so I can see what the final Markdown will look like if I want too! I like being able to customize my setup, so I really like using VS code for this process.

3. Revision

Next, I run my post through Grammarly -- I have the pro version. I like how it allows me to choose the tone I'm trying to use in the post and the audience, and how I can "teach" it to be more accurate for my writing. It also picks up on overused words, which can be really helpful as well. I copy and paste my text into the desktop editor, and then go through each error making sure that the content is good as I go.

4. Visuals

The next step in my process is creating visuals for social media and to add visual interest to my posts. These usually have the tl;dr versions of my posts, or just the headline. I make them in all of the preferred sizes for social media sites so that when you press the share button or share the link to a post, the image should look pretty good (at least on my site)!

I draw these up in Sketch, I have a boilerplate setup that I just copy and paste that contains the different artboards for differently sized images. Then, I just add in the designs I want for the post and format them!

5. Publishing

The final step is to actually press publish and send your post into the world! I highly recommend posting to someone else's site at first, or at least crosspost -- unless building and maintaining the blog infrastructure is your primary goal! Right now I post to my own site, dev.to, and Medium. I also tried LinkedIn once, but it was tough to format, and only around 100 people read it, so it wasn't worth the effort in my experience. Medium can be tricky too, but Markdown to Medium makes it a little easier -- it converts your markdown code to Gists, so you don't have to worry about the weird Medium code formatting!

Honestly, for me, pushing publish is often the hardest part. I have a graveyard of unpublished posts on my computer that I may or may not post at some point. Honestly -- I regularly wait until days after writing my posts to publish them because of nerves. I want to list some of my common worries and how I push myself to still eventually post.

Nobody's going to read my post: So what. I've already put all the effort into writing it, worst case scenario I benefit from writing the post but nobody else does.

I'm not experienced enough to write about this: If you have a blog post that contains mostly correct information, or at least your interpretation of the topic, then you're experienced enough. There are lots of excellent posts out there from the perspective of newbies, and they're really important!

What if my code is wrong? Or I got a detail wrong?: It happens! I've had bugs in my articles before! So have lots of people. Sure, somebody might be rude about it, but in my experience, most people just want to help. Plus, then you learned something new from writing the post, and you can edit easily enough!

What if people are mean on the internet?: this is my new problem -- it has been really cool to see my blog grow a little bit, but with that rise comes a downside. There are now a lot more rude comments towards me on social media and inappropriate advances. I'm definitely not perfect at dealing with this, but I try to remember that there are so many more positive comments than negative ones, and hopefully my posts are helping some people out there. I try to ignore them, and I've stopped looking at threads when my posts show up on sites like Reddit or HackerNews that can have more toxicity along with the anonymity. Yeah, people can be rude, but way more people are friendly and benefit from what you're doing.

So, go out there and publish some blog posts! I can't wait to see them.

A Complete Beginner's Guide to React

Tue, 28 Aug 2018 00:00:00 GMT

If you're interested in learning React with Hooks first, check out the 2020 re-write of this post!

I want to get back into writing more code-heavy content, and React is one of my favorite technologies, so I thought I would create a React intro! This post requires knowledge of HTML and JavaScript -- I am of the firm opinion that you should know these before moving on to libraries like React!

What is React

React is a JavaScript library build in 2013 by the Facebook development team to make user interfaces more modular (or reusable) and easier to maintain. According to React's website, it is used to "Build encapsulated components that manage their own state, then compose them to make complex UIs."

I'm going to use a lot of Facebook examples throughout this post since they wrote React in the first place!

Remember when Facebook moved from just likes to reactions? Instead of just being able to like posts, you can now react with a heart, or a smiley face, or a like to any post. If those reactions were primarily made in HTML, it would be a tremendous amount of work to change all of those likes to reactions and to make sure that they work.

This is where React comes in -- instead of implementing the "separation of concerns" that gets impressed upon developers from day one, we have a different architecture in React that increases modularity based on a component structure instead of separating the different programming languages.

Today, we'll keep the CSS separate, but you can even make that component specific if you want!

React vs. Vanilla JavaScript

When we talk about "vanilla" JavaScript, we are normally talking about writing JavaScript code that doesn't use additional libraries like JQuery, React, Angular, or Vue. If you would like to read more about those and what a framework is, I have a post all about web frameworks!

A couple quick notes before we begin

To make this tutorial a little more succinct, some code examples have ... before or after them, which means that some code was omitted.
I use Git diffs in some places to show lines of code that will change, so if you copy and paste, you need to delete the + at the beginning of the line.
I have full CodePens with the completed versions of each section -- so you can use those to play catch-up!
More advanced concepts that aren't essential for the tutorial are in blockquotes, these are mostly just facts that I think are interesting!

Want more advice on learning to code?

Download my free Ebook!

Set Up

If you are creating a production React application, you will want to use a build tool, like Webpack, to bundle your code since React utilizes some patterns that won't work by default in the browser. Create React App is super helpful for these purposes, since it does most of the configuration for you!

For now, since we want to get up and running super quickly so we can write actual React code, we will be using the React CDN, which is only for development purposes! We will also use the Babel CDN so that we can use some non-standard JavaScript features (we'll talk more about that later!).

<script
  crossorigin
  src="https://unpkg.com/react@16/umd/react.development.js"
></script>
<script
  crossorigin
  src="https://unpkg.com/react-dom@16/umd/react-dom.development.js"
></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/6.1.19/browser.js"></script>

I also made a Codepen template that you can use!

In a full React project, I would split my components into different files, but again, for learning purposes we will combine our JavaScript into one file for now.

Components

For this tutorial, we will be building a Facebook status widget, since Facebook wrote React in the first place!

Think about how many places the like widget appears on Facebook -- you can like a status, or a link post, or a video post, or a picture! Or even a page! Every time Facebook tweaks something about the like functionality, they don't want to have to do so in all of those places. So, that's where components come in! All of the reusable pieces of a webpage are abstracted into a component that can be used over and over again, and we will only have to change code in one place to update it.

Let's look at a picture of a Facebook status and break down the different components within it.

The status itself will be a component -- there are lots of statuses within a Facebook timeline, so we definitely want to be able to reuse the status component.

Within that component, we will have subcomponents or components within a parent component. Those will be reusable as well -- so we could have the like button component be a child of the PhotoStatus component and the LinkStatus component.

Maybe our subcomponents would look something like this:

We can even have subcomponents within subcomponents! So, the group of like, comment, and share could be it's own ActionBar component with components for liking commenting and sharing within it!

There are a bunch of ways you could break down these components and subcomponents depending on where you will reuse the functionality in your application.

Getting Started

I wanted to start off this tutorial with a React "Hello World" -- it is tradition after all! Then we'll move to the slightly more complex status example.

In our HTML file, let's add just one element -- a div with an id on it. By convention, you will normally see that div have an id "root" on it since it will be the root of our React application!

<div id="root"></div>

If you're writing the code in the CodePen template, you can write this JavaScript directly in the js section. If you are instead writing this on your computer, you will have to add a script tag with the type text/jsx, so:

<script type="text/jsx"></script>

Now, let's get to our React code!

class HelloWorld extends React.Component {
  render() {
    // Tells React what HTML code to render
    return <h1>Hello World</h1>
  }
}

// Tells React to attach the HelloWorld component to the 'root' HTML div
ReactDOM.render(<HelloWorld />, document.getElementById("root"))

All that happens is that "Hello World" is displayed as an H1 on the page!

Let's walk through what's going on here.

First, we are using an ES6 class that inherits from the React.Component class. This is a pattern that we will use for most of our React components.

Next, we have a method in our class -- and its a special method called render. React looks for the render method to decide what to render on the page! The name makes sense. Whatever is returned from that render method, will be rendered by that component.

In this case, we are returning an H1 with the text of "Hello World" -- this is exactly what would be in the HTML file normally.

Finally, we have:

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

We are using the ReactDOM functionality to attach our react component to the DOM.

React utilizes something called the virtual DOM which is a virtual representation of the DOM that you would normally interact with in Vanilla JavaScript or JQuery. This reactDOM.render renders this virtual DOM to the actual DOM. Behind the scenes, React does a lot of work to efficiently edit and re-render the DOM when something on the interface needs to change.

Our component, <HelloWorld />, looks like an HTML tag! This syntax is part of JSX which is an extension of JavaScript. You can't natively use it in the browser. Remember how we're using Babel for our JavaScript? Babel will transpile (or convert) our JSX into regular JavaScript so the browser can understand it.

JSX is actually optional in React, but you'll see it used in the vast majority of cases!

Then, we are using JavaScript's built-in document.getElementById to grab our root element we created in our HTML.

All in all, in this ReactDOM.render statement, we are attaching our HelloWorld component to our div that we created in our HTML file.

Starter Code

Okay -- now that we've done a "Hello World," we can get started with our Facebook component.

First, I want you to play around with this demo. We'll be working on this throughout the rest of the tutorial. Feel free to look at the code too, but don't worry about not understanding it! That's what the rest of the tutorial is for!

See the Pen State + Props by Ali Spittel (@aspittel) on CodePen.

Let's start off by "hard coding" the HTML for the widget:

<div class="content">
  <div class="col-6 offset-3">
    <div class="card">
      <div class="card-block">
        <div class="row">
          <div class="col-2">
            <img
              src="https://zen-of-programming.com/react-intro/selfiesquare.jpg"
              class="profile-pic"
            />
          </div>
          <div class="col-10 profile-row">
            <div class="row">
              <a href="#">The Zen of Programming</a>
            </div>
            <div class="row">
              <small class="post-time">10 mins</small>
            </div>
          </div>
        </div>
        <p>Hello World!</p>
        <div>
          <span class="fa-stack fa-sm">
            <i class="fa fa-circle fa-stack-2x blue-icon"></i>
            <i class="fa fa-thumbs-up fa-stack-1x fa-inverse"></i>
          </span>
        </div>
        <div>
          <hr class="remove-margin" />
          <div>
            <button type="button" class="btn no-outline btn-secondary">
              <i
                class="fa fa-thumbs-o-up fa-4 align-middle"
                aria-hidden="true"
              ></i>
              &nbsp;
              <span class="align-middle">Like</span>
            </button>
          </div>
        </div>
      </div>
      <div class="card-footer text-muted">
        <textarea
          class="form-control"
          placeholder="Write a comment..."
        ></textarea>
        <small>120 Remaining</small>
      </div>
    </div>
  </div>
</div>

With some added CSS, this looks like the following:

Here's a Codepen with the full starter code.

For the sake of this tutorial, we will be creating four components: a Status component which will be the parent, a Like component that will encompass the liking logic, and the Comment component which will contain the logic for typing in a comment. The Like component will also have a child LikeIcon that will show up or be hidden when you toggle the like button.

Component Architecture

Let's go ahead and divide the HTML code that we've written into those components.

We'll start with the shell of a component, and we'll render it as well to make sure it's working!

class Status extends React.Component {
  render() {
    return (
      <div className="col-6 offset-3">
        <div className="card">
          <div className="card-block">
            <div className="row">
              <div className="col-10 profile-row">
                <div className="row">
                  <a href="#">The Zen of Programming</a>
                </div>
                <div class="row">
                  <small className="post-time">10 mins</small>
                </div>
              </div>
            </div>
          </div>
          <p>Hello world!</p>
          <div className="card-footer text-muted" />
        </div>
      </div>
    )
  }
}

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

One interesting note about the above, is that we had to change "class" attributes to "className". Class already means something in JavaScript -- its for es6 classes! Some attributes are named differently in JSX than in HTML.

We can also delete the content of our HTML, leaving just an element with the ID root -- the parent "content" div is just for styling!

<body>
  <div class="content">
    <div id="root"></div>
  </div>
</body>

Here's the HTML that is going to go in the Status component. Notice, some of the original HTML isn't there yet -- it's going to go into our subcomponents instead!

Let's create a second component, and then we'll include it in our Status component.

class Comment extends React.Component {
  render() {
    return (
      <div>
        <textarea className="form-control" placeholder="Write a comment..." />
        <small>140 Remaining</small>
      </div>
    )
  }
}

Here's the component for our comment. It just has our textarea to type in, and the text with how many characters we have remaining. Notice that both are wrapped in a div -- this is because React requires us to wrap all the contents of a component within one HTML tag -- if we didn't have the parent div we'd be returning a textarea and a small tag.

So, now we need to include this component within our Status component since it will be our subcomponent. We can do so using that same JSX syntax we used to render the Status component!

class Status extends React.Component {
  render() {
    return (
      <div className="col-6 offset-3">
        <div className="card">
          <div className="card-block">
            <div className="row">
              <div className="col-10 profile-row">
                <div className="row">
                  <a href="#">The Zen of Programming</a>
                </div>
                <div className="row">
                  <small className="post-time">10 mins</small>
                </div>
              </div>
            </div>
          </div>
          <div className="card-footer text-muted">
+           <Comment />
          </div>
        </div>
      </div>
    )
  }
}

Okay, now we just need to do the same for our likes!

class LikeIcon extends React.Component {
  render() {
    return (
      <div>
        <span className="fa-stack fa-sm">
          <i className="fa fa-circle fa-stack-2x blue-icon" />
          <i className="fa fa-thumbs-up fa-stack-1x fa-inverse" />
        </span>
      </div>
    )
  }
}

class Like extends React.Component {
  render() {
    return (
      <div>
        {/* Include the LikeIcon subcomponent within the Like component*/}
        <LikeIcon />
        <hr />
        <div>
          <button type="button">
            <i
              className="fa fa-thumbs-o-up fa-4 align-middle"
              aria-hidden="true"
            />
            &nbsp;
            <span className="align-middle">Like</span>
          </button>
        </div>
      </div>
    )
  }
}

Then we need to include it in our original Status component!

class Status extends React.Component {
  render() {
    return (
      <div className="col-6 offset-3">
        <div className="card">
          <div className="card-block">
            <div className="row">
              <div className="col-10 profile-row">
                <div className="row">
                  <a href="#">The Zen of Programming</a>
                </div>
                <div className="row">
                  <small className="post-time">10 mins</small>
                </div>
              </div>
            </div>
+           <Like />
          </div>
          <div className="card-footer text-muted">
            <Comment />
          </div>
        </div>
      </div>
    )
  }
}

Cool, now we have React-ified our original HTML, but it still doesn't do anything! Let's start fixing that!

All in all, the code from this section will look like this CodePen!

State and Props

We have two different user interactions that we want to implement:

We want the like icon to show up only if the like button is pressed
We want the number of characters remaining to decrease as the person

Let's start working on these!

Props

Imagine that we wanted our comment box to allow for a different number of letters in different places. On a status, for example, we want a user to be allowed to write a 200 letter long response. On a picture, however, we only want them to be able to write a 100 character response.

React allows us to pass props (short for properties) from the PictureStatus component and the Status component to specify how many letters we want to allow in our response, rather than having two different comment components.

The syntax for props looks like the following:

<Comment maxLetters={20} />
<Comment text='hello world' />
<Comment show={false} />

var test = 'hello world'
<Comment text={test} />

The props look like HTML attributes! If you are passing a string via props, you don't need the brackets, but any other data type or a variable needs to be within the brackets!

Then, within our component, we can use our props:

console.log(this.props.maxLetters)

They are bundled together in the props attribute of the instance so they can be accessed with this.props.myPropName.

So, let's change the hardcoded 140 characters to be easily changeable outside the component!

First, we'll change where we instantiate the Comment component within the Status component (note some code is omitted!):

class Status extends React.Component {
        ...
          <div className="card-footer text-muted">
+            <Comment maxLetters={280} />
          </div>
        </div>
      </div>
    )
  }
}

Then we'll change the hardcoded 140 character limit in the Comment component.

class Comment extends React.Component {
  ...
        <div>
        <textarea className="form-control" placeholder="Write a comment..." />
+       <small>{this.props.maxLetters} Remaining</small>
      </div>
  ...
}

State

The props that we pass from component to component will never change within the child component -- they can change within the parent but not within the child. But -- a lot of the time we will have attributes that we will want to change within the life of a component. For example, we want to keep a tally of how many characters the user has typed into the textarea, and we want to keep track of whether the status has been "liked" or not. We will store those attributes that we want to change within the component in its state.

You'll notice a lot of immutability within React -- it is highly influenced by the functional paradigm, so side effects are also discouraged.

We want this state to be created whenever we create a new instance of a component, so we will use the ES6 class constructor to create it. If you want a quick refresh on ES6 classes MDN is a great resource!

State is going to be an object with any key-value pairs that we want to include. In this case, we want a characterCount of how many characters the user has typed. We'll set that to zero for now!

class Comment extends React.Component {
  constructor () {
    super()
    this.state = {
      characterCount: 0
    }
  }
  ...

Now let's subtract that from the maxLetters prop, so we always know how many characters we have remaining!

<small>{this.props.maxLetters - this.state.characterCount} Remaining</small>

If you increase the characterCount, the characters remaining display decreases!

But -- nothing happens when you type! We're never changing the value of characterCount. We need to add an event handler to the textarea so that we change the characterCount when the user types!

Event Handlers

When you've written JavaScript in the past, you've probably written event handlers to interact with user input. We are going to do the same in React, the syntax is just going to be a little bit different.

We are going to add a onChange handler to our textarea. Inside of it, we will place a reference to an event handling method that will run every time the user types in the textarea.

<textarea
  className="form-control"
  placeholder="Write a comment..."
  onChange={this.handleChange}
/>

Now we need to create a handleChange method!

class Comment extends React.Component {
  constructor () {
    super()
    this.state = {
      characterCount: 0
    }
  }

  handleChange (event) {
    console.log(event.target.value)
  }
...

Right now, we're just console.log-ing the event.target.value -- this will work the same way as it does in React-less JavaScript (though if you dive a little deeper, the event object is a little bit different). If you look at that console, we are printing out what we are typing in the textbox!

Now we need to update the characterCount attribute in state. In React, we never directly modify state, so we can't do something like this: this.state.characterCount = event.target.value.length. We instead need to use the this.setState method.

  handleChange (event) {
    this.setState({
      characterCount: event.target.value.length
    })
  }

But! You get an error -- "Uncaught TypeError: this.setState is not a function". This error is telling us that need to preserve the context of the es6 class within the event handler. We can do this by binding this to the method in the constructor! If you want to read more about this, here's a good article!

class Comment extends React.Component {
  constructor () {
    super()
    this.handleChange = this.handleChange.bind(this)
...

Okay! We're almost there! We just need to add the ability to toggle the like showing up!

We need to add a constructor to our Like component. In that constructor, we need to instantiate the component's state. The thing that will change within the lifecycle of the component is whether or not the status has been liked.

class Like extends React.Component {
  constructor() {
    super()

    this.state = {
      liked: false
    }
  }
  ...

Now we need to add an event handler to change whether or not the status has been liked!

class Like extends React.Component {
  constructor() {
    super()

    this.state = {
      liked: false
    }

    this.toggleLike = this.toggleLike.bind(this)
  }

  toggleLike () {
    this.setState(previousState => ({
      liked: !previousState.liked
    }))
  }
...

The difference here is that the callback function that this.setState receives a parameter -- previousState. As you can probably guess from the name of the parameter, this is the value of state before this.setState is called. setState is asynchronous, so we can't depend on using this.state.liked within it.

Now, we need to:

a) call the event handler whenever the user clicks on the like button: b) only show the LikeIcon when liked is true

  render() {
    return (
      <div>
        {/* Use boolean logic to only render the LikeIcon if liked is true */}
+       {this.state.liked && <LikeIcon />}
        <hr />
        <div>
+          <button type="button" className="btn no-outline btn-secondary" onClick={this.toggleLike}>
            <i
              className="fa fa-thumbs-o-up fa-4 align-middle"
              aria-hidden="true"
            />
            &nbsp;
            <span className="align-middle">Like</span>
          </button>
        </div>
      </div>
    )
  }

Awesome! Now all of our functionality is in place!

Bonus: Functional components

If you feel like you're in over your head already, feel free to skip this part, but I wanted to make one more quick refactor to this project. If we create components that don't have state associated with them (which we call stateless components), we can make our components into functions instead of ES6 classes.

In that case, our LikeIcon could look something like this:

const LikeIcon = () => {
  return (
    <div>
      <span className="fa-stack fa-sm">
        <i className="fa fa-circle fa-stack-2x blue-icon" />
        <i className="fa fa-thumbs-up fa-stack-1x fa-inverse" />
      </span>
    </div>
  )
}

We just return the UI of the component instead of using the render method!

Here is a CodePen that implements this refactor!

Cheat Sheet

I love cheatsheets, so I made one with the content from this post!

You can also download it as a PDF here!

Next Steps

To recap, we talked about the component architecture, the basic React syntax and JSX, state and props, event handlers, and functional components.

If you would like to view all the CodePens from this tutorial, here is a collection!

If you would like to try to extend the code from this tutorial, I would recommend changing likes to reactions or creating a photo component that reuses some of the components that we made!

Also, here are some other awesome places to learn React:

A Web Design Crash Course: From one non-designer to another

Sun, 19 Aug 2018 00:00:00 GMT

I will preface this by saying that I'm not professionally a designer. That being said, I like building pretty things and have had some success with that. A lot of developers seem overwhelmed by design, so I wanted to do a quick write-up with visual examples with quick tips on how to improve the visuals of your site. Rules are made to be broken, but if you want to make a great website as easily as possible, these are some good rules of thumb!

Color

I really enjoy playing with color on my websites, but there needs to be a balance and a coordinated color scheme for the site to look cohesive and professional. It's essential that these colors don't clash, that they have a reasonable level of contrast, and that they are consistent.

Consistency

Here's my color scheme for The Zen of Programming:

I use the same hex codes for green, pink, and grey for my backgrounds, headers, text, and buttons.

You can use CSS variables to make sure that your colors are the same throughout your code.

body {
  --pink: #cf92b7;
  --green: #59876b;
  --grey: #4a4a4a;
}

h1 {
  color: var(--pink);
}

If you are using SCSS or another CSS preprocessor, this is even easier!

As far as the number of colors involved in your theme, four is usually a good bet. Maybe make two of these colors neutrals (like black, white, or grey) and two bolder pops of color. Monochromatic color schemes that use shades of one color can definitely work as well!

When I work with rainbow color schemes, I treat the rainbow as one color and then use two neutrals for everything else. For example, on alispit.tel I use a dark grey for some text, white for the background, and then the rainbow colors for letters and random shapes.

Clashing Colors

It's important to make sure your colors look good together and don't clash. Usually, the colors opposite to each other on the color wheel clash. Of course, you can make excellent websites that utilize clashing colors, but it is more difficult and may be better left to designers. Some examples would be red and green or orange and purple.

Also, keep the tones of the colors in mind -- if you are using a cool toned pink, a cool toned green may be good to pair with it instead of a warm-toned green. Warm-toned colors have redder undertones, and cool toned colors are bluer.

Contrast

Make sure there's a reasonable level of contrast between the colors on your website. If there isn't, it will be much more difficult to read your content. Here's an awesome site that will check your contrast for you. Lighthouse testing will also check this for you! In general, put light colors on top of dark ones, and dark colors on top of light ones!

Color Meaning

If you are working on a website for a brand, different colors have different implicit meanings to readers, and they can convey different moods so it can be helpful to keep those in mind.

Tips for choosing colors

There are a lot of awesome websites that make it easier to pick good color palettes that coordinate well.

I sometimes use the Coolors generator when I'm building a new site. I also follow this account on Instagram, and I will save color palettes that I like when I see them. Finally, If I just want to see a bunch of colors and choose between them, I use the color page on Materialize -- I like their colors!

Text

On most sites, the text will be the most critical part. You need it to be easy to read and for the most important content to be emphasized.

Here's an example of really hard to read text:

Let's work on making it more readable!

Spacing

Add spacing to your text content. There are a few types of spacing that can make your content more readable. The first is adding padding on the sides of your page.

On the sides of your content

On a lot of websites -- the text won't span the width of the page, it will be inside of a container that takes up only part of the page. This makes the content more comfortable to read since your eyes need to move less, and the page will look better. The W3C recommends fewer than 80 characters per line.

<style>
  .container {
    width: 80%;
    margin: 0 auto; /* centers the div on the page */
  }
</style>

<div class="container">
  <p>
    Lorem ipsum dolor amet master cleanse cloud bread brunch pug PBR&B actually.
    Thundercats marfa art party man bun gluten-free sriracha. DIY tofu cred blue
    bottle etsy. Retro listicle normcore glossier next level etsy lumbersexual
    polaroid pour-over 90's slow-carb health goth banjo. Unicorn chicharrones
    8-bit poke glossier.
  </p>
</div>

Line Height

We can add line-height to add more space between lines of text. The most recent Android operating system added a more substantial line-height to notifications, which makes them easier to read at a glance.

Also, it is best for accessibility purposes to add more line-height -- the W3C recommendation is 1.5 to 2.0. Remember having to double space essays in high school? We're doing the same thing here, just online this time!

p {
  font-size: 18px;
  line-height: 2;
}

This will transform the text on the left to the text on the right in the image below.

Paragraph Padding

I would also make sure to add padding in between your paragraphs so that it is easy to differentiate between them.

p {
  padding-bottom: 27px;
}

Word Spacing

If you are using all-caps for a header, you may want to add more spacing in between words so that it is easier to differentiate between them.

Here is my blog's header with additional word spacing:

And here it is without:

h1 {
  word-spacing: 9px;
}

The first is a lot easier to read!

Alignment

It is easiest to read content if it is aligned to the left and un-justified for English and other top-left to right languages. Your content will be this way by default! Just make sure you don't have a text-align: center; on it! Feel free to center your headers or the container your text is in, but have long blocks of content left-aligned.

Readable fonts

Some fonts are easier to read than others. For content on the web, it is generally easier to read fonts that are sans-serif. Serifs are the little points that come off of the ends of letters in some fonts -- you can see a serif in the green circle in the diagram below!

My rule of thumb is one decorative (think cursive or un-traditional) font or a serif font for headers and one sans-serif font for content per website.

Some of my favorite fonts:

Serif and Decorative

Sans-Serif

Roboto
Lato
Montserrat
Fira Sans
Arial - this one comes on your computer

Color

Black text on a white background can cause eye strain because of too much contrast. I use dark greys for my content. Then, there is still a lot of contrast, but not as much as there would be with black text.

p {
  color: #4a4a4a;
}

The same is true with backgrounds -- a pure black is often not the best choice -- a dark navy or grey will make your content easier to read.

Sizing

There are differing opinions on how large your content should be and what unit of measurement you should use (em vs. px for example); however, the consensus leans towards 16-18 pixels and having that scale for people who zoom in or out on your site.

Headers of varying types should be larger than your content. Also, use different font weights to differentiate text.

Once we change these things...

Our content becomes a lot easier to read!

Backgrounds

Making background images look good, especially with text on top of them, is really difficult. I would avoid background images unless they are critical to the site. I'm going to give a couple alternatives and solutions for making background images work if you still decide to use one!

On the below image, the text is challenging to read.

Split the Page

If you want to keep the image, you could split the page so that the picture displays on one half and the text on the other.

<style>
  .container {
    display: grid;
    grid-template-columns: 1fr 1fr;
  }
</style>

<div class="container">
  <div class="text">
    My Text
  </div>
  <img src="path/to/img" />
</div>

Use a less busy picture

If you want to keep the full page background image, if possible, use a simple picture without too much going on. In the one I'm using above, there are a lot of colors and large text that the user can still read. Using an image of a landscape or a pattern will be less distracting.

Add Text Shadow

You can also add a text shadow below your text to make it more readable.

.text {
  text-shadow: #4a4a4a 1px 1px 8px;
}

With the above changes in place and an increased font-size, the font on a background image becomes a lot easier to read!

Background Colors

I wouldn't use a super bright color for your background. Pretty much any color will be difficult to read on top of it, and it may strain people's eyes to read.

Calls to Action

When you build a website, there's usually something that you want the user to do. On e-commerce sites, you want the user to buy something. On a portfolio you probably want the viewer to contact you. On a blog, you want the user to subscribe. When you're designing a site, keep that action in mind. You may want to use a bright color, larger text, or feature that "call to action" on multiple places on your site. You also may want to make sure that it is visible everywhere on the site.

For example, my subscribe form for my blog is always in the sidebar, and it has color on it to grab the reader's attention. On my portfolio, I have links to my social media accounts on the home, about, and contact pages.

Emphasizing the important content will look different on every site, but it's important to keep the action you want the user to take in mind with each design choice you make.

UI Frameworks

You may not want to start from scratch when you design a site, so using a UI Framework may be helpful. Some of these include Bootstrap, which I would make sure to customize since its heavily used; Materialize, which follows Google's Material design philosophy; and Grommet, my favorite aesthetically -- it also emphasizes accessibility.

Design Checklist

Since this is a pretty long post with a lot of tips, I wanted to distill the most important information into a checklist. It's written in GitHub markdown, so you can copy and paste it onto an issue or into a markdown file. Then you can either check the box or replace the space with an x for each action item.

## Color

- [ ] Uses consistent colors throughout
- [ ] Uses non-clashing colors
- [ ] The color choice makes sense for the business purpose of the site

## Text

- [ ] The text has padding on both sides.
- [ ] The line-height is 1.5-2.0
- [ ] There's padding between paragraphs
- [ ] If your headings are in all caps, there's increased word spacing
- [ ] Blocks of text are un-justified
- [ ] Blocks of text are left-aligned
- [ ] Sans-serif fonts are used for body text
- [ ] A maximum of two fonts are used - one decorative or serif and one sans-serif
- [ ] body text isn't pure black on white
- [ ] body text is 16-18px and is scalable

## Backgrounds

- [ ] Use a pattern or simple image
- [ ] A text shadow is used to make headings readable
- [ ] The background isn't too bright

## Calls to Action

- [ ] Important information is highlighted in order to attract user interaction

My Favorite Free Resources for New Programmers

Sun, 12 Aug 2018 00:00:00 GMT

Last week, I shared my tips for new developers and how to start coding. I also wanted to share my favorite free resources for learning how to code. I have used or gone through each of these personally, so I can vouch for them being good quality and beginner friendly!

For HTML and CSS

A game for learning CSS selectors: CSS Diner
A game for learning CSS Flexbox: Flexbox Froggy
A game for learning CSS Grid: CSS Grid Garden
A video I made for learning CSS from zero: Learning CSS Through Creating Art
An awesome CSS Grid series by Jen Simmons: Layout Land

For JavaScript

A video series introducing JavaScript: Khan Academy Computer Programming
An awesome more advanced written introduction to JavaScript: A re-introduction to JavaScript
30 days of JavaScript challenges with corresponding videos by Wes Bos: JS 30

Want more advice on learning to code?

Download my free Ebook!

For other Programming Languages and Concepts

This site has it all -- from HTML, CSS, and JS through frameworks and other programming languages. It has a unique REPL tutorial format: Code Academy - this would be my top recommendation for where to start.
Learn a web framework -- from the command line through Python and Django and through HTML and CSS -- all in roughly a day: Django Girls - their online tutorial was where web development clicked for me -- it was very pivotal in my career!
Try Ruby code directly in your browser: Try Ruby
Github has a series of tutorials for learning both Git and GitHub directly in the browser: Try Git

For Computer Science

A series of illustrated guides to computer science fundamentals: BaseCS - there are also podcast and video versions of some of these articles!
A bunch of cheat sheets I wrote when studying for interviews: Coding Cheat Sheets
Video versions of a lot of classes including computer science classes: MIT on YouTube

For Code Challenges

Tons of challenges with difficulties attached: CodeWars
Another code challenge site with more consistency: HackerRank
Mathematical coding problems: Project Euler

Awesome beginner Libraries

Build art with JavaScript: P5.js
Build a customized map with JavaScript: Leaflet
Build virtual reality applications with HTML: A-Frame
Build a JavaScript game: Phaser

Communities

Ask questions with the #explainlikeimfive, #help, and #meta tags dev.to
Participate in Twitter chats, listen to awesome motivational podcasts, and read helpful blog posts: CodeNewbies - they also have a Slack group!

25 Tips for New Developers: Advice from a (Mostly) Self-Taught Software Engineer

Tue, 07 Aug 2018 00:00:00 GMT

The most common question I get from blog readers is "What is your advice for new programmers?" So, I thought it was time to write up my thoughts.

I will write up my full story in the future, but I took two computer science classes in college. Then, I got a software engineering internship shortly after. I started doing web development work, initially on the backend and then eventually on the frontend. My college definitely did not teach web development, let alone within the first few computer science classes, so I taught myself.

I don't think my story is unique -- all programmers are self-taught to some degree, whether that's fully self-taught or that they have a masters in computer science, but they taught themselves RegEx along the way. In fact, self-teaching may be one of the most important skills you can have as a developer.

In addition to my own experience, I also teach people to code as my primary job and for organizations I volunteer with -- so this article is drawing on that experience as well.

The rest of this article will have my tips for started.

My Tips for New Programmers

1. Have your reason, and remember it

If you want to start programming, there has to be a reason for that. Whether its that you love writing code, you want to have a more lucrative career, or that you are doing a bunch of Excel work and you want to make that more efficient. Keep track of that reason; programming is hard, and you will get frustrated sometimes. It will be essential to keep that reason in mind to stick with it. You could put a sticky note on your computer, a note on your home screen, or (like me) write it on your mirror with a dry erase marker.

2. Build a solid foundation

This may be a unique piece of advice, but I think its really helpful. Before you start writing code, if you haven't looked at math in a while, I would revisit the concepts from Algebra 1. Most of programming is built on algebra 1 math -- i.e., functions and variables. Understanding these concepts outside of programming will be super valuable in the future. I recommend Khan Academy's Algebra 1 course!

3. Find a community

Another thing that will be really helpful is finding a community to support you as you start writing code. This community will be valuable because other people will be in the same place as you, offer resources that helped them, and offer encouragement. I would suggest finding a meetup in your area as the top solution here, even small cities tend to have a group somewhat nearby. If there isn't one, I would suggest dev.to and the CodeNewbie community as two excellent alternatives. CodeNewbie has a weekly Twitter chat, a Slack group, and podcasts to listen to. Dev.to has a bunch of blog posts and a #discuss tag where you can post your questions!

Want more advice on learning to code?

Download my free Ebook!

4. Break down problems into smaller ones

One of the most important parts of programming is taking a large problem and breaking it into smaller and smaller pieces until those pieces are solvable. If you are looking at a blank text editor not knowing where to start, it may be because you haven't broken down the problem enough!

5. Pseudocode

Related to the previous point, a lot of times it is beneficial to write down in detail what you are trying to do in plain words before even trying to write code. This process is called pseudocoding, and it can take whatever form you want it to. It can also be helpful to solve a problem really slowly on paper first, thinking about or even writing down the individual steps you are taking to solve that problem.

6. Embrace the cycle of learning

If you're learning to code as a second career, especially if you've been away from the classroom for a while, learning how to learn is going to be a big part of your process. There are lots of ups and downs involved, which is very natural! I would brace yourself for that rollercoaster before starting out.

7. Start with free resources

There are a million and one resources for learning how to code. Some are free, and some are paid. I would start with the free resources, make sure you like writing code, and then after that, you could think about moving onto paid resources or even a bootcamp. I have a post about my favorite free learn to code resources here.

8. Find your niche

There are a lot of worlds within programming, find one world that you love and focus on that. Instead of trying to learn 8 programming languages, frontend and backend, compiled and interpreted languages, all the text editors and developer tools, etc. Find a few things you are really interested in and get good at them.

9. Get good at pattern recognition

Recognizing patterns in code is one of the most important skills you can have. When people talk about writing "DRY" code (i.e., Don't Repeat Yourself) they are talking about reducing the patterns in your code. I recommend the game Set for pattern recognition -- you can even play online each day on the New York Times' website!

10. Make good habits early

It will be easier to write clean code in the future if you get into the habit early. Bad habits can be hard to break. Here are my tips for writing cleaner code. If you are doing web development, running HTML and CSS validators on your code can tell you exactly what to fix!

11. Identify your learning style

Everybody learns differently -- whether that means you are a visual learner, love videos, need somebody to push you, or you love documentation, you will learn best differently than the person next to you. Identify how you learn best, and rely on resources that fit that style well. For example, I learn best from reading documentation and code examples from that documentation, and I lose focus easily in tutorials.

12. Struggle, but not too much

Struggling a little bit when you are learning is really important so that you can solve the problem yourself and find an answer using resources that exist. That being said, it can become unproductive and demotivating to struggle with a problem for too long. After a few hours, reach out to someone for help!

13. Get comfortable with failure

Programming is hard, and finding the right answer won't be immediate. One of the most pivotal moments in my programming journey was failing at writing a Sudoku solver. It can be challenging to adjust to not getting everything right away and seeing those error messages, but that is a huge part of programming.

14. Love your error messages

Error messages are super helpful, but when you are starting out that red error message can be terrifying! One huge step to take is to read through those messages, understand them, and then use them to solve the problem. In fact, you will get to a point where a program silently failing will be far more annoying than a useful error message!

15. Some programming languages are easier than others

There isn't a right answer for what programming language to learn first; however, some will be easier to pick up. My top three are Python, Ruby, and JavaScript because all three have a large community behind them, have more straightforward syntax, and are interpreted, so you don't need to go through a compiling process.

16. You don't need to know everything

It is straight up 100% impossible to know everything about programming. Nobody knows every programming language, every single method that's out there, every library and framework, or the perfect solution to every problem. Don't worry about learning everything, just focus on what you do know and extending that.

17. Depth over Breadth

Learning one thing in depth is better than learning a tiny bit about a lot of things, especially at first. That in-depth knowledge will carry over and make learning that next thing easier. Put the blinders on, so you don't get tempted to drop what you're learning and move to something new.

18. Focus on the fundamentals first

The fundamentals of programming are invaluable, and you will use them no matter what you end up doing with programming. Focus on having a solid knowledge of loops, conditionals, functions, data types, and (in most languages) object-oriented programming before moving on to learning about that awesome library that everyone's talking about. It will be so much easier to learn that library once you know the fundamentals really well. They will also carry over from language to language, so you only have to really learn them once -- after that it's just syntax!

19. Get good at Problem-solving

Problem-solving is the basis behind programming! Getting better at this is critical. Solving riddles, writing code on paper, and breaking down problems can really help with problem-solving. Something I sometimes see with new developers is that they approach programming like a research problem instead of a problem-solving project -- if they Google something well enough, then they'll have a solution. Yes, Google and Stack Overflow are super helpful, but rely on yourself sometimes too. Try something out a few different ways before researching it. Or, research small parts of the problem instead of the problem itself -- i.e. "turn a String into an array JavaScript" instead of "reverse string JavaScript."

20. Get good at researching

One of the biggest things to learn is how to find good answers to your questions or to learn new features of your language or library. Using Google is important, so is joining communities and subscribing to resources. The Google template I normally use is "problem language/framework/library" in as few words as possible and without filler. So, "sort array JavaScript", "spin element CSS", or "create router Vue."

21. Build projects you love

When you're learning, you will be building various projects to practice (and show off) your skills. Pick project ideas that are interesting to you; you will be much more likely to finish them and want to put work into them. Related, complete those projects. A few really good finished projects is way more impressive than a bunch of half-finished ones!

22. Compare yourself to only yourself

There are a lot of people learning to code out there. Don't compare your progress to someone else's, instead compare yourself to previous you and focus on your own growth.

23. Do a bunch of code challenges

Doing quick code challenges can really help solidify the fundamentals. They are great for problem-solving and practicing for interviews. I post one on Twitter every day with the hashtag #CodingPuzzle if you want someone else to solve them with!

24. Celebrate your wins

Learning to program can be a really difficult process, so when you accomplish something, even if its small, celebrate it! I keep track of my wins in Google Keep so, if I have a bad day, I can come back to those wins and remember them!

25. Programming is awesome

Programming is really cool because you get to build things. I always come back to this Sandi Metz quote:

Those of us whose work is to write software are incredibly lucky. Building software is a guiltless pleasure because we get to use our creative energy to get things done. We have arranged our lives to have it both ways; we can enjoy the pure act of writing code in sure knowledge that the code we write has use. We produce things that matter. We are modern craftspeople, building structures that make up present-day reality, and no less than bricklayers or bridge builders, we take justifiable pride in our accomplishments.

This all programmers share, from the most enthusiastic newbie to the apparently jaded elder, whether working at the lightest weight Internet startup or the most staid, long-entrenched enterprise. We want to do our best work. We want our work to have meaning. We want to have fun along the way.

Sandi Metz

Building a Kickass Portfolio

Thu, 02 Aug 2018 00:00:00 GMT

According to GitHub, I have had a portfolio site since September 1st, 2016. And, according to Google Analytics, I got less than 300 views on the two iterations of my portfolio from September of 2016 through October of 2017. In October 2017, I did a complete rewrite of my site, and the results were pretty dramatic. I got 1,861 views the first month, and I've averaged around a thousand hits on a month since then. Of course, correlation is not causation, but I do think the redesign definitely had a positive impact. It's not exactly Facebook, but for a portfolio site that doesn't provide the viewer with anything but information about me, I think these numbers are pretty okay!

In this post, I am going to go through an in-depth look at what has worked for me, what hasn't, my tips for building an awesome portfolio, and other people's portfolios that I love.

What Didn't Work

Before I get to my current portfolio that I really love, I want to talk about my first two sites.

My First Portfolio

The first one was a Jekyll site which used SASS and Pug. I deployed it here for nostalgia's sake -- check out the projects -- they're all from college, and most are in C++!

This setup was unnecessarily complex for the actual content of the website. I used Jekyll, MaterializeCSS, SASS, and Pug for such a simple page -- I think the Gulp setup was longer than the actual CSS needed! I was just transitioning on to writing frontend code at any capacity, so this was really a learning opportunity for me to use SASS and Gulp. I had no need for Jekyll either -- I only had a few projects listed and only one page.

Also, there are a bunch of 404's showing up in the console for resources that were unfound. If I was a developer looking at the site, I would definitely be critical of that.

The screenshots for my projects are not great. They are all either of code or cropped in an un-optimal way.

The fonts are also too small, it is difficult to read the text. My social icons are not exactly the most prominent, which means that they probably didn't have too high of an engagement rate.

There were some things that I did well, though. I really like the highlighted words in the bio -- it draws the user to look at those keywords, even if they don't read the whole bio. I also appreciate that the site is responsive, so users could view the site on different sized screens. Currently, around 1/3 of my traffic comes from mobile sources, so its important to remember those users!

My Second Portfolio

The second iteration was an HTML and CSS site with moving polka dots in the background. You can check it out here. I will admit, that I still have a soft spot for this portfolio.

I really like the moving bubbles, and how they change with user interaction. I also enjoy the minimalism of the site. I think the quick bio on the homepage is effective and expressed my interests well.

Again, the fonts are somewhat small, and having to go to a new HTML page to view any information about me is probably not the best. Also, having my talks and my code projects on the same page leads to unbalance.

Overall, though you can see a lot of the themes of this portfolio in my current one.

What Worked

In October of last year, I started from scratch and built a portfolio that was a little bit out of the box. Your portfolio is one of the only sites that you will build that is a complete creative expression of yourself with no constraints. So, I went all in, interactivity, animations, you name it, it has it.

If you click anywhere on the homepage, a random shape appears. If you hover over the letters, they animate. If you hover over my picture on the bio page, it spins.

I used Vue for this portfolio, so it seamlessly transitions from page to page. I also increased the font sizes, so readers could gather information more quickly and easily. My contact page offers large buttons to follow me elsewhere on the internet.

The original version of this design was built in HTML, CSS, and a very few lines of JavaScript. As far as my technology needs go, this was totally fine. I wanted to move to Vue for my own maintainability needs -- the reconfigured setup makes adding new projects a lot easier. I also like the smooth routing that Vue Router offers, instead of navigating to an actual new page.

This design grabs people's attention, and they stay on the site in order to interact with it. Also, people reach out to me about my site a bunch, which, if I was looking for a job, would be awesome!

What I could still do better

As far as effectiveness for converting people to my other social media, I could have links to my sites on each page rather than just the contact page. I also probably need to cull through my projects and choose a few to feature, rather than have 26 personal projects listed! I also don't have screenshots of my projects -- this is intentional, but I could probably get more traffic to them if I put pictures on them. I didn't like the different color palettes that adding in screenshots of my program would create. Also, I don't have many projects that I find super impressive in themselves. For the most part, they are pretty small, and I create them to learn something. I could further optimize my site, but for now, I really like where its at.

My tips for building a kickass portfolio

Make a portfolio that is a true expression of yourself. Programming is in a lot of ways a creative field, so use your creativity!
Make the site interactive, so people want to stay on your site, and they remember it.
Buy a domain name -- I moved from aspittel.github.io to alispit.tel. I really like the play on my name, and you can get a lot of domains for pretty cheap. I use NameCheap, and it's totally worth the \$8.00 a year for the domain.
Make sure you don't have console errors -- a lot of technical employers look for this, so make sure that your site is bug-free!
Don't use a technology just for the sake of it. If you have a super minimalistic personal website, don't use a heavy-duty framework or library just for the sake of using it.
Make sure your website works on mobile phones, and I would encourage making it work for users that use a split-screen setup.
I would steer away from using a template found online -- to me, it's pretty apparent when these are used. I understand using them for people who aren't web developers, but if you are a web developer show off your skills!
Use it to market yourself -- if you want to show off specific skills to employers, make sure those skills are featured on your site. I want people to visit my blog, so I have it featured on my home page. I also want to do more speaking, so I have a whole page dedicated to my talks. I no longer want to write C++ code professionally, so I took those projects off of my site.
Make sure your links aren't broken. I have totally been guilty of this at certain points, but it doesn't look great, and then your viewers can't see that destination!
Update your portfolio -- I'm guilty of not doing this that often too, but I try at least every few months to add new projects and talks to my site.
Use a critical eye, and be intentional about the design. I use Sketch to draft my sites before moving to code.
Think about page speed -- I run lighthouse testing on all of my sites to make sure they are performant.

A few of my favorite portfolios

Timo Becker - You connect the dots and create different illustrations -- just play with it, it's awesome.
Ben Halpern - this site is so memorable and fun.
Julia Khusainova - This site is really minimalistic, but gets the point across.
Nik Papic - another simple but pretty one.
Robby Leonardi - a game resume!
Dinesh Pandiyan - the color change is a really cool feature, and I like the minimalist design.

My Terminal Setup: iTerm + Zsh

Tue, 31 Jul 2018 00:00:00 GMT

As a follow up to my post on my text editor setup, I wanted to write about the other key part of my development setup -- my terminal. Unlike my relatively new text editor setup, my terminal configuration has followed me around for years -- spanning over multiple jobs and even more computers. It's the first thing I get set up on when I get a new computer

The Terminal

I use iTerm2 for my Terminal emulator. It has some really cool features, like search, autocomplete, and paste history. That being said, the feature that makes it a complete must have for me is the split panes.

When I do web development work, I usually have panes open for my server session and for running other commands as necessary. When running many processes at a time, as was required at my old job, I would easily have 10 panes open at a time

You can use the shortcut cmd + d for a new pane horizontally, and cmd + shift + d for a new vertical pane.

I do have some tweaks to the color palette that I use -- I think the biggest is that my default font is pink (the forefront color).

Other than that, most of the "magic" comes from my shell, Zsh!

The Shell

For my shell, the programming language the command line uses, I use Zsh instead of Bash.

There are some pros and cons of using Zsh, the biggest drawback I've found is some difficulty installing certain software. This was a big learning curve at first, but over time I've gotten used to common stumbling blocks and don't have as many problems. Taking this into account, I would only recommend Zsh for experienced shell users!

That being said, the pros for me far outweigh the cons. The tab completion is much better in Zsh as compared to Bash. It even has tab completion for Git!

Oh My Zsh is a framework for managing your Zsh configuration, and it is a must download. When I refer to Zsh, a lot of the features are actually a part of Oh My Zsh.

My .zshrc

Instead of a .bash_profile, Zsh primarily uses a .zshrc file where your customizations are saved. By default, there are a bunch of comments explaining different settings in that file. I am going to go through some of my settings below.

Zsh has awesome themes, which change the appearance of your prompt.

I use Spaceship which displays a bunch of excellent information. For example, in the directory for my blog, which is a node app, my git branch, the git status, the package version, and the current Node version display. Also, it shows the amount of time the previous command took to run and the computer battery percentage if it is low! This changes slightly from directory to directory, but its really nice to have this information so accessible, especially compared to how difficult it can be to create something similar in a Bash environment.

I am always switching on and off the auto-correct built into Zsh. Right now I have it turned on, but it does sometimes annoy me.

ENABLE_CORRECTION="true"

Another excellent Zsh feature is plugins. These make Zsh have better autocomplete for different languages or add additional features to the shell. I especially recommend the git plugin -- it's what gives you tab completion for git! I also really like zsh-syntax-highlighting. It highlights valid commands green and invalid ones red, so you don't even have to test the command to see if it will work!

plugins=(git node bundler osx rake ruby python javascript bash zsh-syntax-highlighting)

After that, I have boring PATH and git configuration, so I'm going to leave that out.

Finally, we get to my aliases and custom functions. My guilty pleasure function that isn't great practice is entitled "acp". "acp" adds, commits, and pushes my code, and it looks like this:

function acp() {
  git add .
  git commit -m "$1"
  git push
}

I use it way too much, but it really speeds things up when I'm working on personal projects.

I have two custom aliases setup:

alias groups="python ~/wdi/groupr/groupr.py"
alias zen="gatsby build && surge public/ zen-of-programming.com"

The first creates random groups of my students for in-class activities and projects. Zen deploys my personal site. Yes, I only have two custom aliases; however, that is just because so many are built into Oh My Zsh!

Some built-in ones I rely on especially hard are "..." which is an alias for "cd ../..". You can keep adding periods and keep moving back in directories. You can also omit "cd" and just type the file name to change from one directory to another -- "blog" is equivalent to "cd blog." There are also other aliases built in to do almost anything you could dream of with git. I also enjoy please=sudo, even though I don't personally use it!

Another bonus utility I have on my computer is tree (which you can install on a Mac with brew install tree). This lists the folders and files in a directory in a really nice way.

Public Speaking as a Developer

Wed, 25 Jul 2018 00:00:00 GMT

As a follow up to my post from March on blogging as a developer, I wanted to give my tips for doing public speaking events as a developer. A little over a year ago, I submitted my first call for papers (aka conference application) to the Code(Her) conference in DC where I live. It was accepted, and I gave my first conference talk last August. Around the same time, I moved from a traditional software engineering job to teaching at General Assembly's bootcamp. From that point on, I've given over 20 talks at conferences and meetups over the past year. All that being said, I wanted to give my tips -- from the application process through giving the actual talk.

Why Speak?

These reasons are going to look really similar to my reasons for blogging!

Reinforce your knowledge on topics. The best way to really learn something in depth is to teach it to somebody else!
Demonstrate your knowledge. You can show to the world that you really know a topic inside and out!
Build a community and meet other people who have similar interests to your own.
Challenge yourself and keep yourself accountable.
Help people who are learning the topic you are speaking about!

In addition, most conferences give speakers free admission or even travel assistance, which makes going to conferences a lot easier financially.

Picking a Topic

The first thing that you have to do in order to give a talk is to think through what you want to give that talk about. I would pick something that you can tell a good story about, that you are passionate about, and that you feel comfortable talking about for an hour or so. You do not need to be an expert in the topic, in fact talking about your learning process or hearing about something from a newbie's perspective can sometimes lead to the best talks. Also, your talk doesn't need to be crazy technical -- some of my favorite talks barely even talk about code! I usually convert my blog posts into talks because I am already part of the way there!

Some of the talks that I have given are:

Learning CSS Through Creating Art
Web Ready Augmented Reality
Web Development for Data Scientists
Intro to Web Frameworks
Building a Progressive Web Application with Gatsby
Web-Ready Data Visualizations in Python with Bokeh
Programming 001
Building Art with Code
Teaching Code

I tend to lean towards giving workshops and more code-heavy talks since I teach code full time, so that feels the most natural for me.

The Call for Papers Process

The first step in giving most talks is the call for papers process, where you apply to give your talk. Different conferences have different requirements for the CFP, but normally there are two main parts: a short abstract that summarizes your talk that the conference will use to market it if it is accepted. Then, there is a longer description of your talk where you can provide an outline of what you will talk about and why.

Be succinct and catchy in your abstract -- think of this as your sales pitch and your summary for your talk. These normally have a character limit, so you really have to think about each word and pitch your talk as well as possible here!

My 300 character limited abstract for my "Web Ready Augmented Reality" talk is as follows:

Augmented reality is becoming more popular for both its artistic and business applications. This talk will explore the frameworks and tools that make AR more developer friendly, including adding live masks to a webcam image in 47 lines of JavaScript!

There are a lot of directions that you can take your full description in; however, the formula I normally go with is as follows:

The Learning Objectives for the Talk. I normally give three to four bullet points on what I want attendees to learn during my talks.
A description of the talk and the technologies used in it. I write a few paragraphs about why I want to give the talk, the context for it, why it will fit in well at the conference, and the "stack" used in the talk if relevant.
An agenda for the talk. I give a rough breakdown of what the time breakdown will be for the talk. Ex. 5-minute intro, 10 minutes of demos, 10 minutes live code, 15 minutes Q&A etc.
What attendees will leave with. I try to think about why people should come to my talk, and what they will get from my talk. I love giving workshops, so in that case, the answer is normally demos and their own mini-projects. For shorter talks, this can be a renewed enthusiasm for a technology or a new knowledge about a library.
Links to existing materials. Again, I normally base my talks on my blog posts, so I will attach those. If I've given the talk before, I will also attach the slides that I used.

Here and here are where I keep my CFPs if you want to read through them! The second one is a really cool co-talk with my friend that I would love to give this fall if anyone is looking for speakers!

Finding Events

The next step is to find a conference you want to talk at. There are a couple resources that I use to find these. The first is PaperCall which lists open CFPs that you can submit to via their site. I also follow Mozilla Tech CFPs and CallbackWomen on Twitter to hear about local events. There are websites that I see from time to time listing upcoming conferencesFinally, I am a member of the Slack groups for my local tech community and see a lot of CFPs and people asking for meetup speakers there.

Once you submit to conferences, don't feel discouraged if you don't get accepted to everyone! Different conferences are looking for different things, and they have different audiences. In addition, there may be other people submitting similar proposals, so they can only pick one talk on a topic! I have gotten a lot of rejections and a lot of acceptances! I will also say in my experience it is harder to get beginner centric talks accepted because there are usually fewer new developers at tech conferences! You can submit more than one talk to a conference too, which I also normally do!

It won't happen again until February, but I attended Global Diversity CFP day this year, which was awesome! Put it on your calendar!

Developing your Talk

Now comes the hard part -- developing and practicing your talk. Each talk will take different steps to develop depending on the content, of course! I tend to start out with a markdown document and just outline my thoughts. I do the research that I need to do on technical topics -- I read articles, watch other conference talks, look through my own code and other people's. I put all the helpful links in one place so that I can come back to them afterward, and I write down any notes that I have as well.

Then, I add some structure to the talk -- I start to develop a timeline of what I want to talk about and when.

Usually, the best talks tell some sort of story and give a lesson to your audience. I love this talk by Saron Yitbarek about how to structure your tech talk.

After that, I write my slides. I have custom CSS for impress.js that I use for each presentation. I have a few web components I also use to make the slides act the way that I want them to. Getting it set up initially is kind of tough, but I personally think its worth it in the long run to have a setup that I really like.

I tend to use few words on my slides, and I like using a lot of images on them as well. Many people are visual learners, so having diagrams can really make concepts more clear. I link to the finished version of any code demos that I plan to use during the talk. I also usually have a lot of links to more resources so that

I tend to put my Twitter handle on the first slide so that people can tag me in things as I go, some people even put their handle on every slide! I also have all my links on the last slide so that people can get in touch with me if they want after.

I recommend practicing a lot -- you will probably be less nervous day of if you are prepared, and the timings and transitions will be smoother. If you are doing live coding, make sure you know the code in and out!

Make sure you pay attention to the length of your talk! Some conferences do 30-minute slots, others 45, some even hour and fifteen-minute slots! Check ahead of time to make sure that your talk has the appropriate amount of content for the time slot that you have.

The Day of your Talk

So, I'm not going to sugar coat this, you will almost definitely be nervous on the day of your talk, especially right before. It happens! I still get nervous and I do this all the time! My biggest tip here is to listen to peppy music that you really like right before you speak-- I listen to Britney Spears and Beyonce before every talk and love it. I wear clothes that I'm comfortable in, that usually make a statement -- that's just another thing that makes me feel more confident in front of a crowd.

Another tip is to pretend to be as confident and peppy as possible, even if you don't feel that way -- people usually can't tell the difference. Finally, I usually go over my slides a few times the day of the talk so that I really remember everything that I'm supposed to say.

Your talk is a performance -- you are in stage or in front of a room of people, so being engaging is important. I talk with my hands, sound super excited, and always talk about how much I love writing code. It makes my audience more excited as well, and they keep paying attention to my talk. In the same vein, you want to be understandable, so speak clearly, project, and don't rush.

I make my slides available to the audience before all of my talks so they can follow along. I will use BigTextBox on the projector to show the link to the slides, and I will put the link in the conference Slack group and with the conference hashtag on Twitter. I send them out ahead of time so that people can follow along on their own computers if they want -- they can read the text more easily, play with demos, and see my code samples. I also keep the links to my slides up after so people can come back to the resources I have linked.

Some piece of technology will almost definitely fail during the conference, so be prepared. You may barely have internet, your microphone may misfire, a demo may break, or your projector may be awful. It happens! Don't worry too much about it, it happens and people understand! Earlier this year, I ended up projecting some of my demos over my phone because the internet wasn't working at the conference center! I would also recommend bringing your own adapters just in case the conference staff doesn't have the one for your laptop on hand. I personally don't use clickers to move from slide to slide, I just use my keyboard, but a lot of people really like them!

If you want to watch one of my talks, I did my CSS art talk for dev.to a few weeks ago which was super fun!

Take advantage of the opportunity -- conferences are great places to meet new people and learn new things. Do your best, but don't worry about perfection!

Extreme Makeover: Code Edition

Mon, 23 Jul 2018 00:00:00 GMT

I am a little bit obsessed with writing clean code. Code should be written for future developers (including yourself) and extendability -- it should be relatively easy to add features to your application and to maintain your code. If we were writing code for computers, we would just write binary! Here are some of my tips for writing cleaner code:

1. Use clear variable and function names

Code becomes much easier to read if you write out full, descriptive variable and function names. The below code isn't very clear:

function avg(a) {
  let s = a.reduce((x, y) => x + y)
  return s / a.length
}

It becomes a lot more readable if we write out full variable names!

function averageArray(array) {
  let sum = array.reduce((number, currentSum) => number + currentSum)
  return sum / array.length
}

Don't minify your own code, use full variable names that the next developer can understand.

2. Write short functions that only do one thing

Functions are more understandable, readable, and maintainable if they do one thing only. If we have a bug when we write short functions, it is usually easier to find the source of that bug. Also, our code will be more reusable. For example, our above function could be renamed "sumAndAverageArray" because we are calculating the sum using reduce and then calculating the average of that sum.

function sumAndAverageArray(array) {
  let sum = array.reduce((number, currentSum) => number + currentSum)
  return sum / array.length
}

We can break this into two functions, and it becomes more clear what each part of the code is doing. Also, if we are creating a large program, having the sumArray function could come in handy!

function sumArray(array) {
  return array.reduce((number, currentSum) => number + currentSum)
}

function averageArray(array) {
  return sumArray(array) / array.length
}

If you are writing a function that could be named with an "and" in it -- it really should be two functions.

To summarize my tips for functions...

3. Documentation

Write good documentation for your code so that future developers understand what your code is doing and why.

The following code has "magic numbers" in it that aren't documented.

function areaOfCircle(radius) {
  return 3.14 * radius ** 2
}

We could add comments to the above code to make it more understandable for someone who doesn't know the mathematical equation for finding the area of a circle.

const PI = 3.14 // PI rounded to two decimal places

function areaOfCircle(radius) {
  // Implements the mathematical equation for the area of a circle:
  // Pi times the radius of the circle squared.
  return PI * radius ** 2
}

Note: the above code is just an example! You would probably want to use Math.PI instead of creating your own PI estimation.

Your comments should describe the "why" of your code.

Bonus: using a documentation style for your code. For Python, I love Google Style Docstrings, and JSDoc is great for JavaScript.

4. Sandi Metz's Rules

Sandi Metz -- an awesome Ruby developer, speaker, and author -- has four rules for writing clean code in object oriented languages.

Classes can be no longer than 100 lines of code
Methods and functions can be no longer than 5 lines of code
Pass no more than 4 parameters into a method
Controllers can instantiate only one object

I highly recommend watching her full talk on these rules!

I've been following these consistently for the past two years or so, and they become so ingrained that I barely think about them! I really like them, and I think they make code more maintainable.

These rules are only guidelines, but they can significantly clean up your code.

To Summarize the Sandi Metz rules...

5. Be Consistent

When writing code, consistency is key. People shouldn't be able to look at a code base and tell exactly who wrote each line of code without a git blame! If you are using semicolons in JavaScript, use them at the end of each statement. Use " vs ' consistently as well!

I would recommend using a style guide and a linter to enforce these standards -- for example, I love Standard JS for JavaScript and PEP8 for Python! I even have my text editor setup to enforce these standards whenever I save!

Find a code style and stick to it.

6. Keep your code DRY

One of the first things taught to new programmers is "don't repeat yourself". If you notice patterns in your code, use code to reduce those duplications. I often encourage my students to play the game SET to work on their pattern recognition skills.

That being said, if you DRY up your code too much or choose the wrong patterns to abstract, your code can be close to unreadable and you may need to duplicate your code more down the road. Sandi Metz has a great article on how "duplication is far cheaper than the wrong abstraction."

Don't repeat yourself, but also don't abstract your code to an extent that it is not understandable.

7. Encapsulation + Modularization

Group like variables and functions in order to make your code more reusable and understandable.

let name = "Ali"
let age = 24
let job = "Software Engineer"

let getBio = (name, age, job) => `${name} is a ${age} year-old ${job}`

If you have multiple people in your program, something like the following is more clear:

class Person {
  constructor(name, age, job) {
    this.name = name
    this.age = age
    this.job = job
  }

  getBio() {
    return `${this.name} is a ${this.age} year-old ${this.job}`
  }
}

or if you have only one person in your script:

const ali = {
  name: "Ali",
  age: 24,
  job: "Software Engineer",
  getBio: function() {
    return `${this.name} is a ${this.age} year-old ${this.job}`
  },
}

In a similar vein, break long programs into different files so that your code is more modular and digestible. Long files are often hard to sift through, and you may want to use small chunks of code from project to project.

Group like items in your code so that it is more reusable.

In short...

These are some good guidelines for cleaning up your code, but they aren't written in stone! I personally don't use all of these all the time (see my personal projects!), and no code is perfect. These are just some tips for writing code that can be more easily reused, read by other developers, and extended.

What is a Web Framework, and Why Should I use one?

Wed, 18 Jul 2018 00:00:00 GMT

"Framework" is a word used a lot in relation to code. So, what even is a framework? When we talk about frameworks, those frameworks normally fall into three different categories -- frontend, backend, and CSS or user interface frameworks. But even once you know what frameworks are, which one should you learn or use and why? This post will discuss what a framework is, what frameworks are out there, and how to make decisions about what kind of framework you should use for your projects!

What are Frameworks

If we look at a couple different web applications we can see that there are a lot of duplicated features. Many have user authentication, pages that render, they connect to databases, they have profiles you can look at, they all have stylized feeds of information etc. If I wanted to, I could write all of that logic myself every time I want to build a new application; however, there are also a lot of tools available which can do that for us instead.

In addition, a lot of the time when we build applications we want to format our code in certain ways that help us become more efficient and help other developers understand our code. Web frameworks help us achieve structure in our applications, and they give us additional features we can add to them without too much extra work. Frameworks give us a place to start so that we can focus on features rather than configuration details.

Code is read many more times than it is written, and it is so important when you are working with other developers that they know where the code for certain tasks is being written so they can use it in their own code. The frameworks also have conventions for how the code is written and structured, which standardize how the developers write their code.

Most websites share a very similar (not to say identical) structure. The aim of frameworks is to provide a common structure so that developers don’t have to redo it from scratch and can reuse the code provided. In this way, frameworks allow us to cut out much of the work and save a lot of time.

To summarize: there’s no need to reinvent the wheel.

from Awwwards.

Under the hood, frameworks are just code libraries (i.e. other people's code), and the popular ones are open source! So you can look at your library's code online!

Backend vs Frontend

The frontend of a web application is the part you see and interact with. It consists of the web design and the interaction of the site. In terms of programming languages, this is almost always comprised of the CSS, HTML, and JavaScript of the page.
The backend consists of the server, the database, and the code that interacts with them. This also consists of the code that gives dynamic data to the frontend of the site. This can be handled in most programming languages. The ones we will discuss primarily today are Python, Ruby, and Node JavaScript but there are countless others.

Want more advice on learning to code?

Download my free Ebook!

User Interface Frameworks

User interface frameworks help create stylized and professional looking web applications. Most include some sort of grid system so that you align elements, they have color schemes so that is handled for you, and they stylize your HTML components using CSS so that they look clean and professional. These are within the frontend domain; however, normally when we refer to frontend frameworks we are talking about JavaScript frameworks.

Some user interface frameworks include:

Bootstrap
- Very well known and built by Twitter
- Easy to learn and looks professional
- Can be easy to spot "Bootstrap Sites"
- Can be difficult to customize components
Materialize
- Clean looking
- A bit more "fun" than Bootstrap
- Lots of styling and color options
- Follows Google's Material style guide
Foundation
- Lots of examples
- Professional looking
Semantic UI
- Lots built-in
- Built-in themes so it's customizable
Grommet
- Has a huge focus on accessibility
- Looks really clean
- Not as used as some of the others
- Made for React JS (another framework we will look at later)

Choosing a UI Framework

Choosing a User Interface framework mostly comes down to personal preference in appearance and the goals of the site. The different styles may appeal to different industries or may convey a different message to users.

Frontend Frameworks

Frontend frameworks are, in most cases, written in JavaScript and are for organizing the functionality, interactivity of your website. Some of these include:

Vue
- Easy to learn
- Very fast
- All tools associated with it are packaged well
- Takes parts from Angular and React and optimizes them
- less widely adopted than some others
- Flexible -- you can use it in multiple ways
AngularJS
- Built by Google
- Well supported
- Huge number of features
- Improves application scalability
- Difficult to debug
- Large learning curve
Angular 2+
- Built by Google
- Well supported
- Encourages reusability
- Improves application scalability
- Large learning curve
React
- Built by Facebook
- Bundles frontend code into components
- Organizes code and data to make code more reusable
- Large learning curve
Ember
- Gives a large amount of functionality out of the box
- Opinionated (you have to use its formatting)
- Steep learning curve

Choosing a Frontend Frameworks

The world of frontend frameworks is evolving especially fast, it seems like a new frontend framework is on the rise every few months. Learn what makes sense to you, and don't worry too much about what the "hottest" one at the moment is.

Some people argue that React and Vue are libraries instead of frameworks, but a lot of people consider them frameworks, so I included them!

Backend Frameworks

Backend frameworks are a lot more varied. They are written in a variety of programming languages and have a wide variety of features. Below, like the above list, is a very incomplete list of some of the frameworks out there for writing application backends.

Spring MVC
- Java (more difficult language to learn)
- Very fast
- Less opinionated
Django
- Python (easier language to learn)
- Happy medium between being very opinionated and less structured
- Gives you a lot of functionality out of the box (like user authentication, database connections, and view rendering)
- Can be difficult to integrate a fancy front-end.
- Python's data handling is amazing
Flask
- Python (easier language to learn)
- Less opinionated and more customizable than Django
- Gives you less out of the box (you have to build more)
Ruby on Rails
- Ruby (easier language to learn)
- Very opinionated
- Has great tools like scaffolding so you can build things fast
- Gives you a lot of functionality out of the box (like user authentication, database connections, and view rendering)
- The asset pipeline helps with front-end development
- Ruby takes longer to run programs than some other programming languages
Meteor
- JavaScript (easier language to learn)
- Gives you a lot of functionality out of the box (like user authentication, database connections, and view rendering)
- Integrates very well with modern front-ends
Express
- JavaScript (easier language to learn)
- Very customizable
- Very lightweight
- Less built-in features
- Node is very fast

Choosing a Backend Framework

Usually, you choose a backend framework based on the programming language it is written in. Also, take into account what features you want to add -- if you want authentication (or user login) for your website, for example, writing it in Django where authentication is built in will be a lot easier than writing it in Flask where you would need an additional service.

Learn More

If you want to use or learn a framework, here are a bunch of applications built with different ones, so you can evaluate which one makes the most sense to you. There are a lot more frameworks out there of various sizes and popularities, but this article gives a brief overview of some of the popular ones out there and where to get started. There is no right answer on what to learn first! There are pros and cons to everything, so weigh what is most important to you and go from there. Frameworks are super helpful and make writing code a lot quicker in most cases, but having a strong programming foundation before that is also super important -- so make sure you know the language your framework is written in well first. Frameworks are super helpful for writing websites because they enforce a structure that other developers in the framework understand, and they give you common functionality so you don't have to reinvent the wheel!

Where to start learning...

Django Girls Tutorial - I learned my first framework through their online tutorial!
Code Academy
TodoMVC
CodeNewbie Podcast

And if you need an idea for an application...

My Visual Studio Code Setup

Tue, 17 Jul 2018 00:00:00 GMT

I love the text editor setup I've been using for the past year and a half, so I want to show off my setup! Visual Studio Code has far surpassed my experiences with Atom, Spyder, Sublime Text, Emacs, and Idle (the built-in Python editor) which I used for the years before it. I thought I would do a quick write up on my setup and the extensions I love!

Theme

Since I teach people how to code professionally and give a lot of talks on programming, having a readable theme is super important to me. I also love to have a theme that I enjoy aesthetically, so usually something with a lot of girly colors.

Those criteria being set, my two absolute favorite themes are Fairy Floss and Dracula.

Fairy Floss

Dracula

Font

I am a long-term FiraCode loyalist (pre-dating VS Code!); I like the ligatures that make my code more readable at a glance. It's pretty easy to set up too, which is really nice!

Save Configuration

Another key piece of my setup is my save configuration. The first thing that I love is autosave, which you can turn on via the file drop-down. I have it further configured so that whenever I pause when writing code, my code is saved automatically without me doing anything. I cannot explain how helpful this is for live coding and for beginners.

// in settings.json
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 100,

In the same vein, I have Prettier set up to format my code on cmd + s. Ideally, this would run automatically as well, but it is close enough for now. I used StandardJS to do the same for a while, before moving over to a pro-semi-colon client.

// in settings.json
"editor.formatOnSave": true,

I use two spaces for most language indentation, the only exception is Python, where I use four spaces by default.

// in settings.json
"[python]": {
    "editor.insertSpaces": true,
    "editor.tabSize": 4
},

Emmet

I am incredibly reliant on Emmet, so I love that it is built in for VS Code. I also have it set up to work in more than just my html files:

// in settings.json
"emmet.includeLanguages": {
  "html": "html",
  "erb": "erb",
  "javascript": "javascriptreact",
  "vue": "html",
  "ejs": "html"
},

Integrated Terminal

I will write a longer post on my terminal set up at some point, but I use ITerm with ZShell on my Mac, and so I have VS Code's integrated terminal set up to use that setup.

// in settings.json
"terminal.external.osxExec": "iTerm.app",
"terminal.integrated.shell.osx": "zsh",

Extensions

I have a lot of language and framework-specific extensions built-in, which are boring and very dependent on the developer, so I will skip over those in order to discuss some of my favorite all-purpose extensions.

VS Live Share - this extension is straight up magical, and I truly believe it will change code education and pair programming in the near future. It allows developers to Google Doc-style collaborate on the same file on different computers. You can even open up access to your localhost ports across machines and share terminal sessions. There are some bugs, especially on Windows machines, but it's so cool that it doesn't even matter!
Code Spell Checker - I write a lot of Markdown and page content directly in my text editor, and I definitely have some spelling issues. I love this extension for underlining my mistakes and offering suggestions, even when I'm offline.
Import Cost - this one is more a "nice to have" rather than a necessary, but it shows the size of the npm packages I am importing in my projects.
HTMLHint - I use this for live HTML validation directly in my editor. No more having to run the W3C validator on every change!
GitLens - GitLens shows Git blame annotations and author highlighting within documents. Its really helpful for working on multi-author projects!
CodeRunner - this extension allows you to press a play button to run your code directly within VSCode with no terminal interaction needed! Especially helpful for new programmers.
EmojiSense - I love Slack's emoji-autofill post : feature, and this extension allows you to do the same in VSCode!