DEV Community: gortron

Animating text over images in JS

gortron — Sun, 21 Jun 2020 19:20:30 +0000

Introduction

I've been building a personal blog site for my writing and photography, and it's been a great excuse to experiment with CSS that I don't always get a chance to use.

In this post, I'll walk through how to animate text over a background image. In my portfolio, I use it to animate over image previews of posts. It'll end up looking something like this:

Solution

My solution uses React and Emotion, but the principal of how I animate over my image should be viable for any other front-end framework.

My approach was to create a container for the background image, and then lay a container on top of the background image. The top container is translucent until it is hovered over, and then it and the text it contains become opaque.

The html structure (here, written in jsx) looks like this:

<BackgroundImg alt={alt_text}>
  <Hover>
    <AnimatedTitle>{title_text}</AnimatedTitle>
    <AnimatedParagraph>{paragraph_text </AnimatedParagraph>
  </Hover>
</BackgroundImg>

Using the @emotion/styled library, I made 3 CSS-in-JS styled components to represent these 3 blocks. Code with in-line comments below.

Note that BackgroundImage here is a wrapper component from Gatsby.js that does some nice image-load optimization functions in the background, but for your purposes you could use a div.

// Styling and Animation for Desktop
const BackgroundImg = styled(BackgroundImage)`
  width: 33vw;
  height: 33vw;
  margin: 2vw 2vw 2vw 2vw;
`

const Hover = styled.div`
  height: 100%;
  width: 100%;

  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;

  /* The component is not opaque, but opacity transitions out for 300ms */
  background-color: #efece4;
  opacity: 0;
  transition: opacity 300ms ease-in-out;

  /* When the user hovers over the component, it becomes opaque over 300ms */
  &:hover {
    opacity: 0.95;
    transition: opacity 300ms ease-in-out;
  }

  /* All children (animated text) move to default position when component is hovered over */
  &:hover > * {
    transform: translate3d(0, 0, 0);
  }
`

const AnimatedTitle = styled.h2`
  /* Transform to 50px down on load, but user doesn't see this because div this text is in is translucent  */
  transform: translate3d(0, 50px, 0);
  transition: transform 300ms ease;
  text-align: center;
  margin-bottom: 10px;
`
const AnimatedParagraph = styled.p`
  transform: translate3d(0, 50px, 0);
  transition: transform 300ms ease;
  text-align: center;
  margin-bottom: 0;
  font-size: 12px;
  font-style: italic;
`

Conclusion

This of course only scratches the surface of the transformations and animations CSS is capable of. Highly recommend the MDN spec to anyone who wants a more thorough overview of CSS transforms and transitions. I hope this post has been helpful for anyone trying to solve a similar problem.

Using Emotion for CSS-in-JavaScript

gortron — Sun, 14 Jun 2020 17:15:31 +0000

Introduction

You're already familiar with CSS, and likely with CSS-supersets like sass and less, which add much-needed utility and convenience to CSS. But some frontend developers are turning to CSS-in-JS, an increasingly common pattern for styling web applications.

It's easy to understand why this approach is gaining traction. Imagine you've been tasked to make a button component with React, and you've been given some specs for its styling. You have two options:

1) Separate JS and CSS

Write the Button.js React component and give it a class name like <Button className="styled">, then write the component-specific css in a separate file.

// Button.js
import React from 'react'
const Button = () => (
  return <button className="styled">Click Me</button>
)

/* sass or less which allows for logic statements */
button.styled {
  padding: 32px;
  background-color: hotpink;
  font-size: 24px;
  border-radius: 4px;
  &:hover {
    color: white;
  }
}

But, if another engineer needs to debug the component or change styling in the future, they need to work in both the JS and CSS files. This is a negligible issue for a simple component, but a more onerous task for a brand re-work.

2) CSS-in-JS

Write the component and styling logic in one file.

// Button.js
import React from 'react'
import { css } from 'emotion'

const Button = () => (
  return <button css={css`
    padding: 32px;
    background-color: hotpink;
    font-size: 24px;
    border-radius: 4px;
    &:hover {
      color: white;
    }`}
  >Click Me</button>
)

I haven't touched on other major benefits of CSS-in-JS, such as the ease with which you can pass styling arguments as props to your components, e.g. <Button big pink>, or making styled components e.g. StyledButton = button.styled{...}.

