DEV Community: egghead.io

Content Modeling and Data Design with Sanity.io

Joel Hooks 🌩 — Sun, 07 Feb 2021 05:00:25 +0000

Data is the bedrock of most applications and challenging to get right. It's
vital for the long-term health of an application to have data that is
understandable, flexible, and relevant to users.

This article discusses how we are reconsidering content modeling at a data level for egghead to allow for more flexible collaboration and design.

Where we were at when this started

We have two APIs available that access the same underlying postgres database. One is a REST API that has nice hypermedia capabilities and is pretty slow built on top of jbuilder. The other is a well-formed GraphQL API that is much more performant and provides immediate and direct access to slices of the data we want.

Both of these APIs are fairly 1:1 with the underlying database and define what I've come to look at as a "hyper specified" content model that got the job done, but has been a serious constraint that we've had to live with for many years 😅

Both of these APIs take 30-40 minutes to deploy and require fairly deep knowledge of Rails, GraphQL, and Ruby.

The deeply technical API layer provides a massive barrier to entry, and because everything is very closely tied to the database changes can have rippling side-effects that were never intended

Resources and Collections

When egghead was a sparkling fresh app I started out modeling what was obvious at the time.

Lessons: people come to egghead to watch lessons, not videos.
Series: sometimes people want to watch a series of lessons (not videos)

Later we added Playlists, called them collections, and then decided that both a series and a playlist were actually courses. lol

Fundamentally what we are dealing with are resources and collections, where a collection is just a resource with a list of other resources referenced.

Where we want to be

We want to build a digital garden. We want to curate, update, associate, and present relevant resources to users so that they can quickly find what they need and reach the outcomes they desire.

For us, this requires a "metadata" layer that sits above the APIs without a rigid schema or the need for deep levels of technical know-how to operate.

For years we've done this by creating various JavaScript/JSON data structures in flat files that get compiled in with the application.

You can see an example here where we keep various metadata about egghead courses. Another example is this one that describes the data for our curated home page.

This honestly isn't bad, but it's still tedious, error-prone, and requires us to use IDEs as UI for updating content. Not ideal, but very flexible.

Content Modeling with Sanity.io

After exploring several alternatives and living with the flat json files for years, a product has emerged that checks most of the boxes that we need. Deep flexibility. Ease of use. An incredibly nice authoring experience and a welcoming team and community.

Sanity.

What first stands out to me about Sanity is that it installs into your project via their CLI (command line interface). This was so different to me that it was hard to understand at first, but once I got the CLI installed with a default starter dataset, it started to make sense.

Once I read the docs and started to explore the flexible potential it really clicked.

The core atom of our emerging system is the resource type. You can see how it evolved here on Github if you're interested.

A resource as a type property. It can describe any of the content types that we deal with at egghead, and we can always add additional types as needed. Types are resources like podcasts, videos, courses, collections, and features.

We are able to sync our existing database with Sanity, so all of the items that are in postgres are represented in Sanity. It could potentially replace a huge portion of our data needs, but for now, we are keeping them synced manually.

Modeling resources, not layout

What's stood out as important for us is that we want to create a robust resource model that describes and augments core content. We want it to be flexible and longer-lived than a typical layout and withstand heavy changes to design and presentation.

We want our data to work in different contexts across our app (and beyond) so we are intentionally avoiding any layout concerns in the content model. The data describes what, not where, the content will ultimately be displayed.

This means that instead of modeling pages, we are describing content and layering on supporting assets and metadata that allow us to choose content that's appropriate and relevant, when and where you need it.

A Practical Example

To illustrate, on the egghead homepage we present a large banner that showcases a resource, a new course, an evemt, etc

It's represented in home-page-date.ts as a property called jumbotron

{
  id: 'jumbotron',
  title: 'Introduction to Cloudflare Workers',
  byline: 'new course',
  description:
    `Follow along with Kristian Freeman as you build a localization engine that
     renders data based on the Edge location nearest to the application's user.`,
  image: '/banner.jpg',
  path: '/playlists/introduction-to-cloudflare-workers-5aa3',
  slug: 'introduction-to-cloudflare-workers-5aa3',
  instructor: {
    name: 'Kristian Freeman',
    slug: 'kristian-freeman',
    path: '/q/resources-by-kristian-freeman',
    twitter: 'signalnerve',
    image: '/headshot.jpg',
  },
},

This works pretty well. When we want to swap it out we just go in and enter new data. It's not great though, and requires a deploy.

When I sat down to model this in Sanity, the first impulse was to create a document called "Home Page Jumbotron". Then I can query Sanity using their GROQ query language on the server and create a similar data structure to render the header graphic:

export const getServerSideProps: GetServerSideProps = async ({res, params}) => {
  const load = async () => {
    const data = await sanityClient.fetch(groq`
      *[slug.current == 'home-page-jumbotron'][0]{
        name,
        title,
        description,
        summary,
        byline, 
        meta,
        path,
        'slug': resources[][0]->_id,
        'instructor': collaborators[]->[role == 'instructor'][0]{
          title,
          'slug': person->slug.current,
          'name': person->name,
          'path': person->website,
          'twitter': person->twitter,
          'image': person->image.url
        },
        'background': images[label == 'background'][0].url,
        'image': images[label == 'badge'][0].url,
      }
  `)
    return data
  }

  const resource = await load()

  res.setHeader('Cache-Control', 's-maxage=1, stale-while-revalidate')
  return {
    props: {
      resource,
    },
  }
}

This is getting better. It produces the same data structure, and we can now live-update the header component inside of Sanity Studio and don't need to redeploy. While that is creating documents that are tied to specific pages, it isn't modeling data for layout and gives us a ton of flexibility.

If this is your first time seeing GROQ it might look strange, but it's actually a fascinating and relatively simple way to query data. Here's the official GROQ Cheat Sheet that gives a great overview.

Taking that a step further I can consider replacing the entire home-page-date.ts with a loader that looks like this using what is referred to as an "outer reflection" in Sanity's GROQ query language:

import {sanityClient} from 'utils/sanity-client'
import groq from 'groq'

export async function loadHomePageData() {
  const slugs = {
    jumbotron: 'home-page-jumbotron',
  }
  const data = await sanityClient.fetch(
    groq`
      {
        'jumbotron': ${jumbotronQuery},
      }
  `,
    slugs,
  )

  return data
}

const jumbotronQuery = groq`
*[slug.current == $jumbotron][0]{
  name,
  title,
  description,
  summary,
  byline, 
  meta,
  path,
  'slug': resources[][0]->_id,
  'instructor': collaborators[]->[role == 'instructor'][0]{
    title,
    'slug': person->slug.current,
    'name': person->name,
    'path': person->website,
    'twitter': person->twitter,
    'image': person->image.url
  },
  'background': images[label == 'background'][0].url,
  'image': images[label == 'badge'][0].url,
}
`

This approach would allow me to add a structured query to load the data for each section, feature, and call to action (CTA) on the home page of the site and give the team the ability to update, curate, and tend our collaborative digital community garden without requiring a deploy of the front end.

If we want to change the design or switch out the data we are loading, that starts to become simpler as well.

We are able to layer assets on top of our resources with ease and allow our designers and editorial team members to have more collaborative creative control over the resulting page.

Where we are headed...

This is a great start. Sanity has a lot of potential and we haven't even begun to scratch the surface. We are going to be tuning our content model and importing more data first. Then we will start to explore Sanity's Structure Builder, which can be used to design content pipelines and workflows that give us even more flexibility in our digital gardening process.

Having a bespoke, contextual, lovely content authoring tool at our disposal is exciting, and I'm looking forward to digging in more.

Questions? Please feel free to ask on twitter!

TailwindCSS Dark Mode in Next.js with Tailwind Typography Prose Classes

Joel Hooks 🌩 — Wed, 27 Jan 2021 02:16:37 +0000

