DEV Community: Djoe Pramono

A Case Study of Date and Time

Djoe Pramono — Sat, 08 Aug 2020 06:34:49 +0000

In IT, dealing with date and time, can be quite challenging. There are a lot of things to consider and things can be quite complicated especially when you need to make changes to an already existing system.

The purpose of this blog post is to surface the importance of thinking about your data type more carefully, especially when you are dealing with date and time.

The Basic

To limit the scope, we would only talk about three data types

DATE, which represents a date
DATETIME, which represents a date with a time component
TIMESTAMP, which represents a date, time and a timezone offset

	Sample
`DATE`	2020-02-23
`DATETIME`	2020-02-23 18:09:18
`TIMESTAMP`	2020-02-23 18:09:18+00

Pretty simple eh? But sometimes some people forgot that only TIMESTAMP can represent an absolute value of time. Depending on the function you use to deal with DATE and DATETIME, it may give you a different absolute value.

Case Study

You live in Melbourne (UTC+10) and you just inherited and are now responsible for a legacy database that stores user registrations in DATETIME format. One day, an account manager asks you to graph the user registrations for the last 1 month.

It sounds like a simple task, but if you have been dealing with data that contains all sort of time value for a long time. There are a few alarms bells that should get you on your toes. Let's pretend that you are having this conversation with your colleague, John.

"Since there is no timezone explicitly stored, the timezone for the data should be UTC or UTC+10. We just need to check the configuration"

Yes, you could check the timezone of your host machine. You also need to check if your database takes the host machine timezone configuration into account, or if it has its own configuration. But it's not that simple.

Since we have been saving the registration in DATETIME you cannot 100% sure that when the data was stored, it was at the DATETIME + the current timezone config. Who knows the timezone settings was changed a month ago. If an event data is stored without representing its absolute value, some of its data is lost.

"We should've stored the registration time in UTC"

This is a bit misleading, UTC is not a type, TIMESTAMP is. 2020-02-23 18:09:18+00 UTC time is the same as 2020-02-24 04:09:18+10 Melbourne time.

Most of the time when people say this, they should've said "we should've stored the user registration in timestamp format". When storing a timestamp, you don't have to always store it in UTC. UTC or UTC+10 are just a display format.

However, choosing the right display format is still important. Especially because, when you pass the data across to the next micro service or from backend to frontend, this DATETIME would be transmitted as a STRING.

"Fine, but it's a common sense to store all time related field in `TIMESTAMP` "

In this particular case, yes. It's good to store an event in TIMESTAMP. In fact, you MUST store an event as a TIMESTAMP. TIMESTAMP has the most information in it and it is meant to represent absolute value of a time. This is very useful if you want to do some analysis later.

But calling to store every time related fields in a TIMESTAMP is a bit of a stretch. There are situations where storing in DATE or DATETIME can be good. Let's start with the most obvious example: storing a user birthday. Should we store this in TIMESTAMP ? Of course not, DATE is better in this case.

How about storing an appointment time? This is a tricky one, but in my opinion we should store it a DATETIME format. Why? Because when making an appointment most people do not care about the timezone. Imagine that you try to make an appointment for tomorrow and there is a day light saving. Even when the timezone change, the date and time of the appointment does not. If the appointment is at 9 AM tomorrow, it will be held at 9 AM tomorrow regardless of the timezone offset.

Sometimes timezone can even change with a very short notice just because a government decide to do so. There are case studies which you can read here. If what you are trying to record doesn't need to care about the timezone, record it in DATETIME

So depending on the situation, we should choose carefully whether we should store data in DATE , DATETIME, or TIMESTAMP.

"Actually for the graph, we would need to break the data into dates. But does that mean we will lose some information?"

Yup, and that is fine. The raw event data can be stored in TIMESTAMP but they can then be converted into DATE for easier processing both by our brain and computer's logic. Losing some information, in this case time and timezone, is not necessarily a bad thing.