As an aside, Emotion is a popular library (see also: styled-components) for CSS-in-JS, and well worth a look. (I borrowed their styling for this blog post!)

Conclusion

These two schools exhibit a philosophical question: is styling something "other" than the object that is styled, or is styling an inextricable property of the thing that is styled? In my opinion, it's the latter. So, to my taste, CSS-in-JS makes more organizational sense to me. (A poor analogy: imagine having to look away from a house to figure out what color it is.)

Beyond that, choosing between separating JS and CSS and using CSS-in-JS is a tradeoff between strict adherence to separation of concerns, and developer convenience/experience.

This to me seems like a broader trend of everything-in-JS. JS seems to continue to evolve into do-anything language. Consider the popularity of Node.js, and the recent announcement of TensorFlow.js.

An Overview of Server-side Rendering

gortron — Mon, 08 Jun 2020 05:12:01 +0000

Server-side rendering has been around for awhile, but is undergoing a Renaissance as new tools like Gatsby and Next.js gain traction. So what is server-side rendering, and how is different from a client-side rendered web app? What is the advantage to server-side rendering?

Consider a web application, in which a Node server hosted by AWS serves a React application (compiled into HTML/CSS/JS). When a client-user sends a request to that web app's URL, the web app's server responds with the HTML/CSS/JS needed to load the front end of the web app. The client loads the JS, and if it's a web app of any complexity it will then fetch any resources necessary for the app to run. Consider that, in client-side rendering, a user will typically wait for one request-response cycle, wait for the JS in the response to load, and then wait for another request-response cycle.

Much has been written about user's reactions to page load times, but note that milliseconds count.

Fetching not only slows down the user experience, but presents challenges for SEO. When Google indexes your web app's URL, it doesn't wait for fetching to complete. It indexes the html that is sent back from the web app's server.

Server-side rendering is an alternative model to client-side rendering. The goal of server-side rendering is to offload as much of the work from the client to the server as possible. You can do this by rendering at run time (Next.js) or rendering at build time (Gatsby).

For example, by rendering at run time, you can make it the server's responsibility to fetch data for the web application. So when a user sends a request the app's URL, that will trigger the server to fetch data for the app, and once the fetch is resolved it will send all the HTML/CSS/JS the client needs in the response; the client won't need to fetch again. Depending on where your server is and where the storage for the data is, this can make a significant difference.

By rendering at build time, however, your server is configured to fetch any data the app needs before a client sends a response, and compose that data into static HTML/CSS/JS. Then, when a client sends a request the web app's URL, the server responds with the static HTML/CSS/JS it's already built.

Server-side rendering is ideal for web applications that don't involve significant dynamic interaction with the user, where you could ostensibly do one fetch to get all the data you need for the web app to function (blogs, smaller shops).

I hope this post has help clarify what server-side rendering is, and why it can be a powerful methodology.

React: making a store from createContext and useReducer

gortron — Mon, 01 Jun 2020 01:54:08 +0000

Introduction

For all but the simplest applications or static sites, React developers will use state to manage data. Determining the optimal location for state is part of the job of a React developer. Is this data relevant only to this component? This container? Or the entire application? Tools like Redux are popular solutions for managing 'global' state for JS frameworks like React.

There are advantages to using Redux (including its documentation, developer tools, and user base), but in this post I'll share an approach that uses existing React tools to make a state container. Specifically, this approach uses createContext and useReducer to make a StateProvider.

Approach

First, we'll write our reducer and store in a store.js. Note that the switch for your actions will look different from mine, but the pattern should look similar.

import React, { createContext, useReducer } from "react";

const initialState = { mobile: true, projects: null, checkout: null };
const store = createContext(initialState);
const { Provider } = store;

const StateProvider = ({ children }) => {
  const [state, dispatch] = useReducer((state, action) => {
    switch (action.type) {
      case "addToCart": {
        return { ...state, checkout: action.payload };
      }
      default: {
        throw new Error(`Unhandled action type: ${action.type}`);
      }
    }
  }, initialState);

  return <Provider value={{ state, dispatch }}>{children}</Provider>;
};

export { store, StateProvider };