When you release a modern website one thing is clear... users expect dark mode out of the box. They aren't interested in your excuses. They don't care about the time it will take to implement, they just want dark mode. Now. 😅

What you will learn about in this article.

This article is going to explain in clear steps how to add TailwindCSS native
dark mode to a Next.js site, including the TailwindCSS Typography plugins prose
classes.

There is an assumption that you have a working knowledge of both TailwindCSS and
Next.js and a site that you'd like to implement a toggle between a dark and a
light theme.

To do this, you will use:

Next.js: A React "meta-framework"
TailwindCSS: A utility-class system for styling web applications
TailwindCSS Typography: A plugin that provides a set of prose classes that provide consistently nice looking typographic defaults (useful for Markdown files, for instance)
next-themes: React Hooks based utility library for Next.js that let's you switch themes in your application.

Motivation for dark mode

With a recent relaunch of egghead.io there were daily requests for a "dark mode" for
the website. In the past our site had had a default singular dark theme, meaning a theme where the background is dark, and the text is light. The new site presented a solid
white–incredibly bright–theme that wasn't very pleasant for many users viewing experience.

Bright themes are particularly aggravating when you are working in a dark room, and
some users have vision troubles that are exacerbated by light or dark themes. This
means that the ability to choose between one or the other is often critical for some
users' ability to use the site at all.

Getting Started

If you don't have a Next.js + TailwindCSS site to work from, here's a github branch
from my Next.js Tailwind Starter that is "pre-dark mode" that you can use.

From this point we need to update some configuration files.

The Tailwind Config

tailwind.config.js is in the root directory of the project and provides TailwindCSS
the information it needs to correctly run in your environment. The TailwindCSS team
has done a great job giving us sensible defaults, but almost every project will have
specific needs and requirements that require custom configuration.

module.exports = {
  purge: ['./src/**/*.tsx'],
  theme: {
    typography: (theme) => ({}),
    extend: {},
  },
  variants: {},
  plugins: [require('@tailwindcss/typography')],
}

This config is almost as basic as it can be. Since you are using the TailwindCSS Typography plugin, this config let's TailwindCSS know that you want to use it. The config also has a purge property that provides an array o globs letting TailwindCSS know which files it should analyze for purging extra classes not used in your application. If we didn't configure purging, the result would be every single class TailwindCSS has to offer being shipped with our application.

That might not be the end of the world, but it is a lot of extra bundle size that your users will never actually need.

So we purge.

After the purge configuration the see the theme, variants, and plugins. Right now these sections are sparse, but that's about to change.

Enabling Dark Mode in TailwindCSS

Enabling dark mode in TailwindCSS is effectively the flip of a switch:

module.exports = {
  darkMode: 'class',
  purge: ['./src/**/*.tsx'],
  theme: {
    typography: (theme) => ({}),
    extend: {},
  },
  variants: {},
  plugins: [require('@tailwindcss/typography')],
}

By adding darkmode: 'class' to the config, you've instructed TailwindCSS to include all of the CSS utility classes for dark mode. This enables a dark variant that you can now add as classes to your React elements like className="bg-white dark:bg-gray-900" and the correct class will be provided when dark is active on your html element.

To test out dark mode in the Next.js app, you'll need to make a couple of changes to the /src/_document.tsx source file that is used to provide custom document structure to the Next.js application.

<Html className="dark">
  <body className="dark:bg-gray-800">
    <Main />
    <NextScript />
  </body>
</Html>

First we add the dark class to the Html element. This enables the dark mode for the entire application. Then we add dark:bg-gray-800 to the body element to provide a dark background for the Next'js application when it is in dark mode.

yarn dev will run the application, and you should see a dark background. Delete dark from the Html elements className and your app should refresh with a default white background.

We've achieved dark mode! 🌑

Obviously your users aren't going to change source code to enabled toggling, so the next step is to add a button that will toggle the dark mode on and off.

Creating a theme with next-themes and React Hooks

Technically your app is going to have two themes: light and dark

Potentially your app could have many themes up to and including hot dog stand. That's amazing if you want to provide your users with that level of flexibility! lol

There are several relatively complicated ways you might approach the problem of toggling themes. As with many things in the React.js and Next.js world, somebody else has already solved the problem very well, and for this the community favorite is next-themes which promises (and subsequently delivers) a "perfect dark mode in two lines of code".

Yes please.

yarn add next-themes

Open /src/_app.tsx

function MyApp({Component, pageProps}: AppProps) {
  return (
    <>
      <DefaultSeo {...SEO} />
      <Component {...pageProps} />
    </>
  )
}

Now, in /src/_app.js import the ThemeProvider and wrap your application Component with it:

import {ThemeProvider} from 'next-themes'

function MyApp({Component, pageProps}: AppProps) {
  return (
    <>
      <DefaultSeo {...SEO} />
      <ThemeProvider>
        <Component {...pageProps} />
      </ThemeProvider>
    </>
  )
}

So far, nothing has really changed in the app. Since dark is hard-coded in your _app.tsx and there is no mechanism to toggle the mode, your application is stuck in dark mode.

Go ahead and delete the className from the Html element:

<Html>
  <body className="dark:bg-gray-800">
    <Main />
    <NextScript />
  </body>
</Html>

Your application will reload, and will once again have the default white background that got us into this situation in the first place.

Toggling between light and dark modes with just a click

Open /src/pages/index.tsx:

export default function Home() {
  return (
    <div>
      <h1 className="text-3xl text-pink-500" css={{backgroundColor: 'teal'}}>
        Welcome to Your App
      </h1>
    </div>
  )
}

This is relatively simple React page component that is located at the root of the site. It defines a div as a container and an h1 element with a bit of welcome text and some questionably stylish classes applied.

To make the toggle work, we need to import a hook from next-themes, manage a little piece of state, and wire it all together in a button.

First, import the useTheme hook:

import {useTheme} from 'next-themes'

export default function Home() {
  return (
    <div>
      <h1 className="text-3xl text-pink-500" css={{backgroundColor: 'teal'}}>
        Welcome to Your App
      </h1>
    </div>
  )
}

Now call the useTheme hook to gain access to theme and setTheme.

import {useTheme} from 'next-themes'

export default function Home() {
  const {theme, setTheme} = useTheme()
  return (
    <div>
      <h1 className="text-3xl text-pink-500" css={{backgroundColor: 'teal'}}>
        Welcome to Your App
      </h1>
    </div>
  )
}

Now, add a button element with an onClick handler to use as a toggle:

import {useTheme} from 'next-themes'

export default function Home() {
  const {theme, setTheme} = useTheme()
  return (
    <div>
      <h1 className="text-3xl text-pink-500" css={{backgroundColor: 'teal'}}>
        Welcome to Your App
      </h1>
      <button onClick={}>toggle</button>
    </div>
  )
}

To toggle, we want to check and see what the current theme is, and set the appropriate theme based on that:

import {useTheme} from 'next-themes'

export default function Home() {
  const {theme, setTheme} = useTheme()
  return (
    <div>
      <h1 className="text-3xl text-pink-500" css={{backgroundColor: 'teal'}}>
        Welcome to Your App
      </h1>
      <button onClick={() => setTheme(theme === 'dark' ? 'light' : 'dark')}>
        toggle
      </button>
    </div>
  )
}

A couple of things to note are:

The button is completely unstyled and doesn't really look like a button
clicking it does absolutely nothing 😭

The first issue just means you need to use tailwind to make the button look awesome, but the second issue is more concerning and you need to address that to get this toggle working at all. It's a multi-faceted problem resulting from how we've configured dark mode.

In the tailwind.config.js you set darkMode with the class option. This configuration property also has a media option that uses the prefers-color-scheme media of modern browsers and operating systems to look at how the user has configured their system. The class option, however, means we can select and toggle the mode. In fact, you could delete the button, set the darkMode config to media and call it a day.

For many use cases the class config is the most flexible and is preferred.

In /src/_app.js you need to tell the ThemeProvider to use the class attribute:

<ThemeProvider attribute="class">
  <Component {...pageProps} />
</ThemeProvider>

Let your app compile, refresh the page, and start toggling. Back and forth. Dazzling. A fully configured dark mode powered by Tailwind CSS in a Next.js app.

The future is now.

Solving some problems with our TailwindCSS config and dark mode

This is great. It works!

There are still a couple of problems to solve:

Build times are slooooooow (on large projects they can also completely run out of memory)
If you visit /hi - an mdx file rendered and presented with TailwindCSS Typography prose class, you notice that the text is black.

Slow builds with TailwindCSS Dark Mode and Next.js

This is a known problem that is at the core a webpack issue and both the Next.js team and the TailwindCSS team are aware of it. Basically, TailwindCSS + Dark Mode is a massive CSS file, and webpack hates building source maps for massive CSS files.

👋 If you know how to solve this please hit me up on{' '}
Twitter

For our application this is a huge hassle and requires that we run the development environment with additional memory allocated to node:

NODE_OPTIONS=--max-old-space-size=4048 yarn dev

Ultimately it's a small price to pay for dark mode, and will eventually be fixed upstream. It was also alleviated a bit for us by turning on purging for the dev environment in tailwind.config.css

module.exports = {
  darkMode: 'class',
  purge: {
    enabled: true,
    content: ['./src/**/*.tsx'],
  },
  theme: {
    typography: (theme) => ({}),
    extend: {},
  },
  variants: {},
  plugins: [require('@tailwindcss/typography')],
}

These options require purge to be an object instead of an array. We set enabled: true and content: ['./src/**/*.tsx'] which is the same array as we had previously set purge to.

Purging CSS means that TailwindCSS tries it best to analyze the source that you've pointed to in content and not remove any CSS classes that you've used.

You can test it now by running the following commands:

yarn build
yarn start

Controlling the Purge

If all is well, your app should function as expected. If toggling dark mode doesn't work or appear to do anything, it could mean that the dark CSS class variants have been stripped from your application because the dark class isn't assigned to a className by default.

In this example, that doesn't appear to be happened, but if you encounter this in your application where it works in development, but not in production you might need to add a safelist property to your tailwind.config.js purge options:

module.exports = {
  darkMode: 'class',
  purge: {
    enabled: true,
    content: ['./src/**/*.tsx'],
    options: {
      safelist: ['dark'], //specific classes
    },
  },
  theme: {
    typography: (theme) => ({}),
    extend: {},
  },
  variants: {},
  plugins: [require('@tailwindcss/typography')],
}

The safelist allows you to specify classes that TailwindCSS will always keep around for you and not purge. At the time of this writing the only documentation for this is buried in some Github issue comments.

Dark Mode for TailwindCSS Typography Prose Classes

By default TailwindCSS Typography doesn't support dark mode. Prose classes are also notoriously challenging to customize. You can't just set a className instead you need to override defaults in your tailwind.config.js:

module.exports = {
  //...
  theme: {
    extend: {
      typography: (theme) => ({
        dark: {
          css: {
            color: 'white',
          },
        },
      }),
    },
  },
  //...
}

In the theme section of the config you a typography property under extend which allows us to extend the @tailwindcss/typography plugin. The configuration property takes a function that passes in the theme and returns an object that extends the theme for that plugin.

It makes me a little dizzy to think about, but the extension we return adds a dark property with a css property that sets color: 'white'

Now, in /src/layouts/index.tsx on line 28 you'll find the prose class being applied to a div. This file is the default layout that mdx files use in your application.

<div className="prose md:prose-xl max-w-screen-md">
  {title && <h1 className="text-xl leading-tight">{title}</h1>}
  {children}
</div>

Now add dark:prose-dark and dark:md:prose-xl-dark to the className of the div:

<div className="prose md:prose-xl dark:prose-dark dark:md:prose-xl-dark">
  {title && <h1 className="text-xl leading-tight">{title}</h1>}
  {children}
</div>

Refresh...

Nothing happens. No changes. There's another step in the tailwind.config.js in the variants config add typography: ['dark']:

module.exports = {
  darkMode: 'class',
  purge: {
    enabled: true,
    content: ['./src/**/*.tsx'],
    options: {
      safelist: ['dark'], //specific classes
    },
  },
  theme: {
    typography: (theme) => ({}),
    extend: {
      typography: (theme) => ({
        dark: {
          css: {
            color: 'white',
          },
        },
      }),
    },
  },
  variants: {
    typography: ['dark'],
  },
  plugins: [require('@tailwindcss/typography')],
}

Voíla! You should see the body text of http://localhost:3000/hi become white as configured.

There are a lot of options for customizing the look and feel of your markdown. If you want some inspiration, Lee Rob has done a wonderful job for his personal site and you can check out the config here.

Summary

Users want dark mode and to set it up with TailwindCSS and Next.js it requires some configuration and basic state management. What you've done so far is just a start, and there is a lot of room to expand on the styles to make your application shine.

If you'd like to look more closely at a larger scale full-featured application (the one you are looking at right now in fact), you can checkout the repository for the egghead website on Github.

Here's the end state of the project you've been working on in this article on Github as well.

If you've got any questions, please ask them on Twitter!

There's also an edit link below if you'd like to send any corrections or updates directly ⭐️

Illustrated Notes on Web Security Essentials

Maggie Appleton — Mon, 30 Nov 2020 18:03:02 +0000

Between IoT botnet attacks, Bitcoin ransomware, and the weekly cadence of high-profile data breaches, doing anything on the internet feels like playing Russian Roulette.

And that's just for normal people using it.

As a developer, you're partially responsible for protecting all those normal people from the horrors of whatever LulzSec are up to right now. The least you can do is make sure your website isn't an accessory to their nefarious activities.

So what does the current landscape of internet risk looks like. How, exactly, is LulzSec going to hack into my mainframe in 2020?

Here's my illustrated notes from Mike Sherov's egghead course on 'Web Security Essentials' that should give you a big picture overview of what to should look out for.

Turns out there's a small set of fairly well-known and easy to defend attacks that we can protect ourselves from:

Man in the Middle (MITM)
Cross-Site Request Forgery (CSRF)
Cross-Site Scripting (XSS)

Shielding yourself from these three is a great starting point. It's at least enough to keep the script kiddies out.

Keeping out this trio of attacks will go a long way. Thankfully, you do not have to brave the black hat darkness alone.

Mike Sherov's course covers a whole range of ways to mitigate your risk and protect against them.

👁‍🗨 If these are hard to read, you can download a free high-res PDF version on the course itself.
Dev.to limits image sizes a lot and it's hard to make it readable on here. Apologies!

WTF is Rust? The Illustrated Notes

Maggie Appleton — Mon, 23 Nov 2020 16:46:55 +0000

The Rust programming language keeps winning the middle-school popularity contest of the developer world: "most loved" on Stack Overflow surveys.

So, what's this Rust thing and why is everyone enamoured?

Let's explore...

This happy balance Rust manages to strike – between speed, control over memory, and human-friendliness is what makes it so popular.

The kind of programmes you can write with Rust would otherwise be made in a language like C or C++. A lot of developers find the C-suite challenging to work with, so this friendly alternative is very welcome!

It's got the Goldilocks Effect going on. Not too slow, not too dangerous, not too complicated – just right.

The Rust community is also infamous for being welcoming, open, and encouaging to newcomers. Fostering that kind of culture is very likely why it's gained so much traction in the last few years.

Anyone who hangs out in Developer World long enough realises frameworks and languages are identities much more than they're tools. You belong to Team React, or Camp Python, or the Rust Crew.

And no one wants to join a bunch of judgey gatekeepers.

I've just done a sweeping and completely incomplete overview of Rust here. But it's enough to point you in the right direction.

While researching and making these I watched Pascal Precht's egghead course that shows you how to Write Your First Rust Programme

It's free 20 minute course that shows you all the basics.

