DEV Community: Daniel Hintz

Exploring CSS: Micro-frameworks (Tailwind)

Daniel Hintz — Thu, 04 Feb 2021 00:34:43 +0000

Next up in this series is trying out Tailwind CSS, another framework. I've heard a lot about how great Tailwind is, so I've really wanted to check it out for quite some time, what better time than now? Tailwind is:

A utility-first CSS framework packed with classes like flex, pt-4, text-center and rotate-90 that can be composed to build any design, directly in your markup.

There is a lot more to this framework than there was with Plume, so just know that I'm only scratching the surface at this point.

What's To Like

Documentation

My first thought when I looked at the documentation was "Wow, there's a LOT more to unpack here than there was with Plume!" but the good news is that the documentation is top-notch. Not only does it do an excellent job of walking through how to use Tailwind, but it also contains instructions for related topics, like what is a pre-processor or how to build JavaScript components.

Set Up

There are a couple of options for setting up Tailwind, and the documentation does a great job of talking you through not only how to set it up with each method, but also why you might want to use each method. The easiest way is through a CDN. All you have to do is include the link in your HTML and you're done. Nothing to install or download. However; the documentation warns against this as you lose a lot of the best features. The recommended method is to install Tailwind as a PostCSS plugin, but I didn't go this route, mostly because I haven't gotten to exploring preprocessors yet - one thing at a time. The last option is to use NPX to install Tailwind into your project as a CSS file: npx tailwindcss-cli@latest build -o tailwind.css. This is the route I took and, as a bonus, it is pretty close to what I did with Plume.

Utilities & Components

This is where Tailwind really shines. Where Plume is awesome for quickly setting up the basic components across your site, but not great at customizing individual elements, Tailwind is just the opposite. There are hundreds of options in Tailwind, and they are all applied to the individual element, rather than making broad strokes across the site. As well, they are designed very tactically, meaning that each option only does one thing and can be chained with other options to get to the full effect that you are going for. This means that, if I know I want to do something like create a flex-box that is centered in the page, all I have to do is look at the documentation for each "piece" of the formatting (display, sizing, spacing, and background), then just go down the list of options and copy/paste the class that gives the effect I want.

Additionally, Tailwind gives you some pretty great pre-made components for free! I particularly like the select and dropdown menus. You'll generally need to build your own components using the provided utilities; however, unless you pay for Tailwind's premium content.

Customization

Tailwind allows you to customize everything and create a very detailed "theme" for your site styling. This goes well beyond what Plume can do, but is also a much heavier effort. Although it doesn't seem too bad to customize, and the documentation does a great job of walking you through it, I decided to see how far I could get without doing any customization, so it's outside the scope of this article. One really cool thing I did see; however, is that you can customize on several "layers" to help you avoid specificity clashes!

Component Extraction and Abstraction

A major drawback of Tailwind is that there is a LOT of duplicated code in your HTML (more on this below). Fortunately, this can be avoided by extracting common components or abstracting the styles using Tailwind's @apply feature. This either requires very thoughtful planning, or a retro-active approach (after you've finished, go back and find/abstract your more common components), the latter being not so ideal. But I imagine once I've used it a few times and I'm more familiar I'll have a pretty good idea of what I'll want to abstract away before even getting started. Unfortunately, when I tried to use this feature I was unable to get it to work since I'm not using any CSS preprocessors. A project for another time.

Responsiveness

Unsurprisingly, Tailwind components support responsive design. But the thing is, since everything is applied to each component, Tailwind makes it insanely easy to keep your site consistently responsive. It has built-in breakpoint prefixes, so you can tell each component what to do when the screen is small, and then how to change when it gets to a medium size, for example. Personally, breakpoints are one of my biggest pet-peeves about writing CSS because it tends to feel like I'm re-writing the entire style for each breakpoint. I also get really ADHD about it and end up with two dozen breakpoints, each changing a few things at a time. Time consuming, inefficient, and unwieldy. The fact that Tailwind saves me from myself in this regard might make this my favorite feature!

Transformations & Transitions

Tailwind even includes transformations and transitions! For my simple test I didn't use these, but based on how easy all the other utilities have been to use, I'm excited to try these out soon to make the experience of writing transitions better.

What's Not To Like

Learning Curve

There is a ton of functionality in Tailwind. This makes it extremely powerful, but it also makes it feel like I have to re-learn CSS. As I use it more and more, it will undoubtedly become second nature and this won't be an issue anymore, but it certainly takes some getting used to at first.

Code Duplication

As I mentioned before, a big drawback of Tailwind is that there is a LOT of duplicated code. In fact, even in my simple testing layout, I would need to manually copy/paste the entire HTML code from the first article to each of the following ones, and let's not even get into what a nightmare it would end up being if you are building HTML elements programmatically in JavaScript! For example, take a look at all the code I'd need to copy for each and every similar button that I want to put on my page:

<button class="bg-gradient-to-r from-blue-500 to-blue-900 my-4 max-w-max px-8 py-2 text-white font-bold">Cool Button</button>

Luckily, if you're using a pre-processor, the brilliant creators have already thought of this and they have us covered by including extraction and abstraction features as mentioned in the To-Like section. It requires another step, but that's a small price to pay for all of the benefits above.

The Dreaded Paywall

While there are some very generous free components available, you'll need to fork out some cash in order to get all of them. Some of these paywalled components (buttons for example) are on the more basic side too. The good news, of course, is that you can build anything you want using their utilities which are all free, it just takes time and practice.

Verdict

Tailwind is absolutely amazing! I almost feel like, if I could start all over, it might have been great to learn Tailwind first and THEN learn custom CSS. It's powerful and customizable enough to perfectly create any style or element that you could ever want, but at the same time it's surprisingly simple to use thanks to the very deliberate and tactical design, and the accompanying documentation. Definitely beats writing your own CSS, especially if you use a preprocessor and can abstract out some of those common, Tailwind-heavy elements.

As always, here's my testing layout:

And the code to make it:

<!DOCTYPE html>
<html lang="en">
  <head>
    <title> </title>
    <meta name="viewport" content="width=device-width, initial-scale=1"> 
    <link rel="stylesheet" href="tailwind.css">  
    <link rel="stylesheet" href="style-tailwind.css">
  </head>
  <body>
    <div class="bg-gray-100 text-gray-500 p-5">

      <article class="flex flex-col flex-wrap max-w-4xl px-4 pb-9 mx-auto bg-white mb-5">
        <figure class="mx-auto pb-4"> 
            <h3 class="text-5xl pt-3 pb-8 font-medium font-serif text-center">Project 1</h3>
            <img src="http://placekitten.com/g/600/300" alt="Visual Store"/>
            <figcaption>
                <p class="text-center text-sm">This is the first project in the list.</p>
            </figcaption>
        </figure>
        <p class="text-left pb-3 text-lg"><strong>Main Features:</strong> Some cool things are in this.</p>
        <p class="text-left pb-3 text-lg"><strong>Backend Techs:</strong> Here's what I used to build the API.</p>
        <p class="text-left pb-3 text-lg"><strong>Frontend Techs:</strong> Here's how the site was built.  Make sure to include Plume!</p>
        <span class="mx-auto">
            <button class="bg-gradient-to-r from-blue-500 to-blue-900 my-4 max-w-max px-8 py-2 text-white font-bold">Cool Button</button>
            <button class="bg-green-500 my-4 max-w-max px-8 py-2 text-white font-bold">Good News!</button>
            <button class="bg-red-500 my-4 max-w-max px-8 py-2 text-white font-bold">Bad News!</button>
        </span>
      </article>

      <article class="flex flex-col flex-wrap max-w-4xl px-4 pb-9 mx-auto bg-white mb-5">
        <figure class="mx-auto pb-4">  
            <h3 class="text-5xl pt-3 pb-8 font-medium font-serif text-center">Project 2</h3>
            <img src="http://mrmrs.github.io/photos/whale.jpg" alt="Visual Store"/>
            <figcaption>
                <p class="text-center text-sm">This is Number 2.</p>
            </figcaption>
        </figure>
        <p class="text-left pb-3 text-lg"><strong>Main Features:</strong> Some cool things are in this.</p>
        <p class="text-left pb-3 text-lg"><strong>Backend Techs:</strong> Here's what I used to build the API.</p>
        <p class="text-left pb-3 text-lg"><strong>Frontend Techs:</strong> Here's how the site was built.  Make sure to include Plume!</p>
        <span class="mx-auto">
            <button class="bg-gradient-to-r from-blue-500 to-blue-900 my-4 max-w-max px-8 py-2 text-white font-bold">Cool Button</button>
            <button class="bg-green-500 my-4 max-w-max px-8 py-2 text-white font-bold">Good News!</button>
            <button class="bg-red-500 my-4 max-w-max px-8 py-2 text-white font-bold">Bad News!</button>
        </span>
      </article>

      <article class="flex flex-col flex-wrap max-w-4xl px-4 pb-9 mx-auto bg-white mb-5">
        <figure class="mx-auto pb-4"> 
            <h3 class="text-5xl pt-3 pb-8 font-medium font-serif text-center">Project 3</h3>
            <img src="http://mrmrs.github.io/photos/cpu.jpg" alt="Visual Store"/>
            <figcaption>
                <p class="text-center text-sm">Third entry is the charm.</p>
            </figcaption>
        </figure>
        <p class="text-left pb-3 text-lg"><strong>Main Features:</strong> Some cool things are in this.</p>
        <p class="text-left pb-3 text-lg"><strong>Backend Techs:</strong> Here's what I used to build the API.</p>
        <p class="text-left pb-3 text-lg"><strong>Frontend Techs:</strong> Here's how the site was built.  Make sure to include Plume!</p>
        <span class="mx-auto">
            <button class="bg-gradient-to-r from-blue-500 to-blue-900 my-4 max-w-max px-8 py-2 text-white font-bold">Cool Button</button>
            <button class="bg-green-500 my-4 max-w-max px-8 py-2 text-white font-bold">Good News!</button>
            <button class="bg-red-500 my-4 max-w-max px-8 py-2 text-white font-bold">Bad News!</button>
        </span>
      </article>

    </div>
  </body>