Next we'll wrap our application with our StateProvider, to subscribe our Store to that App's view. In your index.js, your code could look like this:

const app = (
  <StateProvider>
    <App />
  </StateProvider>
);

Lastly, we'll need a way to dispatch actions from the view to the reducer in the store. Your App container might look like this:

import React, { useContext } from "react";

const App = () => {
  const { state, dispatch } = useContext(store);
  const itemAdded = item => {
    dispatch({ type: "addToCart", payload: { ...item } });
  };
}

Conclusion

I like this pattern for managing global state in React applications, especially simple ones, principally because it reduces the amount of syntactic sugar from mapStateToProps, mapDispatchToDrops, and export default connect(...). I hope this post was helpful to you!

React custom hooks: a clean approach to fetch

gortron — Mon, 25 May 2020 00:51:38 +0000

Introduction

Custom hooks are not a React feature, per se; but implementing custom hooks follows the same design pattern of React's common hooks like useState and useEffect.

As the React documentation specifies, a custom hook is _a JavaScript function whose name starts with ”use” and that may call other Hooks.

If you're familiar with React, you may be familiar with the following pattern, where a component fetches a some data from a backend service, e.g.

const myComponent = () => {
const [posts, setPosts] = useState([])

useEffect(() => {
  const getPosts = async () => {
    const response = await fetch("my_backend_url")
    const data = await response.json()
    return data
  }

  setPosts(getPosts())
}, [])

  return (
    <ul>
      {posts.map(post => (
        <PostPreview key={post.slug} post={post}>
      ))}
    </ul>
  )
}

This common pattern can be abstracted into a custom hook, which cleans up the component code.

Code

Consider the following approach to getting/setting posts. This code would exist in something like ./src/hooks/use-posts.js.

const usePosts = async () => {
    const response = await fetch("my_backend_url")
    const data = await response.json()
    return data
}

Now our component could be re-written to be:

const myComponent = () => {
  const posts = usePosts()

  return (
    <ul>
      {posts.map(post => (
        <PostPreview key={post.slug} post={post}>
      ))}
    </ul>
  )
}

Conclusion

There are many considerations when you're refactoring functional code to improve it. Among those considerations are: is this easier to follow?, does this separate concerns?, and does this follow the language's design patterns? The custom hook pattern for React is affirmative to all of those considerations. I hope you find this post useful.

Environment Variables with pm2: The Right Way

gortron — Mon, 18 May 2020 01:35:29 +0000

Introduction

This post is meant to support anyone who is setting up environment variables for a Node.js daemon that they will manage with pm2. Specifically, this post will show you how to handle NODE_ENV for development and production settings for pm2.

There are multiple ways to handle environment variables for a pm2 daemon.
1) Some deployment tools, like Heroku or Netlify, let you set environment variables.
2) You can set them in your CLI.
3) You can use a pm2 ecosystem.yml file.

There are trade-offs between all of these approaches. The first option forces you to navigate a deployment tool's interface to figure out any bugs relating to environment variables.

The second approach makes it easier to debug. You might implement it with something like this, in the scripts section of your package.json:

"scripts": {
  "start": "NODE_ENV=production && pm2 start app.js",
  "dev": "NODE_ENV=development && pm2 start app.js"
}

While this approach is viable, to my tastes it feels "hacky". It does the immediate job of setting one environment variable, but what if you wanted to set more environment variables? Maybe you would write a set_env_var.sh script and invoke it in your package.json script, but then you would have to go to that shell script to debug any issues.

pm2 provides a preferred way to handle environment variables: an ecosystem file.

Solution

Compare this ecosystem.yml file below with the package.json snippet above:

apps:
  - script: ./app.js
    name: "app"
    env:
      NODE_ENV: development
    env_production:
      NODE_ENV: production

It would be far easier to add environment variables, here. And, better still, you're clearly communicating your intent to your collaborators: this file is where we handle environment variables for our pm2 daemon.

You complete the solution by adding something like the following to your package.json:

"scripts": {
  "start": "pm2 restart ecosystem.yml --env production",
  "dev": "pm2 restart ecosystem.yml --env development"
}

Similar to the first package.json scripts, these scripts will start (or restart an existing) pm2 process, and update the environment for that process to include the variables you declared in your ecosystem.yml file.

