Forem: Cory Dorfner

Displaying Markdown Posts On Your Gatsby Site

Cory Dorfner — Tue, 27 Dec 2022 19:40:40 +0000

Hello and welcome to the sixth post in my series on Building a Powerful Blog!🎉 If you haven't already, I would recommend going back to the first post of the series, Creating a Gatsby Blog Site, and reading through the rest of the series before continuing. By now, we've learned everything from creating your very own Gatsby site and deploying it on Netlify, all the way to creating content in Markdown files and pulling that information into your site.

Now it's time to finally get to work on the user interface of your site and learn how to display the content from your posts using your "blog-post.js" file in the templates directory. With a little bit of React components and Bootstrap, we'll transform the raw data returned from your GraphQL data layer into a beautiful UI for your readers. I hope you're as excited as I am!🥳

Displaying Your Pages

For displaying the content of your blog posts onto the page created from your "blog-post.js" template file, we'll update the return statement from the BlogPost function with a few elements and functions from react-bootstrap and gatsby-plugin-image. We've already installed gatsby-plugin-image during the creation of our site so this just leaves the installation of react-bootstrap and it's dependency, bootstrap. To get started, we need to go back to our terminal and run the below command to install the needed packages into our code base:

npm i react-bootstrap bootstrap

Bootstrap is a powerful and extensible front-end toolkit packed full of features and components to help you develop the UI of your site faster than before. There are several frontend toolkits out there that you can use in place of Bootstrap so feel free to utilize whichever you're most comfortable with. For the purposes of this tutorial though, I'll be using Bootstrap v5.2.

Once the package has been installed, we'll need to specifically import the minified CSS of Bootstrap in a new file titled gatsby-browser.js. This file is where Gatsby expects to find any usage of the Gatsby Browser APIs, and also allows for the customization and extension of default Gatsby settings affecting your browser, such as the CSS. Go ahead and create this file in the root of your directory, and add the following line of code before saving the file and restarting your server:

import "bootstrap/dist/css/bootstrap.min.css"

With the server up and running again, navigate to your "blog-post.js" page in the templates folder and import the necessary packages at the end of your current import list. We'll only be importing the methods and components we need. As you continue forward with the updating of this file, I'll explain what each of these imports are for. With these changes, your import section should now include the following:

import React from "react"
import PropTypes from "prop-types"
import { graphql } from "gatsby"
import { Container, Row, Col } from "react-bootstrap"
import { GatsbyImage, getImage } from "gatsby-plugin-image";

From here, let's work on updating the BlogPost function and displaying the content from your blog post. To get started, remove the console.log(post), as well as the h1 element from your return statement. In it's place, add the following code:

<Container fluid className="min-vh-100 text-bg-dark">
    <Row className="justify-content-center">
        <Col md={6}>
            <h1 className="text-center">
                {post.frontmatter.title}
            </h1>
        </Col>
    </Row>
</Container>

The <Container> element will help contain, pad, and align your content within a given device or viewport. The attributes selected will make the container span the entire width and height of your viewport, as well as add a dark background and modify the text color to white.

The <Row> element will act as a wrapper for our column with the selected attribute centering the children columns. You can add up to 12 <Col> elements per row, allowing you to create different combinations of elements that span any number of columns. You can indicate the number of columns to span using attributes on the element. Adding md={6}, as we did, will specify it to span only 6 column templates of the row.

Finally, we have the <h1> element, which takes the title of your blog post from the frontmatter and center aligns it using the text-center class. Saving the file at this point, and returning to your browser, should display the following:

Next, we'll add in the banner image from your frontmatter to display above the header element of your web page. With the use of GatsbyImage and getImage from gatsby-image-plugin, we'll be able to fetch the image in multiple sizes and formats with only a few lines of code!

The Gatsby Image plugin is incredibly powerful, with many different features to help deliver the image exactly how you see fit. Gatsby's documentation on this plugin is very helpful, so I would recommend reading through it to better understand all that you can do with this plugin. We'll add our <GatsbyImage> element directly above our prior <h1> element:

<Col md={6}>
    {post.frontmatter.banner &&
        <GatsbyImage
            image={getImage(post.frontmatter.banner)}
            alt="Banner Image" />
    }
    <h1 className="text-center">
        {post.frontmatter.title}
    </h1>
</Col>

We first check to verify your frontmatter has a banner image stored in the data layer. If one is found, only then will it try to render an image component on your page. As your local dev site is built and cached the first time you run your server, you may need to clean your Gatsby build so that it can find this new image to display on your web page.

If you return to the browser, and the image only appears as the blurred placeholder, return to your terminal and stop the server with ctrl+c. Run npm run clean to remove the prior build files and then restart your server with npm run develop. After the server starts, refreshing your localhost web page should display a page similar to the following:

All that's left now is adding in the necessary code to display the rest of your blog post content onto the page. The below code snippet will display our dateCreated field, the dateEdited (if it does not equal dateCreated), our timeToRead field, as well as the remaining content of our blog post outside of the frontmatter:

<Row className="text-center">
    <Col xs={12}>
        <small>Created on {post.frontmatter.dateCreated}</small>
    </Col>
    {post.frontmatter.dateCreated !== post.frontmatter.dateEdited &&
        <Col xs={12}>
            <small><em>Updated on {post.frontmatter.dateEdited}</em></small>
        </Col>
    }
    <Col xs={12}>
        <small>{post.timeToRead} min read</small>
    </Col>
</Row>
<hr />
<div
    dangerouslySetInnerHTML={{ __html: post.html }}
/>

This code will be placed directly after the </h1> closing tag from the previous code block but before the </Col> closing tag. All of the text within the <Row> component will be centered within their parent element with the use of className="text-center". Also, each <Col> component has been set to the entire width of the parent element by setting xs={12}. The text here is being placed into a <small> HTML component to reduce the text size and allow for the title and body of the post to stand out. After the <Row> component, we add in a horizontal rule with the use of the <hr /> element to provide a clean line break between the metadata and the content of the post.

To add in our Markdown content, we use the dangerouslySetInnerHTML property of a <div> element. This lets React know that the HTML inside of this component is not something to care about, as it is content that you have created yourself. There's also performance gains to be had with this property as React will bypass checking the children of that node as it knows the HTML is coming from another source. With the use of this property, we can safely pass in our formatted HTML content and allow React to display it properly on the page, without any additional formatting needed in our code.

You must exercise caution when using this property though, particularly for anything that might allow for user input. Using this type of property on something like a comment field, without any sanitization of the data being passed into it, will allow for users of your site to enter in a script that can do anything from locking out a different users browser, installing cookies, or even wiping data from your data layer. As we're only passing in our own content to this <div> though, we can feel safe in using this property. If you would like to know more, you can find information about the dangerouslySetInnerHTML property on the ReactJs website, including a link to more information on cross-site scripting (XSS) attacks.

We have now finished setting up the basic structure and design of your blog post pages! Putting it all together from this and my previous articles, your code in "blog-post.js" should look similar to the following:

import React from "react"
import PropTypes from "prop-types"
import { graphql } from "gatsby"
import { Container, Row, Col } from "react-bootstrap"
import { GatsbyImage, getImage } from "gatsby-plugin-image";

const BlogPost = ({ data }) => {
  const { markdownRemark: post } = data
  
  return (
    <Container fluid className="min-vh-100 text-bg-dark">
      <Row className="justify-content-center">
        <Col md={6}>
          {post.frontmatter.banner &&
            <GatsbyImage
              image={getImage(post.frontmatter.banner)}
              alt="Banner Image" />
          }
          <h1 className="text-center">{post.frontmatter.title}</h1>
          <Row className="text-center">
            <Col xs={12}>
              <small>Created on {post.frontmatter.dateCreated}</small>
            </Col>
            {post.frontmatter.dateCreated !== post.frontmatter.dateEdited &&
              <Col xs={12}>
                <small><em>Updated on {post.frontmatter.dateEdited}</em></small>
              </Col>
            }
            <Col xs={12}>
              <small>{post.timeToRead} min read</small>
            </Col>
          </Row>
          <hr />
          <div
            dangerouslySetInnerHTML={{ __html: post.html }}
          />
        </Col>
      </Row>
    </Container>
  )
}

BlogPost.propTypes = {
  data: PropTypes.shape({
    markdownRemark: PropTypes.shape({
      frontmatter: PropTypes.shape({
        dateCreated: PropTypes.string.isRequired,
        dateEdited: PropTypes.string.isRequired,
        path: PropTypes.string.isRequired,
        title: PropTypes.string.isRequired,
        description: PropTypes.string.isRequired,
        banner: PropTypes.object,
      }).isRequired,
      timeToRead: PropTypes.number.isRequired,
      html: PropTypes.string.isRequired,
    }).isRequired,
  }).isRequired,
}

export default BlogPost

export const pageQuery = graphql`
  query BlogPostByPath($path: String!) {
    markdownRemark(frontmatter: {path: {eq: $path}}) {
      frontmatter {
        dateCreated(formatString: "MMMM DD, YYYY")
        dateEdited(formatString: "MMMM DD, YYYY")
        path
        title
        description
        banner {
          childImageSharp {
            gatsbyImageData(
              layout: FULL_WIDTH,
              placeholder: BLURRED
            )
          }
        }
      }
      timeToRead
      html
    }
  }
`

From just the above block of code, you will now be able to view pages for each Markdown file you have saved within the "posts" folder of your codebase! Depending on the content of your own Markdown file, your page should now look something similar to the following:

Now that you have the "blog-post.js" file set up, any time you merge a PR into your main branch with an added or updated Markdown file in your "posts" folder, Netlify will kick off a new deployment to your production site. After the build is complete, you'll be able to navigate to your site in a browser and see the changes you made!

I hope you enjoyed this series on How to Build a Gatsby Blog! All that's left to do now is to add in your own personal flair to the design of the blog pages. This can be done by continuing to utilize the pre-built Bootstrap styles, or creating your own CSS file and importing those styles into "blog-post.js". Regardless of what you choose though, I have confidence that it will look great, as it will be an extension of who you are as a person. Best of luck with the design of your blog page and I look forward to seeing the finished product! Please let me know about it in the comments below and I would be more than happy to take a look at it and see what you've come up with! The links to my social media accounts can be found on the contact page of my website. Please feel free to also share any of your own experiences on working with Gatsby, general questions and comments, or even other topics you would like me to write about. Thank you and I look forward to hearing from you!👋

Fetching Markdown Posts From Your Data Layer

Cory Dorfner — Tue, 15 Nov 2022 17:58:53 +0000

Hello and welcome to the fifth post in my series on Building a Powerful Blog!🎉 If you haven't already, I would recommend going back to the first post of the series, Creating a Gatsby Blog Site, and reading through the rest of the series before continuing. So far, you've created and deployed your Gatsby site with Netlify, as well as created your Markdown post and stored it in your data layer. You also have learned the power of Gatsby and GraphQL to create dynamic pages for each blog post file stored in your data layer. Let's now find out how we can utilize GraphQL even further to fetch the data from your Markdown posts.

Retrieving From Your GraphQL Data Layer

To pull in and populate your newly created blog pages with the content from your posts, we'll have to retrieve the data from your GraphQL data layer. There are two main ways we can accomplish this:

Fetch the data within "gatsby-node.js" and pass it to your pages using the context field
Fetch the data directly within the "blog-post.js" template file