👁‍🗨 If these are hard to read, you can download a free high-res PDF version on the course itself.
Dev.to limits image sizes a lot and it's hard to make it readable on here. Apologies!

Illustrated Notes on Custom React Hooks

Maggie Appleton — Fri, 20 Nov 2020 10:21:09 +0000

Illustrated notes on Joe Previtte's course on Building Custom React Hooks on egghead

The Basics of React Hooks

If you're not up to speed on React hooks, here's a very quick overview...

Hooks let us do more than just display static UI components. They give us the ability to hold state in our components, and use lifecycle events that can handle side effects and data changing over time.

We used to do this with class components, but the React library added hooks in early 2019 with version 16.8.

The Two Main Hooks

The React library comes with a set of "build in" hooks. There are 10 official hooks, but the two most common ones are useState and useEffect.

1. useState

useState lets us hold "state" – a piece of data that changes over time while your app is up and running.

2. useEffect

useEffect let's us perform side effects. That means we can execute functions or run code that isn't directly about rendering UI elements to the DOM.

This includes making data requests, or running JavaScript functions after the components have already rendered.

Creating Your Own Custom Hooks

We can also remix these built-in hooks to create custom hooks.

These are simply functions you write that use the basic hooks, and layer extra functionality on top of them.

There's a great collection on usehooks.com if you want to see some examples.

Once you've written your hook, there's a handy create-react-hook library that does all the formatting grunt work and makes uploading your hook to npm easy.

Just use npx create-react-hook, add a package name, description, Github details, and licence. There's a default template that works for most cases.

It'll generate a series of files and folders for you. You just need to add your hook file to the /src folder, write the readme, and take care of some other housekeeping.

After that you're all ready to publish your hook for others to use 🎉

Joe's course is nice and short, and covers all the details of how to do this.

You can get a handle on custom hooks in under 30 minutes. Then start writing your own!

👁‍🗨 If these are hard to read, you can download a free high-res PDF version on the course itself.
Dev.to limits image sizes a lot and it's hard to make it readable on here. Apologies!

Illustrated Notes on Fixing Git Mistakes

Maggie Appleton — Tue, 17 Nov 2020 17:39:55 +0000

These are illustrated notes I made while working through Chris Achard's Fix Common Git Mistakes course on egghead.

The course is a great refresher on the fundamental structure of git, adding and removing commits, and (critically) undoing mistakes of all kinds.

The Basic Structure of Git

Chris covers all the various 'levels' your Git files can be at. I personally needed to think of it as a spatial stack to understand how files move between them.

Every time I push commits to Github I see something like this in my head:

I also found it helpful to think of the 'stash' as a side drawer you tuck files away in, and then can 'pop' them back out later.

Branches are Pointers

This framing of git branches as "pointers" you can move around changed the way I think about them a lot.

We can move the pointers to different commits, which are just different versions of our project at a specific point in time.

Git Log

git log is a handy feature that shows you all your previous commits and their details. It's quite verbose though.

git log --oneline is much easier to read since it only shows you the commit hashes and messages

git log --graph draws a tiny graph in the terminal showing branches and merges

Undoing Mistakes

Git Commit Ammend

git commit --ammend lets us add or change files in our last commit, as well as the commit message

Git Reset

git reset will move a file backwards. If you're committed a file to either staging or the local repo, we can bring it back to our working directory.

Git gives us three levels of "intensity" for resetting - git reset --hard, git reset --soft, and mixed.

If you don't specify one, mixed is the default which just moves it from the local repo back to your working files.

Git Diff

git diff is a handy utility for seeing what's changed between two commits or two files

You can compare two commits using their branch names or commit hashes: git diff main new-feature

You can also compare two files by passing in both file names: git diff path/to/file/ComponentA.js path/to/file/ComponentB.js

Detached Head

A detached head is less morbid than it sounds. It just means we've checked out a commit using it's specific hash name, such as git checkout 49da32
That commit is now the "head" because it's the most recent version of our project.

It's "detached" because we've navigated there directly and aren't on our usual branch structure. We have to "reattach" the commit back to our branch with git checkout -b my-new-branch-name

It feels good to be less lost in the git forest now.
I hope some of these techniques make your git log less sad too :)

There's plenty more in Chris' course that I left out here.

👁‍🗨 If these are hard to read, you can download a free high-res PDF version on the course itself.
Dev.to limits image sizes a lot and it's hard to make it readable on here. Apologies!

Illustrated Notes on Advanced JavaScript Fundamentals

Maggie Appleton — Wed, 04 Nov 2020 19:27:35 +0000

Being humans, we rarely learn things linearly.

No one begins their JavaScript journey by reading the TC39 language specification line-by-line like a pedantic masochist.

Instead we all cobble together a good-enough understanding, leaving holes here and there to fill in later.

If you're like me, you might have been stumbling through your JavaScript journey without 100% grokking prototypical inheritance, or how call, apply, and bind work on functions.

It's fine. Stuff mostly works.

Until it doesn't ¯_(ツ)_/¯

At some point, it's useful to stop stumbling around and peek back at those holes.

I found Tyler Clark's egghead course on Advanced JavaScript Foundations was the perfect opportunity to strengthen my JS foundations.

While working through the course, I illustrated a set of notes to help me understand and remember all the concepts.

Primitive Types & Autoboxing

Prototypical Inheritence

The `New` Keyword

The `.this` keyword

These illustrations aren't perfectly designed to explain the concepts they're about, and instead work as shorthand notes for me.

Take a look at Tyler's course if you want to dig into the concepts more.

Recording a Great Coding Screencast

John Lindquist — Fri, 23 Oct 2020 22:56:47 +0000

It seems trivial to record a 1-8 minute screencast, but there are actually quite a few moving parts when it comes to recording a high quality screencast. Here's some of our thoughts on the subject.

If you're interested in a more in-depth guide to how we create lessons for egghead.io, please check out our instructor's guide.

The Screen

First and foremost a coding screencast is about the code, and we need to make sure it looks great. There are a few aspects to this that help ensure that is the case.

Resolution

1080p is a great target resolution, but we've also had great results when we record at 1280x720(HiDPI) mode, giving an effective visible resolution of 1280x720, but extremely crisp. This resolution is achievable on 27" monitors and retina MBPs.

To enable HiDPI, we use the RDM tool. On retina MacBooks, this "just works". For external monitors, or non-retina Macs, you can follow these instructions to enable HiDPI mode.

Using HiDPI mode gives an extremely crisp final product that looks fantastic (readable) on phones and tablets.

If you can't use this mode, recording at normal 1280x720 is a decent substitute. By constraining to this small window, you are able to fill the screen effectively for coding screencasts.

The Code

The code is the champion of the screencast. To that end, it deserves maximum horizontal space. It is a good idea to use an 80 or 120 character "column" for the code and bump the font size up to fit.

We will typically work in a 3 column layout, with the editor taking up 2/3s and a browser on the right side in the remaining 1/3 of the screen. You might prefer to flip back and forth between the browser and the editor, it is up to you.

It is important to keep in mind that some padding allowances should be considered for the top and bottom of the recording window, as they can get cut off by player chrome.

Recording

We strongly encourage recording in small "takes" rather than trying to record the entire lesson. A take can be as small as a single sentence. Try each take as many times as you need. When you make a mistake, just undo your last sentence and try again. Recording in tiny takes sets you up for success when it comes time to edit.

When it comes to time to actually record your screen, my personal preference is Screenflow. Recording is simple and the editing experience is smooth. But there are plenty of other great options out there.

Editing

Now it's time to cut out all the mistakes. If you followed the "take" advice, you can reach for the "ripple delete" tool and easily chop out all of the mistakes you made. I strongly recommend editing your lesson immediately after you record so all the mistakes you made are fresh in your mind.

The more confident and practice you get with editing, the more confident you will be with making mistakes in your videos. So it's a good idea to try out the whole process a few times when you're just getting started to get the hang of working in a "takes" mindset.