This is a useful pattern, when setting up dev ops for a pm2 micro service. Consider the following snippet from app.js:

const TOKEN =
    process.env.NODE_ENV === "production"
      ? process.env.PROD_TOKEN
      : process.env.DEV_TOKEN;

If you call yarn start, you will re/start a pm2 process with a token designated for production; if you call yarn dev, you will re/start a pm2 process with a token designated for development.

Conclusion

I hope this guide was useful for anyone getting started with pm2, and thinking through how to implement environment variables for their daemon. An example application that uses this pattern can be found on my GitHub.

Deploying to AWS with Travis via ssh

gortron — Sun, 10 May 2020 19:59:16 +0000

Introduction

The goal of this post is to provide a sample solution for setting up CICD from a GitHub repo to an AWS ec2 instance using Travis—I hope someone debugging this problem finds this useful.

I recently worked on a small personal project for a Discord bot, which I deployed on an AWS ec2 instance. My workflow for deploying my GitHub repo to my ec2 instance wasn't that onerous for a personal project—ssh to my ec2 instance, cd to repo, git pull, and restart pm2.

But it had a problem: any time a contributor made a pull request, I had to deploy the updated master using the workflow above. That approach works fine for one person, but makes less sense for a group of contributors. I needed a deployment methodology that would essentially recreate the steps above, but would do so anytime a pull request was merged to master. That sounded to me like I needed lightweight CICD tooling.

There are many tools to help set up CICD deployment to an AWS ec2 instance (Jenkins, Travis, CircleCI among them). I to setup a custom deployment on Travis, mainly because Travis is hosted and wouldn't require me to set up another ec2 and s3 instances.

Below, I'll describe how I executed this problem in brief. My solution is an adaptation from Thomas Parisot, so great thanks to him. He writes in greater depth about why his solution solves for security concerns with ssh'ing to ec2 from Travis, and I strongly consider anyone solving this problem to visit his blog as well.

Execution

1) Set up an ssh key for Travis

If you don't already have the Travis CLI tooling, use $ brew install travis
Make sure you have a .travis.yml file in the root directory of your project repo.
While in your root directory of your project repo, execute the following:

$ ssh-keygen -t rsa -b 4096 -C 'build@travis-ci.org' -f ./deploy_rsa
$ travis encrypt-file deploy_rsa --add
$ ssh-copy-id -i deploy_rsa.pub ec2-user@<your-ec2-instance>
$ rm -f deploy_rsa deploy_rsa.pub
$ git add deploy_rsa.enc

2) Set up your Travis custom deployment

The commands above will add most of what you need to your .travis.yml file. We will make changes, though, so that the encrypted deploy_rsa key gets added to ./tmp/ so that it doesn't accidentally get deployed:

before_deploy:
- openssl aes-256-cbc -K $encrypted_<...>_key -iv $encrypted_<...>_iv -in deploy_rsa.enc -out /tmp/deploy_rsa -d
- eval "$(ssh-agent -s)"
- chmod 600 /tmp/deploy_rsa
- ssh-add /tmp/deploy_rsa

Now that Travis is configures ssh in its before_deploy lifecycle, we will tell it what to do in its deploy lifecycle. We want it to ssh to our ec2 instance and execute a deployment script:

deploy:
  provider: script
  skip_cleanup: true
  script: ssh ec2-user@<your-ec2-instance> 'bash ./deploy.sh'
  on:
    branch: master

3) Write a deploy script for Travis to execute

The final step is to add a deployment shell script in the root directory of your ec2 instance. After a successful build, travis will ssh to your ec2 instance and call bash ./deploy.sh. So the last step is to add a deploy.sh script in the root directory of your ec2 instance.
Your deployment script will look unique from mine, but I'll provide mine below as guidepost.
As stated in my intro, I want mine to cd to my previously deployed repo, git pull to get the latest, yarn to add any missing dependencies, and pm2 restart all to re-start my Node server.

echo "Changing directory to ~/cupbot"
cd cupbot
echo "Pulling from git"
git pull
echo "Yarn'ing"
yarn
echo "Restarting pm2 instances"
pm2 restart all

Conclusion