Let's say that the user registrations are stored in UTC timestamp, and it needs to be piped into a series of data transformation pipeline. In this case we need to take into account what is the final product that come out in the end. If we need to aggregating the events based on Melbourne dates, then it might make more sense to extract all of the required information from the raw data table into another table and transform the TIMESTAMP into DATE.

Just make sure when transforming TIMESTAMP into DATE, take the timezone into consideration. We must not take a shortcut, where we turn DATETIME into a STRING and truncate it to get the date. Instead we should use the built in functions, to get the DATE value out of TIMESTAMP . The catch though, the syntax might differ from one database to another.

This makes the next step in the pipeline easier, since they only need to worry about DATE and they don't need to do the DATETIME to DATE transformation from then on.

"But then what happen if we actually needs the time component?"

Then we need to go back all the way to the raw data table. We must not grab the data from the derived table.

One thing that could help here is to have a derived table that stores the event in DATETIME. This would help some analysis like how many users registered in the morning. But of course this depends on the business requirement. Keep the full data for as long as we need it. Once we don't, shed things that we don't need to make things lightweight for the next step.

When dealing with a data pipeline, it's better to spend sometime understanding the end-to-end process including the data type used as an input or output at every steps.

Be careful when trying to compare two different types. For example, when the graph that you build for the account managers suddenly need to have a date input where it is used to graph the registration time of a user for a given date. Then when building the solution you should first convert the DATE input into two TIMESTAMP . One representing the beginning of the day and another one representing the end of the day. In other words you need a range. Only when you have the same type between data and input parameter, in this case TIMESTAMP, you can then proceed to the calculation.

Alternatively you can convert all of the registration timestamps into dates and store it in an intermediate table. Then you can use the input without any transformation and the calculation shall proceed in DATE format.

"How about the frontend?"

It is similar. You display the data in a display format that is suitable for its purpose. You can display a date for a birthday, a date and time for a booking time, and a timestamp for an event log.

Please make sure that you use a library to display these especially when the data source is a timestamp in STRING format. Do not ever try to process it yourself. Let the library help you to convert STRING into the appropriate display with the correct timezone settings.

Note that there are two timezone settings that you need to be aware of. One is the user machine settings and another one is the browser settings. These two settings can have different timezone setup

"And that's it I guess"

Yes, that's it for this blog. Thank you for reading and any feedbacks are welcomed.

How to Publish NPM Packages with CircleCI

Djoe Pramono — Mon, 03 Feb 2020 11:21:14 +0000

I had been hearing good things about CircleCI for a while and I was itching to give it a try. Coincidentally, I published an NPM package not too long ago called Falidator, a module to validate TypeScript objects in a more functional way. So I thought, this is it, let's set up CircleCI for it.

So far the experience has been great and their guide is pretty good. Unfortunately some topics were not covered there, and as I set it up, more and more questions popped up along the way. Thus I decided to write a yet another guide/blog about publishing an NPM package with CircleCI. If you are just interested in seeing the final config, feel free to jump straight to the conclusion.

1. Default Sample Config and The First Few Changes

The first few steps are nothing unusual

Create a CircleCI account
Authorise CircleCI to access the Github account,
Go to dashboard.
Click on Add new project,
Select the NPM package repository,
Select Node in the dropdown and we will be greeted with a sample barebone config.

version: 2
jobs:
  build:
    docker:
      - image: circleci/node:7.10

    working_directory: ~/repo

    steps:
      - checkout

      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies-

      - run: yarn install

      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}

      - run: yarn test

This config needs to be copied to .circleci/config.yml and once committed, we can click Start Building, but before that let's make some changes first.

The docker image is quite old. Thankfully CircleCI has a wide range of docker images available for us to use. Most of the time, changing the version to the desired value is enough. But to be certain, we can check here or here for more complete set.

Leave the working_directory as is. This is where the code will be checked out and where the CI process will take place. Since I use npm instead of yarn, I change the run configs to npm install and npm run test respectively.