</html>

That's it, no custom CSS required!

Exploring CSS: Micro-Frameworks (Plume)

Daniel Hintz — Sat, 30 Jan 2021 01:08:25 +0000

By now, I've spent a LOT of time learning how to effectively use CSS from scratch and I think it's finally time that I stop doing that and allow myself to make my life easier. To do that, I will be doing an "Exploring CSS" Series where I take a look at libraries, pre-processors, frameworks, and the like to find out which I like and can start using going forward.

This is my first entry in the series, and I'll be looking at a micro-framework called Plume. Plume is:

A lightweight and highly themeable CSS Micro-Framework. Plume is meant to be the lowest CSS layer on your app. [Plume is great for] working on a small to medium application, if you feel that you don't need all the larger frameworks' features, or if you just want to code and grow all the style by yourself. Plume offers a solid, highly customizable and extendable start point.

Sounds like a great starting point to me!

What's To Like

Set Up

First of all, Plume is extremely simple and quite quick to get up and running. Just download the library (or install it), add the link to your HTML, and add class=”plume” to the body tag and you’re ready to go. You could also have certain "plumed" containers if you would like since it's scoped in your HTML, hence needing the class="plume" line. In that case, you would just include that in your wrapper element rather than the body tag.

Customization

Next up is customization. My biggest problem with things like Bootstrap is that it creates a sort of cookie-cutter website where nothing really stands out all that much. Plume; however, is all about creating a custom theme, and it's really easy to do (you barely even need to know CSS). Everything you need is on the Plume webpage, that's right - a single page. You just go through a list of supported attributes and customize each one however you like. You can see what it will look like on the page itself as you play with each option. Once you have your theme put together, just click the </> button and copy/paste the content into the top of your CSS file since it’s just a series of CSS variables. Want to make a change later on? Just go to your CSS and change the value for the appropriate variable and watch your whole site change to reflect it!

Another benefit of this variable approach? Since it’s so quick and easy to set up a custom theme, you can have a whole bunch of different themes on your site! Maybe you want different types of containers to have different coloring and font, or maybe you want your user to be able to choose between different theming options. It's easy to do, you just need a simple JavaScript script to change the relevant variables in your CSS :root and you're good to go. In fact, Plume has its own theme picker on the site to demonstrate this concept. I think adding that element of personal customization is pretty cool, and using Plume, it’s no sweat.

Components

Then there's actually building your site. Plume proved to be excellent for quickly building out basic site structure and linking it all to a home-made, consistent theme. It comes with some basic styled components, like various types of form inputs and buttons that will automatically sync up with your custom theme thanks to everything linking back to those CSS variables. It also sets up your basic container styling (sizing, alignment, spacing, etc.) for you, so no more wrestling to get your content centered.

All of the components are added purely by adding a class to your HTML elements. There is nothing else that you need to do. So say you want an element with everything centered except for the paragraph text. All you need to do is write some HTML:

<div class="pm-container pm-ground pm-text-center">
  <h2>Example</h2>
  <p class="pm-text-left">Some Text</p>
  <p class="pm-text-left">Some Text</p>
  <button class="pm-btn-success">Push Me!</button>
</div>

and you'll get this:

Responsive

And finally, Plume components are responsive out of the box, which is a huge win. It doesn't do a whole lot to help you with your site structure (grids, flexbox, layout templates, etc.), but that's not what these micro-frameworks are for, at least in my mind. You own setting up your site's structure, then you can sit back and let Plume make it look good!

What's Not To Like

Limitations

The options are pretty limited; however, with only about a dozen component families included. Using only Plume, I was able to get my site’s basic layout looking pretty darn good within an hour, but there is still a lot of individual element customization that I would likely want to add in from this point. This is, of course, by design. Remember the creator states "Plume offers a solid, highly customizable and extendable start point." So just know that you are still going to need to do some custom CSS work after you've "plumed up" your site.

Verdict

As this is the first one I'm evaluating, it's hard to say at this time. But just going on Plume's own merits and not comparing to anything else, I love it! I would absolutely use this as my starting point when I'm staring at a blank page. This framework takes a HUGE chunk of the tedious stuff off my plate and makes for a great consistent template for my site to be built upon.

Here's my simple testing layout using nothing but Plume:

And of course, here's the code:

// HTML

<!DOCTYPE html>
<html lang="en">
  <head>
    <title> </title>
    <meta name="viewport" content="width=device-width, initial-scale=1">   
    <link rel="stylesheet" href="plume-css/lib/plume-all.css">   <!-- Add Plume as a Stylesheet -->
    <link rel="stylesheet" href="style.css">
  </head>
  <body class="plume">  <!-- Apply Plume to full site -->
    <div class="pm-container pm-surface">

      <article class="pm-text-center pm-container pm-ground">
        <figure class="pm-text-center"> 
            <h3 class="pm-font-secondary">Project 1</h3>
            <img src="http://placekitten.com/g/600/300" alt="Visual Store"/>
            <figcaption>
                <p class="pm-font-primary">This is the first project in the list.</p>
            </figcaption>
        </figure>
        <p class="pm-font-primary pm-text-left"><strong>Main Features:</strong> Some cool things are in this.</p>
        <p class="pm-font-primary pm-text-left"><strong>Backend Techs:</strong> Here's what I used to build the API.</p>
        <p class="pm-font-primary pm-text-left"><strong>Frontend Techs:</strong> Here's how the site was built.  Make sure to include Plume!</p>
        <button class="pm-btn-gradient">Cool Button</button>
        <button class="pm-btn-success">Good News!</button>
        <button class="pm-btn-error">Bad News!</button>
      </article>

      <article class="pm-text-center pm-container pm-ground">
        <figure class="pm-text-center"> 
            <h3 class="pm-font-secondary">Project 2</h3>
            <img src="http://mrmrs.github.io/photos/whale.jpg" alt="Visual Store"/>
            <figcaption>
                <p class="pm-font-primary">This is Number 2.</p>
            </figcaption>
        </figure>
        <p class="pm-font-primary pm-text-left"><strong>Main Features:</strong> Some cool things are in this.</p>
        <p class="pm-font-primary pm-text-left"><strong>Backend Techs:</strong> Here's what I used to build the API.</p>
        <p class="pm-font-primary pm-text-left"><strong>Frontend Techs:</strong> Here's how the site was built.  Make sure to include Plume!</p>
        <button class="pm-btn-gradient">Cool Button</button>
        <button class="pm-btn-success">Good News!</button>
        <button class="pm-btn-error">Bad News!</button>
      </article>

      <article class="pm-text-center pm-container pm-ground">
        <figure class="pm-text-center"> 
            <h3 class="pm-font-secondary">Project 3</h3>
            <img src="http://mrmrs.github.io/photos/cpu.jpg" alt="Visual Store"/>
            <figcaption>
                <p class="pm-font-primary">Third entry is the charm.</p>
            </figcaption>
        </figure>
        <p class="pm-font-primary pm-text-left"><strong>Main Features:</strong> Some cool things are in this.</p>
        <p class="pm-font-primary pm-text-left"><strong>Backend Techs:</strong> Here's what I used to build the API.</p>
        <p class="pm-font-primary pm-text-left"><strong>Frontend Techs:</strong> Here's how the site was built.  Make sure to include Plume!</p>
        <button class="pm-btn-gradient">Cool Button</button>
        <button class="pm-btn-success">Good News!</button>
        <button class="pm-btn-error">Bad News!</button>
      </article>

    </div>
  </body>
</html>

// CSS

:root {   /* downloaded from Plume Site */
  --pm-primary-color: #309AFD;
  --pm-secondary-color: #00004b;
  --pm-app-surface-color: #F1F2F3;
  --pm-app-ground-color: #fff;
  --pm-mark-border-radius: 0px;
  --pm-button-border-radius: 0px;
  --pm-input-border-radius: 0px;
  --pm-input-border-width: 1px;
  --pm-pre-code-border-radius: 0px;
  --pm-app-text-color: #848586;
  --pm-app-base-font-size: 19px;
  --pm-app-line-height: 1.2rem;
  --pm-app-container-padding: 1rem 2rem;
  --pm-app-container-max-width: 900px;
}

html {
  line-height: 1.15; /* 1 */
  -webkit-text-size-adjust: 100%; /* 2 */
}

body {
  margin: 0;
}

Convert Your Old Class Components to Functions. Just Do It Already!

Daniel Hintz — Sat, 23 Jan 2021 02:41:51 +0000

It's now generally acknowledged that using hooks in React is better than using classes. There are a ton of blogs and discussions on the subject and over time they have inched more and more uniformly toward hooks. Yet my React training still used classes, and I know that many developers still use classes today as well. My guess is a lot of them do so for the same reason I've been sticking to classes: I'm already familiar with class-based stateful components, and I'd have to re-learn how to implement state and lifecycles if I make the switch. Maybe that's not the greatest reason, but with so much out there that needs to be learned, it is hard to prioritize learning a new way of doing something when the "old way" is already working perfectly for me today.

But here's the thing - in React interviews, they expect you to use hooks. If you use a class you get the toughest interview question of them all..."Why did you do it that way?" 😨...😰...😢