I hope this was useful to anyone looking to deploy from a GitHub repo to an AWS ec2 instance. If you get stuck or need help, please don't hesitate to comment or reach out. The discord bot repo I deployed is available here as well.

AWS EC2 Deployment Guide

gortron — Sun, 03 May 2020 18:13:02 +0000

Introduction

I thought I would share my personal deployment checklist for AWS EC2. I remember the first time I deployed, I felt like there were a lot of gotchas. I've put together this checklist, which helps me keep track of the different steps it takes to create a new EC2 instance you can ssh into, configuring its environment, and deploying on it.

For first-timers deploying to AWS, I hope you find this helpful.

Steps

Create a new EC2 instance.

Defaults / free tier are fine, except for Security Groups and Key Pair.
1. The included port 22 is for SSH.
2. Open Port 80. Can use your laptop IP address or leave it as 0.0.0.0 which leaves it exposed to any IP.
3. Add other ports as necessary. If your server "listens" on 3000, then add 3000. But you may want to consider using nginx to only listen on port 80 but "route" relevant requests to 3000, 8000, etc.
4. Make a new Key Pair (.pem) and download it. Move it to ~/.ssh . You can do that with mv <drag file to terminal to get current path> ~/.ssh
SSH into your instance.

You need to configure the read/write authorizations on your ssh key. Then you need to add that key to the destination site and finally add the key to your keychain. Keychain is going to run through all possible ssh keys whenever you try to connect to a site.
1. chmod 400 ~/.ssh/<your key>. If you need to debug this step, use ls -lh <filepath> , which will tell you permissions. should just be r at the front.
2. ssh -i identityFile ec2-user@<your host ip address>
3. ssh-add ~/.ssh/<your key>.pem
4. eval "$(ssh-agent -s)" - starts the ssh-agent
5. Finally, ssh ec2-user@<your host ip address>
Install necessary software.