2. Utilising CircleCI Cache

How about restore_cache and save_cache? As we know, installing npm modules can take a while, especially if we have tons of them. The idea here is to save the state after we install them and re-use that state in the next run. The cache is stored for up to 30 days. It's good enough especially if we have multiple builds in a day with minimal changes to the dependencies.

What happen behind saving and restoring cache

Let's talk about the save_cache first. The config above basically says, save the state of node_modules folder after npm install and give it a key based on the checksum of package.json. This means if our package.json doesn't change the checksum value would stay the same.

During restore_cache, CircleCI would try to get the latest cache that match the key(s). In our settings, we are matching against 2 keys: v1-dependencies-{{ checksum "package.json" }} and v1-dependencies-.

if none match the first key, the cache will then be matched against the second key.
if multiple caches are found, the newest one is used, regardless if it's an exact match or partial match.

At first I was not sure if I should match the cache against multiple keys or just one key. I was afraid that the cache would cause more headache and not worth the time saved. But then, I realised npm install will be run anyway regardless of the cache. It just means that if the cache is older, it may need to install more modules, whatever the cache doesn't have yet.

Immutable cache and how npm install works

Cache in CircleCI are immutable. This means if we want to save a new cache we need to give it a different key. So I was wondering if putting the checksum of package-lock.json instead of package.json is a better idea. Well, let's have a look on how npm install works. From what I know in npm version 6.12, these behaviours exists.

npm install install modules based on package.json and not package-lock.json
npm install does not install the latest version available but rather it matches the version specified in package.json
If package.json and package-lock.json are out of sync, during npm install, npm will attempt to correct package-lock.json based on package.json
To check the installed and available versions of node modules, run npm outdated
To update all of our node modules based on our package.json, run npm update. If we just want to update one module, run npm install <module-name>. Running either of this function will adjust our package.json and package-lock.json if a new version is found.
Symbols in package.json actually have a meaning. ^ means the module can be updated (not installed) to the latest minor version that satisfy the semantic versioning. While ~ means the module can be updated to the latest patch version that satisfy the semantic versioning.

Based on these behaviours, it makes more sense to use the checksum of package.json instead of package-lock.json as package.json seems to be the source of everything node module. But hey check the npm version that you are using, and make sure you are using the latest node version if possible.

Busting CircleCI cache

What's the v1 in the config for? It's actually to bust the cache. Say we want to start fresh without any of the previous cache, we can change the name of cache key from v1 to v2 and there we have it, a clean slate as the key won't match.

At one point I was thinking can I put v1 into environment variable e.g. CACHE_VERSION? After all it seems that it can be configured like so:

    environment:
      CACHE_VERSION: 1
    ...
    steps:
      - restore_cache:
          keys:
            - v{{ .CACHE_VERSION }}-dependencies-{{ checksum "package.json" }} # CACHE_VERSION environment variable can only be set in the web UI settings
            - v{{ .CACHE_VERSION }}-dependencies- # fallback match
      - save_cache:
          paths:
            - node_modules
          key: v{{ .CACHE_VERSION }}-dependencies-{{ checksum "package.json" }}

Turns out we cannot do it this way. Once run, the above config returns the following error

error computing cache key: template: cacheKey:1:4: executing "cacheKey" at <.CACHE_VERSION>: can't evaluate field CACHE_VERSION in type cache.TemplateValues

The job itself runs just fine, but no cache is used. I gave it another try, this time I put set environment variable in the context. Alas it's still not working. From here, I found out that it's not possible to use environment variable for the cache config. So I gave up and reverted everything to what it was without a variable.

3. Jobs and Workflow

Jobs

All right so far we know what a job is. It's basically a series of steps to be run consecutively by CircleCI e.g. checking out code, testing, linting etc. This is the config that I end up having.