Luckily, after a ahem learning experience finally convinced me it's time to learn about hooks, I found out they're really not bad at all, at least in the simplest implementations.

There are two "main" hooks and that was all I am initially concerned with: useState and useEffect. So below, I'm going to create an unstyled digital clock component, using both classes and hooks, to show off how to use both of these. At the end I'll do a side-by-side comparison.

Class

Before we can even get started, we need to set up the component. first, import React, and its Component class, and then create our Clock component that inherits from it.

import React, {Component} from 'react';

export default class Clock extends Component {};

Then, let's start by setting up our state. We need to create a Date Object representing the current date/time and set it in the component's state with a key of currentTime.

  state = {
    currentTime: new Date
  };

And then we can call our render function to display that value in the DOM. To convert it to a time string, we'll use toLocaleTimeString().

import React, {Component} from 'react';

export default class Clock extends Component {
  state = {
    currentTime: new Date
  };

  render() {
    return(
      <h2>{this.state.currentTime.toLocaleTimeString()}</h2>
    );
  };
};

And that will display the time on the page. But to make it a clock, we need it to "tick" each second as time goes by. We start by defining a tick() function that sets the state to the new moment in time. Then we want to call that tick function every second by setting up a one second interval. For the interval, we need to wait until the component is mounted, then start the interval timer. To do something "once the component is mounted" we use the componentDidMount lifecycle method. Finally, if and when the Clock component is unmounted, we'd want the interval to stop so that the computer isn't constantly counting for no reason. To do something "once the component is unmounted" we use componentWillUnmount which runs just before the component is destroyed.

import React, {Component} from 'react';

export default class Clock extends Component {
  state = {
    currentTime: new Date
  };

  tick() {
    this.setState({currentTime: new Date});
  };

  componentDidMount() {
    this.int = setInterval(() => this.tick(), 1000);
  };

  componentWillUnmount() {
    clearInterval(this.int);
  };

  render() {
    return(
      <h2>{this.state.currentTime.toLocaleTimeString()}</h2>
    );
  };
};

And now we have ourselves a ticking clock!

Hooks

Now, let's see how to do the exact same thing using hooks. Again, we need to start by setting up the component. Notice we need to move the export statement to the bottom now.

import React, {useState, useEffect} from 'react';

const Clock = () => {};

export default Clock;

Then, once again, we'll set up our state with the same key & value. Here, we're defining two separate variables at the same time. currentTime is our key, and setCurrentTime equates to calling this.setState() in a class. Finally, calling useState actually calls setCurrentTime, so you need to pass an argument to set up the initial state, in this case a Date object.

const [currentTime, setCurrentTime] = useState(new Date);

What we render will remain unchanged, but since we're using a functional, not class, component we just need to return the JSX, we don't need to use the render() function.

import React, {useState, useEffect} from 'react';

const Clock = () => {
  const [currentTime, setCurrentTime] = useState(new Date);

  return(
    <h2>{this.state.currentTime.toLocaleTimeString()}</h2>
  );
};

export default Clock;

And now it's time to get that clock a-ticking. We'll start by defining that tick() function again which sets the state to the new moment. We do this by defining a normal function (there's no class for instance methods) which uses our new setCurrentTime function variable to change state. Where things get interesting is, since there's no lifecycle methods without the class, we need to use useEffect(). This function actually includes both the componentDidMount and componentWillUnmount methods all in one. We still need to define our interval and set the callback to tick(), but now we will have our useEffect function return another function. This returned function stands in for componentWillUnmount and should be used to clean up any services that were started once the component is destroyed.

import React, {useState, useEffect} from 'react';

const Clock = () => {
  const [currentTime, setCurrentTime] = useState(new Date);

  function tick() {
    setCurrentTime(new Date);
  };

  useEffect(() => {
    let int = setInterval(() => tick(), 1000);
    return cleanup => {
      clearInterval(int);
    };
  });

  return(
    <h2>{currentTime.toLocaleTimeString()}</h2>
  );
};

export default Clock;

Lastly, we can take this one step further by converting our functions to arrow functions. Take a look at the side-by-side below to see the refactored component.

Comparison

Hooks	Class

The functional way looks a lot more concise doesn't it? So what do you think...are you convinced to start using hooks yet, or do you need to learn the hard way like I did?

Since I like to have defined rules so that I can just follow down the list, here is your Converting Class To Function Checklist:

Change the import statement
- From: import React, {Component} from 'react'
- To: import React, {useState, useEffect} from 'react'
Change the component declaration
- From: export default class Clock extends Component {}
- To: const Clock = () => { & move the export to the end of the file
Change the state definition
- From: state = {currentTime: new Date};
- To: const [currentTime, setCurrentTime] = useState(new Date);
Drop this.state. from anywhere that uses state data
Change any this.setState() to the new function defined in useState
Change any instance methods/variables to regular functions/variables
- From: tick() {} / this.int =
- To: function tick() {}; / int =
- Alt: convert function to arrow function tick = () => {}
Finally, change any lifecycle methods to useEffect()
- From: componentDidMount() {}; / componentWillUnmount() {}
- To: useEffect() which returns a cleanup function

Email and Text from Rails

Daniel Hintz — Thu, 14 Jan 2021 22:40:40 +0000

Hey Everyone!

I've learned, and applied, a lot in the last few months, but there was a big glaring gap that I just hadn't addressed yet, and that was messaging users outside of my own app. So, to finally get this addressed, I wanted to add functionality to my recipes app to send a shopping list to my users by email and/or text messaging.

Email was pretty obvious, there are classes built into Rails called ActionMailers - these allow you to build email templates similar to how you would build a view in a Rails site, and then sends out that email. Text messaging required a little searching, but ultimately there was a gem that was perfect for my purposes. Here, I'll go through how to set up the emailing functionality in Rails, and then how that will translate into SMS capability using the sms-easy gem.

This is broken down into 4 high-level steps:

Configuring Rails
Creating your Mailer
Setting up your workflow
Converting the Mailer to use an SMS address

Sending Emails

Like I said above, to send emails from Rails, there is a built in functionality called ActionMailers.

Configure Rails Environment

The first step for using ActionMailers is to get them configured in our app. First, we'll add some configuration to each of our environments. We need to do three things here.

Tell Rails how we want to deliver our mailer. In this case, using SMTP: config.action_mailer.delivery_method = :smtp.

Set up default URL options to say what URL the email will be sent from and how it will be sent

host = 'localhost:3000' // this needs to be set to your actual site url in your production environment
config.action_mailer.default_url_options = { :host => host, protocol: 'http' }

Configure the SMTP settings so Rails can log into the correct service, with the proper authorization, and actually send the email. The below is for Gmail, but there are plenty of other options, such as Outlook, if you don't want to use Gmail just Google "Outlook SMTP Settings":

  config.action_mailer.smtp_settings = {
    :address              => "smtp.gmail.com",
    :port                 => 587,
    :user_name            => ENV["Email_Username"],
    :password             => ENV["Email_Password"],
    :authentication       => "plain",
    :enable_starttls_auto => true
  }

Setup the Gmail Account

Notice the lines in the above code that use ENV[], these point to an environment variable. After all, we don't want to have our email login info out there for the whole world to see. So, the next step is to create these in our .env file (this requires the gem dotenv-rails.

Of course, to get the :user_name and :password, we'll need to create a Gmail account. The important thing to keep in mind for this is that, once your account is created, you'll need to go to Settings -> Security -> Signing in to Google to set up 2-step verification, and then create an App Password to allow your app, a 3rd party app from Google's standpoint, to access your account. This App Password will be the password you include in the smtp_settings above, not your personal password.

Create your Mailer

To create the Mailer, you could manually add the files needed, but Rails comes with a handy-dandy generator to do a lot of the setup for us. Run rails generate mailer shoplist_mailer and Rails will create a mailer file app/mailers/shoplist_mailer.rb and a views folder app/views/shoplist_mailer, along with some testing files.

The Mailer

First, make sure that application_mailer.rb has the correct defaults set up:

class ApplicationMailer < ActionMailer::Base
  default from: "noreply.whats.cookin@gmail.com"
  layout 'mailer'
end

Then, within app/mailers/shoplist_mailer.rb we will add a method to create an email. This method will receive the arguments from your controller as params, and it needs to convert them to instance variables to be passed into a view. It will then use ApplicationMailer's built in #mail method to pull the view (which we'll set up in the next step) as the template and pass in those instance variables. It should end up looking like this:

class ShoplistMailer < ApplicationMailer 
  def new_list_email
    @recipe_name = params[:recipe]
    @user = params[:user]
    @shoplist = params[:shoplist]
    mail(to: @user.email, subject: "What's Cookin' Shopping List")
  end
end

The View

Now that our Mailer is set up to find a view and pass it information, we need to actually create the view. We're going to create 2 files under app/views/shoplist_mailer, the file names need to match the method name in your Mailer (in this case new_list_email), and they will be nearly identical except that one will be an html file and the other a text file. What we're doing here is setting up our primary (html) view, and a backup (text) view in case there's an issue with sending html. You shouldn't need to worry about any of the html setup as it should already be done for you in app/views/layouts/mailer.html.erb.

This is your email template, so make it your own way, but here is mine as an example:

// app/views/shoplist_mailer/new_list_email.html.erb

<h3>Hello <%= @user.name %>,</h3>
<p>
  Here is your shopping list for <strong><%= @recipe_name %></strong>:
</p>
<ul><% @shoplist.each do |item| %>
  <li><%= item %></li>
<% end %></ul>

<p>Thank you for using <strong>What's Cookin'</strong>. Enjoy your meal!</p>

// app/views/shoplist_mailer/new_list_email.text.erb

Hello <%= @user.name %>,

Here is your shopping list for <%= @recipe_name %>:

<% @shoplist.each do |item| %>
  <%= item %>
<% end %>

Thank you for using What's Cookin'. Enjoy your meal!

And that's it, on to the next piece.

Setup Workflow

Okay, now that we have the email settings configured and our mailers created, all that's left to do is get your workflow set up. How does it go from a user clicking a button on the page, to sending that email out?

*Note that your use case may not be exactly the same as mine, so the steps may be a little different. I've tried to note some areas to watch for this, but it's up to you to figure out your app's specific workflow.

Add a new Route (this step may not be necessary - for example, if you just need an auto-notification upon user signup it would NOT require a new route)

resources :recipes  // for the basic Recipe model
post '/recipes/send_shoplist' => 'recipes#send_shoplist'  // specific route for sending a shopping list

Add a new Action to Controller (this step may not be necessary - similar to the route, an auto-notification wouldn't require its own controller action)

// app/controllers/recipes_controller.rb

def send_shoplist
  // controller code goes here
end

Instantiate the Mailer from your Controller and pass in args - this is the step that actually tells Rails to send the email

// create args from params coming from fetch call
@shoplist = params[:shoplist]
@recipe = params[:recipe]

// pass args to Mailer and call delivery method
ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user).new_list_email.deliver_now
render json: "Shopping List Successfully Delivered".to_json

Connect frontend:

*this entire step may not be necessary - if the user doesn't need to explicitly instruct the app to send them data (ex. auto-notification) there wouldn't necessarily need to be a dedicated call to your API - hence not needing a route and controller action

Here, we need to create a function containing a POST request to the correct Controller action and we'll include whatever data we need for the email in the body (in this case, which recipe and what ingredients were chosen by user). It's also important to keep in mind that the backend will need to know which user to send the email to. In my case, I could identify the current_user via my authorization flow, but you may need to pass a user_id as a param instead. Once the function is created, we'll attach it as an eventListener somewhere on our page if it's designed as a manual user action.

// code doesn't include assigning recipe and list variables
function sendShopList() {
    fetch(`${RECIPES_URL}/send_shoplist`, {
        method: 'POST',
        headers: {
            "Content-Type": "application/json",
            "Accept": "application/json",
            "Authorization": // dependent on auth strategy
        },
        mode: 'cors',
        credentials: "include",
        body: JSON.stringify({recipe: recipe, shoplist: list})
    })
    .then(resp => resp.json())
    .then(msg => alert(msg))
    .catch(function(error) {
        alert("Shopping List Could Not Be Delivered - Error Unknown")
        console.log(error)
    })
}

// Attach function to a button's eventListener
shopListButton.addEventListener("click", () => {sendShopList()})

Sending Text Messages (SMS)

Now that we have our ActionMailers set up, let's add texting functionality as well. We want our users to be able to choose whether the notification is sent to their email, phone, or both. The good news is that adding the texting functionality is almost effortless. Note that setting up fields to gather the needed data is outside the scope of this article, but is very important.

How It Works

First thing's first, let's talk about how this actually works. Like everything else in coding, there are multiple ways to go about texting users. If you are building a commercial app, you may want to look at a service like Twilio to simplify things and make it fool-proof. For our app, we're not concerned about being completely sure that 100% of users have a texting option, so we're going to implement a free method of texting instead.

As a reminder, the gem we're going to use for this is called sms-easy so make sure that it's installed in your Gemfile. This gem takes advantage of mobile carriers' email-to-text services. Basically, if you send an email to the correct address, it will route to the user as an SMS message instead. So the sms-easy gem essentially tracks these special addresses and performs a lookup and transformation based on the phone number and carrier. As an aside, it also has functionality to directly send the message from the controller, but we don't want to use that, because we want the text to match the email template that our ActionMailers are already sending out.

So, we need to do 2 things:

Get the special email-to-text address.
Route our ActionMailer email to that special address.

Let's look at how it's done.

Implementation

First, we need to update our Mailer from before so that it's flexible enough to change the "to:" address based on passed in input. All we need to do is modify one line:

// FROM
mail(to: @user.email, subject: "What's Cookin' Shopping List")

//TO
mail(to: params[:recipient], subject: "What's Cookin' Shopping List")

Once that's set, we can change the Mailer call in our Controller so that it provides that "to:" value as a parameter:

// FROM
ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user).new_list_email.deliver_now