You'll need git at a minimum. Rest is app-specific. This example is for nvm/node/yarn.
1. sudo yum install git. which git to make sure it's working.
2. Install nvm: curl -o- [https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh](https://raw.githubusercontent.com/nvm-sh/nvm/v0.34.0/install.sh) | bash
3. Install node: nvm install node
4. Install your version: nvm install <your local version #>
5. Install yarn: npm install -g yarn@<your version #>
Configure git.

Your local is already set up to ssh nicely with git. New EC2 instance isn't (yet).
1. ssh-keygen -t rsa -b 4096 -C "your_email@example.com" Use an empty passphrase when prompted.
2. Add the key to your ssh-agent with eval "$(ssh-agent -s)" and ssh-add ~/.ssh/id_rsa
3. If you have problems with this, see step 2 above.
4. You then need to copy the content of this newly generate id_rsa file into your github security. use pbcopy < ~/.ssh/id_rsa.pub or vim ~/.ssh/id_rsa.pub to do this.
5. If you need to debug, git has a guide here.
Set up the directory.

Finally, clone the repo.
1. git clone <repo .git>
2. yarn
3. Any files not pushed to github, like .env, need to be copied over. use scp <drag .env file to terminal> ec2-user@<your host ip address>
4. if you need this to run while you're not in ec2 terminal, use pm2 start <app.js or runfilename.js>

Conclusion

There are many ways to configure an EC2 instance and set it up, but I hope this barebones guide is useful to beginners debugging their deployment. I'll be writing a future post that demonstrates ways to set up testing, logging, and CICD on EC2.

A Hitchhiker’s Guide to RegEx

gortron — Sun, 26 Apr 2020 17:49:17 +0000

tl;dr

At some level, most files and programs you interact with are strings. RegEx helps you find very specific string patterns. With a few simple regex building blocks, you can make remarkably complex search queries. Read on for a deeper explanation and a beginner’s guide on how to get started with regex.

So, you’re learning to be a hacker, huh? I bet you’ve run into some variant of this problem, then: go find something specific in a large set of data. I’m being deliberately vague, here. Information, and ways of searching it, comes in many formats. By now, you’ve probably got a handle on hashes, arrays, strings, and the like. And you’re getting comfortable with a few nifty enumerators (What’s your favorite? I like Ruby’s .select method. More on that later.).

But you’re here because someone has asked you to find a whacky, difficult-to-grasp data element and your normal tools aren’t cutting it. You Google’d the problem. Some (generous, saintly)random on StackOverflow solved a similar problem for someone else a few years ago. They said something about ‘regex’, and then a shared a line of code with an alarming number of /’s and \’s. And you might be thinking, okay, WTF is this? RegEx doesn’t make a great first impression, but trust me, you want to sit down on the couch next to RegEx at your friend’s party. It has .~Special Powers~.

RegEx is short for Regular Expression. A Regular Expression is a special string used for pattern-matching and searching. One of the best features of regex is its portability: it has a syntax you learn one, but use in many contexts. Most languages have an enumerator that helps you search for a pattern (like Ruby’s .find), but what makes regex really powerful is the level of control it gives you over that search pattern.

A regular expression is comprised of characters. You know, like ASCII characters. Specifically, a regex is comprised of two types of characters: literal, and meta. Literal characters are ‘simple’ characters; letters, numbers, and punctuation. Metacharacters, like { } [ ] ( ) ^ $ . | * + ? \, are ‘complex’ characters. I’m oversimplifying the point, but essentially metacharacters are the characters that have special meaning in the context of regex. Metacharacters convey richer information than literal characters.

Remember how I said regex was powerful? With just characters and metacharacters, you can search for any ASCII string, specifically, or strings with a more general search parameters.

Let’s look at a simple example. We’ve got a filename, and we’re trying to parse information from that filename. The filename is Talking Heads - Speaking in Tongues - This Must Be the Place (Naïve Melody).mp3 How can we grab the Artist, Album, Song Name, and Filetype? With Ruby, maybe we could try to .split around the “-” characters, but that won’t help us out with the Filetype, where we want to split based on a “.”. Take a look at this regexp cookbook and see if any of these ingredients might help us:

. is a wildcard. It represents *any* ASCII character.
\ let’s us search for metacharacters, such as .[{(\|$^
\d is for *any* number 0–9
\w is for *any* whitespace
[ ] let’s us match specific characters in a given slot
{ } let’s us catch repetition
* represents 0 or more of the characters after a character
+ represents 1 or more of the characters after a character
? we can use this to make character optional
( | ) let’s us search based on multiple parameters

What looks helpful? It looks like we’re dealing with hyphens, whitespace, AND .’s. Let’s chain a few of these together into one regex.
Let’s say string = Talking Heads - Speaking in Tongues - This Must Be the Place (Naïve Melody).mp3

Then string.split(/\w - |\./) returns:
[“Talking Head”, “Speaking in Tongue”, “This Must Be the Place (Naïve Melody)”, “mp3”]

The easiest way to learn is to do. Use your preferred interactive coding environment to experiment with regex. Or, see the Further Reading section below for other resources for learning this powerful tool.

Making Your First Twitch Bot

gortron — Sun, 19 Apr 2020 22:19:00 +0000

Introduction

In this post, I'll walk through implementing a Twitch bot. Specifically, I'll be going through initial configuration to connect to Twitch with Node and the tmi.js package, as I feel the documentation available makes this less straightforward than it should be.

I'll be referencing code from this repo, which I put together for this post.

Implementation

Start with the instructions and sample code (or pull from my GitHub repo, linked above) that Twitch provides here. Once you've created an account for your bot, registered it for the tmi.js packages' OAuth, and have a local clone of my/or GitHub's repo, then you're ready to set up your .env file and bot.js script to connect to Twitch.

The code Twitch provides in their getting started guide asks you to put your OAuth credentials and other environment variables directly into the bot.js script. This is an anti-pattern, and makes it easy to expose credentials you want to keep secret.

Instead, we'll use the dotenv.js package to manage environment variables.
1) Add the dotenv package with yarn add dotenv
2) Add a .env file to your project's root directory
3) Add the following code to the .env file:

BOT_USERNAME=<YOUR BOT'S USERNAME>
OAUTH_TOKEN=<YOUR BOT'S TMI OAUTH TOKEN>
CHANNEL_NAME=<TARGET CHANNEL'S NAME>

Example syntax:

BOT_USERNAME=mytwitchbot
OAUTH_TOKEN=oauth:fsjgslgd4jkdfgsds5sjskl
CHANNEL_NAME=mytwitchusername

4) Update code in bot.js to reference the environment variables:

const opts = {
    identity: {
      username: process.env.BOT_USERNAME,
      password: process.env.OAUTH_TOKEN
    },
    channels: [process.env.CHANNEL_NAME]
  };
  const target = opts.channels[0]

Your set up is complete! To run, call node bot.js in your shell.

Conclusion

In this post, you reviewed how to configure your environment variables to connect to Twitch. I hope it was helpful. Feel free to reach out to me if you have trouble connecting your own bot to Twitch.

A Hitchhiker's Guide to MVC

gortron — Mon, 13 Apr 2020 17:44:52 +0000

Background.

MVC, or model-view-controller, is a prevalent software design pattern. It was pioneered by Trygve Reenskaug, and introduced in 1979 after a trip to the Xerox Palo Alto Research Center. (Never heard of the Xerox PARC? You can learn more about its amazing story here.) Why is MVC, a pattern which pre-dates the internet, still taught as an axiom of software design for web apps 40 years later? To answer that question, we first need to talk about clean code.

Any developer will tell you that in many cases getting the code to run is a lot easier than making the code clean. While everyone has their own taste as to what clean code is, generally clean code does a good job of being organized and easy-to-read. Like many system, code demonstrates entropy; the code will trend towards an inherent state of disorder. It takes hard work to keep code ordered and clean. MVC remains popular because it is indispensable in this effort. So what is it?

Concept.

MVC stands for model-view-controller, and it is a framework for thinking about how human users can interact with programmed models (be they abstract or tangible). It's particularly useful in designing user-interfaces, including web apps. In a system designed around MVC, all responsibilities are split between the view, the controller, and the model. Let’s talk about the domain of a restaurant, and explore what these mean through analogy.

Fig. 1: A simplified view of the MVC framework.

Example.

View - Customers show up to a restaurant and sit down at a table, where they will view possible meal options on a menu and eventually their resulting meal. In most restaurants, to get a meal, you don’t cook it your self at the table. You give the waiter your order.

Controller - Waiters act as the go-between for customers and chefs. They take meal orders from customers, give the orders to the chefs in a structured format, and eventually return the resulting meal to the specific customer that ordered it. Have you ever eaten at a restaurant where a waiter seemed to have perfect control of the situation? Where they seemed to know exactly where and when things needed to happen? The secret of any great waiter is their friendship with the chef.

Model - A chef’s only job is to make meals. In the kitchen, they’ve got the two things they need to make a great meal: the cooking methods they’ve perfected, and the necessary ingredients on hand. A chef receives a customer’s order from a waiter, makes the customer’s meal, and gives the meal back to the waiter who puts it on the customer’s table. At a great restaurant, a chef is a model to the craft of cooking.

In terms of software, a view is responsible only for rendering information to the user. A controller is responsible only for directing various user requests to the model, and returning the model’s response. And a model is responsible only for the logic and handling of data.

A lot of popular web app frameworks, including Rails and Express.js, leverage MVC. Let's work with this example in Rails.

Quick Code.

Rails is a very opinionated webapp framework that strongly encourages developing within the MVC framework. Here's a high-level view of how Rails web apps are structured:

Fig 2. A Rails system diagram demonstrating an MVC pattern.

But, one of the advantages of being opinionated is that Rails is fast. One line in your terminal does a lot of the heavy, tedious lifting of building a webapp.

$ rails new restaurant

After you've started a new Rails app, you'll notice a directory in that project's root called app. Let's look what's inside there.

Fig 3. The file structure of a new Rails app.

Wild! Rails insists that we build in MVC. And why not? MVC is a popular design pattern for a reason. Let's go over some of the benefits of sticking to MVC.

Benefits.

As a convention, MVC sets expectations for the underlying code and makes it easier to collaborate. If you asked me to help you debug a web app you had designed around MVC, right out of the gate we would have a shared understanding and language of the high-level patterns of your program. This saves a lot of time and headache in collaboration.
MVC helps us separate concerns by assigning responsibilities across controllers, views, and models. Separation of Concerns is an essential design principle which developers use to build and maintain clean code. A modification to one part of our application will not effect the whole, and debugging will be more efficient. When we develop web apps around MVC, we stand on the shoulders of giants like Trygve Reenskaug who thought hard about separations of concerns about the past.
MVC makes it much easier to parallel develop and ship clean code faster. Because it separates concerns, MVC allows for effective parallel development. Different engineers can work on the model, view, and controller concurrently.