What Should I Say?

Your words should reflect what's happening on the screen. Don't talk without showing something and don't show something without talking. As you walk through the steps of your lesson, you can keep the user focused with the forward progress you're making. So the more you give instructions like "type this" or "click that", the more the user has to pay attention.

Volume

Volume is important. Nothing ruins an awesome screencast quicker than messed up levels. I use a small laptop and headphones to test my audio. On the laptop, I want the volume to be clear from across a small room, with minimal distortion. It should be in stereo and sound good in headphones too. With headphones, max volume should be loud, but distortion free.

Content

This is totally up to you.

What are you stoked about in web development?
What do you see as being painful, and how do you solve it?

Our basic guideline is to identify pain. A Pain Thesis™, if you will. Identify the pain, state it, and then walk through the solution. There is so much pain in web development, and this provides endless quantities of worthy topics.

Feel free to scour Stack Overflow for questions and create videos that answer them. Video offers an advantage over a simple copy/pasted code example because you can show the process. Developers love watching process! (And feel free to amaze them with your custom workflows)

Have fun! Convey the joy you've found in solving software problems and sharing those solutions with others. We're not professors shoving text books down students throats. We're not trying to fill some sort of quota or meet deadlines. We're doing this because we love sharing information and care deeply about code and best practices.

Supplemental content

People are very keen on getting their hands on the code. There are a couple approaches to this.

Full-on Project: This is how you would normally work. Structured, full project that makes use of dependency management systems and requires a brief README to explain how to get running ASAP.
Minimal Files: An HTML file and a JavaScript file. In this case, use CDN links where possible.

They almost always want code, even for the most trivial things.

Stay Focused

If you need to go off on a tangent, consider making another separate video. Your audience is watching your video for what you put in the title, so do your best to limit to that specific topic. This also has the side-benefit of making the video easier to find and organize in groups with other videos.

We make "bite-sized" videos because our audience's time is precious. Each video should have enough content to satisfy a learning craving while also supporting binge-watching across multiple videos for those developers diving head-first into the latest and greatest technologies.

Top 10 egghead screencasting tips

Stick to it. It's worth it. - This is work. You're new to this. Expect it to be hard, but expect to succeed when you put in effort. The final payoff is huge.
Accept feedback gracefully.
Relax and have fun. - Humans are more trustworthy than robots. Monotone voices kill lessons. This stuff is interesting, so let it come across in your lessons that you are truly interested.
Do Dry Runs - Just hit record and start talking. Create a terrible lesson. You'll learn a ton by just doing it live. Then, do it again. You'll nail it down in a few takes and it's much easier than just sitting there stressing about it.
FOCUS - Write your lesson title. Teach only about that title. Don't go off on tangents, instead, MAKE MORE LESSONS!
Show, the flow - Every example has a "stream" of how pieces fit together. It will be obvious to you and you'll be tempted to skip over it because you think it's too obvious. Show how the code goes from point A to point B. Show how task X outputs file Y. Show how button M makes div N disappear.
Make A LOT of mistakes, then edit - This is NOT a conference presentation. You do NOT have to be "perfect" or "practiced". You just need to edit out the mistakes. So relax, say stupid stuff, pause, do it again, then edit out the bad stuff later. LOTS of pausing. LOTS of mistakes. Editing is easy.
End fast, start faster - Avoid saying "Hi". Skip "This lesson is about X, Y, Z" Just go. They can read the title of the lesson above the video. Then at the end, just stop. Don't say "Next time", just MAKE THE NEXT LESSON!
Recap when it's complicated - If your lesson has a lot of moving pieces, use the end to walk them through all the steps again. Basically show the flow part 2.
Be tidy - If a section gets "sloppy", stop yourself and start over. Having to watch a lesson where an instructor "reacts" the lesson is painful. Take control of the lesson and stay in control. You are the authority.

Conclusion

It takes a little practice, and it can be surprising how long it takes to record a condensed 3 minutes of excellent coding how-to. It definitely gets easier with practice!

How xstate saved our 🥓

Ian Jones — Fri, 23 Oct 2020 15:37:39 +0000

useEffect Overload

egghead is the CMS, sale provider, and authentication for what we call Wes Bos as a Service (WBaaS) sites. This includes TestingJavaScript.com, PureReact.com, and now EpicReact.dev.

When we set out to build EpicReact.dev, we knew what we were doing. We've built 2 of these sites before and had handled authentication and purchasing. I figured it was time to extract the purchasing code out of these sites into its own package.

I used [[tsdx]] because it's a great way to author libraries and who doesn't like some [[TypeScript]]. This process went well. I was enjoying the benefits TypeScript gives you.

Heres a quick explanation of the commerce package. It was one big useReducer. I had state that relied on other elements of my state, and as Kent says, this is the time to useReducer.

The api of our hook was like this:

const {
    notification,
    parityCoupon,
    countryName,
    onApplyParityCoupon,
    displayParityCouponOffer,
    error,
    onPurchaseComplete,
    displayPrice,
    seriesPackageLoading,
    showClaimCoupon,
    purchasing,
    clearNotifications,
    appliedCoupon,
  } = usePackage({
    sellable,
    quantity: 1,
    authToken: () => {},
  });

You can tell that theres a lot going on under the hood. We passed a sellable, quantity, and authToken to the hook. A sellable is something that has a price and a url on the object to check that price along with a url to make the purchase.

For the internals, heres the stack of hooks that I ended up with:

useAvailableCoupons.tsx
useCouponFromHeader.tsx
useDefaultCoupon.tsx
useFetchPackageForSellable.tsx
usePackage.tsx
usePackageCheckout.tsx
usePackageReducer.tsx
useParityCoupon.tsx
useRequest.tsx

usePackage is the hook that orchestrated everything. The basic flow was:

receive a sellable from props
instantiate initial state
fetch the current price of the sellable
check for an applied coupon
extract available coupons
extract purchase power parity (PPP) coupon
create a function to handle purchase complete
create a function for when the coupon is applied
return display price, functions, and other relevant data

The main areas being: load the most recent price, handle any available coupons, give the user of the hook information about everything that's happening.

Most of these hooks are use effects waiting for changes of the particular state they manage. Lets take a look at the useParityCoupon hook:

const useParityCoupon = (
  dispatch: DispatchType,
  availableCoupons?: CouponType[],
) => {
  React.useEffect(() => {
    const parityCoupon = find(availableCoupons, {
      coupon_region_restricted: true,
    })
    if (parityCoupon) {
      const countryCode = get(parityCoupon, 'coupon_region_restricted_to')
      const countryName = get(parityCoupon, 'coupon_region_restricted_to_name')
      const displayParityCouponOffer = !(
        isEmpty(countryName) ||
        isEmpty(countryCode) ||
        isEmpty(parityCoupon)
      )

      dispatch({
        type: SET_PARITY_COUPON,
        displayParityCouponOffer,
        parityCoupon,
        countryName,
      })
    }
  }, [availableCoupons])
}

You may notice one of the bugs that was in our purchase flow. availableCoupons is of type CouponType[] which is not a stable value. React will shallowly compare this reference. When this hook runs again, availableCoupons will always be different. These hooks were scattered with issues like this. This is one of the foot guns that made debugging these hooks difficult.

I ran into issues testing this code in EpicReact. One being, the parity coupon was not being set when it should have been. When the value you expect to be there isn't, you have to go inspect what could be affecting it. In this case, I had to inspect these hooks:

usePackage.tsx
useFetchPackageForSellable.tsx
useAvailableCoupons.tsx
usePackageReducer.tsx
useParityCoupon.tsx

Tracing the data through all of these hooks is a nightmare. First you check if usePackage is calling useParityCoupon correctly. Next, we have to check if the values from useFetchPackageForSellable are setting state in usePackageReducer correctly. Then I had to make sure that useAvailableCoupons set the coupons correctly and finally that useParityCoupon was sending the correct event when it was supposed to. This took a lot of debugger and console.log statements to just figure out what the flow of data was.