Both of these files were created in the prior post, Creating Pages from Markdown with GraphQL and both options are a valid approach. I prefer to utilize the second option though as it helps encapsulate the blog post data within each individual page, and keeps your code clean and organized. So let's get started by firing up your server with npm run develop and navigating to http://localhost:8000/___graphql in your browser to open GraphiQL. Here, we're going to play around with the query a bit to identify what we would like to pull in as a starter for our template file.

Right away, I know we're going to want to pull in all of the data from the YAML frontmatter so we should expand the markdownRemark field and the blue frontmatter field within that. Remember, we want the blue field as that specifies the data to be retrieved. The purple fields specify what to filter your data on. From here, click each checkbox that's available. When clicking the checkbox for dateCreated and dateEdited, more will appear under those fields. Be sure to click the formatString checkbox for both and enter "MMMM DD, YYYY". This will format the date fields for you automatically so that you don't have to in your code. There are several format strings that can be entered so feel free to play around until the format appears to your liking.

Next, let's get your banner image in the query as well. From the frontmatter dropdown, click the banner dropdown, then the gatsbyImageData checkbox. This will again display some additional fields where we'll select layout and change its value to FULL_WIDTH, as well as placeholder and change its value to BLURRED. There are many options within the gatsbyImageData field, too many to go into detail here on. If you're interested in learning what each of them are for though, I would recommend reading the Gatsby Image API documentation to utilize it to it's full power.

With the frontmatter taken care of, we can navigate back to the markdownRemark dropdown and select the html and timeToRead fields near the bottom of the dropdown. If you happened to collapse a dropdown in the explorer, you'll notice that the applicable fields within that dropdown all get removed from your query as well. If this happens, just be sure to expand the dropdown again and all of your prior selections will reappear.

Before we can run this query, we need to add in the path it has to search for within your Markdown file. To do this, we'll add ($path: String!) immediately after MyQuery at the top of your query. This tells the query that it should expect a variable of type String and pass it through. We'll then add a filter to only return results where the path field equals the variable being passed through. This is accomplished by adding (frontmatter: {path: {eq: $path}}) immediately after the markdownRemark field of your query. Putting it all together, your query should look similar to the following:

query MyQuery($path: String!) {
  markdownRemark(frontmatter: {path: {eq: $path}}) {
    frontmatter {
      dateCreated(formatString: "MMMM DD, YYYY")
      dateEdited(formatString: "MMMM DD, YYYY")
      path
      title
      description
      banner {
        childImageSharp {
          gatsbyImageData(layout: FULL_WIDTH, placeholder: BLURRED)
        }
      }
    }
    timeToRead
    html
  }
}

To specify a variable for your query to use, we'll have to expand the Query Variables section of GraphiQL found at the bottom of the center panel. Click on this section and add { "path": "/my-first-blog-post" } to it.

Once you're ready, you can execute the query using the "play" button at the top of the center panel and view your response in the right panel. If any errors are returned, be sure to read through them fully to understand the issue. It may be that there's a typo in your variable, the formatString options you created for your date fields, or even with how your passing the variable into your query. The error messages from GraphiQL are pretty descriptive to help you debug the issue.

Now that you have a query returning the data you want for your blog post, we can go ahead and transfer that query into your "blog-post.js" file. Navigate to the file within the templates folder of your codebase and import GraphQL and PropTypes at the top of your file.

import PropTypes from "prop-types"
import { graphql } from "gatsby"

PropTypes will help you document the intended types of properties being passed to your function and warn you, in development, if they don't match. This will help you ensure you're always getting back the intended data and assist you in debugging if something goes wrong. There are many different validators within the PropTypes object but we'll only need to know a few, such as string and object.

If you're interested in reading more on the different types of validators, I would recommend checking out the prop-types npm package itself. For now, just know that we'll be adding validators onto the BlogPost object itself and modeling the GraphQL query based off what you created earlier. You'll add the following code snippet immediately before you export the BlogPost object.

BlogPost.propTypes = {
  data: PropTypes.shape({
    markdownRemark: PropTypes.shape({
      frontmatter: PropTypes.shape({
        dateCreated: PropTypes.string.isRequired,
        dateEdited: PropTypes.string.isRequired,
        path: PropTypes.string.isRequired,
        title: PropTypes.string.isRequired,
        description: PropTypes.string.isRequired,
        banner: PropTypes.object,
      }).isRequired,
      timeToRead: PropTypes.number.isRequired,
      html: PropTypes.string.isRequired,
    }).isRequired,
  }).isRequired,
}

export default BlogPost

Here you can see that we're specifying they types of each field, as well as whether they're required or not. Next, we can copy and paste your query into a pageQuery variable, which we'll export so that your BlogPost object can find it. This will get added immediately after you export the BlogPost object and will look similar to the following:

export default BlogPost

export const pageQuery = graphql`
  query BlogPostByPath($path: String!) {
    markdownRemark(frontmatter: {path: {eq: $path}}) {
      frontmatter {
        dateCreated(formatString: "MMMM DD, YYYY")
        dateEdited(formatString: "MMMM DD, YYYY")
        path
        title
        description
        banner {
          childImageSharp {
            gatsbyImageData(
              layout: FULL_WIDTH,
              placeholder: BLURRED
            )
          }
        }
      }
      timeToRead
      html
    }
  }
`

You'll notice that I modified the query name from MyQuery to BlogPostByPath. This is mainly done to ensure each query has a unique name and helps you keep things organized.

With your page now retrieving the necessary information from your data layer, let's go ahead and add it as a parameter to your BlogPost function by adding { data } to the parentheses of your arrow function. While we're at it, we'll also deconstruct this data object and assign the markdownRemark object to a variable with const { markdownRemark: post } = data. This will pull the data from that object and assign it to a variable named post to help with readability of your code. From here, we can quickly validate the data being returned from your query by logging the post object to the console. You're BlogPost function should look similar to the following:

const BlogPost = ({ data }) => {
  const { markdownRemark: post } = data
  console.log(post);

  return (
    <h1>Hello World!</h1>
  )
}

Returning to your blog post webpage and opening the console of your DevTools by clicking F12, you should be able to see an object has been logged. When you expand the object, it should look something like:

Looking deeper into the object, you can see the various fields that we'll be using to populate our blog post page with. That discussion will have to be left for another day though as this post is already getting pretty lengthy. In the meantime though, I would recommend reading more on the Gatsby Image API to better understand all that can be done to transform and deliver your beautiful images to your readers.

In the next post, we'll further develop the template file to utilize the content retrieved from your data layer. Afterwards, you'll have a clean and minimalistic design for your viewers to read your inspiring blog posts! I hope you enjoyed this post and found it's content helpful as you continue your journey through web development! The links to my social media accounts can be found on the contact page of my website. Please feel free to share any of your own experiences on working with the Gatsby Image API, general questions and comments, or even other topics you would like me to write about. Thank you and I look forward to hearing from you!👋

Creating Pages From Markdown With GraphQL

Cory Dorfner — Tue, 08 Nov 2022 18:17:03 +0000

Hello and welcome to the fourth post in my series on Building a Powerful Blog!🎉 So far, you've created your Gatsby site and deployed it for the world to see using Netlify. You've also learned about the power of Markdown for writing your own blog posts and have stored and retrieved it with GraphQL. If you haven't already, I would recommend going back to the first post of the series, Creating a Gatsby Blog Site, to get caught up before continuing. Now it's time to pull it all together and learn how to create reusable templates to display your blog post, and the many to come, on your own website. So what are we waiting for? Let's get started!👏

Creating Your Blog Post Pages

There are a few steps that will need to be taken to retrieve the content from your Markdown files. We'll first start by creating a template file so that the server has something to build your blog page off of. We'll then move on to creating a file in the root of your directory, which will run during the process of building your site. This file will create the separate URLs that you can navigate to from your site for each Markdown file. Then, we'll update the template file to display some of the content from your blog post in a nicely formatted view.

To get this started, go to the "src" folder of your codebase and create a folder titled "templates". Within this new folder, created a file titled "blog-post.js" so that your directory looks similar to the following:

+-- src
|   +-- pages
|   +-- posts
|   +-- templates
|   |   +-- blog-post.js
+-- gatsby-config.js

Within the newly created "blog-post.js" file, we're going to import React, create a quick function to return an h1 element, and export that function for use during the Gatsby build process. The code is as follows:

import React from "react"

const BlogPost = () => {
  return (
    <h1>Hello World!</h1>
  )
}

export default BlogPost

If you started up your local server right now and tried to view this page, you would be unable to do so. The reason being that Gatsby doesn't yet know how to handle this file! For this, we will need to create another file titled "gatsby-node.js" in the root of your directory. This file will implement the createPages API from Gatsby Node APIs and create dynamic blog pages for you. Let's first fetch your blog post data from the GraphQL data layer:

exports.createPages = async ({ actions, graphql, reporter }) => {
  const result = await graphql(`
    {
      allMarkdownRemark {
        edges {
          node {
            frontmatter {
              path
            }
          }
        }
      }
    }
  `)
}

Here, we're using a similar query to the one you've seen in the last section of this post. We've removed the sort and limit fields though as they're currently not needed. This query will return all Markdown files that you have set the gatsby-source-filesystem plugin to point to in your "gatsby-config.js" file. This looks good right now, but what if there was an error when trying to run the query? That's where the following code comes into play:

exports.createPages = async ({ actions, graphql, reporter }) => {
  ...

  if (result.errors) {
    reporter.panicOnBuild(`Error while running GraphQL query.`)
    return
  }
}

With these few lines of code, you're able to report out that there was an error while running the query, and exit out of the createPages function so that you're entire site doesn't crash. In all my time of working with Gatsby, I've never seen this issue occur. Nevertheless though, it's good to have just in case. Now that we have the result from your data layer, how to we tell Gatsby to create the necessary pages using your template file? Look no further than the below snippet of code:

const path = require("path")

exports.createPages = async ({ actions, graphql, reporter }) => {
  const { createPage } = actions
  ...

  result.data.allMarkdownRemark.edges.forEach(({ node }) => {
    createPage({
      path: node.frontmatter.path,
      component: path.resolve(`src/templates/blog-post.js`),
      context: {}
    })
  })
}

We need to require the Path module from Node.js to provide us with a way of working with directories and file paths. Be sure to require that at the start of the file. We'll also need to extract the createPage method from the actions object and assign it to a variable. This should be done immediately at the start of your arrow function. Finally, towards the end of the arrow function, we're utilizing a forEach loop to iterate over each edge, or "post", and call the createPage method. This method will be called with an object consisting of:

the path to use for the URL,
the component to build the page with,
and any additional context.

This additional context field is useful if there's extra data that needs to be provided to the component itself but, for now, we'll go ahead and leave it empty. Below is the full snippet of code for you to check your "gatsby-node.js" file against mine:

const path = require("path")

exports.createPages = async ({ actions, graphql, reporter }) => {
  const { createPage } = actions

  const result = await graphql(`
    {
      allMarkdownRemark {
        edges {
          node {
            frontmatter {
              path
            }
          }
        }
      }
    }
  `)

  if (result.errors) {
    reporter.panicOnBuild(`Error while running GraphQL query.`)
    return
  }

  result.data.allMarkdownRemark.edges.forEach(({ node }) => {
    createPage({
      path: node.frontmatter.path,
      component: path.resolve(`src/templates/blog-post.js`),
      context: {}
    })
  })
}

That's it! Our site will now create a page for every node, i.e. Markdown file, it finds within your filesystem. As long as those files have a path within their frontmatter, you'll be able to navigate to that page and see the h1 we added as a placeholder. Let's go ahead and give it a try by stopping your server with ctrl+c and restarting it with npm run develop. Once the server is running, go to your web browser and navigate to http://localhost:8000. You should see the landing page of the Gatsby site you originally built. From here, add on a forward slash to the URL, followed by whatever you entered in the path field of your YAML frontmatter. For me, that's going to look like http://localhost:8000/my-first-blog-post and the page should look like this:

What a rush! We now have a site with dynamically generated URLs for any blog posts you add to the "posts" folder. While we're only displaying a placeholder for your blog post, this is just the beginning of what we can do for your blog site! If you would like to learn more about the power of Gatsby Node APIs while we wait for the next post to be released, I would highly recommend reading through their reference documentation.

In the next post, we'll continue working in the template file to retrieve the rest of the content from your blog post. This will help keep your code clean and organized, while setting us up nicely to display to content on your web pages. I hope you enjoyed this post and found it's content helpful as you continue your journey through web development! The links to my social media accounts can be found on the contact page of my website. Please feel free to share any of your own experiences on working with the Gatsby Node APIs, general questions and comments, or even other topics you would like me to write about. Thank you and I look forward to hearing from you!👋

Adding Markdown Posts to your Data Layer

Cory Dorfner — Thu, 03 Nov 2022 17:45:41 +0000

Hello and welcome to the third post in my series on Building a Powerful Blog!🎉 So far, you've created your Gatsby site and deployed it for the world to see using Netlify. You've also learned about the power of Markdown for writing your blog posts and have created a blog post of your own. If you haven't already, I would recommend going back to the first post of the series, Creating a Gatsby Blog Site, to get caught up before continuing.

Now it's time to learn how to store your Markdown blog post, and the many to come, directly in your own codebase and add them to your GraphQL data layer in Gatsby. These steps will allow you to easily add and maintain your blog posts, while reducing code duplication and simplifying the process for pulling the content into your website. I hope you're as excited to get started as I am!🥳

Storing Your Blog Posts

Storing the content of your blog posts within your site is as quick and easy as adding in a folder and moving any content already created into specific folders for each post. That's it; that's all there is to it.

We'll start by locating the src folder in the root directory of your codebase. When you have find it, right-click on the folder and select the New Folder... option. Give this new folder the title of "posts". Next, we're going to create another folder within the newly created "posts" folder. These subfolders are needed in the case that you would also like to include images with your blog posts. While we could store these images elsewhere and simply reference them in the post, I've found this way to be cleaner for keeping everything organized. With this new folder, you can title it how ever you see fit. For the purposes of this post, we'll give it the name of "My First Blog Post".

Within this subfolder is where we will store the markdown file itself, as well as any related images or files. To create a new file, right-click on the "My First Blog Post" folder and select New File... from the menu. When the new file is created, you again can give it whichever title best suites your needs. Just be sure the extension of the file is .md. Again, we'll give this new file the title of "My First Blog Post.md" for the purposes of this blog post. At this point, you can add in your YAML frontmatter and blog post content, chocked full of your knowledge and teachings for others to enjoy. If you haven't already, you can read up on how to format your content from my previous article, Writing Posts in Markdown

Now that we have your post added into your codebase, we can utilize GraphQL to retrieve the data and content from within your files!

Adding To Your GraphQL Data Layer

GraphQL is a powerful query language, providing a complete and understandable description of the data in your API, and a quick runtime for fulfilling those queries with your existing data. Gatsby utilizes its own GraphQL data layer to store all of the data for your site, whether that's in your codebase's filesystem, a content management system like WordPress, or even a database. The data is retrieved from these different sources using specific source plugins.

We've already installed the necessary source plugin for retrieving data from your filesystem during the creation of the site, gatsby-source-filesystem. When the site is being built, this plugin will pull the data from your filesystem and add it directly into your site's GraphQL data layer. To get the data back out of the data layer, we'll write GraphQL queries to retrieve the data and provide it as objects to the templates we'll create later on. First things first though, let's create the needed queries to retrieve your blog post content.

Before we can get started, we need to make one quick change to the "gatsby-config.js" file that was created with the site. Within your IDE, go to the root folder of your directory and open it up. In this file, you'll find an array of plugins being exported. Find the gatsby-source-filesystem objects in the array; there should be two. Below the second object, we're going to add another of these objects to target our folder of markdown files:

module.exports = {
  siteMetadata: {
    title: `Personal Website`,
    siteUrl: `https://www.yourdomain.tld`
  },
  plugins: ["gatsby-plugin-image", "gatsby-plugin-sitemap", 
  ...
  }, {
    resolve: "gatsby-source-filesystem",
    options: {
      path: `${__dirname}/src/posts`,
      name: "posts"
    }
  }]
};

These configuration options will add all of the files in the folder, specified by the path option, into your data layer. The __dirname section of the path string is a variable from Node.js that stores the absolute path for the directory that contains the file currently being run. This will ensure that the correct folder is being pulled from each time. The name option gets set to the sourceInstanceName field for each file, allowing you to source files from multiple folders, if necessary. By providing a different name option for each gatsby-source-filesystem configuration object, you can build GraphQL queries that filter down to a specific folder.

After you have saved this file, start your local development server using npm run develop in your terminal. If the server is already running, be sure to stop it with ctrl+c and then start it back up again. This will ensure your new configuration changes are picked up by the server and will add the files to your data layer. Next comes the fun part of querying your data layer using GraphiQL. This is an incredibly useful tool from Gatsby to help you test out your GraphQL queries before adding them to you code, ensuring the request always responds with the data you expect.

Once the codebase has been built and the server is up and running, go to http://localhost:8000/___graphql in a new tab of your browser. There's three underscores in the URL so be sure to include three in yours as well. Navigating to that URL will display the following page:

I've selected some basic fields from the Explorer column on the left panel to create the query in the center panel. From the Explorer column, you can toggle the dropdowns to expand the different fields that are available in the data layer. Blue items correlate to the data you can query for, while purple items correlate to arguments that can be used to filter the data. After clicking the "play" button at the top of the page, the results of the query are displayed in the right panel. Those are the basic steps to retrieving your data from the data layer but, if you would like to know more about Gatsby's GraphiQL, I would recommend viewing their GraphQL Data Layer overview.

To request all Markdown files from your data layer, we're going to use the allMarkdownRemark field. Feel free to explore the different fields within this dropdown to see what data you can get back from your content. Once ready, build the below query, using related fields in the Explorer panel or copying my query directly into your center panel, to get the path of all Markdown files in your posts folder:

query MyQuery {
  allMarkdownRemark(
    sort: {order: DESC, fields: frontmatter___dateEdited}
    limit: 1000
  ) {
    edges {
      node {
        frontmatter {
          path
        }
      }
    }
  }
}

After running the query, your response should look similar to the object below:

{
  "data": {
    "allMarkdownRemark": {
      "edges": [
        {
          "node": {
            "frontmatter": {
              "path": "/my-first-blog-post"
            }
          }
        }
      ]
    }
  },
  "extensions": {}
}

That's all there is to it! You now have your blog post added into the GraphQL data layer and can retrieve it in GraphiQL! I can't say it enough though, I would highly recommend reading through Gatsby's GraphQL Data Layer, as well as their GraphiQL How-To Guide. These sources will greatly help you better understand how to work with this tool, as well as GraphQL itself.

In the next post, we will continue working within the codebase to build pages from your blog posts using only one template file. That's right! One file will be used to create individual web pages for each blog post you have in your "posts" folder. I hope you enjoyed this post and found it's content helpful as you continue your journey through web development! The links to my social media accounts can be found on the contact page of my website. Please feel free to share any of your own experiences on working with GraphQL, general questions and comments, or even other topics you would like me to write about. Thank you and I look forward to hearing from you!👋

Writing Posts In Markdown

Cory Dorfner — Tue, 18 Oct 2022 17:05:33 +0000

Hello and welcome to the second post in my series on Building a Powerful Blog!🎉 Throughout this series, we'll be using Gatsby as the framework, GraphQL as the data layer, and Netlify as the CI/CD pipeline. We'll be covering everything you need to know to get your first blog site up and running, including a basic understanding of how Gatsby sites work, how to utilize the numerous Gatsby plugins, and incorporating GraphQL as your data layer. These solutions will help create a fully functional, streamlined, no-database solution for presenting your work to millions.

Today's topic will be on the use of Markdown for your blog posts. Before we get into it though, please know that I'm not saying Markdown is the best or only way you should be writing blog posts. Everyone should utilize what works best for them to get out there and start sharing your knowledge with your audience. You should build your brand in the most enjoyable and comfortable way for yourself. There are numerous ways to create and share your content with your audience, each with their own pros and cons, and Markdown is no different. While Markdown might not be that for you, I have found it to be the most intuitive and resilient way for writing blog posts. With that in mind, let's get into it with the following topics:

Why Markdown?
Formatting Your Content
Utilizing YAML Frontmatter
Adding Images and Video
Markdown Cheat Sheets

Why Markdown?