I hope this Hitchhiker’s Guide has helped you understand the MVC framework.

Can you write a JS function that memoizes Fibonacci?

gortron — Mon, 06 Apr 2020 03:04:14 +0000

Introduction

In this post, I'll walk through implementing the Fibonacci sequence in JavaScript, and then improving the approach by memoizing previous returns from the function. You can think of memoizing like implementing a 'cache' which stores information from previous calls to a function. In JavaScript, the best approach to take advantage of closures and implement an outer function, which creates the cache as a map, and an inner function, which inherits the scope of the outer function and can write/read from the cache.

1: Recursive Fibonacci

Reviewing recursion is outside the scope of this post, but I wanted to share this approach with you as the memoize function will incorporate this code. This approach to fibonacci solves in O(log n) run time.

const fibonacci = (n) => {  
  if (n < 3) {
    return n - 1;
  }
  return fibonacci(n - 1) + fibonacci(n - 2);
};

2: Memoize Fibonacci

Memoizing the recursive function above will make a tradeoff between speed and space. Implementing the cache will take O(n) space complexity, but the best case for the solution will become O(1) instead of O(log n).

There are degrees of increasing utility (or, intelligence) to memoizing the fibonacci function.

Only cache answers for a given n, e.g. fib(20) would not benefit from previous calls of fib(21) or fib(19)
Cache all solutions up to a given n, e.g. fib(20) should cache fib(1...20), but fib(21) doesn't take advantage of fib(20)
Given an n greater than a previous n, leverage the solution for the previous greatest n, e.g. fib(21) should leverage fib(20)

The approach I implement below is the latter of the three. It 'caches' all previous solutions to the fibonacci function, including the recursive calls. So, memoizeFib(5) will cache the fibonacci number that corresponds to (1...5).

const memoizeFib = (n) => {
  const cache = {};
  const fibonacci = (n) => {
    if (cache[n]) {
      return cache[n];
    }

    if (n < 3) {
      cache[n] = n - 1;
      return n - 1;
    }

    let solution = fibonacci(n - 1) + fibonacci(n - 2);
    cache[n] = solution;
    return solution;
  };
  return fibonacci;
};

You would call this code by creating an instance of the memoizeFib function (which creates the cache and returns the fibonacci function), and passing that instance an argument. Example:

const memoizedFib = memoizeFib()
memoizedFib(5) // returns 3

Conclusion

Closures and memoizing in JavaScript are not only used to improve performance and prevent repetitious, expensive work. They're used for data security and privacy. Consider that, for the above example, the cache for memoizedFib is not accessible outside the scope of memoizedFib.

If you want to play around with the code above, you can fork the solution I implemented (with tests) on CodePen here.

DEV Community: gortron

Animating text over images in JS

Introduction

Solution

Conclusion

Using Emotion for CSS-in-JavaScript

Introduction

1) Separate JS and CSS

2) CSS-in-JS

Conclusion

An Overview of Server-side Rendering

React: making a store from createContext and useReducer

Introduction

Approach

Conclusion

React custom hooks: a clean approach to fetch

Introduction

Code

Conclusion

Environment Variables with pm2: The Right Way

Introduction

Solution

Conclusion

Deploying to AWS with Travis via ssh

Introduction

Execution

1) Set up an ssh key for Travis

2) Set up your Travis custom deployment

3) Write a deploy script for Travis to execute

Conclusion

AWS EC2 Deployment Guide

Introduction

Steps

Conclusion

A Hitchhiker’s Guide to RegEx

tl;dr

Further Reading:

Making Your First Twitch Bot

Introduction

Implementation

Conclusion

A Hitchhiker's Guide to MVC

Background.

Concept.

Fig. 1: A simplified view of the MVC framework.

Example.

Quick Code.

Fig 2. A Rails system diagram demonstrating an MVC pattern.

Fig 3. The file structure of a new Rails app.

Benefits.

Can you write a JS function that memoizes Fibonacci?

Introduction

1: Recursive Fibonacci

2: Memoize Fibonacci

Conclusion