jobs:
  test_and_lint:
    <<: *defaults
    steps:
      - checkout
      - restore_cache:
          keys:
            - v1-dependencies-{{ checksum "package.json" }}
            - v1-dependencies- # fallback match
      - run:
          name: Install dependencies
          command: npm install
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}
      - run: npm run test
      - run: npm run lint
      - persist_to_workspace:
          root: ~/repo
          paths: .
  build:
    <<: *defaults
    steps:
      - attach_workspace:
          at: ~/repo
      - run:
          name: Build package
          command: npm run build
      - persist_to_workspace:
          root: ~/repo
          paths: .
  publish:
    <<: *defaults
    steps:
      - attach_workspace:
          at: ~/repo
      - run:
          name: Authenticate with registry
          command: echo "//registry.npmjs.org/:_authToken=$NPM_TOKEN" > ~/repo/.npmrc
      - run:
          name: Publish package
          command: npm publish

You might wonder why we don't run npm run test and npm run lint in one go like so npm run test & npm run lint. This is because by splitting them into two separate steps, we could get more output printed in the CircleCi UI.

What is <<: *defaults? It's basically a shortcut to repeat configs. For example we need to keep repeating the docker image and working directory for each job. That's why we put it in the defaults

defaults: &defaults
  working_directory: ~/repo
  docker:
    - image: circleci/node:12.13

Workflows

Workflow is how one or more jobs are laid out to work together. With workflow, you can set the jobs to be executed in certain order, stopped for approval, or run only if a certain condition are met. For example, we can set a workflow like below to run test_and_lint then run build and publish only if it's master branch.

workflows:
  version: 2
  test:
    jobs:
      - test_and_lint
      - build:
          filters:
            branches:
              only: master
          requires:
            - test_and_lint
      - hold:
          type: approval
          requires:
            - build
      - publish:
          requires:
            - hold

This in turn enables branch protection. When I raise a pull request from my branch to master, there will be a CI check running. We can confirm this by going to the Github repository, Settings --> Branches --> Branch Protection Rules --> Require status checks to pass before merging

4. NPM Token, Tagging and Publishing

NPM Token

Before we can publish, we need to have an NPM token ready. The token is created in https://www.npmjs.com, we need to

Create an account and login
Click on the avatar
Go to Auth Token --> Create New Token
Copy the token into the clipboard
Go back to Circle CI and pick the correct pipeline
Go to Settings --> Build Settings --> Environment Variables
Create a new environment variable NPM_TOKEN and paste the token in

By now you probably have noticed that in the previous topic, we have a step like so

        - run:
          name: Authenticate with registry
          command: echo "//registry.npmjs.org/:_authToken=$NPM_TOKEN" > ~/repo/.npmrc

That's basically adding the token to the home directory, a requirement before we can run npm publish. It baffles me as using environment variables is fine here but not when setting up cache keys.

Tagging

Another requirement before we can run npm publish is that we need to version the package. The version needs to be incremented each time as well. This is tricky because it can be patch, minor, or major version. I was hoping that I could enter the new version during the approval step, but alas I don't think it's possible. Thus I decided that the versioning shall happen locally on my dev machine and I'll push the tag up to GitHub and the workflow will pick up from there

So locally on my dev machine

npm version patch -m "bump to 0.0.7"
git push origin <new_tag>

Meanwhile on the CircleCI, these needs to be setup

workflows:
  version: 2
  generic:
    jobs:
      - test_and_lint: # implicitly all jobs always run on branches, unless filtered.
          filters:  
            tags: # required since `build` has tag filters AND requires `test_and_lint`.
              only: /^v.*/
      - build:
          filters:  
            tags: # required since `publish` has tag filters AND requires `build`
              only: /^v.*/
            branches: # required since we don't want to build on branches, just tags
              ignore: /.*/
          requires:
            - test_and_lint
      - publish:
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/
          requires:
            - build

What's with all of these filters? These are needed because these fundamental behaviours in CircleCI

By default, jobs are running on all branches.
By default, jobs are not running on all tags.