On top of this, we have to make sure that when the user applies the PPP coupon, we refetch the price all over again.

All of this had to be stored in my head before I could start making any changes.

XState Saves the Day

One of the first things you will notice when using the XState version of this hook is how much simpler the api is:

const [state, send] = useCommerceMachine({
   sellable: bundle,
 })

XState just needs the sellable to kick off the price checking process.

XState forces you to think about your discreet states. Theres a big difference between the context you have around your state machine and the states your machine can be in.

Everything I described above can be boiled down into these states:

fetchingPrice
priceLoaded
startingPurchase
handlingPurchase
success
failure

We use these states to build up the context of our state machine. This is what we want to track in our state machine:

sellable
purchaseHeaders
error: null
price: null
appliedCoupon: null
notification: null
email: null
stripeToken: null
quantity: 1
purchase: null

As you can see sellable and purchaseHeaders are all passed in from a closure above. Heres what the basic state machine with no transitions looks like:

const createCommerceMachine = ({
  sellable,
  purchaseHeaders,
}) =>
  createMachine(
    {
      id: 'commerceMachine',
      initial: 'fetchingPrice',
      context: {
        sellable,
        purchaseHeaders,
        error: null,
        price: null,
        appliedCoupon: null,
        notification: null,
        email: null,
        stripeToken: null,
        quantity: 1,
        purchase: null,
      },
      states: {
        fetchingPrice: {},
        checkingPriceData: {},
        priceLoaded: {},
        startingPurchase: {},
        handlingPurchase: {},
        success: {},
        failure: {},
      },
    },
    {
      guards: {},
      actions: {},
    },
  )

You may notice that this createCommerceMachine function takes more arguments than our useCommerceMachine hook and thats because we create an intermediate hook to load authentication and such:

export const useCommerceMachine = ({sellable}) => {
  const {user, authToken} = useEggheadUser()
  const sellableSlug = get(sellable, 'slug')
  const userId = get(user, 'id')
  const commerceMachine = React.useMemo(() => {
    const purchaseHeaders = authToken()
      ? {Authorization: `Bearer ${authToken()}`}
      : {}
    return createCommerceMachine({
      sellable,
      purchaseHeaders,
      stripeToken: process.env.STRIPE_TOKEN,
    })
  }, [sellableSlug, userId])

  return useMachine(commerceMachine)
}

We are memoizing our call to createCommerceMachine because we only want to create a new machine if the sellableSlug or the userID has changed.

The first machine initializes in the fetchingPrice state. This is a state that is invoking a promise (xstate docs). A state can invoke a number of services but in our case we are using a promise. Heres the overview of the state:

fetchingPrice: {
    invoke: {
        id: 'fetchPrice',
        src: (context, event) => {// return a promise here},
        onDone: {
          target: 'checkingPriceData',
          actions: [// do something with the resulting data],
        },
        onError: {
          target: 'failure',
          actions: [// do something if the promise throws an error]
        },
    },
}

You can see that invoke takes a src promise. XState will handle calling this function and handing the resulting data to onDone or onError. This is where we calculate the context.price object.

onDone: {
  target: 'checkingPriceData',
  actions: [
    assign({
      price: (context, event) => event.data[0],
    }),
    'adjustPriceForUpgrade',
  ],
},

We use XState's assign function to take the data that the event gave back and assign it to the price. We have to handle a case where we adjust the price if the user is upgrading a purchase. I do this in separate action because I like to see all the different things that are happening when I read the machine. You could technically do this action in the assign above, but then you aren't optimizing for deletion.

The next state is checkingPriceData:

checkingPriceData: {
  always: [
    {
      target: 'failure',
      cond: 'couponErrorIsPresent',
      actions: ['setErrorFromCoupon'],
    },
    {target: 'priceLoaded', actions: ['checkForDefaultCoupon']},
  ],
},

This is a transient state. We use always to make a transient transition (xstate docs). This is a spot in our state machine where if some condition is true with the current context, we want to conditionally send it to another state. The first condition to return true will be the transition that's executed. The default is to send to priceLoaded state because there is no condition preventing this from happening.

We defined our couponErrorIsPresent guard in our guards object below.

guards: {
    couponErrorIsPresent: (context, event) => {
      return context?.price?.coupon_error
    },
},

All it needs to do is return true or false. We check the specific data we need to see if a coupon_error is present. If it is, we use setErrorFromCoupon to set the error context:

setErrorFromCoupon: assign({
  error: (context, event) => context.price.price_message,
}),

This allows our UI to check the state of our machine and our context to determine if it needs to display an error.

Moving along, we assume that our price check didnt return a coupon error, we move into the priceLoaded state. This is the last state our machine will automatically transition to until it receives an event from the outside telling to to transition to another state. Heres everything the outside world can tell our state machine to do:

priceLoaded: {
  on: {
    APPLY_COUPON: {
      target: 'fetchingPrice',
      actions: [
        assign({
          appliedCoupon: (context, event) => event.appliedCoupon,
        }),
      ],
    },
    DISMISS_COUPON: {
      target: 'fetchingPrice',
      actions: [
        assign({
          appliedCoupon: null,
        }),
      ],
    },
    SET_QUANTITY: {
      target: 'fetchingPrice',
      actions: [
        assign({
          quantity: (context, event) => event.quantity,
          appliedCoupon: null,
        }),
      ],
    },
    START_PURCHASE: {
      target: 'startingPurchase',
    },
    CLAIM_COUPON: {
      target: 'handlingPurchase',
      actions: [
        assign({
          email: (context, event) => event.email,
        }),
      ],
    },
  },
},

You'll notice that APPLY_COUPON, DISMISS_COUPON, and SET_QUANTITY all just send the machine back to the fetchingPrice state. This is one of the benefites of XState. We can reuse our logic on how we fetch the price but give it a slightly different context.

Say our machine recieves the APPLY_COUPON event. This event comes with appliedCoupon. You can see that we are using assign to add the appliedCoupon from the event into our context:

assign({
  appliedCoupon: (context, event) => event.appliedCoupon,
}),

Then our machine transitions back into the fetchingPrice state. I mentioned earlier that fetchingPrice invokes a promise for us. Heres what the promise looks like:

fetchingPrice: {
  invoke: {
    id: 'fetchPrice',
    src: (context, event) => {
      const {
        quantity,
        appliedCoupon,
        sellable,
      } = context
      const {
        priceCheckURL,
        site,
        egghead_id: sellable_id,
        type,
      } = sellable
      return axios
        .post(
          priceCheckURL,
          pickBy({
            sellables: [
              {
                site,
                sellable_id,
                sellable: type.toLowerCase(),
                quantity,
              },
            ],
            site,
            code: appliedCoupon,
          }),
        )
        .then(({data}) => data)
    },
    onDone: {},
    onError: {},
  },

You can see that we are grabbing quantity, appliedCoupon, sellable, and upgradeFromSellable from our context and passing some of those values to the body of our axios.post call. This is how we can reuse our fetchingPrice state, with different context to fetch prices when no coupon is applied, when we've applied a coupon, or even when the quantity we are asking for has changed.

When the user wants to start a purchase, we receive a START_PURCHASE event. This event simply transitions us to the startingPurchase state. We have this state so that we know when the user has clicked the "Purchase" button and a modal to accept their info is been created.

While in the startingPurchase state, we can do two things:

startingPurchase: {
  on: {
    CANCEL_PURCHASE: {
      target: 'priceLoaded',
    },
    HANDLE_PURCHASE: {
      target: 'handlingPurchase',
      actions: [
        assign({
          email: (context, event) => event.email,
          stripeToken: (context, event) => event.stripeToken,
        }),
      ],
    },
  },
},

We can either cancel the purchase and return to priceLoaded or the user has entered their data and is attempting a purchase that we need to handle. In our case, we contact stripe for a token and then get the email that they entered. This is all we need to kick off our purchase process.

handlingPurchase is a state that invokes a promise to POST data to our purchases api endpoint:

handlePurchase: {
  invoke: {
    id: 'handlePurchase',
    src: (context, event) => {// return promise that makes the purchase},
    onDone: {
      target: 'success',
      actions: [
        assign({
          purchase: (context, event) => event.data,
        }),
        'sendToThanks',
      ],
    },
    onError: {
      target: 'failure',
      actions: assign({
        error: (context, event) => {
          return event?.data?.response?.data?.error
        },
      }),
    },
  },
},

This is the same process we've described. We can either transition to success or failure based on the response of the purchase promise. If the purchase was successful, our specific UX is that we send the user to a /thanks page.

State machines are verbose. I haven't described every feature this machine does but in total, this file is 314 lines long. XState forces you to map our all our states and transitions explicitly. This affords you the ability to know exactly when something is happening.

Earlier, when I had a problem with my custom usePackage hook, I would have to follow all the hook calls to track the data and when things happened. In this case, say I am trying to apply a coupon but my machine loads the price, and the request comes back with a price I didn't expect. I can go to my machine and know exactly where coupons get applied to check if it's applied correctly and exactly where the coupon is being used in the request. There's no guessing involved.

As feature requests come in, it's much easier to know exactly where they fit in. Say we want to add a feature so that the user can upgrade from one package to another. We need to send the package we are upgrading from to the server. We know we'll need to pass that package in from react:

const [state, send] = useCommerceMachine({
   sellable: bundle,
   upgradeFromSellable,
 })

Then we know that we will need this object in our context inside of our machine so we can use it when we are fetching our price.

const createCommerceMachine = ({
  sellable,
  purchaseHeaders,
  upgradeFromSellable,
}) =>
  createMachine(
    {
      id: 'commerceMachine',
      initial: 'fetchingPrice',
      context: {
        sellable,
        purchaseHeaders,
        upgradeFromSellable,
       // ...
      },
      // ...
)

Now we can use this upgradeFromSellable object in our fetchingPrice promise.

fetchingPrice: {
  invoke: {
    id: 'fetchPrice',
    src: (context, event) => {
      const {
        sellable,
        upgradeFromSellable,
        // ...
      } = context
      const {
        // ...
      } = sellable
      return axios
        .post(
          priceCheckURL,
          pickBy({
            sellables: [
              {
                upgrade_from_sellable_id: upgradeFromSellable?.slug,
                upgrade_from_sellable: upgradeFromSellable?.type,
                // ...
              },
            ],
            // ...
          }),
        )
        .then(({data}) => data)
    },
    onDone: {// assign the returned price},
    onError: {// assign the error},
  },
},

There's no guessing involved in where we need to put this object to affect our prices call.

There is always state our UI's are dealing with, even if we are explicitly modeling it. State machines force you to model how you want your state to act and what can change the state in your machine. State machines expose the implicit state that you may or may not have known was there.

Announcing the VS Code Snippets egghead Community Challenge

Will Johnson — Tue, 22 Sep 2020 19:10:35 +0000

We are excited to announce the first egghead Community Challenge!

From today Sept 22st until Monday, October 5th, you will have a chance to win some badass prizes by creating VS Code snippets that are helpful for developers!

What are Code Snippets?

Code snippets are templates that make it easier to enter repeating code patterns, such as loops or conditional-statements.

Learn more Code Snippets here

Why Participate?

One of the primary principles of egghead is that we are a "community of practice". One of the tenets of a community of practice is sharing resources that make us better at our craft.

Code snippets speed up workflow and productivity. Creating and sharing some useful snippets will help the community as a whole.

Prizes

3 Winners(1 per category)

3 months subscription to egghead.io
Full egghead Swag Pack from the egghead Swag Store(hat, beanies, stickers, t-shirt)

How To Submit

Create a GitHub repo name egghead-challenge-'yourreponame'
Share the URL to the snippet in the Discord group
Example here: https://github.com/wjohnson85/egghead-challenge-will-snippet/blob/master/snippet-example/

Support

You will be invited to a group DM on discord where we will share resources to help get you to start creating and sharing snippets.

You can also ask questions, get tips, and share ideas with other challenge members.

I highly suggest sharing on social media your progress using #eggheadchallenge

Dates To Remember

September 22: Community Challenge Begins!

October 5th: Community Challenge Submissions Due at 11:59 PM PST.

October 8th:: Community Challenge Winners Announced

If you want to participate comment below and an egghead staff member will be in touch!

How To Get Started with AWS (Q&A)

Will Johnson — Wed, 24 Jun 2020 18:28:43 +0000

To celebrate the release of Tomasz Łakomy's new AWS course Build an App with the AWS Cloud Development Kit.

We hosted an AWS Q&A on Twitter. The egghead web developer community on Twitter was able to ask questions, and Tomasz provided some great answers.

// Detect dark theme var iframe = document.getElementById('tweet-1272937541835067399-53'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1272937541835067399&theme=dark" }

I kicked off the discussion by asking "Can you use other databases besides DynamoDB with AWS?

Tomasz:
Absolutely! DynamoDB is an AWS-exclusive NoSQL database (or key-value store if you'd like to be really accurate) but for instance.

You can use Amazon RDS (Relational Database Service) to use MySQL, PostgreSQL, MariaDB, Oracle (if you need to) and Amazon Aurora

Amazon Aurora is another type of database built for the cloud, unlike DynamoDB it's a MySQL and PostgreSQL-compatible relational database

Ceora asked for suggestions for getting practical/real-world experience in AWS?

@ceeoreo_

Tomasz:
When it comes to getting actual experience: start experimenting

Use S3 to backup your photos
Use Lambda to build an API for your website
Use DynamoDB as a todo list
Use SageMaker to appear incredibly smart because machine learning is magic

He also added going through the AWS Certified Cloud Practitioner prep might be a good idea because the purpose of the exam is to get you familiar with AWS Cloud

The Code Pixi and Vaibhav asked: "What are your recommendations for someone who's a total beginner with AWS?"

@TheCodePixi
@Vaibhav

Tomasz:

First, start with AWS Lambda - you don't have to become an expert, but you can start using it in order to (for instance) build your own serverless APIs

It doesn't have to be a really deep dive, IMHO experimenting is an excellent way to learn (and you're not going to get charged anything on a new account thanks to the free tier - a million free requests per month).

IMHO this egghead lesson WTF is AWS Lambda by yours truly is a great place to start:

Secondly, consider checking out some of the AWS Certified Cloud Practitioner courses - it's the easiest AWS certification exam and the goal of it is to show that you "have the knowledge and skills necessary to effectively demonstrate an overall understanding of the AWS Cloud"

This course is also a great introduction into the world of serverless/AWS:
Develop A Serverless Backend Using Node JS on AWS Lambda

Something more official:
AWS Fundamentals

Aengus asked "What sort of use cases would best be served by using AWS vs something like Netlify or Heroku? When would it be overkill?"

@aengusmcmillin

Tomasz:
"As with all great questions in programming, the answer is: "It depends"

Netlify, Heroku, AWS Amplify solve similar problems when it comes to building web apps and they are amazing at that. My personal site uses Netlify, but all of our infrastructure at OLX Tech lives on AWS since we have a lot of traffic.

Of course, to get started with AWS you don't have to be a huge company, thanks to their free tier (my last bill was $5 though). Even if you use Netlify, IMHO there's a great value of getting to know serverless technologies a bit better.

I wanted to say that serverless is the future, but it's not entirely true serverless is here now and it'll stay for a while"

Kranthiasks "Is it possible to build complex applications completely using AWS lambda/serverless?" and "Can you refer to any resources related to architecting fully serverless applications?"

@kkranthi438

Tomasz:
Yup! It definitely requires a shift in perspective when it comes to thinking about your architecture (you don't have a server running your monolith 24/7).

For example, at OLX Tech we're running serverless services which are built on top of multiple lambdas + DynamoDB

For resources read and watch everything that @theburningmonk has even written/recorded. As well as this eggheadio course:
Building Serverless Web Applications With React AWS Amplify

Lauro asked: "Is it worth getting AWS certified?"

@laurosilvacom

Tomasz:
IMHO it is - it's an excellent way of getting and solidifying your knowledge about AWS Cloud. Having a concrete list of services that you need to understand is better than "I'm going to learn all of it!".

I wrote a bit more about my experience in this post: Passing AWS Solutions Architect Associate exam

John wanted to know "Did diving deep clear up any misunderstandings you had going in?"

@johnlindquist

Tomasz:
Absolutely! For instance, I considered S3 to be an actual 'simple' service: "just buckets that store files, how hard can that be". While that's true on a surface level, S3 has much more to offer when it comes to features like versioning, encryption, different storage tiers

Another thing, I had this idea that since DynamoDB is a NoSQL database it's really flexible and you don't need to think about your access patterns before you start using it. As Alex DeBrie (@alexbdebrie) explains in his excellent "DynamoDB Book", this is not true

Tyler asks, "What are some features you wish AWS would add or possibly features that are coming out that you are excited about?"

@iamtylerwclark

Tomasz:
I'd love to see a CloudWatch console visual overhaul, currently, it's not exactly intuitive and it could definitely use some love. Apart from that (it's a common complaint, I'm not exactly unique in that regard) AWS docs are famously... not approachable for beginners (Which is actually part of the motivation behind my course. I went through all of that so you don't have to!).

I'd also love to see more educational content from AWS featured in the Console - for instance when you go to DynamoDB console for the first time.

And yes, there are various conference talks, webinars, etc but what I feel folks are lacking are guidance when it comes to "I have all those features, which ones are going to solve my problems"

One more thing: Dear AWS, please make the SAVE button in AWS Lambda Console bigger, make it blink, jump, or whatever when I have unsaved changes in the editor. Don't make me debug code that is not even saved :(

These were some really great questions and Tomasz provided some great insight on how to get started learning AWS!

His course Build an App with the AWS Cloud Development Kit is available now!

Looking for code streamers? Here's a list for you!

Will Johnson — Fri, 17 Apr 2020 22:35:04 +0000

Code streaming has become very popular.

More and more people are streaming themselves, solving problems, building things, and interacting with the developer community. They are starting channels on Mixer, Twitch, and YouTube.

We wanted to create a resource of code streamers that can be found all in one place!

We asked the egghead community to share their streams.

Do you stream? Leave a link to your stream in the comments!

Here are some streamers from the egghead community!

Pachi is self-taught developer who loves CSS(who doesn't, though?). She streams herself creating small pages and sometimes playing League of Legends, being a new and showing her drive it's an excellent opportunity to watch someone on their way to big things!

https://www.twitch.tv/pachicodes

Tyler Clark is DevRel Engineer at Auth0. He pairs up with other developers and open source maintainers to learn new tools and technologies in real-world apps. His topics are very diverse in subjects, from tools like React-Query to mastering codesandbox or illustrating development concepts. There's something for every developer.

https://www.twitch.tv/livewithtyler

Eric Boggs teaches free intro to Web Dev lessons. All you need a VSCode and a good attitude. No experience required. This would be an excellent way to introduce someone you know to web dev.

https://www.quarantinecode.com/

Jason Lengstorf hosts the Learn With Jason show where his guest either teach him something new or he teaches them something new in 90 mins. Jason has a great community around him, and his chat is super enthusiastic.

https://twitch.tv/jlengstorf

Eva is a co-founder of includesJS focused on improving diversity in tech. Eva host online conversations on Twitch with developers, organizers, conference speakers, and more.

https://www.twitch.tv/edieblu

Chris Biscardi streams the cutting edge. He is very interested in new technologies and seeing how they crack. On his stream, you can learn about more than what's hot, you learn about what's going to be hot so you can be ahead of the curve.

https://www.twitch.tv/chrisbiscardi

Rahat Chowdhury is a full stack developer and podcast host he streams himself building actual projects with in-demand technologies like React, Gatsby, and GraphQL. In one series, he showed behind the scenes of building his podcast site!

https://www.twitch.tv/rahatcodes

Kurt Kemple streams a variety of coding, design, video/photo editing, fitness, and a bit of gaming. So if you're not in the mood for just development, you can join his community for other topics as well.

https://www.twitch.tv/theworstdev

Sam Julien is a DevReal at Auth0 he streams coding (mostly Angular & React), talk-building, and tech career information. He decided to rebuild his blog in Gatsby and let the community join him in the process.

https://www.twitch.tv/samjulien

Khaled Garbaya if you're interested in learning JAMStack, this would be the stream to follow. Khaled builds real projects live from start to finish using the JAMStack, and you don't miss a thing!

https://www.twitch.tv/kgarbaya

Ryan Warner for developers looking to improve their design skill's Ryans stream in an excellent place to start. Ryan starts working in Figma and brings designs to life with code.

https://www.twitch.tv/RyanWarnerCodes

Give these streamers a follow and get involved in their chat!

DEV Community: egghead.io

Content Modeling and Data Design with Sanity.io

Where we were at when this started

Resources and Collections

Where we want to be

Content Modeling with Sanity.io

Modeling resources, not layout

A Practical Example

Where we are headed...

TailwindCSS Dark Mode in Next.js with Tailwind Typography Prose Classes

What you will learn about in this article.

Motivation for dark mode

Getting Started

The Tailwind Config

Enabling Dark Mode in TailwindCSS

Creating a theme with next-themes and React Hooks

Toggling between light and dark modes with just a click

Solving some problems with our TailwindCSS config and dark mode

Slow builds with TailwindCSS Dark Mode and Next.js

Controlling the Purge

Dark Mode for TailwindCSS Typography Prose Classes

Summary

Illustrated Notes on Web Security Essentials

WTF is Rust? The Illustrated Notes

Illustrated Notes on Custom React Hooks

The Basics of React Hooks

The Two Main Hooks

1. useState

2. useEffect

Creating Your Own Custom Hooks

Illustrated Notes on Fixing Git Mistakes

The Basic Structure of Git

Branches are Pointers

Git Log

Undoing Mistakes

Git Commit Ammend

Git Reset

Git Diff

Detached Head

Illustrated Notes on Advanced JavaScript Fundamentals

Primitive Types & Autoboxing

Prototypical Inheritence

The New Keyword

The .this keyword

Recording a Great Coding Screencast

The Screen

Resolution

The Code

Recording

Editing

What Should I Say?

Volume

Content

Supplemental content

Stay Focused

Top 10 egghead screencasting tips

Conclusion

How xstate saved our 🥓

useEffect Overload

XState Saves the Day

Announcing the VS Code Snippets egghead Community Challenge

What are Code Snippets?

Why Participate?

Categories

Prizes

How To Submit

Support

Dates To Remember

How To Get Started with AWS (Q&A)

I kicked off the discussion by asking "Can you use other databases besides DynamoDB with AWS?

Ceora asked for suggestions for getting practical/real-world experience in AWS?

The Code Pixi and Vaibhav asked: "What are your recommendations for someone who's a total beginner with AWS?"

Aengus asked "What sort of use cases would best be served by using AWS vs something like Netlify or Heroku? When would it be overkill?"

Kranthiasks "Is it possible to build complex applications completely using AWS lambda/serverless?" and "Can you refer to any resources related to architecting fully serverless applications?"

Lauro asked: "Is it worth getting AWS certified?"

John wanted to know "Did diving deep clear up any misunderstandings you had going in?"

Tyler asks, "What are some features you wish AWS would add or possibly features that are coming out that you are excited about?"

Looking for code streamers? Here's a list for you!

The `New` Keyword

The `.this` keyword