To answer this question, we first need to know what it actually is. Markdown is a lightweight markup language that you can utilize with plaintext documents to add formatting elements to. This is different than applications like Microsoft Word, where you click buttons to format your content and the changes are immediately visible. These are referred to as WYSIWYG (What You See Is What You Get) editors. With Markdown, you add various syntax to the text to specify the formatting for your content. This might be something like adding an asterisk before and after a phrase to make it italicized (i.e., *this is an italicized phrase*), or adding a number sign before it to turn it into a heading (i.e., # This Is A Heading). The goal of Markdown's syntax is to make it as readable as possible, without looking like it's been marked up with tags or formatting instructions.

Now that you have a little bit more background information on what Markdown is, let's get into why I decided to use it for my blog posts:

Markdown is incredibly portable:
- Markdown-formatted text can be creating and transferred between any device, running on any operating system. These files also can be opened by virtually any application. While word-processing applications allow you to save your work, they typically do so in a proprietary file format that can't be reopened in a different application.
- Try taking a document created with Microsoft Word and opening it in Google Docs or Pages. You'll likely see many formatting changes that completely disrupts the flow of the document you spent days creating.
The above also makes Markdown future-proof:
- This becomes critical for important documents like dissertations, books, emails, technical documentation, and yes, blog posts on your website.
- As Markdown can be used for everything, having a system that is future-proof ensures that your "everything" won't be lost because the application you're using stops working in the future.
Markdown is everywhere:
- It's supported in websites like GitHub, and numerous desktop and web-based applications. I've found these applications to be more intuitive and user-friendly than the standard word-processors currently on the market. Take Obsidian as an example. It's marketed as "A second brain, for you, forever" and that's exactly what it is.
  - This application uses connections between Markdown files to help create a mind map of your content.
  - It also is incredibly extensible so that you can make the app your own and has a vibrant community to help learn and create together.
  - Furthermore, you never have to worry about losing your content as everything sits in a local folder on your computer. Combine that with a cloud-based backup storage like Google Drive, and you have a perpetual mind-map that you can bring with you anywhere.

I hope at this point I've convinced you that using Markdown for your blog posts is the best way to go, or at least worth a try. If so, let's get into how I utilize it to create my blog posts!

Formatting Your Content

While Markdown syntax can be a bit nuanced and tricky to get used to, the best way to learn about it is to just begin using it. If you have Visual Studio Code installed on your computer, I would recommend beginning with that until you're a bit more comfortable with the language. To get started, open a new text file in VS Code by going to File -> New Text File (ctrl+n) and select Markdown as the language of the document. Go ahead and save your file, giving it whatever name you like, and selecting Markdown as the file type. You now have a playground to start learning Markdown with!

For our Markdown, we will be using the CommonMark specification, as it is already utilized by Visual Studio, GitHub, and Obsidian. We'll go through a couple of the main items here but I've included some links to Markdown Cheat Sheets at the end of this post to help further your knowledge on the syntax.

When it comes to starting your blog post, it's best to include a heading at the top, utilizing an h1 with a single number sign before it. For sub-headings further down in the article, you can create h2, h3, all the way to h6 headings with the relative amount of numbers signs before it.

Markdown	HTML	Rendered Output
`# Heading One`	`<h1>Heading One</h1>`	Heading One
`## Heading Two`	`<h2>Heading Two</h2>`	Heading Two
`### Heading Three`	`<h3>Heading Three</h3>`	Heading Three

With headings in place, you can add in a Table of Contents as well, which includes making an ordered list and linking to your headings. To make an ordered list, you start on a new line with a 1.. For each additional item needed in the ordered list, you just move to a new line and increment the value. The next part is to create the links to your headings, this involves using square brackets, [], to write the text the user will see, followed immediately by parenthesis, (), which is what will contain the link to the heading. For in-document links to any headings (h1 to h6), start with a number sign, immediately followed by a hyphen delimited string matching your heading in all lowercase. This would look something like #this-is-my-heading, which would link to # This is my Heading. Putting it all together, your Table of Contents would be created with the following:

Markdown HTML Rendered Output

Markdown	HTML	Rendered Output
`1. [First Heading](#first-heading) 2. [Second Heading](#second-heading) 3. [Final Heading](#final-heading)`	`<ol> <li> <a href="#first-heading"> First Heading <a> </li> <li> <a href="#second-heading"> Second Heading <a> </li> <li> <a href="#final-heading"> Final Heading <a> </li> </ol>`	First Heading Second Heading Final Heading

1. [First Heading](#first-heading)
2. [Second Heading](#second-heading)
3. [Final Heading](#final-heading)

<ol>
  <li>
    <a href="#first-heading">
      First Heading
    <a>
  </li>
  <li>
    <a href="#second-heading">
      Second Heading
    <a>
  </li>
  <li>
    <a href="#final-heading">
      Final Heading
    <a>
  </li>
</ol>

First Heading
Second Heading
Final Heading

With the headings and table of contents in place, you can start adding in the content; building out a blog post that everyone can enjoy and learn from. As stated earlier, there is a lot more syntax that can be utilized with Markdown to improve the formatting of your content so be sure to check out those cheat sheets. Let's continue forward though with how you can add metadata to your blog post, through the use of YAML Frontmatter!

Utilizing YAML Frontmatter

YAML frontmatter is utilized to capture the metadata about your blog post and is defined at the beginning of the file, starting and ending on lines with three dashes (---). This becomes incredibly useful to capture basic information including, but not limited to:

Title
Author
Description/SubTitle
Blog Series
Date Created
Date Edited
Tags
Banner Images

The list could go on and on, but you get the picture. Any general information about your post can be captured in key-value pairs, where the key is before the : and the value is after it. The best part about this is that it doesn't appear when the Markdown is rendered on your blog site, so you can put anything in there you need, pull it into your site with GraphQL, and use that data to add important UI elements. I'll get more into the details on how we can utilize this frontmatter in a future blog post though. For now, just know that the structure for your YAML Frontmatter should follow the below format, which has been taken directly from this blog post:

---
path: "/writing-posts-in-markdown"
dateCreated: 2022-10-18
dateEdited: 2022-10-18
title: "Writing Posts In Markdown"
description: "Struggling to find the best format for writing blog posts? Learn some quick tips and tricks to utilize the power of Markdown for your blog site."
series: "Building a Powerful Blog"
tags: ["tutorial", "beginners", "webdev", "markdown", "learning"]
banner: "./writing-posts-in-markdown-banner.png"
---

Adding Images and Video

Another area I wanted to mention is working with images and videos in Markdown. While adding images and gifs can be done using the Image syntax, adding videos has an additional layer of complexity to it. Trying to display videos in your Markdown content with the Image syntax will not work, as it doesn't support file types like MP4.

To add an image to your Markdown, utilize the following syntax:

![Alt text of the image](Absolute/Relative URL of the image)

An example of this would be:

![The beautiful views from Emory Peak at Big Bend National Park](./emory-peak-big-bend.png)

The rendered output would look like this:

Adding animations is a whole different story though. While great at grabbing people's attention and helping break up your content, animations in improper formats can greatly slow down the load time and responsiveness of your blog site. So, while you can use the GIF format with the Image syntax to display our animation, I would highly recommend against it. Instead, you'll want to use formats like MPEG4/WebM for animations and PNG/WebP for static images. This will help boost the performance of your site and improve the experience for your users.

The only problem is, the following won't work to display a video:

![This video will not properly show](https://media.giphy.com/media/lXu72d4iKwqek/giphy.mp4)

The rendered output would be:

As you can see, trying to use the proper format for animations causes issues when using the Image syntax in Markdown. What Markdown does support though is HTML elements. By adding the <video/> element, you can easily get the job done.

<video 
    autoplay 
    loop 
    muted 
    src="https://media.giphy.com/media/LpLd2NGvpaiys/giphy.mp4" 
    type="video/mp4" 
    controls="controls" 
    controlslist="nodownload nofullscreen noremoteplayback" 
    disablepictureinpicture 
    aria-label="Shocked Cosmo Kramer from Seinfeld">
    Sorry, your browser doesn't support embedded videos.
</video>

There's a lot to unpack here and but these specific attributes were selected after reading through the MDN web docs on the <video/> element. Some of these might not be applicable to you and your needs so I would recommend reading through those docs as well to identify what you would like to use. For example, if you're displaying a longer video, you might not want it to autoplay and loop back to the beginning on completion. You also might not want it to be muted so that the reader can listen to the video. If so, you just don't include those attributes with the element.

Depending on what you choose, the rendered output could look something like this:

As you can see, while videos add a bit of complexity to your blog post, it's not impossible to provide animations to your readers in a proper format. Utilizing the Image syntax for static images and the Video element for animations, you can better display your content to the reader, without hindering your site's performance.

Markdown Cheat Sheets

Hopefully by know, I've helped better explain the wonderful benefits of using Markdown for your blog posts and have helped clear up some of the more intimidating aspects. If not, that's alright as the community around Markdown is vast and there are numerous resources out there to help you learn more on the topic:

Markdown Guide's Cheat Sheet: This is a great website to help learn more about Markdown and its basic and extended syntax.
Adam Pritchard's Cheat Sheet: Another great resource for those specifically looking for syntax guidelines.
Writing on GitHub: Perfect for those looking to write in Markdown primarily on GitHub.
CommonMark Spec: For the daring adventurer looking to learn as much as they can about the specification utilized by VS Code and GitHub.

If you're struggling with any of the more detailed aspects about Markdown, the above resources should be able to answer all of your questions. If not though, please feel free to reach out and I'll do my best to help answer your questions!

There you have it! Those are the major components need to write and format your blog posts using Markdown, complete with metadata, properly formatted content, and eye-catching images and animations. All that's left is finding the content to write about. If you're struggling in this area, feel free to take a peak at some of my prior blog posts on my personal website for ideas and inspiration. You can also get a head start on building your skills by writing on what you are passionate about. Even if you feel like others won't care to read it, I promise you they are out there.

From here, we will continue on to using some of the plugins you installed while creating the site, alongside GraphQL, to build all the pages you need for your blog site using only templates. This is really where you can make the site your own, utilizing React and CSS to style the pages however you see fit. I hope you enjoyed this post and found it's content helpful as you continue your journey through web development! The links to my social media accounts can be found on the contact page of my website. Please feel free to share any of your own experiences with writing in Markdown, general questions and comments, or even other topics you would like me to write about. Thank you and I look forward to hearing from you!👋

Creating a Gatsby Blog Site

Cory Dorfner — Thu, 06 Oct 2022 18:02:58 +0000

Hello and welcome to the first post in my new series on How to Build a Gatsby Blog!🎉 I have been writing blog posts for over a year now and recently made the decision to add them to my personal portfolio website. This decision stems from several different reasons but the main reason is because I view my blog posts as an extension of myself and my thoughts. With my portfolio being in place to display who I am as an individual, it not only felt right, but necessary to add my blog posts to my site.

Throughout this series, we'll be using Gatsby as the framework, GraphQL as the data layer, and Netlify as the CI/CD pipeline. We'll be covering everything you need to know to get your first blog site up and running, including a basic understanding of how Gatsby sites work, how to utilize the numerous Gatsby plugins, and incorporating GraphQL as your data layer. These solutions will help create a fully functional, streamlined, no-database solution for presenting your work to millions.

Why Use Gatsby?

While there are numerous ways to go about creating and deploying your own site, I wanted to show you the path I chose for creating my blog site. I decided to use Gatsby for this site for various reasons. As I've become very familiar with the React library and wanted to learn more about GraphQL, Gatsby was an easy choice for me. It combines these two tools to help you build fast and secure websites, where integration of various content, APIs, and services helps create a very powerful web experience. They also have improved security as statically generated sites have less vulnerabilities than traditional websites. If you're interested in learning more about Gatsby before continuing on, feel free to check out their Why Gatsby page for more details on the power and functionality of this framework.

All of the features provided by Gatsby make it the perfect framework to use for something like a blog site. As a Static Site Generator (SSG), Gatsby uses Server-Side Rendering (SSR) APIs to create static HTML when building your site, instead of upon request from a user. This gives you the SEO and social sharing advantages of SSR, with the speed and security of SSG. Gatsby will help create a lightning-fast Progressive Web App (PWA) right out of the box, giving you a site that can be saved to a user's mobile device to view while off-line, with pages that load in milliseconds and incredibly smooth transitions.

To create our site, we will utilize Gatsby's Command Line Interface (CLI) to get things started and then just a couple of steps afterwards to get your site deployed to Netlify. Before we get started though, there are a couple of items that need to be addressed. To keep this post on topic, it's assumed that you have a basic understanding on the fundamentals of web development. This includes HTML, CSS, JavaScript, the command line, and React. I'm also assuming that you have Node.js (v14.15 or newer), Git, Gatsby CLI, and Visual Studio Code installed and ready to go on your local machine. If you're unsure about any of these topics, I would recommend walking through the Gatsby tutorial to Set Up Your Development Environment. There's some great information in there to make sure you're ready to go with creating your Gatsby site. With that out of the way, below are the steps we will follow to make it all happen:

Creating the Gatsby Site
Running Locally
Setting Up GitHub
Deploying to Netlify

Creating the Gatsby Site

To create the basic template for your Gatsby site, you'll need to open up your terminal and enter the command gatsby new into the Gatsby CLI. This will bring up an interactive prompt, asking you questions about the site you are trying to build.

If you are having trouble with the Gatsby CLI, you can also create the site by running npm init gatsby from the CLI instead. There are several questions that need to be answered before your site can be created. Your answers to these questions are your choice but I'll provide some insights into potential answers based off my selections.

What would you like to call your site?
  ✔ · Personal Website
What would you like to name the folder where your site will be created?
  ✔ personal-website
✔ Will you be using JavaScript or TypeScript?
  · JavaScript
✔ Will you be using a CMS?
  · No (or I'll add it later)
✔ Would you like to install a styling system?
  · No (or I'll add it later)
✔ Would you like to install additional features with other plugins?
  · Add responsive images
  · Add an automatic sitemap
  · Generate a manifest file
  · Add Markdown Support (without MDX)

The options selected will help by installing additional features and plugins during the creation of your site, avoiding the need to do so later. For this site though, only those four additional features from the last question will be needed. This will update your gatsby-config.js file with templated options for each plugin to get you started.

While you might be tempted to select the Google Analytics tracking script option, I would recommend against it. This selection will install the gatsby-plugin-google-analytics plugin, which Gatsby actually recommends against installing, as it utilizes analytics.js, which is an outdated Google tagging system. Instead, you should install the gatsby-plugin-google-gtag, which utilizes a Global site tag (gtag.js) to combine multiple Google tagging systems and replace older ones, such as analytics.js. We will cover the installation and implementation of this plugin in a future blog post on Improving SEO, so we can avoid worrying about this now.

Selecting the addition of responsive images, a sitemap, Markdown support, and generating a manifest file are all very valuable items to add to your site during creation. While these can be done at any point you want, adding them now just helps check off a couple more items from the to-do list. For example, selecting the Add responsive images choice will install gatsby-plugin-image, gatsby-plugin-sharp, gatsby-source-filesystem, and gatsby-transformer-sharp, while also adding them into your gatsby-config.js file. The will handle the hard part of producing images in various formats and multiple sizes for you. From here, all you will need to do is import and use the StaticImage and/or DynamicImage components into your pages and Gatsby will handle the rest. The other selections you choose during the creation of your site will follow the same pattern. They'll install their necessary packages and update the gatsby-config.js file for you so you can begin using them from the very beginning. How cool is that?!

We, of course, will be getting into more details on how to utilize these various plugins as we progress through the creation of your blog site. If you interested in learning more about them now though, I've added the packages installed by the selections specified above, as well as their respective links:

Add responsive images:
Add an automatic sitemap:
- gatsby-plugin-sitemap
Generate a manifest file:
- gatsby-plugin-manifest
Add Markdown Support (without MDX):
- gatsby-transformer-remark

After all of the required information is entered, the last prompt asks, "Shall we do this?". All that is left from you is to enter "Yes" or "Y" and your new Gatsby site will be automatically generated by the CLI. Depending on your computer and internet speed, the time for this process to complete will vary. You'll know the site creation has been completed when you see the below message:

That's all there is to it! You are now the proud owner of a brand new Gatsby site, ready to be built into whatever your heart desires. The next step is to run it locally and see what it looks like!

Running Locally

Now that you have the code for your site, we can go ahead and run it locally to view it in your favorite browser. To get it up and running, you'll use the terminal to set up your local development server. When this development server is running, you'll be able to utilize your web browser to view and interact with a local copy of your site. This is a very useful tool, allowing you to test your code and make sure it's working as intended before you publish a new version of it to the internet.

With Gatsby, this is as simple as entering a command into your terminal, once you're in the root folder of the project you would like to start. It's important to be working within the directory of your site whenever there are any commands you would like to run. If you have just completed the gatsby new command, you'll notice the first step afterwards is to go into the directory you just created with:

cd personal-website

Once you're in your site's directory, running the below command will start the development server for you:

gatsby develop

If you were unable to install the Gatsby CLI, or just prefer to run the server without it, you can instead use the following command to get your site up and running:

npm run develop

Once Gatsby has been able to go through the necessary steps of getting your server running, the terminal should display the following message:

With that, you can now open your favorite web browser and view your new Gatsby site by navigating to http://localhost:8000.

You can visit this site by navigating to the address as long as your development server is running. If you would like to shut down the server, all you need to do is go back to your terminal, hold down the control key, and click "C" (ctrl-c). If you want to run your server again, all you have to do is run gatsby develop in the terminal!

That's all it takes to run your site locally, but what if you needed to do some development work on a computer other than the one your currently using? This is where Source Code Management (SCM) tools, like GitHub, are incredibly useful to work with from the very beginning.

Setting Up GitHub

SCM tools allow you and others to collaborate together on projects and contribute to the codebase from anywhere. They can help you work on your problems, move ideas forward, and learn throughout the entire process without any fear of irreversible changes. While there are many variations of this tool out there, we will be using GitHub to store and track the changes made to our codebase.

If you don't yet have a GitHub account, you can head over to github.com and create your account by clicking the "Sign Up" button in the upper right-hand corner. Once you are signed in, you will need to create a repository for your new Gatsby site. This can be done by clicking the "+" icon in the upper right-hand corner of the navigation bar and then selecting "New Repository".

When creating the repository, be sure to give it a short, yet memorable, name. I typically go with the same name that I provided when running the gatsby new command in the terminal. I also recommend adding in a description for your website, but this is optional. In regards to whether to make the repository public or private, that choice is completely up to you. It won't have any impact on deploying your actual site and allowing others to view it, but choosing public does allow anyone to go and look at the actual code for your site. The last section contains the initialization options. As Gatsby has already included a README.md and .gitignore file in your repository when the site was being created, you can leave these two options unchecked. The choice of a license is also up to you, but for the purposes of this post, I have decided to leave it unchecked.

Once created, all that's left is to push the existing code from your computer to the new repository. You'll find instructions on how to perform these steps from your browser after the repository has been first created. They will look similar to the below screenshot that I have taken after creating my repository:

Just be sure that you are using your actual username, and the name you gave your repository, when running the git remote add origin command in the terminal. If you are using GitHub for the first time, you will likely come across an error in the terminal about permissions. To work past this, you'll need to set up a personal access token (PAT) for your GitHub account. This is so GitHub knows that you are authorizing your computer to push any code changes to your remote repo. I would recommend following GitHub's guide on Creating a personal access token to complete this part of the process.

Once you have completed those three commands from the terminal, you should be able to refresh GitHub and see your code on their servers. You can now log into GitHub from any device to view your code, as well as pull that code to any computer you would like to continue developing on. This also will make the next step of our process easier so that you can deploy your site to Netlify and finally view your new Gatsby site online!

Deploying to Netlify

There are numerous options these days to host your site, each with their own pros and cons. Some will provide better uptime or site speed, while others might have top tier customer support. Some will be free to use (up to a point), while others might only have paid options. Making the choice on which provider to go with for hosting your site can be a very difficult one, and it's important to do your research before jumping into anything.

At the time of this writing, Netlify is still a very good option to go with. It works incredibly well with Gatsby, as a static site generator, as you will be deploying your site to a global edge network. It also allows for live site previews in a staging environment, where you can collaborate with others before moving the site to a production environment. You get instant rollbacks to any version of your site, as well as the deployment of static assets and the use of dynamic serverless functions. All of these options align well with the offerings of Gatsby and the best part is that it comes with a Free Tier!

Still yet, you may want to stick closer to the Gatsby tutorial and build your site with Gatsby Cloud. This is a fair choice as it is specifically optimized for building, deploying, and hosting Gatsby sites. If you choose to go with Gatsby Cloud, I would recommend following their tutorial on getting started with the service. Otherwise, continue reading below on deploying with Netlify.

Sign up for Netlify by clicking on the "Sign Up" button in the upper right-hand corner
On the Team Overview page, click on "Add new site" and select "Import an existing project"
Under "Connect to Git Provider", select the "GitHub" button
- If this is your first time connecting GitHub to Netlify, you'll need to give Netlify permission to access your GitHub account
- A new browser window should open, where GitHub will ask you if you would like to give Netlify access to your GitHub repos towards the bottom of the window. You can choose whether to give access to all of them or to specific repositories. You only need to give access to this current repo, if so desired. Then click "Save" to continue on.
When you return to Netlify, the repository list should contain the GitHub repos you allowed. Select your blog site repo.
After selecting your repo, you will be able to modify some configuration values, such as the owner within your Netlify account, as well as the branch to deploy. Leave the default settings and click the "Deploy site" button
Netlify will begin building your site automatically and you'll be taken to a dashboard where you can see the status of your deployments, steps to further set up your site, and other critical information about your site.
- After the site is built, you'll see a link to your new site, which is automatically hosted on Netlify!

That's all there is to it. You're site is now online and can be viewed by anyone!👏

Any time you push a change to the main branch of the GitHub repo linked to this site, Netlify will automatically begin building a new version of your site and publish online. Also, any time you create a Pull Request pointing to your main branch, Netlify will automatically build a version of that in a staging environment to assist you with debugging before it goes live!

Congratulations!🎉 You have just created a Gatsby site! If this was the first site you've ever created, this could seem like a very cumbersome process but I promise you that the next time through will be a walk in the park. Let's go ahead and recap everything that we just did:

We created a Gatsby site on our local machine using the Gatsby CLI
The terminal was then utilized to run the Gatsby site locally, where you could view the website at http://localhost:8000.
We then set up a GitHub repo and pushed our local code to their servers, allowing you to view your code online and pull it to any authorized computer
Finally, we deployed your code to Netlify to build a hosted version of your site so that any users with an internet connection can view it

From here, we will continue on to using some of the plugins you installed while creating the site, alongside GraphQL, to build all the pages you need for your blog site using only templates. This is really where you can make the site your own, utilizing React and CSS to style the pages however you see fit. I hope you enjoyed this post and found it's content helpful as you continue your journey through web development! The links to my social media accounts can be found on the contact page of my website. Please feel free to share any of your own experiences with creating a Gatsby site, general questions and comments, or even other topics you would like me to write about. Thank you and I look forward to hearing from you!👋

Negotiating & Celebrating

Cory Dorfner — Mon, 26 Sep 2022 16:48:26 +0000

Hello and welcome to the final post in my After the Interview series! If you've already been following along, welcome back! If not, I would highly recommend reading through my first post of the series, Getting the Offer, as a precursor to what will be a very informative series on what to do after the interview. Throughout this series, we'll be discussing topics like receiving and evaluating your offer letter, as well as handling the negotiation process afterwards. There's a lot to cover though, so let's continue the discussion with negotiating your offer letter!

"Let us never negotiate out of fear. But let us never fear to negotiate."
-John Fitzgerald Kennedy

At this point in time, you should have been able to review the offer letters you've received and determined what criteria might be lacking in each of them. That's right! It's very unlikely that you will have received an offer that satisfied each and every one of your criteria. Even if there was, it's still highly beneficial for you to go back to your recruiter to start the negotiation process. While this might seem like the path to take if you want the offer rescinded, trust me, it's not. It's highly unlikely that a company will take back your offer letter as long as you're reasonable in the negotiation process. How can one be reasonable in this process though? I'm glad you asked.😊

1) Negotiation
2) Celebration

Negotiation

Now that you've selected the offer that best suits you and your values, it's time for the fun part of negotiation! This can be a very intimidating process to under go but it can also be very valuable to getting a little extra added onto your salary or signing bonus. The best way to go about this process is to think about how important it is for you to get this job and just jump right into it. If you need to get this job, start the negotiation process with a value around 10% more than your current offer. If you have other job options, start the negotiations somewhere closer to 20% more than your current offer. Also, be sure to go back with an actual dollar amount, not a percentage. It's much more effective to ask for an additional $10,000 on the offer than to just ask for more money.

A company is very unlikely to revoke an offer just because you decide to negotiate the terms, as long as you don't come back with something absurd. It also helps if you have alternative options, like your current job or the other offers you hopefully received. If a recruiter knows you don't need this job, they're much more likely to negotiate with you. By going somewhere around 10-20% more on your offer, it gives you a little wiggle room to overshoot the amount you're actually looking for without asking for too much.

When starting the negotiation process, be sure to do so in a manner that's comfortable to you. While it's best to negotiate with the recruiter over the phone, it's more important that you just start the process. If talking about this over the phone is not something you're comfortable with, get things started over emails. Also, consider the possibility that they might come back with a counter-offer on something other than the salary. Many companies have salary tiers for their various positions and might not be able to increase your salary any further. To compensate for this, they might offer you a bigger signing bonus, or improved stock options in the company. If you're moving to join the company, you could also ask for a relocation bonus instead of an increased salary as well. Whatever their response is though, just be sure to evaluate it to see if it aligns closely to your original negotiation amount.

Celebration!

Congratulations, you did it! You successfully navigated through the interviewing process, received an offer from an incredible company, and negotiated the deal that you wanted. Now you can bask in your victory and let all of your friends and family know you got the job at the company of your dreams! I'm so proud of you and your accomplishments and I can't wait to see what good you help bring about in this world with your unique set of skills and values.

The interviews you'll have are not over yet though. While you may be in the company of your dreams now, who knows what you'll be doing in a few years from now or what you would like to be doing. Whether you're looking for a new job or not, it's always a good idea to keep practicing on your interviewing skills. Doing an annual refresher of your resume and applying to new jobs, even if you don't intend to leave your current one, is a great practice to undergo. This will help keep yourself fresh and ready for whatever opportunity comes your way. Who knows, maybe one of these practice interviews will open a brand new door of possibilities that you could never have imagined. So remember to keep practicing and continue to improve yourself, one step at a time.

If you enjoyed the post, be sure to follow me so that you don't miss my future content, where I continue to dive deep into what I'm learning and how we all can grow as individuals! The links to my social media accounts can be found on the contact page of my personal website. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Evaluating the Offer

Cory Dorfner — Tue, 20 Sep 2022 13:13:20 +0000

Hello and welcome to the second post in my After the Interview series! If you've already been following along, welcome back! If not, I would highly recommend reading through my first post of the series, Getting the Offer, as a precursor to what will be a very informative series on what to do after the interview. Throughout this series, we'll be discussing topics like receiving and evaluating your offer letter, as well as handling the negotiation process afterwards. There's a lot to cover though, so let's continue the discussion with what to do after you get the offer letter.

"You never achieve success unless you like what you are doing."
-Dale Carnegie

Congratulations, you did it! You received the offer letter you've been looking for and maybe even offers from multiple companies, if you're lucky. Now comes the difficult process of reviewing the offer(s) and determining if the offer, and company, are the right fit for you. This includes looking at factors such as the company's stability, how that company might impact your career development, your own happiness while working at that company, the financial package they are offering you, and other important factors that may be more critical to you and your values. Let's go ahead and take a little look into these various factors now.

Company Stability

I'm taking a leap here and guessing that you don't want be fired or laid off any time soon, right?

This is where evaluating the company's long-term stability is important. Are they a bigger company with a long track-record of profits and growth? Are they a smaller company at the beginning round of seed funding? Whatever may be the case, you have to do your research to ensure your future won't be turned upside down in a couple of months. It also will be important to understand your own wants and needs. Large, more established companies tend to grow more slowly, providing less opportunities to move up the career ladder. They also will be less likely to afford you the opportunity to work with bleeding-edge technologies.

If stability isn't an important factor of yours and you feel that you would be able to get a new job quickly, it could be better for you to take the offer from the start-up, even if it's unstable. Otherwise, stability might be more important to your values if you don't feel confident that you can get a new job quickly after a lay-off. Whatever the case, make sure you evaluate the stability against your own career development goals.

Career Development

You have to review each offer before accepting to determine how the position might ultimately effect your career path. While one of these offers may be for the company of your dreams, it's very likely that you may want to move companies and start the interview process all over again. You should answer some questions honestly, and with deep consideration, to better understand your needs:

What does the company offer you in terms of learning and growth development? Are there topics relevant to you that you will be able to learning while working for this company?
Is the team I'll be working on growing any time soon?
If it is growing, what opportunities will that provide for me to grow into a managerial or technical lead?
What does their promotion and career development process look like? Do they have a defined process to help you in progress in your career?
How does the company and position title look on your resume and portfolio? Will it make for an easier interview process with a different company, where you may get a promotion and increased salary?
If you do decide to move companies in the future, is this current company located in a tech hub where you can join a different company easily, or will it require you to move? If there are very few tech companies in the city, your future career opportunities could be more restricted, making it less likely to reach your goals.

Your Happiness

To some, hopefully most, this might be the most important category of them all. While the company and financial package is important, none of that will make you want to stay at a company if you are not happy. It will take a deep dive into understanding your needs and wants, your values, and what you're looking for in a career. The following are some examples of what these may be but you'll really want to look inward to identify what's important to you.

The Company Culture🤼: Ask your friends in the company and future teammates how they view the company culture. As this is connected with everything, such as how the leaders make their decisions, how the company is organized, and even the social aspect of the company, it's important to understand if you will fit in well with this culture.
The Manager and Teammates👩‍💼: Have you met these individuals and did you enjoy talking to them and getting to know them? If things were awkward or you felt uncomfortable, that might not change as you start working with them. As these are the individuals you'll be spending the majority of the day with, being uncomfortable around them will not be a very pleasant experience.
The Hours⌛: Talk to your friends in the company and future teammates as well about the amount of hours they work. Try to deduce if this is due to their own personal choices or the culture of the company, as well as if it's a typical week or due to the launch of a new product. If they're working over 40 hours/week, does that align with your own lifestyle or will being overworked take away the joy of working for the company.
The Product/Tech Stack🧑‍💻: This category might not be as important to you as the culture of the company or the hours worked, but you'll still want to find out what type of product you'll be working on and if it's something that intrigues you. If you're excited to work on this product and with the tech stack that they've chosen, great! Otherwise, you'll want to evaluate how this might impact your happiness. It would also be beneficial to do a little research into the company's policy on transferring to other teams. If you know the company is working on a product or with a tech stack you're more interested in, and you're allowed to transfer a year into working with the company, your current teams' product might not be a critical point to consider.

The Financial Package💵💴💶💷

When reviewing the offer letter, be sure to look at more than just the salary. While that number is important, the amount that you actually receive from the company each year will be vastly different. Be sure to also look over the new hire bonuses, annual bonus, stock options, health benefits, retirement plans, and cost of living.

New Hire Bonuses💸: This may include things like a signing bonus, relocation bonus, and/or other one-time bonuses. When looking at these amounts, spread their value over however long you plan to stay at the company. If you're only planning to stay for two years, split that cash value by two and add to your annual salary. It's also important to look at any kind of payback clause on the bonus. For example, the company may require you to work with them for 3 years, otherwise you have to pay back the relocation bonus. If this is the case, how does that align with your career development plans?
Annual Bonus💰: These annual payouts can range anywhere from nothing to over 30%. If your recruiter or hiring manger didn't provide this information to you, try to reach out to some friendly contacts at the company to find out what you might receive. Most company's annual bonuses are also tied to the profit goals of a company. If you don't believe the company will be in the green over the next few years, how might that look for your annual bonus? If your prior research points to a company that might likely exceed their expectations, you could be in for a large windfall of cash with a multiplier on your bonus.
Stock Options📈: Equity in a company can be a make it or break it part of your annual compensation. Just like the annual bonus, you have to do your research to identify how well you feel the company will do in the future over the next several years. Once you have a feel for this information, treat that extra cash like your new hire bonus and spread the value over however long you plan to stay with the company before adding it to your annual salary.
Health Benefits👩‍⚕️: Is the company providing you with the option for medical coverage or will you have to sign up for your own plan through the marketplace? If they do provide you with medical coverage, will their plans meet your medical needs?
Retirement Plans👴: What about the employer match in your 401(k)? Some companies may provide something like a 100% match on the first 5% you contribute to your 401(k). While not immediately available due to early withdrawal laws on your retirement plan, it's still an important amount to consider as it helps set you up with a nice little retirement egg.
Cost of Living🏠: The amount of money it costs to live in a specific, geographical area can greatly impact the amount of money left over in your gross income after your expenses. These costs can include things like housing, transportation, food, entertainment, healthcare, and taxes. For example, living in San Francisco, CA is 51% more expensive than Austin, TX. You will want to do a little research into the locations of each offer to determine the severity of their impact on your take-home pay. NerdWallet has an incredible Cost of Living Calculator to help make this process a little bit easier.

Remember that your salary will change year over year though and it's important to consider how a company will help you grow and advance your career. Try not to put too much emphasis on the short-term view of your immediate salary and consider how the company will help you towards your long-term financial goals

Other Important Factors

While the above factors are important, you'll also want to take some time and evaluate anything else that you feel is important.

This might include how close the new job location is to your friends and family, what types of events and activities you'll have in the city of your new job, walkability of the city, so on and so forth. Whatever you value in a career, company, and location are all important factors to analyze against each job offer to help you identify which is the right fit for you.

A great method to compare these potential offers would be to rank each factor's importance to you as a 1 (not important), 3 (important), 9 (very important). You can then rank each offer against how well they satisfy each factor, using the same scale of 1, 3, and 9, and multiply that against the factor's importance. After all have been evaluated, sum the numbers for each offer and you'll have your prioritization ranking for each. This can be done, not only for these other important factors, but also for the previously discussed factors above. Below is an example table showing this concept in action.

Job Offer	Factor #1	Factor #2	Factor #3	Factor #4	Total
Job Offer	3	1	3	9	Total
Offer #1	1 (3)	9 (9)	9 (27)	1 (9)	48
Offer #2	9 (27)	3 (3)	3 (9)	9 (81)	120
Offer #3	3 (9)	1 (1))	1 (3)	1 (9)	22

That's all there is to it! A quick prioritization matrix can help you immensely in evaluating your offer and deciding what is going to be best for you. While there are numerous different factors to consider, this activity will be well worth your time. I hope you utilize it to properly consider everything and not just go with the offer providing you the highest salary. As you can see, there's a lot more to consider, which will net you a higher take-home pay in the future, as well as help ensure your happiness and mental stability are intact to see it all through.

If you enjoyed the post, be sure to follow me so that you don't miss the rest of this series, where I continue, in detail, on what to do After the Interview, including negotiating your offer letter! The links to my social media accounts can be found on my contact page. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Getting the Offer

Cory Dorfner — Wed, 14 Sep 2022 12:21:09 +0000

Hello and welcome to the first post in my new series, After the Interview! If you've already been following along with my prior series, Acing the Interview, welcome back! If not, I would highly recommend reading through that series as a precursor to what will be a very informative series on what to do after the interview. Throughout this series, we'll be discussing topics like receiving and evaluating your offer letter, as well as handling the negotiation process afterwards. First things first though, let's get started on what to do after the interview, but before you get that offer letter.

“One part at a time, one day at a time, we can accomplish any goal we set for ourselves.”
-Karen Casey

Phew! You did it!😤 You made it through your interview! Ideally, the interviewer loved you and either scheduled a follow up interview for you with some other individuals in the company, or has let you know that they'll be getting back to you shortly with an offer letter. If you feel like the interview might not have gone as well as you hopped though, don't fret. While the interview is important, how you handle the follow up after the interview and potential rejection is just as critical. You have to remain present and responsive to the company, as there's a lot still to be done after the interview process, such as:

Thank You Letters
Handling Offers and Rejections

Thank You Letters

Thank you letters sent directly to your recruiter and interviewers can make or break your chances of getting an offer letter. One survey by TopResume, show that 68% of recruiters and hiring managers say a quick thank you letter after the interview matters to them. The interview process doesn't end when you leave the building after your interview. The post-interview activities provides you with the wonderful opportunity to create a stronger relationship with the interviewers and hiring manager, keeping your candidacy at the top of their mind. That survey also showed that 16% of the interviewers out-right reject an interviewee because they never sent any kind of thank you email or note after the interview. Another survey by CareerBuilder showed that 43% of interviewees don't send thank you notes after the interview.

This data shows that, while many companies expect a thank you letter after the interview, almost half of all candidates don't do so. Taking this into consideration, you can see how important this part of the process can be and how sending short, timely thank you letters after each interview and to each interviewer can be incredibly helpful. Not only can you reiterate why you're the right person for the job, it also provides you with the opportunity to mention something you may have forgotten during the interview, or even provide the correct solution to a question you may have gotten wrong during the interview. This shows the interviewers that you have the persistence and capabilities needed to do the job, even if you weren't able to prove that to them during the intense pressure of an interview. So be sure to get a business card or contact information from each interviewer and tuck that information away to follow up within 24 hours of the interview.

When writing your concise thank you letter, be sure to cover the following topics:

Use short and clear subject lines for your follow-up email. Something like, "Thank you for the interview yesterday" or "[First Name], it was great meeting you"
Thank each interviewer for their time by starting the email with the interviewer's first name and including some authentic part of the interview that you are grateful for involving that interviewer. Don't hesitate to mention something specific that you both discussed, such as a specific problem or skill that individual needs, and how it's one of your strong points, making you a great fit for the position
Reiterate your interest in the company and why you are a great cultural fit, but don't come off as desperate. 1 or 2 quick sentences should be more than enough to do so
Wrap up the email by asking if they have any other questions for you and what the next steps are in that company's interview process.
Finally, be sure to include your full name, email, and phone number in the signature of the email so that they know how to reach out to you, if needed.

Below is a sample thank you letter that you're free to use in your post-interview communication:

[Interviewer's First Name],

Thank you for taking time out of your busy schedule to meet with me yesterday about the [insert job title] job opportunity. It was a pleasure learning more about the role and where you see the company over the next several years.

It's clear to me by the projects you discussed that [insert company name] would be a very exciting place to work. I'm very interested in becoming an integral part of your team and contributing to its many successes in the future.

I'm confident that my knowledge in [insert applicable skill] and experience with [insert applicable skill] will help bring about those successes with you and the rest of your team, as your new [insert job title].

If you have any other questions for me, or need additional information, please don't hesitate to reach out. I'm looking forward to hearing back from you on the next steps.
Once again, thank you for your time and have a great rest of the day.

Sincerely,
John Smith
Phone: 123-456-7890
Email: email@gmail.com

As you can see, thank you letters take very little time to write but can have a major impact on your chances of landing that dream job. Be sure to write up one and send it out quickly after each interview to help separate you from the rest of the candidates and get the job offer you deserve.

Handling Offers and Rejections

Even when it comes to handling offers and rejections from companies, it's very important how you handle yourself and how you respond. If you have received an offer, but have interviewed with multiple companies, you might be waiting to hear back from them. If you wanted to wait before accepting/declining the offer extended you to, you can ask for an extension on the offer. Most offers from companies come with a deadline included, likely one to four weeks out from the offer date. While you should try to accept or decline the offer within that window, companies will typically try to accommodate an extension, if needed.

When it comes to declining an offer, it will be in your best interests to do so in a cordial manner and on good terms to keep a line of communication open with the interviewers. It might turn out that you become interested in working for the company a few years in the future or the contacts you made at this company might move to a different company that you're more excited to work for. With this in mind, provide a non-offensive and inarguable reason as to why you're declining the offer. For example, if you're declining an offer from a big company to go work at an environmentally friendly company, let them know why you're declining there offer and that you feel like making an environmental impact on the world is right for you at this current point in time. A big company can't argue with the fact that they likely won't suddenly become an environmentally friendly company in the next few years. Not only does this provide you with an inarguable reason as to why you're declining the offer, but it also helps build bridges to re-interview with the company in a few years when they do create plans to become environmentally friendly.

If you don't hear back from the interviewer immediately, it doesn't mean you're rejected and won't get the job. There are numerous reasons why the decision to hire you could be delayed. The company may have a couple more interviews to go through before making a decision. One of the interviewer's might not have provided their feedback on you to the interview team yet, causing a delay in getting a holistic idea of you. It could also be that they're busy drafting up your offer letter and discussing the details of that offer letter with your future boss! Whatever is the cause of the delay though, try to stay calm. Spend some time outside enjoying nature, or being around friends and family, to get your mind off the interview. If there still is no response from the company after a few days, it's more than acceptable to follow-up, politely, with your recruiter.

If you do end up being rejected by the company, it's not the end of the world. While being rejected is never a fun experience, it doesn't mean that you're not an excellent engineer or that you're not worthy of the position you interviewed for. Just as the mock interviews teach you something about yourself and the interview process, so will you have learned a lot from this interview. It might be that you had an off day, or just don't "test well" with these types of interviews. Whatever the reasoning, it will be in your best interest to reflect on the interview process and try to identify what went wrong. Be sure to remain cordial and responsive by thanking the interviewer for their time, letting them know that you're disappointed with their decision but understand, and ask when you can reapply to the company. While some of the bigger companies won't provide feedback due to their own company policies, it never hurts to ask them something like, "For the next interview, is there anything that you believe would be beneficial for me to work on?".

Once you find out that information, you can focus on improving upon it for the next interview. There are plenty other companies and excellent positions to interview for out in the world and I know you'll find one that you absolutely love. It will take time but stay persistent and you'll be sure to find it. If there is no other company that you want to work for though, it is possible for you to re-apply to the company and try again. Big tech companies like Facebook, Apple, and Google reject numerous candidates during every interview cycle. The hiring managers also realize that these interview processes aren't perfect and can sometime reject good candidates because of it. When previously rejected individuals re-apply again 6-12 months later, companies are typically eager to re-interview and might even expedite the process based off your prior performance. Your initial interview results most likely won't have a major impact on your re-interview so keep studying up and preparing yourself for that next interview. With a little bit of persistence, you may end up getting that offer letter to the company of your dreams.

If you enjoyed the post, be sure to follow me so that you don't miss the rest of this series, where I continue, in detail, on what to do After the Interview, including evaluating and negotiating your offer letter! The links to my social media accounts can be found on my contact page of my personal website. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Day of the Interview

Cory Dorfner — Thu, 08 Sep 2022 16:46:39 +0000

Hello and welcome to the last post in my series, Acing the Interview! If you've already been following along, welcome back! Throughout this series, we have discussed topics like behavioral and technical questions, as well as design patterns, algorithms, and data structures. We also covered areas such as mock interviews and how to discuss your projects. If you are just joining us, I would highly recommend going back to the first post of this series and reading through it all to be prepared for your interview.

Today, we'll be going in depth on what to expect during the day of the interview, once again summarizing some examples from Cracking the Coding Interview¹ with some of my own experiences and insight. If you have the time though, I would highly recommend purchasing the book and reading it through to be prepared for your next interview. We have a lot of information to cover so let's get started with our next topics: The Process and Why.

"Rule number one is, don’t sweat the small stuff. Rule number two is, it’s all small stuff."
-Robert Eliot

Well, you made it! It's the day of your interview and you're panicking. Your nervous, anxious, probably a little queasy, and can't eat, right? I mean, it's understandable. Today's the biggest day of your life that's going to define who you are and who you will be for the rest of your time on this small rock in the vast cosmos, right? Wrong! Today's just another day, where you get to spend some time meeting new people, talk about yourself, and grab yourself a little treat after crushing that technical question.

While interviews can be intimidating, it's important to remember to stay calm, clear-headed, and eat a healthy, balanced meal. The interview process might be difficult, but, if you've read through the prior posts in this series, I hope that you're feeling confident in your skills and know what you will choose to talk about. That's right; never forget that you get to choose what you talk about, not the interviewer. They might try and throw twists and turns your way but remember that there's never a wrong way to talk about oneself. It's who you are and it's gotten you this far in life so it can't be wrong.

The Process

The interview process will likely start off with some friendly introductions and some small talk so that everyone can get comfortable, including the interviewer. From there, the discussion might change focus to your resume, where the interviewer will ask you some questions about your past experience, education, skills, etc. This will be a great time to get into some detailed discussions on the projects that you prepped to discuss. After the deep dive into your projects, the interviewer will likely shift the focus of discussion to the behavioral topics. Remember, this is where you get to talk about who you are as an individual and no one knows you better than yourself.

Be sure to answer those questions in the STAR format and don't worry if there are follow up questions for more information. Just answer them honestly and completely and you'll make the interviewer happy. After a quick discussion about you, the interviewer will be ready to steer this process towards the technical questions. You've had a big smile on your face up until this point. The interview has been great so far, answering the interviewer's questions with ease, laughing with them, and feeling spectacular. They start asking you to solve a technical problem that you've never seen before in all the questions you've practiced for the past several weeks.

The smile slowly fades and you feel the temperature of the room increase 10° as you start to wonder if you're interviewing for the right position. Imposter syndrome begins to set in and you're asking yourself why these questions are even asked, instead of focusing on what the interviewer is asking you. Stop right there and get those thoughts out of your head. This is your time to shine. It's your time to show the interviewer that you know how to dissect a problem, ask questions for clarification, and solve those problems. The practice you've been putting in for the past several weeks on technical questions hasn't been to know the answers to whatever questions you might be asked, but to have a process to follow for any technical question.

In fact, if you do get a question you already know the answer to, you should let the interviewer know. It might seem counterintuitive but you want to show the interviewer you know how to problem solve, not copy an optimal solution from memory. If you don't, they will likely find out as you write out the solution and you might as well walk out of the interview right then and there. On the other hand, telling them will be massive bonus points in your favor and show to the interviewer that your confident and a great cultural fit for the company. Just remember to follow the process laid out in my Technical Questions post and you'll show the interviewer that you're also a great technical fit for the company.

Why?

To better understand why these questions are asked in interviews, it's important to understand that the entire reason for the interview process is to better understand you as a person. They're trying to assess your communication skills, problem-solving skills, technical understanding, coding skills, experience, and cultural fit within the company, all within a tight window of an hour or two. It might be that you're a great candidate but don't do well on these types of questions, or you feel like you could look up the answer if it ever came up during your career. You might feel like you're never going to use a one-sided (meta) binary search tree and, if you did, you would easily be able to look it up. You might also be frustrated that they're having you write code on a whiteboard when you would obviously never be doing that in the real world. While these concerns are valid, you need to look at it from the company's perspective as well.

To a company, turning away good candidates because they didn't get the technical questions correct, while unfortunate, is acceptable to them. They would much rather have that happen then hire someone who does well in an interview but has no technical skill at all. Also, problem-solving skills are critical to a company. If you are not able to show these skills during the technical question portion of the interview, how are they to know you'll start displaying them during your career. Knowledge on basic data structures and algorithms are also incredibly useful. While you might not have to know about a meta binary search tree during your career, it's very difficult to decide if one should be used if you don't even know it's a thing.

Furthermore, while writing code on whiteboards can be frustrating, it lets you focus on what's most important; solving the problem. Almost everyone will have some bugs and/or syntax errors in their code when writing it on a whiteboard. It's more beneficial to focus on the meat of the problem and make sure you write out the correct code for the solution. The whiteboard will also help you present more on what you're writing, explaining your thought process as you go, which is exactly what the interviewer is looking for.

Never forget that you've spent the needed time to prepare for this interview and you're ready for whatever comes your way. All interviews are relative to the other individuals. The interviewer and company are trying to better understand you as a person and your capabilities, as they compare to other individuals that they have interviewed in the past. With that in mind, it's understandable that getting a hard question isn't necessarily a bad thing. It could be just as difficult for you as it was for others and does not make it any more likely that you'll get it wrong. Just stay calm and remember to have fun!

If you enjoyed the post, be sure to follow me so that you don't miss my next series, where I dive deep into what to do After the Interview! The links to my social media accounts can be found on my contact page. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Sources

McDowell, G. L. (2021). Cracking the coding interview: 189 programming questions and solutions. CareerCup, LLC.

Projects & Mock Interviews

Cory Dorfner — Thu, 01 Sep 2022 17:06:10 +0000

Hello and welcome to the fourth post in my series, Acing the Interview! If you've already been following along, welcome back! Throughout this series, we'll be discussing topics like behavioral and technical questions, as well as design patterns, algorithms, and data structures. We will also cover areas such as mock interviews, how to discuss your projects, and what to expect during the day of the interview. If you are just joining us, I would highly recommend going back to the first post of this series and reading through it all to be prepared for your interview.

Today, we'll continue on to the next topic of discussion, once again summarizing some examples from Cracking the Coding Interview¹ with some of my own experiences and insight. If you have the time though, I would highly recommend purchasing the book and reading it through to be prepared for your next interview. We have a lot of information to cover so let's get started with our next topics: Projects & Mock Interviews.

"One important key to success is self-confidence. An important key to self-confidence is preparation."
-Arthur Ashe

Your Projects

One of the best ways for an interviewer to understand your capabilities, work-ethic, and how you handle difficult situations is actually through something you should be very familiar with; your own projects!

During this part of the interview, you will be able to dive deep into the work that you've done in the past, as well as go into any details about difficulties during the project and how you overcame those issues. Utilizing the Interview Prep Grid from my Behavioral Questions post, you can capture some critical information about your past projects to discuss with the interviewer. To prepare to discuss your past projects, pick 2 or three before the interview with the following criteria:

Those projects did more than just teach you something. They had challenging functionality that pushed the boundaries of your skill set
Where the project had challenging functionality, you played a central role in completing that functionality
You are able to talk about those projects at a technical level
The projects are different enough where you won't be repeating topics when discussing them

When discussing those projects during the interview, cover topics like:

challenges you and the team faced,
technical discussions,
mistakes that were made,
what you learned from those mistakes,
how you might do things differently if given the opportunity,
reasoning behind the choices of technologies,
and tradeoffs between those technologies and others that were under consideration.

It's important to be prepared for any follow-up questions that the interviewer may have. It will be difficult to prepare for this, as nobody knows what the interviewer will think of as your discussing the project, but spend some time when reviewing your projects to think of topics that the project didn't cover. This might include things like the scalability of the project, how you would take it from on-prem to cloud-based (or vice-versa), SCM/Project Management tools used, architecture of the project, etc. The more you can talk in depth about your projects and think outside the box to answer the interviewer's questions, the better your skills will be conveyed to the interviewer and the company. One possible way to be better prepared for these questions would be to participate in the Mock Interview process.

Mock Interviews

These types of interviews are a form of training practice to prepare you for the real interview. They simulate the real thing, with a real individual, and actual questions covering the topics from this series. These include behavioral questions, technical questions, data structures, algorithms, design patterns, and your past projects.

Mock Interview Resources:

Pramp: My resource of choice for Mock Interviews. This is a free service where you're matched up with interviewers based on your choice of programming language and can have a one-on-one video session with that individual. You alternate as both the interviewer and the interviewee, allowing you to practice your interview and get a deeper understanding of the process. You can take as many interviews as you would like and can customize each session to focus on a particular area troubling you.
InterviewBit: This is another great and free resource for practicing your interviews. In a similar fashion to Pramp, you're paired with a peer interviewer in an interactive one-on-one session. This interview process is anonymous though with a collaborative real-time code editor and audio calling. You also can have as many mock interviews as you like, alternating between the interviewer and interviewee.
Interview Buddy: This is a paid service, with different tiers depending on how many interviews you would like to do. With this resource, you are matched with an industry expert, averaging 9+ years of experience in interviewing. You also receive an interview scorecard and a recording of the interview so you can go back and better understand what went well and what you can improve upon.
Interviewing.io: Another paid service, starting at $150, where you're paired in an anonymous technical interview with senior engineers from FAANG or other top companies. At the end of the interview, you get detailed, actionable feedback discussing exactly what you need to improve upon to get that dream job

Benefits of a mock interview:

Helps increase your confidence, while reducing your stress and anxiety
Gives you invaluable feedback on your responses to their questions in a low-stress environment
Provides you with the opportunity to improve upon your behavioral-based interview questions and project details before the real interview
The chance for extra practice on technical questions

Be careful with these mock interviewers though. They can become time-consuming and contribute to interview fatigue. It's also difficult to determine if you have a trained interviewer, with the same interview techniques that you might experience during the real thing. If you start to do several of them and try to rehearse your answers as well, the interviewers during the real interview will likely be able to see right through you when you don't go into the necessary details to answer their questions. With that in mind though, these mock interviews are still an important tool to utilize in preparation for your interview. Just be sure to limit it to only a few to avoid being this guy during your interview

If you read my prior blog post in the series, Finding Your First Mentor, you should have a mentor, or mentors, by now. A mentor is another great resource to help you prepare for an interview! They likely have gone through a few of these interviews themselves and could help guide you in some areas of study that they came across, the general interview process, as well as do some mock interviews with you. If you have not been able to read that post yet, I would highly recommend going back to it and getting started on your journey of finding a mentor. Not only would they have knowledge on the interviews that they went through, but they will also be a great fountain of support as you prepare for your interview and wait for the outcome of the process.

If you enjoyed the post, be sure to follow me so that you don't miss the last post of this series, where I go into detail on what to expect the day of so that you too can Ace the Interview! The links to my social media accounts can be found on my contact page. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Sources

McDowell, G. L. (2021). Cracking the coding interview: 189 programming questions and solutions. CareerCup, LLC.

Technical Questions

Cory Dorfner — Fri, 26 Aug 2022 23:08:15 +0000

Hello and welcome to the third post in my series, Acing the Interview! If you've already been following along, welcome back! Throughout this series, we'll be discussing topics like behavioral and technical questions, as well as design patterns, algorithms, and data structures. We will also cover areas such as mock interviews, how to discuss your projects, and what to expect during the day of the interview. If you are just joining us, I would highly recommend going back to the first post of this series and reading through it all to be prepared for your interview.

"Trust yourself. You know more than you think you do."
-Dr. Benjamin Spock

Technical questions are the foundation of most interviews from top tech companies and allow the interviewers to validate the level of skill presented through your resume. While you may be intimidated by this part of the interview, remember that there are rational ways to approach these questions. The best way to identify these rational methods are to practice solving problems. I'm not talking about just reading through problems and solutions, but actually spending time to understand the problem and why the solution is the best approach. Simply memorizing the solutions won't help you during the interview. Regardless of the problem you're trying to solve, it's best to attempt to solve the problem in the following order:

1) Try to solve the problem on your own and be considerate of the time and space complexity with Big O notation
2) Use paper to write your code to get used to coding without things like auto-code completion, syntax highlighting, and debugging
3) Test the general, edge, and corner cases with your code on paper. By practicing this before your interview, you'll be able to breeze through this process in the interview
4) Take the paper code and type it as-is into your computer. If you find mistakes in your code that the IDE fixes, make a note of it to avoid during the next problem and during the interview

When it comes to the technical questions, most interviewers likely won't ask you for specific algorithms but there are some basics that you should know. It will be important that you understand when to use the following topics, how to implement them, and any applicable space and time complexity, especially hash tables:

Data Structures	Algorithms	Concepts
Linked Lists	Breadth-First Search	Bit Manipulation
Trees, Tries, & Graphs	Depth-First Search	Memory (Stack vs. Heap)
Stacks & Queues	Binary Search	Recursion
Heaps	Merge Sort	Dynamic Programming
Vectors / ArrayLists	Quick Sort	Big O Time & Space
Hash Tables

It will also be beneficial to become familiar with the Powers of 2 table. While not vital to memorizing it, you should be comfortable with it to answer questions related to scalability and/or memory limitations

Power of 2	Exact Value (X)	Approx. Value	X Bytes into MB, GB, etc.
7	128
8	256
10	1024	1 thousand	1 KB
16	65,536		64 KB
20	1,048,576	1 million	1 MB
30	1,073,741,824	1 billion	1 GB
32	4,294,967,296		4 GB
40	1,099,511,627,776	1 trillion	1 TB

During the interview, it's important to remember that their technical questions are intended to be difficult and it's okay if you don't get any answer immediately. What's critical during the interview process is that you listen to the directions of the interviewer and ask questions. Depending on your performance, the interviewer's personality, what they're looking for, and the difficulty of the question, they may help more than you expect. Using the following approach in your practice questions, and during the interview, can help you greatly in providing the answer the interviewers are looking for.

As an interviewee, it's important to understand that you don't need to answer every questions correctly or fully. It's a common and dangerous rumor that not doing so means you failed the interview and will not receive the job. There are multiple ways your performance during the interview is evaluated and none of them involve whether you got the answer "right". First, the interviewer looks for how optimized your solution is, the amount of time it took to reach that solution, how many questions you asked, and the cleanliness of your code. Good code is readable, efficient, simple, maintainable, and, most importantly, correct. Second, they evaluate your performance in comparison to the other candidates being interviewed. If you get difficult questions and have a few mistakes along the way, that could be better to the interviewer than a candidate that received easy questions and had no mistakes. Lastly, most questions provided by the interviewers are so difficult that even a strong interviewee might not be able to immediately create the optimal solution. It's okay if it takes you some time to complete the question. What is most important to the interviewer is that you don't give up. Always be eager to step up to whatever question the interviewer asks you to hit it head-on and with excitement.

If you enjoyed the post, be sure to follow me so that you don't miss the rest of this series, where I dive deeper into preparing for the interview, and what to expect the day of, so that you too can Ace the Interview! The links to my social media accounts can be found on my contact page. Please feel free to share any of your own experiences with the interviewing process, general questions and comments, or even other topics you would like me to write about. If this series of posts help you land that dream job of yours, be sure to let me know as well. Thank you and I look forward to hearing from you!👋

Sources

McDowell, G. L. (2021). Cracking the coding interview: 189 programming questions and solutions. CareerCup, LLC.

Forem: Cory Dorfner

Displaying Markdown Posts On Your Gatsby Site

Displaying Your Pages

Fetching Markdown Posts From Your Data Layer

Retrieving From Your GraphQL Data Layer

Creating Pages From Markdown With GraphQL

Creating Your Blog Post Pages

Adding Markdown Posts to your Data Layer

Storing Your Blog Posts

Adding To Your GraphQL Data Layer

Writing Posts In Markdown

Why Markdown?

Formatting Your Content

Heading One

Heading Two

Heading Three

Utilizing YAML Frontmatter

Adding Images and Video

Markdown Cheat Sheets

Creating a Gatsby Blog Site

Why Use Gatsby?

Creating the Gatsby Site

Running Locally

Setting Up GitHub

Deploying to Netlify

Negotiating & Celebrating

Negotiation

Celebration!

Evaluating the Offer

Company Stability

Career Development

Your Happiness

The Financial Package💵💴💶💷

Other Important Factors

Getting the Offer

Thank You Letters

Handling Offers and Rejections

Day of the Interview

The Process

Why?

Sources

Projects & Mock Interviews

Your Projects

Mock Interviews

Sources

Technical Questions

Sources