Sounds simple, but combined with the execution order config, we end up with a rather nasty set of filters.

Alternatively, since CircleCI allows us to have more than one workflow, we can set it up like below. We just need to make sure that only one workflow runs at any given time.

workflows:
  version: 2
  on_branch:
    jobs:
      - test_and_lint
  on_tags:
    jobs:
      - test_and_lint:
          filters:
            tags:
              only: /^v.*/
            branches:
              ignore: /.*/
      - build:
          filters:
            tags:
              only: /^v.*/
          requires:
            - test_and_lint
      - publish:
          filters:
            tags:
              only: /^v.*/
          requires:
            - build

Unfortunately as you can see, we still cannot get away from the filters due to how CircleCI works with tags. So which one is better? I slightly prefer the latter, but honestly I don't really like either of them. If any of you have a better solution, please let me know. For more reading, you can refer to here

5. Conclusion

That concludes my experience publishing an NPM package with CircleCI. Some pros:

Easy to setup and decent initial config
Plenty of documentations
Everything is configured through the config file with minimal web UI interaction

But of course there are some things that could be improved

Inconsistent experience dealing with environment variables in command, cache, and context
Workflows can be streamlined better. tags and branches can be made to use similar config pattern
When you login to their website, you randomly get the new or old UI. There's a menu to go back to old UI from new UI. But unfortunately there's no way to go from old UI to new UI.

Overall CircleCI is a pretty good. The downsides are there, but they are not critical. CircleCI is easy to use and perfect for a small open source project like mine. If you'd like to see the full config, it's available in the GitHub repo. And that's it, thank you for reading. Feedbacks are welcomed :)

Gatsby One Pager

Djoe Pramono — Sun, 05 Jan 2020 07:49:16 +0000

How to build a Gatsby site? Why the guides online are so fragmented? Isn't there a one pager guide for Gatsby with a working example? Well you have found it. This one page guide would help you build a static site with:

[x] Markdown based blog post
[x] Client side search
[x] Pagination
[x] Code Highlighting
[x] Google Analytics
[x] Responsive design, well we won't really cover this but you can have a look at the Github code.

See it in action on https://www.codeallnight.com or take a peek at the git repo. Feel free to build on top of it. Empty the src/posts folder and start write your own.

1. Prerequisite

First thing first, install gatsby-cli and clone the repo. Cloning the repo is optional, but isn't it always nicer to have a code example at your disposal?

npm install -g gatsby-cli
git clone git@github.com:djoepramono/code-all-night.git
cd code-all-night
npm install
gatsby develop -H 0.0.0.0

Running gatsby develop only, makes the site only avaiable on the host computer via localhost. But sometimes you want to make it accessible to your local network, so that you can test your site with your mobile phone. For this, you need the -H 0.0.0.0.

Each section on this guide might depends on a specific npm package. These packages are already included in the repo package.json. If you don't clone the repo and start fresh instead, make sure you install them.

2. Markdown Posts

Markdown files can be made into pages in Gatsby with the help of gatsby-transformer-remark

Put your markdown files into src/posts. There are some examples there already. Next up, you need to put the following entry into gatsby-node.js

exports.createPages = async ({ actions, graphql, reporter }) => {
  const { createPage } = actions
  const blogPostTemplate = path.resolve(`src/templates/post.js`)
  const result = await graphql(`
    {
      allMarkdownRemark(
        sort: { order: DESC, fields: [frontmatter___date] }
        limit: 1000
      ) {
        edges {
          node {
            frontmatter {
              title
              date(formatString: "DD MMMM YYYY")
              author
              path
            }
            excerpt
            timeToRead
          }
        }
      }
    }
  `)
  // Handle errors
  if (result.errors) {
    reporter.panicOnBuild(`Error while running GraphQL query.`)
    return
  }

  // Create post pages
  result.data.allMarkdownRemark.edges.forEach(({ node }) => {
    createPage({
      path: node.frontmatter.path,
      component: blogPostTemplate,
      context: {},
    })
  })
}