// TO
ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: current_user.email).new_list_email.deliver_now

Now, we need to add a control flow to our Controller based on the user's contact preference so that the proper "to:" parameter gets passed. You can certainly to an if...else statement for this, but this is a great use case for a case statement as well:

case current_user.contactPreference
when 'email'
  // Code to send Mailer via email
when 'text'
  // Code to send Mailer via text
when 'both'
  // Code to send Mailer via email
  // Code to send Mailer via text
else
  // Can't send option
end

Finally, let's fill in that code. For the email case, we already have the code completed in the previous step, so let's throw it in and add a response message so our app knows everything worked out okay:

when 'email'
  ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: current_user.email).new_list_email.deliver_now
  render json: "Shopping List Successfully Delivered".to_json

For the text case, we need to determine what that special carrier address is and pass that address as the recipient parameter instead of the email. This is where we'll make use of our sms-easy gem's sms_address method. The method returns our special address, so let's assign to a variable (recipient) and then pass that into our Mailer call:

when 'text'
  recipient = SMSEasy::Client.sms_address(current_user.phone, current_user.carrier)
  ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: recipient).new_list_email.deliver_now
  render json: "Shopping List Successfully Delivered".to_json

For the both case, we'll assign the recipient variable the same way, and then we'll simply include both of the Mailer calls. The final case, of course, is when there is no match. Normally, this is an error, so we could use begin...raise...rescue but for my implementation, I preferred to simplify by having my Controller send a message to the front-end and then simply do nothing. All together, the modified #send_shoplist method looks like this:

def send_shoplist
  # send selected recipe-ingredients as shoplist
  @shoplist = params[:shoplist]
  @recipe = params[:recipe]

  # send shoplist via chosen contact preference
  case current_user.contactPreference
  when 'email'
    ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: current_user.email).new_list_email.deliver_now
    render json: "Shopping List Successfully Delivered".to_json
  when 'text'
    recipient = SMSEasy::Client.sms_address(current_user.phone, current_user.carrier)
    ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: recipient).new_list_email.deliver_now
    render json: "Shopping List Successfully Delivered".to_json
  when 'both'
    recipient = SMSEasy::Client.sms_address(current_user.phone, current_user.carrier)
    ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: current_user.email).new_list_email.deliver_now
    ShoplistMailer.with(recipe: @recipe, shoplist: @shoplist, user: current_user, recipient: recipient).new_list_email.deliver_now
    render json: "Shopping List Successfully Delivered".to_json
  else
    render json: "Shopping List Could Not Be Sent - No Valid Contact Preference Selected".to_json
  end
end

And that's it! Now our backend is set up so that it will email and/or text the user, depending on their contact preference selection.

Typewriter Effect

Daniel Hintz — Sat, 09 Jan 2021 03:00:50 +0000

I've got this idea for my portfolio site where my name gets typed out when the page loads. It's going to get fancy, but to start out, I just want to just get the typing effect figured out. Luckily, I found a library called Typed.js which is really simple, and looks really great!

I was just messing around, so for now I'm just using vanilla JavaScript. So I started by creating a simple html doc and including the CDN script:

<head>
  <script src="https://cdn.jsdelivr.net/npm/typed.js@2.0.11"></script>
  <title>Typing Effect</title>
</head>

<body>
  <h2>
    <span id="typed"><!-- content will be typed here --></span>
  </h2>
</body>

The simplest way to go is to create a script tag and add the strings you'd like to cycle through as an array.