The code above is utilising Gatsby's createPages API to create a static page for each markdown posts. Each of this markdown files can be enriched with frontmatter, a set of key value pair that exists on top of each markdown file.

Under the hood, Gatsby is using GraphQL, which you can read more here . It also provides you with graphical UI client at http://localhost:8000/__graphql. It's a pretty good tool to explore what queries are available to use.

And if you want to change the template, you can change src/templates/posts. It's a React component, so go nuts if you are already familiar with React.

All right, by now you should know what createPages does.

3. Client Side Search

Before we are talking about pagination, let's talk about search first. I am using js-search to power the search page. The concept is quite simple, during the post pages creation, we also want build the context for the search page. If you want to learn more, have a look at here.

In your gatsby-node.js's createPages, put the following code

const posts = result.data.allMarkdownRemark.edges.map(transformRemarkEdgeToPost)

createPage({
  path: "/posts/",
  component: path.resolve(`./src/templates/clientSearch.js`),
  context: {
    search: {
      posts,
      options: {
        indexStrategy: "Prefix match",
        searchSanitizer: "Lower Case",
        TitleIndex: true,
        AuthorIndex: true,
        SearchByTerm: true,
      },
    },
  },
})

where transformRemarkEdgeToPost is just simple data transformation as follows

const transformRemarkEdgeToPost = edge => ({
  path: edge.node.frontmatter.path,
  author: edge.node.frontmatter.author,
  date: edge.node.frontmatter.date,
  title: edge.node.frontmatter.title,
  excerpt: edge.node.excerpt,
  timeToRead: edge.node.timeToRead,
})

The search here is a client side search. Meaning it doesn't talk to the server during the search as the javascript client already know the whole context, which is passed into the pages via createPages. This makes the search very responsive. Try it out!

Now you hopefully you know the concept of passing data into pages via context. As for the templates, it's using a custom React class component, as it will need to use state. It's available in the repo at src/components/clientSearch.

4. List Page with Pagination

Next up we are going to create a list page with pagination. The default Gatsby guide is good enough, but I went slightly further.

Put the following into gatsby-node.js's createPages function

const postsPerPage = config.noOfPostsPerPage
const noOfPages = Math.ceil(posts.length / postsPerPage)
Array.from({ length: noOfPages }).forEach((_, i) => {
  createPage(
    createListPageParameter(
      `/list-${i + 1}`,
      "./src/templates/list.js",
      posts,
      postsPerPage,
      i
    )
  )
})

Basically, it goes through all of your posts and create pages that contains a subset of your overall posts. Meanwhile createListPageParameter is yet another function that transform data

const createListPageParameter = (
  routePath,
  templatePath,
  posts,
  noOfPostsPerPage,
  currentPageIndex
) => ({
  path: routePath,
  component: path.resolve(templatePath),
  context: {
    limit: noOfPostsPerPage,
    skip: currentPageIndex * noOfPostsPerPage,
    noOfPages: Math.ceil(posts.length / noOfPostsPerPage),
    currentPage: currentPageIndex + 1,
  },
})

Now since we want to have the index page / landing page to be the same with the list page. We need to create it the same way in gatsby-node.js.

createPage(
  createListPageParameter(
    "/",
    "./src/templates/list.js",
    posts,
    postsPerPage,
    0
  )
)

So far so good, now as you can see the context passed contains things like limit, skip, noOfPages, and currentPage. These metadata are then used in the template to invoke yet another GraphQL query as seen in the src/templates/list.js

export const listQuery = graphql`
  query listQuery($skip: Int!, $limit: Int!) {
    allMarkdownRemark(
      sort: { fields: [frontmatter___date], order: DESC }
      limit: $limit
      skip: $skip
    ) {
      ...MarkdownEdgesFragment
    }
  }
`

This result of the call is then available in the bespoke React component's props.data.allMarkdownRemark.edges

What do learn here? It's possible after you passed some metadata to the page through context, e.g. skip and limit you can use them to make another GraphQL call. This is a powerful concept which allows you to add more data into the page.

But what is ...MarkdownEdgesFragment? It's GraphQL fragment. But it behaves slightly differently in Gatsby.

5. Fragment

For the better or worse, Gatsby is using their own version of GraphQL. That's why on the file where a GraphQL query is executed, usually there's this import

import { graphql } from "gatsby"

Gatsby handles GraphQL fragments in slightly different way than standard GraphQL. Normally GraphQL fragments are imported, interpolated at the top of the GraphQL query and then used by spreading it. In Gatsby's GraphQL, the first and second steps are not needed as Gatsby crawls through all of your files and makes all fragments available in the query automagically.

Let's look back at src/templates/list.js

export const query = graphql`
  query HomePageQuery {
    allMarkdownRemark(sort: { fields: [frontmatter___date], order: DESC }) {
      ...MarkdownEdgesFragment
    }
  }
`

MarkdownEdgesFragment is not explicitly imported/interpolated anywhere and yet it can be used in the GraphQL query. It's magic.

6. Styled Components

Gatsby by default uses CSS Modules. However I prefer to use Styled Components. There's a gotcha though. From my experience, sometimes in production the produced css is just missing even though everything is fine when run via gatsby develop. This happens most often on the first page load.

How did I fixed it? Apparently I was missing a module. So make sure that these 3 are installed.

npm install --save gatsby-plugin-styled-components \
  styled-components \
  babel-plugin-styled-components

and make sure gatsby-config.js has the following

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-styled-components`,
      options: {
        // Add any options here
      },
    },
  ],
}

7. Code Highlighting

To highlight code in the posts, I found PrismJs seems to be popular and easy enough to use. Based on this tutorial, you can either use gatsby-remark-prismjs or set it up manually like so:

Install the dependencies from the command line

npm install --save prismjs \
  babel-plugin-prismjs \

Set .babelrc in the root folder of your project. Make sure that the languages that you want to highlight are included in the config.

{
  "presets": ["babel-preset-gatsby"],
  "plugins": [
    ["prismjs", {
      "languages": ["javascript", "css", "markup", "ruby"],
      "plugins": ["show-language"],
      "theme": "tomorrow",
      "css": true
    }]
  ]
}

Lastly, make sure that you invoke it on your pages/templates, i.e. src/templates/post.js

useEffect(() => {
  Prism.highlightAll()
})

8. Google Analytics

A website without any tracking is not complete and we are implementing Google Analytics via Gatsby Plugin GTag.

It's reasonably simple to use. Add the following to gatsby-config.js.

module.exports = {
  plugins: [
    {
      resolve: `gatsby-plugin-gtag`,
      options: {
        trackingId: "YOUR_GOOGLE_ANALYTICS_ID",
        head: true,
        anonymize: true,
        respectDNT: true,
        pageTransitionDelay: 0,
        sampleRate: 5,
        siteSpeedSampleRate: 10,
        cookieDomain: "codeallnight.com",
      },
    },
  ],
}

There are several important things here.

Google Tag Assistant prefer the tracking script to be put in <head>, thus head:true
The plugin must be put as the first plugin in plugins array. I missed this at my first attempt.

Originally I tried to follow this default guide but it did not work, as I couldn't see any traffic on Google Tag Assistant. It simply says No HTTP response detected. Once I switch to Gatsby Plugin GTag, I can see the tracking data on Google Analytics real time. I am not 100% certain why but it's probably related to analytics.js being deprecated

9. Epilogue

And there you have it, one pager guide for Gatsby. It's quite long, but it reflects my time spent in building my personal website at https://www.codeallnight.com. Maybe it's just that I'm not experienced enough, but there are quite a number of things to implement before I'm finally happy with my site.

If you have any feedback, feel free to hit me up on Twitter and as always thanks for reading.