<script>
  const typed = new Typed('.element', {
    strings: ['This effect is super cool!', "I'm going to use it.", 'All the time!'],
    typeSpeed: 40
  };
</script>

And boom, already up and running!

But I wanted to get a little bit more complex and customized. I want my html to determine what should be typed, not my JavaScript. At first I thought I would use an html data-attribute, but then I saw that I don't even have to do that, I can write it as regular html, including style tags, and then Typed.js can pick it up and use it directly by setting the stringsElement option. I also plan on adding more advanced stuff, so I've broken it out onto it's own script.js file just to get it out of my html.

// html
<h2>
  <div id="typed-strings">
    <p>This effect is <mark><em>super</mark></em> cool!</p>
    <p>I'm going to use it.</p>
    <p>For pretty much everything</p>
  </div>
  <span id="typed"><!-- content will be typed here --></span>
</h2>

// JavaScript
const typed = new Typed('#typed', {
  stringsElement: '#typed-strings',
  typeSpeed: 40
});

Then, playing around with its other features, I landed on these options. I slowed it down a little, added a delay before the text gets deleted, and changed the cursor to an underscore to simulate a terminal. To make the terminal effect pop, I also customized the cursor element with CSS. I also wanted it to repeat 3 times, so I added the loop and loopCount options as well.

// JS
const typed = new Typed('#typed', {
  stringsElement: '#typed-strings',
  typeSpeed: 40,
  backDelay: 1000,
  loop: true,
  loopCount: 3,
  cursorChar: '_'
});

// css
.typed-cursor {
  font-weight: 900;
  box-shadow: 0px 1px;
  font-size: 1.3em;
}

And there I have it, in just a few minutes of messing around I had a perfect typing effect.

Next step will be to get really customized, including placement and variable colors, but that's a project for next week.

2020 In The Rear-View

Daniel Hintz — Sat, 02 Jan 2021 00:18:28 +0000

2020 is finally over, and what a year it's been! As I was sipping on my year-end champagne last night and contemplating the year, I thought it would be fun to write an article about the past year - my struggles and victories and what I've learned from them - as well as my future goals for 2021.

The Struggles

There were a lot of struggles in 2020. I was working full time, but getting hired as a developer out of a bootcamp requires a LOT of work, so my biggest struggle right out of the gate was (and still is) time management. I learned to spend 30-45 minutes at the beginning of each day sipping on my coffee and literally breaking the day into chunks. For each chunk, I block off time in my calendar and set an alert for when it's time to pivot. Game-changer.

Related to this is just the sheer amount of work that I have on my plate! I have projects that are half-done, many more that are finished, but need major overhauls now that I've levelled up my knowledge. There are frameworks and even other languages that I am dying to learn. It's been tough to prioritize and slowly chip away at the list, but I am getting there, piece by piece. I've had to adapt the above time-management strategy to a week-by-week schedule in order to set and focus on my weekly priorities to avoid getting lost in the sea of to-do's.

There is also the major challenge of staying motivated and positive. There was a lot of rejection this year while job-hunting. Most companies did not even bother to reject my applications, I just never heard back. In fact, in my 4 months of job-hunting, I only got 2 interviews, neither of which progressed to a second interview...talk about disappointing! But on the bright side, through connecting with others in the field, I learned that the software engineering community is unbelievably supportive! Seriously, not only were people very happy to share their stories, which all involved similar hardships (aka I'm not the only one!), but I had people that I barely knew offer to help push my resume directly to hiring managers, share awesome resources, offer to pair-code, and on and on. I'm pretty good at staying motivated in the face of failure, but this super-positive community kept me from feeling totally defeated.

The Victories

It's actually been difficult to reflect on my victories due to the very top-of-mind lack of success in my job hunt so far, but when I stop and really think about it, I've actually accomplished a ton over the year that I'm very proud of. Firstly, I graduated from the Flatiron program, which is deserving of celebration in itself. I've also built and launched my personal portfolio site which, though there's plenty that I still need to do with it, is looking pretty damn good! I also launched one of my projects, a recipe finder, and have been steadily improving it over the course of the year. It might not be the prettiest site on the internet, but the functionality is pretty cool, and I've found myself using it several times already.

Upon graduation, I felt like the tiniest little fish in the giant ocean. I dreaded putting out a blog because "I didn't know anything that anybody would want to read about," but now after 20 weeks, I have almost 250 followers, and nearing 10,000 views! This community has been super supportive and have shown me that, even though there's an infinite amount that I don't know, there are actually plenty of things that I do know which are more interesting that I would have originally given myself credit for. I really can't say enough how much I appreciate of all of you who have been reading my posts and providing constructive commentary! I've actually started looking forward to opening up DEV and joining in on conversations whenever I can.

Finally, I've overcome what I call "technical paralysis." Flatiron doesn't really teach anything about algorithms, so when I graduated and started engaging in the real-world and preparing for technical interviews, I was horrified to see the types of things that I can expect in the whiteboarding sessions. When I took my first practice interview, I got so frustrated and overwhelmed by the problem that I completely froze up and entirely forgot the basics of JavaScript while I was on the call...not a good look. Through countless hours of study and practice though, I am now quite proud of my ability to think more programmatically and solve these algorithmic problems step-by-step. Though I still have a very, very long way to go, the support from the developer community has helped me become confident in my ability to pass the interviews. I now feel "good enough," and during my last practice interview I was able to sound intelligible and confident, even in the face of not knowing the answer.

Technical Level-Ups

Obviously, I've already gone over a lot of general learnings from the year, but as I reflected on the year, I realized that I've come a very, very long way in terms of technical knowledge since I graduated. It's worth documenting all the self-learning that I've accomplished in addition to everything up above. This is not an exhaustive list, but it hits the highlights.

CSS Variables and their applications in website theming
Major improvements in understanding of CSS styling. A big moment was understanding the relation of a relative positioned element to everything downstream from it.
While we're on CSS, I've gotten comfortable using Flexbox, CSS Grids, and combining the two
I've used and customized Bootstrap, and I've decided I prefer to create my own styling whenever possible
I'm no longer scared of this
I've learned how to test code, including in some complex scenarios
I've learned how to measure the performance of my code
Authentication is now a breeze - I've even combined Rails' Devise with JWT
I can build an API without a corresponding front-end thanks to Postman. And thanks to this community, I've also learned about a potentially better solution: Insomnia
I've used Rails' Action Mailer to send assign custom communications to site events
I've learned some basics of PHP (more to come on this)
Through research and experimentation, I've built a complex program in VisualBasic, despite not knowing the language
I've learned to break down a problem and think about it programmatically to devise algorithms
I've learned about Big O Notation and can calculate it
I've really levelled up my Git skills, pull-requests, resetting HEADs, managing multiple branches and remotes, and more
Basic DevOps stuff - putting a site online, buying and setting up a domain, etc.

Wow that's a lot - it's easy to lose perspective, but man I've killed it this year! 😄

2021 - The Best Is Yet To Come

2021 is going to be my year! I've come too far to stop now. But what is on the horizon for me?

My number one goal, of course, is to find employment as a developer. It's been tough going, but things are starting to look a little brighter.
I will continue to get more involved in the developer community. I can't wait until I'm on the other side, giving advice rather than receiving it!
I will begin contributing to OpenSource in earnest. Once I've finished checking off my personal priorities, this is top of mind.
I WILL learn a new language. Depending on the requirements of my job, I may need to learn a language for their specific stack. If that's not the case, then I will be self-learning starting with PHP. At the moment, I plan to move on to Java after that.
I will learn jQuery. I've already used it a bit, but I'm nowhere near fluent yet. With this and PHP under my belt, I'll be able to work on the vast majority of the existing content on the internet.
Lastly, but perhaps most importantly I will enjoy the summertime! I moved to the beach 3 years ago, but my journey into development has taken all of my free-time ever since. This year, the worst will be over and I'll finally be able to kick back and relax, at least from time to time.

So there it is, 2020 gone, 2021 has finally come. Happy New Year everyone, I hope you're all as excited as I am. See you all on the other side!

Lambdas and '&' in Ruby

Daniel Hintz — Thu, 24 Dec 2020 18:41:58 +0000

places.map(&:city)

I've seen this pattern a lot in Rails and have wondered what exactly it's doing. In researching it, I learned about lambda functions and procs in Ruby, and that in turn led to last week's post about currying functions in Ruby, which relies on basic lambda functionality. Going a bit further, I started looking into the beforementioned pattern, now knowing a bit more about lambdas. At first, I thought I'd understood it, but then I realized that it was more complicated than it initially seemed. The part that was most confusing to me was whether or not the lambda call was supposed to be a symbol, so this is a quick guide for when to use a symbol in this pattern and when not to, as well as an explanation of why.

Here's the TL;DR version if you're not interested in the investigation and the why:

Use Symbol	Don't Use Symbol
Method belongs to the object you are iterating on	Using a Lambda you've created
Iterating on array of objects and operating on a property

Okay now let's look at how I got here.

First thing, let's create a lambda function for use throughout this guide. If you read last week's post, this will look very familiar:

half = ->(numerator) {
    if numerator % 2 === 0
        return numerator / 2
    end
    return "#{numerator} can't be halved evenly"
}

puts half.call(10)
  # => 5
puts half.call(3)
  # => "3 can't be halved evenly"

This pattern is super common for iterators, so we'll want a couple of arrays too:

numarry = [0, 1, 2, 3, 4]
textarry = ["a", "b", "c"]

Alright, so what now?

Say we want to half each of the integers in numarry. We should be able to use '&:' in an iterator to call our lambda like this, right?

puts numarry.map(&:half)

Wrong! You get undefined method 'half' error!

The reason is because half is a lambda, not a symbol, so you need to change it to:

puts numarry.map(&half)
  # => [0, "1 can't be halved evenly, 1, "3 can't be halved evenly", 2]

That makes sense (and seems obvious), so then what's with the symbol pattern at the top? I can't just convert my method to a symbol, so it's not just a matter of preference. Something else must be going on.

I tried a different method, but this time I decided to use a built-in method instead of a local one that I created:

puts textarry.map(&upcase)

And I got an undefined local variable or method 'upcase' error! So, just for fun, I tried it as a symbol:

puts textarry.map(&:upcase)
  # => ["A", "B", "C"]

And voila - it worked! But the question is why?

We know that everything in Ruby is an object, ultimately inheriting from the global class Object. When you define a method, it's defined with an object as its owner. You can see what the owner of a given method is by using the #owner method:

def double(num)
  num * 2
end

puts method(:double).owner
  # => Object

but what about our lambda method at the top?

puts half.class
  # => Proc

So our lambda is not on the same object as the Integer that we are calling it on. This gives me an idea! If we think back to the original pattern: places.map(&:city) the symbol is a property of the Place class, similar to how upcase is technically a property of the String class. Meanwhile, our poor lambda is out there on its own and not associated to anything. There's the difference! Time to test the theory. If I'm correct, then by adding a method to an existing class, I should be able to pass it as a symbol to my iterator.

# modify Integer class to include double method
class Integer
  def double
    self * 2
  end
end

puts numarry.map(&:double)
  # => [0, 2, 4, 6, 8]

It worked! After all this investigating, I finally came to the simple guidelines below.

Use Symbol	Don't Use Symbol
Method belongs to the object you are iterating on	Using a Lambda you've created
Iterating on array of objects and operating on a property

As a bonus, I gained a stronger understanding of how Ruby works under the hood, which is always a good thing!

Functions Creating Functions! (Ruby edition)

Daniel Hintz — Sat, 19 Dec 2020 03:44:41 +0000

A couple weeks ago, I wrote a blog about building function-building functions in JavaScript. This week, I'm going to go through the same concept using Ruby. I'm going to stick as closely as possible to the same flow as the last article to make it easy to compare.

We all know what a programming function is and what it does. It encapsulates a particular behavior. For example, this function divides any number you'd like by 5.

def divide_by_5(number)
    number / 5
end

divide_by_5(15)
  # => 3

In life, we often see different variations of a complex behavior, and this is a situation we see a lot in programming as well. For example, imagine we wanted to add some complexity to the above function so that it only divides numbers that are cleanly divisible by 5. We could easily do this:

def divide_evenly_by_5(num)
    if num % 5 === 0
        return num / 5
    end
    return "#{num} is not divisible by 5!"
end

divide_evenly_by_5(15)
  # => 3
divide_evenly_by_5(7)
  # => "7 is not divisible by 5!"

But we might need to similarly divide by other numbers later on in our program. We could write a new function for each number, but that would be a pain. Instead, let's create a function which in turn creates other functions!

To do this, we'll convert our function into something called a lambda function, which is basically a way to encapsulate a certain behavior into a variable, very similar to const myFunction = function(arg) { console.log("hi "+ arg) }. We need to use .call() to call this lambda function:

divide_evenly_by_5 = ->(numerator) { 
    if numerator % 5 === 0
        return numerator / 5
    end
    return "#{numerator} is not divisible by 5!"
}

divide_evenly_by_5.call(15)
  # => 3
divide_evenly_by_5.call(7)
  # => "7 is not divisible by 5!"

But this is too strict! Let's loosen up the lamda so that we can use whatever numerator AND denominator that we want. This is how we set up our flexibility in Ruby, rather than the wrapper function that we used in JavaScript. It's basically the same thing that we did in the JavaScript tutorial, but in reverse. (Instead of building a super-function out of 2 smaller functions, we're building a super-function and then breaking it into 2 smaller functions.) Note that the order of your arguments are important here:

divide_by = ->(divisor, numerator) { 
    if numerator % divisor === 0
        return numerator / divisor
    end
    return "#{numerator} is not divisible by #{divisor}!"
}

divide_by.call(5, 15)
  # => 3
divide_by.call(5, 7)
  # => "7 is not divisible by 5!"

Now, we need to use a concept called currying to essentially split this method up into 2 "parts." and in Ruby we use a .curry method to do it. This is going to represent whatever the first divide_by argument is, which is why it's important to order them correctly:

divide_by_5 = divide_by.curry.call(5)

Now, we can call divide_by_5 and provide the second argument, in this case the numerator:

divide_by_5.call(10)
  # => 2

The benefit of this pattern is that we can now assign this behavior to any divisor/number variation. As the complexity of the behavior goes up, this becomes more and more useful.

Here's the full code:

divide_by = ->(divisor, numerator) { 
    if numerator % divisor === 0
        numerator / divisor
    end
    return "#{numerator} is not divisible by #{divisor}!"
}

divide_by_5 = divide_by.curry.call(5)
  # => 
div_by_8 = divide_by.curry.call(8)
  # => 
divide_number_by_100 = divide_by.curry.call(100)
  # => 

divide_by_5.call(15)
  # => 3

divide_by_5.call(8)
  # => "8 is not divisible by 5!"

divide_number_by_100.call(500)
  # => 5

Disclaimer: There is a LOT more to these lambdas than this application, they're super useful in Ruby coding. I'm just getting started diving into their functionality.

CSS Plate for Your Recipe App

Daniel Hintz — Sat, 12 Dec 2020 03:17:26 +0000

I was short on time this week, so I've decided to do a short and simple post - I'm going to build a plate design using CSS. I will be using it in my recipe website to house the returned recipes, the idea is that it'll look like each recipe is sitting on a plate.

Starting out, I want to use the least html as possible so that I don't need to keep track of the extra elements. I'm going to have a plate div, which will serve as a wrapper and the rim of the plate, and an inner_plate span that will be the center of the plate and will hold the content.

<div class="plate">
  <span class="inner_plate"></span>
</div>

Next I'll add the CSS to make the design come to life. There are a few key highlights here to notice:

Each recipe will have an image, which is what will dictate the sizing, and I set each image size to 240x150 in the imported html. Because of this, each plate should be fairly uniform in size and shape (it might elongate a little with a really long recipe title due to wrapping, which is okay for my purposes).
By then setting .plate and .inner_plate size to fit-content I can rely on padding and margins to give a flexible shape to each design.
Setting font-size on the plate element allows me to use em/rem to provide flexible sizing for the box-shadows (since they can't use percentage values).
The outer box-shadow provides the shadow effect that makes the plate look 3D, while the inner shadow makes is what makes it look like there's a sloping edge from the rim to the main part of the plate.

.plate {
  position: relative;
  display: inline-flex; // inline so plates can organize next to one another
  flex-direction: column;
  height: fit-content;
  width: fit-content;
  background-color: #e4e4e4;
  border-radius: 50%;
  justify-content: center;
  font-size: 15px;
  box-shadow: 2px 2px 8px 2px #000;
  padding: 30px;
  margin: 20px;
}

.inner_plate {
  align-self: center;
  border-radius: 50%;
  height: fit-content;
  width: fit-content;
  border: #dddddd solid 2px;
  background-color: #d2d2d2;
  font-size: 1rem;
  box-shadow: 0 0 10px 10px #cfcfcf;
  justify-content: center;
  padding: 25px;
  text-align: center;
}

.inner_plate img {
    margin-top: 5px;
    max-width: 100%;
    max-height: 150px;
    border-radius: 40%;
    z-index: 1;
    position: relative;
    margin: 25px 2px;
}

.inner_plate h3 {
    max-width: 250px;
    padding: 0 15px;
}

Finally, I want to add a lighting effect to my plate to go along with the shadow that I gave it. Since I'm keeping HTML to a minimum, I'll use an ::after pseudo-element to add a glare. An offset box-shadow will give it that soft glare-like edge and it can scale along with the inner-plate because it's all set relative to the inner-plate sizing (size is percentage of inner_plate size & box-shadow is percentage of font-size).

.inner_plate::after {
  content: "";
  position: absolute;
  background-color: #e3e3e3;
  height: 40%;
  width: 20%;
  display: block;
  border-radius: 50%;
  transform: rotate(34deg);
  right: 21%;
  top: 42%;
  font-size: inherit;
  box-shadow: -.6em .2em 1em 1em #e3e3e3;
}

And there it is! When empty, you can really see how the subtle lighting effect makes it look more realistic and makes the shadow look real:

And here's how it looks once it's filled with a recipe:

I think this little effect makes my site a lot more fun and engaging. Here what it looks like when you search for recipes on the site.

Before:

After:

Pretty neat, huh?

Devise and JWT in Rails

Daniel Hintz — Sat, 05 Dec 2020 02:09:03 +0000

I needed to implement Devise and JWT using Rails (Rails 5), and I thought, how hard could this be? Boy was I naive... Now there is a lot of information out there on how to do this, but each resource was using a different method and nothing really seemed to work. Well, I've finally figured it out and I want to share it with the world for 2 reasons:

It may save someone days of researching and trial-and-error.
Selfishly, I want to know where I can go to look it up for next time

Warning, this post will assume some knowledge of Rails and a few popular gems, it's a little bit more advanced than my normal stuff so far. So here we go.

How does it work?

First thing's first, there are a few ways this can be handled. There is (was?) a Devise-JWT gem that integrated JWT and worked very similarly to Devise's regular flow. When I tried to go that route, it did not work and I wasted many, many hours troubleshooting. I did eventually succeed in registration, but the sign_in functionality was still not working. It's very probable that this was do to user error, but regardless, I found my way to be much simpler.

Here's how it works.

So basically, you can really think about this in two steps. Step 1 is the standard devise-driven authentication. Step 2 is passing the JSON Web Token back and forth.

Implementation

Project Generation

First, let's build our project. Since we don't need the full Rails functionality because we'll be setting up a separate front-end, we can use the --api flag rails new example-project --api. One of the effects of this flag is that the project will be set up without rails sessions - this is important.

Gemfile

Once we've built our project, first thing we'll do is build out the Gemfile. For the purposes of our authentication flow, we'll need 3 gems

devise for actual authentication
jwt for handling the JSON Web Tokens we'll be passing back and forth.
bcrypt for password-related unit testing - this only needs to be included in the test environment because otherwise it's included in Devise.
BONUS: I pretty much always add pry to help with debugging, and it comes in real handy when I need to check what params are coming over.

Devise Initializer

To configure Devise, we'll run rails generate devise:install from our console to create an initializer file: config/initializers/devise.rb. The good news is that we can largely keep the default configuration; the only special thing we need to do is to set config.skip_session_storage = [:http_auth] (about quarter way down the file).

User Model

Now we need to set up our user model. Devise has a special way to do this by running rails generate devise User. This command creates a User model and prefills it with some Devise functionality, it also creates a database 'devise_create_users' migration, and adds a line to the routes file: devise_for :users which creates routes to the default Devise Controllers.

Once the User model is created, we can finish configuring Devise by selecting which modules we want and adding it after the devise macro. For my app, I just used the basic defaults: devise :database_authenticatable, :registerable

One last thing before we can call the User model ready. Since a given JSON Web Token (JWT) will be associated to a given user, it makes sense to think of a user "creating" their token. Additionally, the goal is to get as much of the app's logic in the models, so to address both of these concerns we will place the logic of creating a JWT in the User model. Here we use the JWT gem to encode a token containing only the user's id. How can the id be the only thing we need you ask? Thinking back to our "How Does It Work" Diagram above, remember that the user will need to pass in their credentials as parameters at the sign-in page and, if successful, the server will issue an encrypted token for them. This is that token, so it will only be used to authenticate that the user is who they say they are once they've already logged in and they try to make a subsequent call to the API. Thus, we only need a way to identify the user: their unique id attribute works perfectly for this purpose.



def generate_jwt
  JWT.encode({id: id, exp: 60.days.from_now.to_i}, Rails.application.secrets.secret_key_base)
end

Routes

As stated above, the rails generate devise User generator will create a route for us automatically that looks like this: devise_for :users. For our purposes, the default controllers aren't going to work on their own because they are meant to operate via sessions, which we will not have in our api-only implementation. So, we'll need to overwrite some of the default functionality - to do this, we need to point to custom registrations and sessions controllers:



devise_for :users,
controllers: {
  registrations: :registrations,
  sessions: :sessions
}

Database

Also stated above, the rails generate devise User generator will create our database migration for us, so the only change we need to make is uncommenting any non-default modules you added in your User model, as well as adding any custom fields you may need. Once you're done, run rake db:migrate and we're done here.

Intermission (Coffee Break)

We've gotten through a lot already, but there's quite a bit more to come, so before we get into the controllers, which contain most of our logic and functionality, take a quick breather and grab a fresh cup of coffee. If you're following along, this is a good time to double check that everything is correct in your app so far...

Ready to continue? Okay, let's do this!

Controllers

There are three controllers that we're going to be concerned with for this, and each of these 3 controllers will have a specific job from the diagram at the top of this article.

The Application Controller is where we will process a JWT when a user sends a request to our API. It's vital to keep in mind that the Application Controller is not concerned with credentials - it simply checks for a valid JWT.
The Registrations Controller is where a user will create his/her credentials, and it will assign the JWT to the user once complete.
The Sessions Controller is where a user will authenticate his/her credentials and it will assign the JWT to the user if successful.

Application Controller < ActionController::API

We will set up our JWT processing functionality first because, once a JWT is assigned, we'll want to check to make sure it's working correctly. Since we know that we will be passing in JSON, we will start off the Application Controller with the following line respond_to :json. Since all other controllers inherit from the Application Controller, we only need to do this for this controller - it will automatically be passed down to the rest. This is also where we'll want to provide our app with similar private methods to what the standard Devise implementation would give us, so let's set up our authentication method authenticate_user! as well as a signed_in? and current_user method, then we'll look at how to get them to work.

For our authenticate_user!, we know that we want this to reject a user as unauthorized unless they are correctly signed in. We also know we'll eventually have a signed_in? method available, so let's go ahead and proceed using that:



def authenticate_user!(options = {})
  head :unauthorized unless signed_in?
end

But for this to work, of course, we need to define signed_in?. Default Devise does this by checking the session for the presence of a user_id. We won't have a session for this, but what we will have is a JWT. We now know that we need a method to somehow pull a user's id out of the JWT and return it. Let's call it @current_user_id and use that future value in our signed_in? method like so:



def signed_in?
  @current_user_id.present?
end

While we're at it, since we know that we'll have a @current_user_id to work with, let's use it to define our current_user method too. We need this to take the id and search our database for a corresponding user record:



def current_user
  @current_user ||= super || User.find(@current_user_id)
end

That's easy enough, essentially just copying the Devise methods, now we just have to find a way to extract that id from a passed JWT. One final reminder: remember that this controller is NOT meant to make sure that the user authenticates against his/her credentials, it's just to see whether they are signed in or not by looking at the JWT. If a user HAS a valid JWT, it means that they have correctly authenticated their credentials and the server gave them one. With that in mind, this is actually super simple using the jwt gem:



def process_token
  jwt_payload = JWT.decode(request.headers['Authorization'].split(' ')[1], Rails.application.secrets.secret_key_base).first
  @current_user_id = jwt_payload['id']
end

That will work, assuming that there IS an Auth header, and that it has a valid JWT. I'm not willing to bet that either of these are always going to happen, so let's put some error handling around it. We want to throw an error if an invalid JWT is sent, but not if there is no Auth header sent at all:



def process_token
  if request.headers['Authorization'].present?
    begin
      jwt_payload = JWT.decode(request.headers['Authorization'].split(' ')[1].remove('"'), Rails.application.secrets.secret_key_base).first
      @current_user_id = jwt_payload['id']
    rescue JWT::ExpiredSignature, JWT::VerificationError, JWT::DecodeError
      head :unauthorized
    end
  end
end

There! Now there's just one last step. We need to make sure that the token is processed before we try to take any other action. To do this, we just need to add before_action :process_token underneath respond_to :json. Now whenever our app is called, it will process the token (if provided) and then take whatever action is required.

Registrations Controller < Devise::RegistrationsController

Okay, next step is to provide our app the ability to register a new user and assign them a JWT to be passed to our Application Controller for processing. As long as we're just using the default attributes for Devise (and calling them "sign_up_params", we don't need to worry about whitelisting parameters because Devise is already doing it for us. The reason we need to have our own controller is so that we can have the user instance build its token for the controller to deliver it. On the client side, we would use this returned token to store in a httpOnly cookie, (or whatever other storage option you prefer).



def create
  user = User.new(sign_up_params)

  if user.save
  token = user.generate_jwt
    render json: token.to_json
  else
    render json: { errors: { 'email or password' => ['is invalid'] } }, status: :unprocessable_entity
  end
end

Sessions Controller < Devise::SessionsController

Finally, the last step in our implementation! Just gotta set up the Sessions Controller so that a user can return and sign back in, and it works the same way as the Registrations Controller. The user will submit params through the front-end, including their email, which our API will use to query the database and return our user instance. Then we'll validate that the password they provided matches the stored password and, if successful, we will distribute a JWT:



def create
  user = User.find_by_email(sign_in_params[:email])

  if user && user.valid_password?(sign_in_params[:password])
    token = user.generate_jwt
    render json: token.to_json
  else
    render json: { errors: { 'email or password' => ['is invalid'] } }, status: :unprocessable_entity
  end
end

Wrap-Up

So there it is. This is how I was finally able to get JWT working with server-side authentication using Devise, the de-facto standard for Rails. Once I realized that JWT is really a separate process from authenticating credentials, it wasn't so bad to figure out. Let me know what you think in the comments. Is there a better way to combine these two gems? Are there major issues with this implementation? If you've successfully used devise-jwt, what is the secret??

Thanks so much for reading and hanging in there to the end! Below this is just the final code (minus Gemfile and Initializer), in case you want to see it all in one place.

Full Code:



# User.rb
class User < ApplicationRecord
  # Include default devise modules. Others available are:
  # :confirmable, :recoverable, :rememberable, :validatable, :lockable, :timeoutable, :trackable and :omniauthable
  devise :database_authenticatable, :registerable

  def generate_jwt
    JWT.encode({id: id, exp: 60.days.from_now.to_i}, Rails.application.secrets.secret_key_base)
  end

end


# Routes.rb
Rails.application.routes.draw do
  devise_for :users,
  controllers: {
    registrations: :registrations,
    sessions: :sessions
  }

  root to: "home#index"
end


# Database Schema
  create_table "users", force: :cascade do |t|
    t.string "email", default: "", null: false
    t.string "encrypted_password", default: "", null: false
    t.datetime "created_at", null: false
    t.datetime "updated_at", null: false
    t.index ["email"], name: "index_users_on_email", unique: true
  end


# ApplicationController.rb
class ApplicationController < ActionController::API
  respond_to :json
  before_action :process_token

  private

  # Check for auth headers - if present, decode or send unauthorized response (called always to allow current_user)
  def process_token
    if request.headers['Authorization'].present?
      begin
        jwt_payload = JWT.decode(request.headers['Authorization'].split(' ')[1], Rails.application.secrets.secret_key_base).first
        @current_user_id = jwt_payload['id']
      rescue JWT::ExpiredSignature, JWT::VerificationError, JWT::DecodeError
        head :unauthorized
      end
    end
  end

  # If user has not signed in, return unauthorized response (called only when auth is needed)
  def authenticate_user!(options = {})
    head :unauthorized unless signed_in?
  end

  # set Devise's current_user using decoded JWT instead of session
  def current_user
    @current_user ||= super || User.find(@current_user_id)
  end

  # check that authenticate_user has successfully returned @current_user_id (user is authenticated)
  def signed_in?
    @current_user_id.present?
  end

end


# RegistrationsController.rb
class RegistrationsController < Devise::RegistrationsController

  def create
    user = User.new(sign_up_params)

    if user.save
      token = user.generate_jwt
      render json: token.to_json
    else
      render json: { errors: { 'email or password' => ['is invalid'] } }, status: :unprocessable_entity
    end
  end

end


# SessionsController.rb
class SessionsController < Devise::SessionsController

  def create
    user = User.find_by_email(sign_in_params[:email])

    if user && user.valid_password?(sign_in_params[:password])
      token = user.generate_jwt
      render json: token.to_json
    else
      render json: { errors: { 'email or password' => ['is invalid'] } }, status: :unprocessable_entity
    end
  end

end

Rails SQL Injections

Daniel Hintz — Sat, 28 Nov 2020 03:35:29 +0000

When studying backend development, I learned that using SQL (and other database querying languages) directly will result in much faster code. SQL is built specifically for querying, so it certainly makes sense, but I've never actually verified if this was in fact true and, if it is, how much faster it is. So, I decided to put it to the test and I created a mini-project in Ruby on Rails to validate the hypothesis that my code will run faster, all else being equal, if I use a direct SQL injection rather than a Ruby-ActiveRecord based approach. Here's what happened.

The Setup

First thing, I needed to create my test scenario and then implement a SQL and an ActiveRecord implementation that gets me to the same result. I'm not going to go through the steps to create the project, but here are the highlights:

Users and associated Orders are stored in the database
Orders have a payer_name and created_at attribute
In the Order Model, I have a method to extract the orders associated to a given user, and sort them by created_at
Optionally, I can filter the results by specifying a payer_name when calling the method
My demo user will have 10 associated orders
6 of these orders have a payer_name equal to "Store1"

After setting up my app and database, I need to code the method described in the above bullets.

Regular Implementation (Ruby & ActiveRecord)

Here's what this code looks like without directly injecting SQL.

def self.sort_orders(user_id, payer_name = '*')
  if payer_name == '*'
    User.find(user_id).orders.sort {|a, b| a.created_at <=> b.created_at}
  else
    User.find(user_id).orders.filter{|t| t.payer_name == payer_name}.sort {|a, b| a.created_at <=> b.created_at}
  end
end

So, regardless of whether a payer_name is specified, the code starts by finding the User instance based on the passed-in user_id, then it finds all the orders that are associated. IF a payer_name is specified, the results are filtered at this point to only include results where payer_name matches what was provided. Finally, any remaining results are sorted in ascending order by created_at.

Note that, if a payer_name is specified, I filter the results BEFORE sorting. This will help my performance a little bit and make the test more fair.

SQL Injection Implementation

Now, I want to add a method that does exactly the same thing, but this time I'll retrieve the results with SQL instead of relying on Ruby and ActiveRecord.

def self.sort_orders_SQL(user_id, payer_name = '*')
  if payer_name == '*'
    self.find_by_sql(["SELECT * FROM orders WHERE user_id = ? ORDER BY created_at ASC", user_id].flatten)
  else
    self.find_by_sql(["SELECT * FROM orders WHERE user_id = ? AND payer_name = ? ORDER BY created_at ASC", user_id, payer_name].flatten)
  end
end

As stated above, this does the exact same thing. One major advantage; however, is that I can add the order logic in the SQL query, avoiding an iterator function altogether. Same deal for the filter logic if a payer_name is specified. This is an excellent use case for injecting a database query!

The Test

Now that I'm all set up, let's get to testing. For this, I'll use a ruby gem called benchmark to calculate how much time it takes to run each method. Since these are not huge methods, I'll run them each many times so that my results can be more easily operated on (I don't want to type that many ".000000"s if I don't have to). I'll use the bm method to run both tests at the same time. I'll start by running each method 1000 times, then just for fun, I'll run the same test method with 5,000 and 10,000 repetitions.

Testing Without 'payer_name' Filter

Benchmark.bm do |benchmark|
  benchmark.report("no-inject") do  // label denoting no SQL injection
    1000.times do
      Order.sort_orders(User.first.id)
    end
  end

  benchmark.report("injectSQL") do  // label denoting SQL injection used
    1000.times do
      Order.sort_orders_SQL(User.first.id)
    end
  end
end

Running the test 1,000 times each results in the following data (Note: Reduction column is calculated, not provided by benchmark gem):

	System CPU Time	User CPU Time	Total CPU Time
no-inject	0.421875	1.609375	2.03125
injectSQL	0.203125	0.5	0.703125
Reduction	51.85%	68.93%	65.38%

5,000 repetitions resulted in the following data:

	System CPU Time	User CPU Time	Total CPU Time
no-inject	0.828125	3.21875	4.046875
injectSQL	0.6875	2.078125	2.765625
Reduction	16.98%	35.44%	31.66%

Finally 10,000 repetitions resulted in the following data:

	System CPU Time	User CPU Time	Total CPU Time
no-inject	1.890625	6.234375	8.125000
injectSQL	1.156250	2.625000	3.781250
Reduction	38.84%	57.89%	53.46%

Testing With 'payer_name' Filter

Now, adding the criteria that I only want to return orders where payer_name is Store1:

Benchmark.bm do |benchmark|
  benchmark.report("no-inject") do  // label denoting no SQL injection
    1000.times do
      Order.sort_orders(User.first.id, "Store1")
    end
  end

  benchmark.report("injectSQL") do  // label denoting SQL injection used
    1000.times do
      Order.sort_orders_SQL(User.first.id, "Store1")
    end
  end
end

Running the test 1,000 times each results in the following data:

	System CPU Time	User CPU Time	Total CPU Time
no-inject	0.390625	0.9375	1.328125
injectSQL	0.09375	0.203125	0.296875
Reduction	76.00%	78.33%	77.65%

5,000 repetitions resulted in the following data:

	System CPU Time	User CPU Time	Total CPU Time
no-inject	1.234375	3.59375	4.828125
injectSQL	1.0625	1.3125	2.375
Reduction	13.92%	63.48%	50.81%

Finally 10,000 repetitions resulted in the following data:

	System CPU Time	User CPU Time	Total CPU Time
no-inject	3.28125	11.359375	14.640625
injectSQL	1.96875	4.203125	6.171875
Reduction	40.00%	63.00%	57.84%

Results

With this data, the hypothesis that direct SQL injection will work faster than Ruby & ActiveRecord is, in fact, supported. Additionally, when looking at the reduction figures, they suggest that it's actually exceedingly faster! It's important to keep in mind that there are other factors effecting the results, including what programs are running on my computer, so running the same test twice is highly unlikely to get the same results. However; with an average reduction of 50.17% for non-filtered, and a whopping 62.10% for filtered results, there is no question that this SQL injection strategy is a huge performance boost in the right circumstance.

Bonus

There was something that was bothering me about my analysis above. The SQL strategy was a huge performance boost, BUT it has the benefit of skipping iterator methods, which will certainly give it the edge. To measure the effect of purely SQL vs ActiveRecord, I need to cut out that mediating factor. So here is the table of results for the same test, but with all sorting and filtering removed. This is simply finding the user based on the user_id, and getting all associated orders in no particular order.

I ran the test with 5,000 iterations.

	System CPU Time	User CPU Time	Total CPU Time
no-inject	1.96875	4.28125	6.25
injectSQL	1.171875	2.546875	3.71875
Reduction	40.48%	40.51%	40.50%

Okay, so this suggests that there is still a massive, if slightly smaller, performance gain from directly using SQL over ActiveRecord. Hypothesis still supported.

Functions Creating Functions!

Daniel Hintz — Sat, 21 Nov 2020 00:23:56 +0000

Hi there! This goes through how to do this in JavaScript. I also wrote a sister-article that goes through how to do the same thing in Ruby.

We all know what a programming function is and what it does. It encapsulates a particular behavior. For example, this function divides any number you'd like by 5.

function divideBy5(number) {
  return number / 5;
}

divideBy5(15)
  // => 3

But in life, we often see different variations of a complex behavior, and this is a situation we see a lot in programming as well. For example, imagine we wanted to add some complexity to the above function so that it only divides numbers that are cleanly divisible by 5. We could easily do this:

function divideBy5(number) {
  if(number % 5 === 0) {
    return number / 5;
  }
  return `${number} is not divisible by 5!`;
}

divideBy5(15)
  // => 3
divideBy5(7)
  // => "7 is not divisible by 5!"

To do this, we'll create a wrapper function, this is where we'll set up our flexibility by passing an argument. This argument will represent the variation in the behavior; in our simple case, it's a specific divisor. We want to be able to divide by 5, or 8, or 100, or whatever else our hearts desire, so we'll call this argument divisor.

function DivideBy(divisor) {
  // the rest of the function will go here.
}

Now, we know that the output of the function needs to be a different function, so our return value will need to be a function declaration. There's no need for this inner function to have a name, so we'll create an anonymous function that takes in an argument - this will be the number that we want evaluated (15 in our first example).

function DivideBy(divisor) {
  return function(number) {
    // the rest of the function will go here
  }
}

Now, we can add in our main functionality, which was defined in our divideBy5() example, but we now get to parameterize BOTH the numerator that we want evaluated, AND the divisor.

function DivideBy(divisor) {
  return function(number) {
    if(number % divisor === 0) {
      return number / divisor;
    }
    return `${number} is not divisible by ${divisor}!`;
  }
}

Great! Now if we call DivideBy(5), we get:

ƒ (number) {
    if(number % divisor === 0) {
      return number / divisor;
    }
    return `${number} is not divisible by ${divisor}!`;
  }

...I know what you're thinking - "What's this? What are we supposed to do with it?" And the answer is deceptively simple: just name it! That output is a function which is asking for a number to divide by the divisor that we just passed in (5). So we create a function expression so we can reference it later: const DivideByFive = DivideBy(5) and we now have the same function as our divideBy5(number) function from before. We can call it like so:

DivideByFive(15)
  // => 3

The benefit of this pattern is that we can now assign this behavior to any divisor/number variation. As the complexity of the behavior goes up, this becomes more and more useful.

Here's the full code:

function DivideBy(divisor) {
  return function(number) {
    if(number % divisor === 0) {
      return number / divisor;
    }
    return `${number} is not divisible by ${divisor}!`;
  }
}

const DivideByFive = DivideBy(5);
  // => undefined
const divBy8 = DivideBy(8);
  // => undefined
const divideNumberBy100 = DivideBy(100);
  // => undefined

DivideByFive(15)
  // => 3

DivideByFive(8)
  // => "8 is not divisible by 5!"

divideNumberBy100(500)
  // => 5