Hello! It's been a long time since I last published a blog post here. 2022 was an interesting year for me. A few of the highlights include:

• Moving back to my hometown in Pittsburgh, PA

• Helping bring in new contributors for Codecademy Docs

  • Hacktoberfest 2022 was a blast!

• Writing my first GitHub Action!

So far this year, in 2023, I have already accomplished a few things:

• I left my job at Codecademy to pursue contract work

  • I'm still writing curriculum content, though!

• I traveled to/worked in Brooklyn, NY for the very first time.

Wait, you left Codecademy?!

Yup! But I didn't "leave" in the coldest sense of the word. I left amicably and everyone from my former team was super supportive of my decision. Part of the reason that I left was that I ultimately wanted a change of pace and scenery. I'm the kind of person that longs for a new challenge after a while.

Looking back on Docs

After working (mostly) on this for over 18 months, it became clear to me that Docs was emerging as an important component of the free-tier experience at Codecademy. As of today:

• There are well over 1,000 Docs entries covering a plethora of topics, concepts, and terms.

• There are over 1,100 forks of the GitHub repository, as well as 280+ stars. ⭐

As a former maintainer of Docs, I couldn't be more proud of the work that my team and I put in to make Docs what it is today.

What to expect for 2023...

Brooklyn-bound

While I'm not yet at liberty to go into detail about my contract work, what I can say about it is this:

• I'm still going to be writing content within the EdTech space.

• For the foreseeable future, my focus areas will be narrowed to the core web dev technologies HTML/CSS & JavaScript.

• Part of my work involves an occasional visit to Brooklyn, NY. 🏙️🗽

  • The commute will be monthly and arduous, but worth it!

Renewed digital presence w/ a blog focus

This year, I want to get back into writing, especially about technical content. However, I'd like to include the following in my digital presence:

• More engagement on platforms like Twitter and Discord

• A monthly "check-in" post about what I've been up to, how I'm feeling, and what I hope to tackle/accomplish next

• Blogs will be more about what I'm learning and how I'm practicing new skills

  • Aiming to publish once per week

Can't wait to get to writing and coding!

Best,

Brandon

What is Docs?

Codecademy Docs is a free, open-contribution resource that has an ever-growing collection of entries spanning many languages and frameworks, including:

• C++
• CSS
• HTML
• JavaScript
• React
• SQL

Currently, more than 700 entries have been submitted and edited by learners from across the world... and counting! Docs was also recently added on Product Hunt and has already amassed over 150 upvotes.

How does it work?

Docs is built by the community and maintained by Codecademy. Every time a new/edited entry goes live, all the contributors involved are credited on the "Contributors" list for that entry.

Docs Github repo

All of the changes to Docs are housed in the Codecademy/docs repo on GitHub.

The "Pull requests" tab contains any open PRs pertaining to Docs entries.

Answering an issue

Issues are ideally created by Docs maintainers in the "Issues" tab to request new entries, edits, or bug fixes. However, this is the place where many contributors go to pick a subject that is appealing and create entries about them.

If you see an issue that you'd like to work on, select it and leave a comment on the thread. Someone from our team will reach out!

Creating a new entry

1. Fork the Docs repo and clone locally

To mitigate any conflicts when merging changes, we recommend that you fork the Codecademy/docs repo.

From your forked Docs repo (or your remote repo), you can then clone it onto your local machine using the repo URL (I usually go with the HTTPS one). This will create your local repo.

git clone https://github.com/github_username/docs.git

Before working on any new changes, always make sure sure that your forked main branch is even with the original Codecademy/docs:main branch. You do this by clicking "Fetch Upstream" and then "Fetch and Merge" on your remote repo:

Then, pull those changes down to your local repo (make sure you're on your main branch):

git checkout main
git pull

2. Create and switch into separate branch

Another important part of contributing to the Docs repo is to never push changes from your forked repo's main branch. This is because reviewers and maintainers may want to test your changes on their own forks. However, they can't do this if the name of the branch they're pulling from is also called main. Therefore, do the following, always create and switch into a separate branch before editing files:

git checkout -b separate-branch

3. Edit and save the file.

In this step, go ahead and make all the necessary changes to the file and save afterwards. When contributing to Docs, you should only work on a single entry (a single file) at a time.

4. Run add, commit, then push to separate branch

Tip: I run git status before following this step just to see which files are staged vs. unstaged for commit.

When finished making changes, we can add (or stage) the files for commit:

git add <space-separated list of files here>
git commit -m "brief summary of changes."

This next part is crucial: we're gonna push the changes up to the branch we created in the last step.

git push origin separate-branch

This will cause a remote-equivalent of the branch to be created on GitHub and, by extension, trigger a prompt to create a new pull request.

Note: The origin remote is the connection between your local repo and the remote repo.

git remote -v
origin  https://github.com/github_username/docs.git (fetch)
origin  https://github.com/github_username/docs.git (push)

Editing an existing entry

There are two distinct methods for editing an existing Docs entry:

• By following the same steps listed in the previous section.
• By editing the file and committing the changes directly on GitHub.

For the second method, a great place to start is from a live entry on the Docs site.

Near the top-right corner of the page for any Docs entry is an "Edit this page on GitHub" link to the equivalent file on the Docs repo, ready for editing!

After making changes, scroll down near the bottom to find a prompt for committing the changes and submitting a pull request.

Inside this prompt, you can:

• Give the commit a specific name and description.
• Custom-name the separate branch that will be auto-created by the prompt.

Handling bugs and errors

For bugs and errors, your options include:

• Reporting it by filling out this issue form.
• Follow the steps outlined earlier in the "Editing an existing entry" section.

Conclusion

At this point, you will have committed/pushed your changes and submitted a pull request to be reviewed by either me or one of my colleagues. After we've approved and merged the changes, congratulations! You've just made your first contribution on Codecademy Docs!

I hope this post was help to anyone interested in building the next best documentation resource. I'm excited to have helped build this project and I hope you'll come and help us build it more!

To hear any updates with Docs, go to #CodecademyDocs on Twitter. And please feel free to leave us any feedback about Docs here.

Package managers have made everyday use of other's code much smoother and more standardized. Gone are the days where there was no consistent way of doing common tasks including:

• Installing/uninstalling Node packages and their dependencies
• Creating/publishing dependencies
• Keeping up-to-date with package versions, as well as the versions of their dependencies (and *theirs.*

This last, bolded point is what this article will be discussing. Today, with package managers like npm and Yarn, there are ways of handily updating packages and their dependencies.

Dependencies and versioning

npm and Yarn both follow the rules of semantic versioning to notate a package's given version. Each package version starts at 1.0.0 and progresses at various points, broken down like this.

$ npm install <package-name>@1.0.0
$ yarn add <package-name>@1.0.0

# 1 --> major release that comes with breaking changes

# 0 --> minor release that comes with non-breaking new features

# 0 --> patch release that comes with non-breaking bug fixes

Many packages use other existing packages to lend to their unique functionality. These packages are known as "dependencies". The next section will show how to update a single dependency.

Updating a single package dependency

To check for outdated dependencies within a package, use the outdated command with either npm or Yarn:

$ npm outdated
$
$ yarn outdated

This will display a list of package dependencies that could be updated to a newer version. Here are some ways to update a single dependency.

npm

The npm update command, when used with a specific package name, updates that package. Some minor syntactical points to note:

• Running npm update <package-name>@x.y.z updates the package to the specific x-major, y-minor, and z-patch versions.

Assuming we have an outdated version of lodash already installed:

$ npm update lodash@4.17.10

• Running npm update <package-name@latest updates the package to the latest available version in the npm Registry .

$ npm update lodash@latest

Yarn

In Yarn, the commands are similar. Instead of using update, use up.

Sticking with the lodash example, here is updating to a specific version:

$ yarn up lodash@4.17.10

And here's updating to the latest version:

$ yarn up lodash

Updating all package dependencies

While we could use npm update or yarn upgrade to update all dependencies within the constraints of the package.json file, this section covers updating all dependencies to their latest major version.

There is a package known as npm-check-updates, which is designed to update all dependencies regardless of what was specified in package.json. It's shorthand alias is ncu.

Because both npm and Yarn have access to the npm Registry, npm-check-updates is compatible with both!

$ ncu

Checking package.json
[====================] 1/1 100%

 lodash           4.17.10  →   4.17.21

Run ncu -u to upgrade package.json

$ ncu -u
Upgrading package.json
[====================] 1/1 100%

 lodash           4.17.10  →   4.17.21

Run npm/yarn install to install new versions.

$ npm/yarn install

It's been a looooooong while since I last wrote exclusively here on Hashnode. I don't know about you, friends, but it's been a long and wild 2021 for me so far. But great things are finally happening for me! Check this out:

That's right! I'm happy to formally announce on My Dev Diary that I now work as a Content Contributor at Codecademy! I'll be working on their Free Team where I get to write amazing, public-facing content. This is an exciting time for me as I've never been more busy yet restless. Currently, I'm working part-time but the work I'm doing is interesting and enlightening!

The Struggle Is Real

But I'm not gonna lie. It wasn't an easy road getting to this point. By the time I had gotten my current role, I had hopped between 3 jobs...just this year! After I graduated my bootcamp last Fall, the world was still in the thick of the COVID-19 pandemic. The economy was already volatile to begin with. The cost-of-living is very high where I live. Money was tight and the situation put a huge strain on my partner, Kristin.

Going from one job to the next was very stressful, to say the least. They were all non-tech jobs and didn't pay super great based on my location.

• The first was at a grocery store on Lower Cape. I worked in the deli and meat departments during the busy 2020 holiday season. It was the first paying work I got after graduating my bootcamp.

• The second was at a garden center down the street from my house. It was, by far, one of the chillest jobs I'd ever worked. I worked at a cash register, which I'd done before. The job wasn't stressful, but I needed something that payed better. By the time I left this job, I'd already discovered the posting for my now-current role.

• The third job was as a mow crew member for landscaping company. Where I live is home to some of the wealthiest Americans, which means big houses, which means "MANY MOWERS NEEDED". The pay was okay and the company was surprisingly alright to work for... though, I only worked there for 3 weeks. But much respect to folks who have done or are currently doing this work. It is not easy by any stretch.

When I got the offer for my current role, I was in a landscape truck on way to the next house to mow. This was the news I was hoping for after almost a year of job-hunting.

There's Light at the End of the Tunnel

The way I found my job was really unorthodox and, honestly, a stroke of luck. I found out about the job opportunity from a tweet from one of Codecademy's curriculum developers. I reached out to one of the leaders on the team and immediately hit it off. I got super lucky.

If there's anything I'd take away from that experience, it is this: Networking matters.

When I wasn't engaging with other people in my space of interest, I wasn't feeling satisfied about the effort I putting into my independent work. But by sharing my work with that team leader and engaging with a member of the tech community, I felt genuinely satisfied by making that connection. Even if the effort went the other way, and I didn't get the job at Codecademy, I had made a new connection that has long-term mutual benefits.

This is all to say that, as long as you stay motivated and focused, you'll see that opportunity when it comes around. And when it does, you'll know you have to take the chance on it. At least, that's how I felt when I found this role. That was my light at the end of the tunnel.

Part of what makes Gatsby a powerful frontend framework is its list of builtin commands via the Gatsby CLI tool . Commands such as gatsby new and gatsby build allow for a smooth experience with development and deployment, respectively. We are going to go beyond these common commands and explore some of the lesser known ones.

Note: Before proceeding, make sure that gatsby cli is installed. Check with npm list -g | grep gatsby-cli. If it is not install, do so with npm install -g gatsby-cli. This article uses Gatsby version 3.8.1 and Gatsby CLI version 3.7.1

Discover other commands with help

As is usual with most CLI tools and package managers, Gatsby CLI come with a help command for displaying every available command.

Some commands, as displayed above, have a shorter version in addition to the longer version. This includes help:

// gatsby help 
// gatsby --help
// gatsby -h

Most commands are organized with their name on the left and a brief description on the right. The help command is useful for a quick reference of a seldom-used command.

View info about the project and local OS

Similar to help, the gatsby info command is meant to display useful information. The important difference is that gatsby info is strictly meant to display information.

Here is a breakdown of what gatsby info will display when run:

• System

  • OS - operating system of local machine
  • CPU - processing information of machine
  • Shell - type and version of shell being used (usually bash or zsh )

• Binaries - locations and versions of command tools such as Node, npm and yarn

• Languages - locations and versions of locally installed programming languages (Python, etc.)

• Browsers - names and versions of installed web browsers (Chrome, Safari, etc.)

• npmPackages - names and versions of Gatsby-related packages

• npmGlobalPackages - names and versions of globally-installed packages (Gatsby-related)

The info command can prove useful for better understanding the local system environment within which the Gatsby project lives.

Explore the project's environment with repl

This last command is interesting. REPL ("read-eval-print-loop") is a environment that allows for some operations to be performed at a specified point in the code. Gatsby REPL provides an interactive shell that lets us work with special variables in our Gatsby environment.

Working from the root directory of a Gatsby project, run the gatsby repl command on the terminal. A shell will appear and should look like this:

With a new interactive shell (gatsby >) open, we can interact with various datum within our Gatsby project. Here are some descriptions of some of the more interesting variables that can be accessed in Gatsby REPL:

Pages

pages returns an array of objects with information about components classified as "pages". Using the default starter page , if we run gatsby repl and type the following operation:

// in the Gatsby REPL shell
gatsby > for(p of pages) { console.log(p[1].internalComponentName + ' = ' + p[1].componentPath)}
Component/dev-404-page/ = /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/.cache/dev-404-page.js
Component/404/ = /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/pages/404.js
Component/404.html = /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/pages/404.js
ComponentIndex = /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/pages/index.js
Component/page-2/ = /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/pages/page-2.js
Component/using-typescript/ = /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/pages/using-typescript.tsx

In the example above, we looped through pages with a for-loop and printed out information about a page's internalComponentName and their componentPath (absolute path).

siteConfig

The siteConfig returns an object that represents the data found in the gatsby-config.json file. This includes plugins and siteMetaData. It's another way of looking at a Gatsby site's configurations.

gatsby > siteConfig
{
  plugins: [
    {
      resolve: 'gatsby-plugin-react-helmet',
      options: {},
      parentDir: '/Users/brandondusch/Desktop/projects/lets-try-gatsby-repl'
    },
...

staticQueries

In Gatsby, with help from GraphQL, we can query for data from virtually any location within our project's environment. Therefore, Gatsby REPL provides a staticQuery variable to act as a representation of those existing queries. For example, when a new Gatsby is created with default settings, there are two predefined static queries. One is located in the seo.js component; the other is located in the layout.js component. This can be confirmed when using staticQueries:

gatsby > staticQueries

Map(2) {
  'sq--src-components-layout-js' => {
    // query information
  }, 
  'sq--src-components-seo-js' => {
    // query information
  }
}

Here is another example that utlilizes REPL operations to present a nice summary of which components have static queries, their location, and the actual queried data:

gatsby > for(q of staticQueries.values()){
... console.log("Id: " + q.id)
... console.log("Location: " + q.componentPath)
... console.log("Query: " + q.query)
... }
Id: sq--src-components-layout-js
Location: /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/components/layout.js
Query: query SiteTitleQuery {
  site {
    siteMetadata {
      title
    }
  }
}

Id: sq--src-components-seo-js
Location: /Users/brandondusch/Desktop/projects/lets-try-gatsby-repl/src/components/seo.js
Query: query usersbrandonduschDesktopprojectsletsTryGatsbyReplsrccomponentsseoJs63159454 {
  site {
    siteMetadata {
      title
      description
      author
    }
  }
}

Wrap-Up

The Gatsby CLI is capable of more than just running a server and starting a new project. In this article, we learned the following:

1. Use gatsby help to display a list of available commands in Gatsby CLI
2. Lookup information about the local machine with gatsby info
3. Perform REPL operations on select Gatsby environment variables with gatsby repl

To learn more about Gatsby CLI, as well as using Gatsby REPL, refer to the links in the "References" section.

Until then, Happy Coding!

References

Commands (Gatsby CLI) -- Gatsby Docs

Gatsby REPL -- Gatsby Docs

Definition of toString() Method

In JS, the method toString() is a prototype method of the Object class that returns a string representation of the object-type it is being invoked against. Since nearly everything in JS is a descendant of an object, they are able to be represented as a string with toString():

// traditional objects 
let testObj = {
  name: "Brandon", 
  age: 28, 
  location: "Massachusetts"
}

console.log(testObj.toString()) // --> "[object Object]" 

// numbers (integers and decimal numbers)
let testNum = 42

console.log(testNum.toString()) // --> "42" 

// Date objects 
let currentDate = new Date() 

console.log(currentDate.toString()) // --> "Sat May 08 2021 22:11:34 GMT-0400 (Eastern Daylight Time)"


// even arrays!
let testArr = [1,2,3,4] 

console.log(testArr.toString()) // --> "1,2,3,4"

The toString() function is one of the most widely-used built-in JS functions given its flexibility with multiple data types. In this article, we are going to explore some less common use-cases for toString() that will take your programming to the next level.

Use-Case #1: Change Integers from Base-10 to Binary

When it comes to performing string conversion on integers, an optional radix parameter can be passed to toString() to convert base-10 integers to other bases. Every base-10 integer has a base-2, binary equivalent. Although there are plenty of other ways of converting a base-10 integer to binary, toString() makes the task seamless when you pass in 2 as the radix.

let testNum = 42 

let binaryTestNumStr = testNum.toString(2)

console.log(binaryTestNumStr) // --> "101010"

As long as the data type being used with toString() is an integer, when you pass in 2, you will get a string representation of the integer in binary form.

Use-Case #2: Convert Colors from RGB to Hexadecimal

The toString() function can also be used to change RGB values to hexadecimal.

In web development, programmers use CSS to add styling to their websites, including color. One common way of representing colors in CSS is with RGB values. RGB is a combination of three numbers, ranging from 0 to 255, that represent the spectrum of red, green, and blue, respectively.

Another common way for writing web color values is with hexadecimal values. They are similar to RGB in that they are technically composed of three values. The difference, however, is that each component of a hexadecimal value is always 2-characters-long. With toString(), we can convert a sole RGB value to its base-16 hex-equivalent by passing in 16 as our radix value:

let rValue = 240 

let gValue = 133

let bValue = 79

rValue = rValue.toString(16) // --> "f0"

gValue = gValue.toString(16) // --> "85"

bValue = bValue.toString(16) // --> "4f"

let hexValue = rValue + gValue + bValue

console.log(hexValue) // --> "f0854f"

When you pass in 16 to toString(), it will expect the value-to-be-stringified to be an integer. It takes the integer and translates it into a 2-character value.

There is something important to point out when converting to base-16 with toString(). In order for an RGB value to be converted correctly, it must fall between 0 and 255. Otherwise, the function will return a confusing result.

Wrap-Up

This article isn't intended to veer you away from learning how these conversions work algorithmically (you should!). It's about demonstrating some interesting use cases for a popular JavaScript function. The toString() function, at the end of the day, returns just a string representation of the object-like value it is being invoked upon.

Thank you for reading and I hope you found this to be interesting and, perhaps, useful.

Keep on Coding.

References

Everything About JavaScript Objects by Deepak Gupta --> (Medium Article)

Object.prototype.toStirng() --> (MDN docs)

For the first 100 days of 2021, as part of #100DaysOfCode, I am re-introducing myself to common JavaScript concepts and blogging about them! For this post, I am going to talk about closures and IIFEs and how important they can be in JavaScript programming.

Closures

In JavaScript, functions are considered to be "first-class" because, like other variables, they can be assigned as a value, passed as an argument and even returned from other functions! Because JS functions are regarded this way, each time they are created, they come with an ability to utilize variables from outside its scope. This ability is known as a closure.

Closures refer to an enclosed function's access to its surrounding state, the lexical scope. For example, in this short code snippet:

let A = "Hello, World!"
function greeting() {
  console.log(A) 
}

greeting() // --> Hello, World!

Despite A not being defined outside the scope of greeting(), it is still accessible within the function. Let's see what happens if we change the value of A below the definition of the greeting() function:

let A = "Hello, World!"
function greeting() {
  console.log(A) 
}

A = "Hello, Other World!"

greeting() // --> Hello, Other World!

Normally, this isn't possible in other languages. But in JavaScript, thanks to closures, when greeting() is executed, the A variable within its scope is bound to the most up-to-date version of the global A variable. Thus, "Hello, Other World!" is logged to the console.

But the most classic example of using JS closures is when you invoke a function inside another function. Let's look at another example:

function FuncA() {
  let name = "Brandon" 
  function FuncB() {
    console.log(name)
  }
  FuncB() 
}

FuncA() // --> Brandon

Again, closures make this code functional (pun intended) by allowing enclosed inner functions to have access to everything inside its surrounding environment.

If you were to return FuncB instead of just invoking it, the name information is still there because of closures. We can execute either with additional variable assignment:

function FuncA() {
  let name = "Brandon" 
  function FuncB() {
    console.log(name)
  }
  return FuncB
}

let newFunc = FuncA()
newFunc() // --> Brandon

...or double parentheses:

function FuncA() {
  let name = "Brandon" 
  function FuncB() {
    console.log(name)
  }
  return FuncB
}

FuncA()() // --> Brandon

Since we're getting into more parentheses...

IIFEs

IIFE (or "iffy") stands for immediately invoked function expression. When you run JavaScript code, function statements go through a "creation" phase where they're prepared for execution but aren't run yet. This happens in the "execution" phase. But sometimes, we don't want a function to hang around and wait to be executed; we want it to run right as soon as it's created. Enter IIFEs.

(function(name) {
  console.log("Hello, " + name)
}("Brandon")) // --> Brandon

In the example above, we enclose an anonymous function statement in an additional set of parentheses. If we didn't do this, we would a SyntaxError thrown at us because function statement usually are expected to have a name. IIFEs get around that. IIFEs turn the function statement into an expression that is immediately invoked.

const AddTheSum = (function(a,b) {
  console.log(a + b) 
}(2,2))

// immediately invoked, no need to write AddTheSum to log to console

const Multiply = function(a,b) {
  console.log(a * b)
}

Multiply(2,3) // function expression stored but not executed; you must use Multiply() to invoke.

Conclusion

If you code with JavaScript, you've already been using closers. Even if one function is written in a file, it is still enclosed in the global scope. Closures let you link data defined in the global scope with the inner function that operate on that data.

There are many libraries and frameworks that wrap their entire code base in a function to avoid value collision in the global scope (IIFEs). This ensures that any duplicate variables with differing values belong in their respective contexts upon executing, preventing a collision.

Together, closures and IIFEs protect your JavaScript program and its data.

Resources

Closures (MDN docs)

IIFEs (MDN docs)

JavaScript Under the Hood Pt. 7: IIFEs

When Stars Collide: Art and Tech Together

When I was in middle and high school, prior to wanting to work in tech, I studied the arts. Vocal music, specifically. But I like to express myself in other art forms, like drawing and writing.

For this year, I wanted to come up with ways to code in a more creative and expressive way as opposed to the usual functional or object-oriented way. I recently started learning to use the p5.js JavaScript library to create compelling sketches with code. Per their official website , "p5.js has a full set of drawing functionality" that treats the whole browser as a sketch canvas.

What is a Sketch?

A "sketch" is a term borrowed from the methodologies of the [Processing language] (https://processing.org/) , which is a direct influence of p5.js. Sketching is the practice of visualizing an idea expressively with code.

The Wall Drawings of Sol LeWitt

One of my first homework assignments for the course was to practice sketching by drawing out these wall drawings by an American artist named Sol LeWitt . Considered the pioneer of Conceptual and Minimal Art, LeWitt was famously known for his wall drawings. The whimsical element of his drawings was that they weren't actual drawings! There were simple text cards with "instructions" for how to envision a given wall drawing.

These instructions were usually composed of 1 or 2 sentences. The idea is that the observer reproduces the work by strictly following Sol's instructions. However, the observer is free to interpret anything else that wasn't explicitly mentioned in the instructions.

This seems like an ideal first exercise for someone like me who is just beginning to learn to draw with code.

Sol's Wall Drawings Using p5.js

Let's use the power of p5.js to draw Sol's "Wall Drawing #17" with code! Here is the image along with the instructions:

Four-part drawing with a different line direction in each part.

OpenProcessing

If you've never "sketched" or used a library like p5.js before, a great place to start practicing is at OpenProcessing , a fantastic online editor for creative coding. It's free to create an account and you can start sketching right away. You could also use p5.js's in-house editor, but this tutorial will be done from OpenProcessing.

Start a New Sketch

Click "Create Sketch" in the top right-hand corner. A new editor will appear with these two crucial pieces of code:

function setup() {
    createCanvas(windowWidth, windowHeight);
    background(100);
}

function draw() {
    ellipse(mouseX, mouseY, 20, 20);
}

The first function, setup(), does exactly what it says: it sets up the canvas on which we will draw our sketch. Inside, we set the dimensions of the canvas with createCanvas(), stretching it to the size of the browser window.

The other function, draw(), executes whatever p5-code is inside and "draws" on the web page "canvas" that was set up earlier.

For the rest of the tutorial, we'll work to refactor both of these functions so we can produce our Sol drawing.

Parse the Instructions

In order to render the desired drawing, we'll need to parse Sol's instructions and turn them into pseudocode. Let's revisit those instructions:

Four-part drawing with a different line direction in each part.

We can think of the "parts" as the sections of the canvas that get a different line direction:

• First part - lines are up and down
• Second part - lines are left to right
• Third part - lines are left-diagonal
• Fourth part - lines are right-diagonal

Notice, also, how, in the final image, it is wider than it is tall. This tells us that when we set up the canvas, its dimensions should reflect that. Let's go with 1000x500:

function setup() {
    createCanvas(1000, 500);
}

Now that our canvas is properly sized, it's time to move to next step.

The line() function

The drawing that we are trying to replicate is made up of just lines. In p5.js, there is a special set of functions dedicated to drawing 2-D shapes, including lines!

The line() function draws a physical line on the page when passed the arguments x1, y1, x2, and y2 --> line(x1,y1,x2,y2). In the example below, we use the function to evenly bisect the canvas.

function setup() {
  createCanvas(400, 400);
}

function draw() {
  background(255, 204, 0);
  line(0,0,400,400)
}

But wouldn't it be tiresome keep writing multiple calls to line()? We'd also need to be mindful of the 1000 x 500 canvas dimensions**. A great solution to this problem is using for loops*!

Loops and Loops of Lines

For the wall drawing, we need to draw enough lines to resemble the sketch above. line() is definitely going to be useful.

for loops are a particularly handy tool for drawing lines because we can control the limit of iterations as well as the number of steps each time. Since there are four parts, we'll need 4 for loops.

*While the instructions do not explicitly say, I drew the lines such that they were stretching 500 pixels-tall, the height of the canvas. Their width will be each be 1/4 of the canvas width, 250 pixels-wide.

Part I - Vertical Lines
To draw this first part, we know that each vertical line must be 500 pixels-tall. Therefore, we also know our y-coordinates: (x1, 0, x2, 500). In the loop, to keep space between the lines, the x-coordinates are going to change by 5 until they get to the 250-pixel mark in the canvas.

Here is what it looks like:

for(let x = 0; x < 250; x +=5) {
  // line code here
}

Next, the line code with the coordinates x, 0, x, 500:

for(let x = 0; x < 250; x +=5) {
  line(x, 0, x, 500)
}

And here is what we get:

function setup() {
    createCanvas(1000,500)
}

function draw() {
    for(let x = 0; x < 250; x+=5) {
        line(x, 0, x, 500)
    }
}

Woot woot! We have drawn the first part of our wall drawing! Onward!

Part II - Horizontal Lines In this part, we are dealing with horizontal lines that go from left to right. Unlike the last part, where we knew the height of each line, in this part we know the width of each line: 250-pixels wide! This is because, since each line spans the width of the entire "quarter" of the canvas, its width is 250.

This part picks up where the last part left off at the 250-px mark. That means that each line will stretch from the 250-px mark to the 500-px mark. Therefore, the x-coordinates for each line won't change and will always be 250,500.

The for loop for the horizontal lines will traverse every 5 y-coordinates, drawing line() each time, until we've spanned the entire 500-px height of the canvas:

  for(let y = 0; y <= 500; y+=5) {
    line(250, y, 500, y)
  }

Nice :) Let's move on to the next part.

Part III - Left-Diagonal Lines The last two parts of the canvas are definitely more challenging to draw. Unlike Parts I and II, where we could draw lines with either a constant x- or y-coordinate, the last two parts deal with diagonal lines.

One way I've found is by drawing each piece of third part from different starting points up to certain point, but completing it nonetheless. Imagine you divide the third part horizontally and draw diagonal line through each half:

This rough sketch outlines my general think about how the lines could be drawn in a sort of fragmented way, where each triangle picks up where the last one left off. Hence, this is why some of the coordinates are doubly marked.

I also noticed that as each line is drawn in the triangle, y1, and x2 coordinates would change while the x1 and y2 coordinates remained constant.

Following this logic, we can create a for loop and do the following:

  for (let i = 0; i <= 250; i += 5){
    line(500, i, 500+i, 0);
    line(750, i, 500+i, 250);
  }

and here's what we get with the rest of our wall drawing:

Sweet! So how can we draw the rest of the third part? We can only iterate up to 250 to evenly draw the lines, which puts us at the 250px mark of the canvas's height. Therefore, we should add 250 to our y1 coordinate to start at the correct place and finish the last two triangles:

  for (let i = 0; i <= 250; i += 5){
    line(500, 250+i, 500+i, 0);
    line(750, 250+i, 500+i, 250);
  }

Part IV - Right-Diagonal Lines For the fourth and final part of our wall drawing, we need to draw diagonal lines going in the opposite direction.

Like last time, imagine you divided the part into two squares and bisected each line to create four triangles, keeping in mind where you are coordinate-wise in the canvas:

Our start and stop points seem to have been rearranged due to the direction change. Starting at (1000,0), as lines are drawn towards the end of the first triangle, the x1 and y2 changing according to iteration.

line(1000 - i, 0, 1000, i)

When the next triangle is drawn, lines drawn going away from the hypotenuse starting at (750, 0), the y1 and x2 coordinates change:

line(750, i, 1000-i, 250)

If we put it in a for loop with a limit of 250, here's what we get:

  for (let i = 0; i <= 250; i += 5){
    line(1000-i, 0, 1000, i);
    line(750, i, 1000-i, 250);
  }

Like the previous part, we add two more line() calls with 250 added to the y1 coordinates:

  for (let i = 0; i <= 250; i += 5){
    line(1000-i, 0, 1000, i);
    line(750, i, 1000-i, 250);
    line(1000-i, 250, 1000, i);
    line(750, 250+i, 1000-i, 250);
  }

And we have finished our Sol Leweitt Wall Drawing!

Not bad for a first p5 sketch, huh?

Resources

Create Your Own Sol Lewitt (with p5.js)

The History of Processing by Casey Reas and Ben Fry

Solving Sol Solutions Page

Earlier this year, before the advent of COVID-19, I attended my first in-person coding meetup in Pittsburgh, PA. I remember there were only a little over a half dozen of us that showed up. The general purpose was for the meetup to be a space fit for focus and deep work. Everybody mostly kept to themselves; headphones on. But I managed to connect with one person there, and we continue to stay in touch through social media.

About a week and half after that meetup, most of the United States went into lockdown due to COVID-19. Soon after that, all future meetups were cancelled until further notice. It was pretty disappointing for me because I had just started my online bootcamp. I was excited to get to engage with the community. Eventually, as the year progressed, the world as we knew it went online, including coding meetups!

After finishing my bootcamp in July, I spent a few months getting to know some engineers in the Greater Boston area. Soon after, I finally felt ready to reengage with the community and attend an online meetup.

My First Online Meetup

The meetup I attended was a weekly hack night at the Code for Boston brigade, a child organization of the Code for America Brigade network . Many engineers I connected with in the area recommended I check out Code for Boston because it was a gateway into gainful employment for them. More importantly, they gained an incredible amount of quality, hands-on experience working with a team to solve unique, challenging problems.

Living just under 2 hours south of Boston, I figured that, once the world came out of quarantine, I could commute every week to attend the meetup. The fact that they moved their hack nights online made attending all the more easier.

When I hopped on the video call for the meetup, I could tell the physical experience had been emulated pretty well (minus the pizza :( ). The first 20 minutes were some general announcements about various developments at Code for Boston. The next 10-15 minutes were sort of like a "daily-scrum" where different members gave updates on the projects they were leading.

Afterwards, most of the attendees left the virtual room and those who were "newly joined members", including myself, remained. This was the "orientation section" where each person (about four of us) had to introduce ourselves and talk about what they hoped to get out of their experience at Code for Boston. The group leaders were super nice and welcoming. They were excited to hear about someone like myself adding some representation from nearby Cape Cod.

The event leaders began to talk about which ongoing projects were recruiting new members to help out. The one that stood out to me the most was a project about " plogging ", which is the act of jogging while picking up litter and waste.

In the near future, I hope to work with Code for Boston on the cause of increasing funding for the arts in the Greater Boston area. Over the last few decades, education in the arts has faced severe budget cuts and COVID-19 has only made the situation worse. If it wasn't for my early exposure to the arts as a kid, I wouldn't be who I am today.

Here are three key lessons I took away from the meetup:

Lesson #1 : It's Alright to Be Uncomfortable

During the "daily scrum" portion of the event, a few people, the project leads, gave brief updates about the projects that they were leading. While that was going on, I didn't feeling completely confident that I understood what was being said. A few days later, I'd realized: it's ok.

First of all, it was my first time ever attending this meetup. Of course I wasn't going to feel in sync with what was going on! Starting anything, especially for the first time ever, can feel overwhelming. But as American humorist Mark Twain once stated:

The secret to getting ahead is getting started.

I believe its as true today as it was for Twain in the 19th/ early 20th centuries.

Lesson #2 : Be Open to Working with New Tools

With new projects come new challenges and problem sets that may require one to go beyond just the tools in their "toolbox". New languages, frameworks and technologies may be introduced as you get involved with more projects.

This holds true even beyond meetups. I was introduced to Ruby and Ruby on Rails in the bootcamp I attending earlier this year. Currently, I'm learning TypeScript while working on a project with a colleague/ friend outside of work.

Lesson #3 : Have Fun with Problems You're Passionate About

One of the things that drew me to Code for Boston (other than being in proximity to where I currently live), was that it's a civic technology meetup. "Civic tech" is described by Code for Boston as "using technology in a creative way to help better the lives of individuals in our communities". More info here.

Having grown up in the City of Pittsburgh, my school background was primarily in arts education (specifically, vocal performance). Though I'm now working in an industry different from what I went to school for, I still hold a deep appreciation for the arts and what it gave me in my life. Over the years, I've felt like arts education has been held as less important in a person's education and, as a result, most of everything in the arts (education, theaters, studios, galleries, concert halls, opera houses, etc) have been economically strained. Keeping the arts as an integral part of our culture is an issue that is near and dear to me. Therefore, the first problem I'd like to tackle with Code for Boston is helping in the arts. One idea that comes to mind is helping artists with showing exhibits of their work in a socially distant way.

Happy Coding!

Brandon

Introduction

One of the reasons why Gatsby is so powerful is that it comes with GraphQL built-in. GraphQL is a querying language that allows developers to query for and manipulate their site's data (images, content, links, etc.). Its methodology for doing this borrows some of its terms from graph theory, like nodes and edges. While there are definitely other ways to query your site data besides GraphQL , doing so has many limits. GraphQL simplifies a lot site complexity, including:

• Storing site data, such as images, links and node properties, in a single place
• Utilizing edges and node to make queried data parsable and accessible
• Improving site loading/ performance by lazy-loading images (using gatsby-image)

For this tutorial, we're going to leverage the power of GraphQL by building a portfolio site with Gatsby. This site will use GraphQL to query for site data including images and portfolio project information.

Prerequisites

In order to get the most value out of this tutorial, you will need the following:

• General knowledge of Gatsby, its plugins and its file structure
• Solid understanding of React (since Gatsby itself is a React-based framework)
• Comfortable parsing and manipulating JSON objects (GraphQL queries return JSON objects)

You will also need to have these Gatsby plugins add:

• gatsby-source-filesystem - loads site data to Gatsby's internal data store
• gatsby-transformer-json- converts data into format to be queried by GraphQL
• gatsby-plugin-sharp - optimizes images
• gatsby-transformer-sharp - allows access to optimized image data
• gatsby-image - allows for lazy-loading of images

Step 1 - Start a New Gatsby Site and Install Plugins

The first thing to do is to create a new Gatsby site on the terminal/ console:

gatsby new portfolio-site

This will take a minute or so to finish installing all the necessary files and folders.

Next, we're gonna sort of "clean up" the default page (src/index.js) by removing the code that renders the default text and images for a new Gatsby site. If you want, you can also change the header that says "Gatsby Default Starter" by going into gatsby-config, into the siteMetaData, and changing the title value. After removing the content, if you run gatsby develop, the page should look like this:

Afterwards, in the terminal, go ahead and cd into portfolio, or into whatever name you gave it.

Next, we'll need to install the necessary plugins to make GraphQL queries possible:

npm install gatsby-source-filesystem gatsby-transformer-json gatsby-plugin-sharp gatsby-transformer-sharp gatsby-image

Check the package.json file to see if the plugins were added.

Afterwards, do not forget to edit the gatsby-config.js to actually enable the plugins. And be sure to change this line:

    'gatsby-transformer-json',
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/src/images`,
      },

...to this line:

    'gatsby-transformer-json',
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `images`,
        path: `${__dirname}/data/images`,
      },

And delete the src/images folder to avoid path conflicts at build-time. I found this necessary because I considered my images to be a part of my data. Therefore, it made sense to lump all my image files in my data folder.

Step 2 - Create a Top-Level data Folder, Then Add Data

To get the most out of Gatsby, we're going to create a data folder at the top-level of the site. Inside, we can organize the data however we want. But let's keep it simple and create an images folder followed by a projects.json (outside of src, inside of data).

Presumably, all images in the site will go in the images folder. This includes images for the main content, the side content, as well as thumbnail images for the portfolio projects themselves.

The projects.json file will be used to store site meta data regarding the projects:

// data/projects.json
[
  {
    "title": "Project A",
    "github_url": "source code link here",
    "demo_url": "demo link here",
    "image": "./images/rails-fitness-image.jpg",
    "description": ""
  },
  {
    "title": "Project B",
    "github_url": "source code link here",
    "demo_url": "demo link here",
    "image": "./images/nyt-bestseller-cli-image.jpg",
    "description": "Users can search for the NYT Bestsellers List by date, filter by category and learn more"
  },
  {
    "title": "Project C",
    "github_url": "source code link here",
    "demo_url": "demo link here",
    "image": "./images/weather-app-image.jpg",
    "description": ""
  }
]

This is an important step because we'll need this meta data in order for it to be accessible in a GraphQL query.

Step 3 - Create a Component with Project Information

We're almost about to perform an amazing GraphQL query to utilize everything we've done so far. But before we do that, we'll want to have some way to extract and represent that project information on the site.

Because Gatsby is a React-based static-site generator, we can create a component to work as a ProjectCard that renders information about a single project. This way, when we query for project data, it will have a place to go.

Let's create a new file, named projectCard, inside the src/components folder. Next, we'll import React in order to create the ProjectCard component.

import React from 'react'

const ProjectCard = () => {
}

export default ProjectCard # allows the component to be imported in another file

Remember when we installed gatsby-image back in the very beginning? We can import a special Image component that allows to access special image properties fetched from the GraphQL query (which we'll see in the fourth and final step).

import React from 'react'
import Image from 'gatsby-image'

const ProjectCard = () => {
}

export default ProjectCard # allows the component to be imported in another file

Now let's go work on the actual ProjectCard component. Notice how it's a functional, stateless component. It can only handle props, which we pass in as an argument to the function. Because Gatsby uses modern ES6+ JavaScript, we can destructure the project object's properties and pick out the ones we want to use. Remember when we set up the project objects and their properties (title, description, image, etc)? Those are the properties we're going to destructure and pass as props to the component. We'll also pass the image data to the Image component:

const ProjectCard = ({ demoURL, githubURL, imageData, title, description }) => {
  return(
    <div className="project-card">
      <Image className="project-image" fluid={ imageData } alt={ title } />
      <div className="project-info">
        <h2>{ title }</h2>
        <p>{ description }</p>
        <a href={demoURL} rel="noopener noreferrer" target="_blank">View the demo</a> &nbsp;
        <a href={githubURL} rel="noopener noreferrer" target="_blank">View the source</a>
        <br/><br/><br/>
      </div>
    </div>
  )
}

Step 4 - Write a GraphQL Query with GraphiQL

Another sweet feature of Gatsby is that, along with GraphQL, it also comes with a cool interface for writing and testing queries. It's called GraphiQL .

GraphiQL can be an especially useful tool for drawing complex GraphQL queries. This was a part of the reason that GraphQL was invented in the first place; GraphiQL makes using it easier.

Visually, GraphQL queries look similar to JSON objects and the returned JSON has the exact same shape. What you query for is what gets returned.

Since we wrote an array of objects in our projects.json file, we're going to install the gatsby-transformer-json plugin to make them queryable by GraphQL.

npm install gatsby-transformer-json

Then, we'll add some code to our gatsby-config.js file to enable the gatsby-transformer-json:

// gatsby-config.js

...
plugins: [
      `gatsby-plugin-react-helmet`,
    {
      resolve: `gatsby-source-filesystem`,
      options: {
        name: `project`,
        path: `./data`,
      },
    },
    'gatsby-transformer-json',
     {
       resolve: `gatsby-source-filesystem`,
       options: {
         name: `images`,
         path: `${__dirname}/data/images`,
       },
     },
  ...
]

Alright! Let's go and write a query! Go to the following url: [your local host name]/__graphql. It should look like this:

Welcome to GraphiQL! To write a query, you simply click on one of the properties in the "Explorer" column on the left-hand side. What happens as you click on properties on the left is that the query writes itself in the middle. Clicking the "Play" button up top runs the query and, if valid, will return a JSON response.

Here is the query we're going to use:

query MyQuery {
  allProjectsJson {
    edges {
      node {
        id
        title
        description
        github_url
        demo_url
        image {
          childImageSharp {
            fluid {
              ...GatsbyImageSharpFluid
            }
          }
        }
      }
    }
  }
}

Note: ...GatsbyImageSharpFluid gives us access to all the properties in fluid, including base64, srcSetWebp and originalName.

This query will return a JSON containing information about each of our portfolio projects, including detailed image information.

To make a query in the actual code base, we'll need to import two essential methods from the 'gatsby' library in the src/pages/index.js file:

• useStaticQuery - A special React hook that makes a GraphQL query at build time

• graphql - Formats a given string into a GraphQL query

import React from "react"
import { Link } from "gatsby"
import Layout from "../components/layout"
import SEO from "../components/seo"
import ProjectCard from '../components/projectCard'
import { useStaticQuery, graphql } from "gatsby"

const IndexPage = () => {
  // this hook runs at build-time, querying for site data related to portfolio projects
  const query = useStaticQuery(graphql`
    query MyQuery {
    allProjectsJson {
      edges {
        node {
          id
          title
          description
          github_url
          demo_url
          image {
            childImageSharp {
              fluid {
                ...GatsbyImageSharpFluid
              }
            }
          }
        }
      }
    }
  }
  `)


  // this
  const projects = query.allProjectsJson.edges;

  return (
    <Layout>
      <SEO title="Home" />
      <h1>Hello, World!</h1>
      <h3>My Portfolio</h3>
      {/*We're gonna map over the array of projects by destructuring the nodes, aliased as "project"*/}
      {projects.map(({node: project}) => {
        const id = project.id
        const title = project.title
        const description = project.description
        const demoURL = project.demo_url
        const githubURL = project.github_url
        const imageData = project.image.childImageSharp.fluid

        return (
          <ProjectCard
            key={id}
            title={title}
            description={description}
            demoURL={demoURL}
            githubURL={githubURL}
            imageData={imageData}
          />
        )
      })}
    </Layout>
  )
}

export default IndexPage

And we now how our list of rendered project cards!

Conclusion

While this may seem like an arduous tutorial, we actually cut down on a lot of coding by using GraphQL. We were able to render a variable amount of specially-queried data for site content. This time, we were only working with three projects. But if we had twice or thrice that many, or more, GraphQL and Gatsby are the ideal team. Gatsby may be meant for building static websites, but the amount of static data at hand makes GraphQL almost a necessity.

Happy Coding!

If you want to take a closer look, or report an issue or make a suggestion, check out the repo on Github !

Resources

ES6 in Depth: Destructuring

Graph Theory

Why Gatsby Uses GraphQL

Part 1: A Single JSON string

// example input 
const exampleJson = `{
  "first-name": "Brandon",
  "last-name": "Dusch",
  "city-and-state": "North Chatham, MA",
  "zip": "12345-1234"
}`;

// example output
`{
  "firstName": "Brandon",
  "lastName": "Dusch",
  "cityAndState": "North Chatham, MA",
  "zip": "12345-1234"
}`;

Notice that the initial input was a stringified JSON. We'd need to parse the string to turn it into a true JSON object.

let parsedData = JSON.parse(exampleJson)

Because objects in JavaScript are not iterable, we should loop through an array of its keys instead. This allows us to access each key-value pair in a iterable fashion. A for..in loop would be helpful, in this case.

Next, we need to make sure we are honoring the rules of camelCase:

• the first word in the phrase is not capitalized
• the remaining words in the phrase are capitalized

We need a test case for this using a combination of an if..else statement and using Array.split and Array.map. Let's enclose everything in a function entitled transformKebabCaseToCamelCase():

// example input 
const exampleJson = `{
  "first-name": "Brandon",
  "last-name": "Dusch",
  "city-and-state": "North Chatham, MA",
  "zip": "12345-1234"
}`;

function transformKebabCaseToCamelCase(jsonData) {
  let transformedJson = {} // initialized as empty object, we'll build as we go
  for(let key in jsonData) {
    let newKeyArray = key.split('-')
    let newKey = newKeyArray.map((word, index) => {
      if(index === 0) {
        return word
      } else {
        return word[0].toUpperCase() + word.slice(1)
      }
    }).join("")
    transformedJson[newKey] = jsonData[key]
  } 
  return JSON.stringify(transformedJson, null, 2)
}

console.log(transformKebabCaseToCamelCase(JSON.parse(exampleJson)))

// expected output
`{
  "firstName": "Brandon",
  "lastName": "Dusch",
  "cityAndState": "North Chatham, MA",
  "zip": "12345"
}`

Excellent! We are now returning a transformed version of our original JSON string. But what if we had key-value pairs where our values are nested collections (such as arrays and objects)?

Part 2: Nested Arrays and Objects

Imagine if we changed out expectations to be something like this:

// example input 
const exampleJson = `[{
  "first-name": "Brandon",
  "last-name": "Dusch",
  "address": {
    "city-and-state": "North Chatham, MA",
    "zip": "12345-1234"
  },
  "pets": [{
     "pet-gender": "male",
     "pet-name": "Bruno"
   },  {
     "pet-gender": "female",
     "pet-name": "Lana-Kane"
   }]
}]`;

// expected output
`[{
  "firstName": "Brandon",
  "lastName": "Dusch",
  "address": {
    "cityAndState": "North Chatham, MA",
    "zip": "12345-1234"
  },
  "pets": [{
     "petGender": "male",
     "petName": "Bruno"
   },  {
     "petGender": "female",
     "petName": "Lana-Kane"
   }]
}]`;

This was part of the interview was challenging. It really tests your comfort level with working with Arrays and Objects. It also requires a good understanding of what JavaScript considers as an object.

JavaScript is a loosely typed, dynamic programming language. The object type is a composite datatype that encapsulates Array, Function and Object (even null is of object type --> typeof null === 'object' // true

Another component to figuring out this part of the problem is understanding how to separate concerns and use recursion. For understandability, we should separate the task of actually converting keys to camelCase to it's own function:

function transformKey(key) {
  let newKeyArray = key.split("-");
  let newKey = newKeyArray
    /// forEach, reduce, filter, find, some
    .map((word, index) => {
      if (index === 0) {
        return word;
      } else {
        return word[0].toUpperCase() + word.slice(1);
      }
    })
    .join("");
  return newKey;
}

However, we now have to consider this: what if the values themselves are objects or arrays that contain more objects? This is where recursion comes in handy.

Let's define another helper function called transformValue(). The base case in this scenario would probably be if the given value is not an Array or an object (not an array or a function), just return the value.

In the case where a given value is an array we should map over each element v such that we recursively call transformValue(v) each time. We'll then return the transformed array.

Finally, if the given value is an object (meaning it's an instance of the class Object but it's not an array or a function), we'll iterate over each key and assigned a newly transformed key, newKey = transformKey(key). Assuming we initialized an empty object like newData = {}, we'll map newData[newKey] to a recursive call to transformValue(), passing in value[key].

// test for a true JSON object is abstracted to a function called "isObject()"
function isObject(data) {
  return (
        obj === Object(obj) && !Array.isArray(obj) && typeof obj !== "function"
  )
}

Our final code will look something like this: 
function transformValue(value) {
  let newData = {}
  if(Array.isArray(value) {
    return value.map((v) => {
      return transformValue(v)
    }
  } else if(isObject(value)) {
    for(let key in value) {
      let newKey = transformKey(key)
      newData[newKey] = transformValue(value[key])
    }
  return newData
  } else {
      // our base case
      return value 
  }
}


function transformKey(key) {
  let newKeyArray = key.split("-")
  let newKey = newKeyArray.map((word, index) => {
    if(index === 0) {
      return word
    } else {
      return word[0].toUpperCase() + word.slice(1)
    }
  }).join("")
  return newKey
}

function transformKebabCaseToCamelCase(data) {
  const parsedData = JSON.parse(data)
  return JSON.stringify(transformValue(pasedData), null, 2)
}

And now when we log it to the console:

// example input 
const exampleJson = `[{
  "first-name": "Brandon",
  "last-name": "Dusch",
  "address": {
    "city-and-state": "NorthChatham, MA",
    "zip": "12345-1234"
  },
  "pets": [{
     "pet-gender": "male",
     "pet-name": "Bruno"
   },  {
     "pet-gender": "female",
     "pet-name": "Lana-Kane"
   }]
}]`

console.log(transformKebabCaseToCamelCase(exampleJson))

// expected output
`[{
  "firstName": "Brandon",
  "lastName": "Dusch",
  "address": {
    "cityAndState": "North Chatham, MA",
    "zip": "12345-1234"
  },
  "pets": [{
    "petsGender": "male",
    "petsName": "Bruno"
   }, {
     "petGender": "female",
     "petName": "Lana-Kane"
   }]
}]`

The combination of recursion, checking for true object instances and separating concerns and tasks into helper functions brings us this newly transformed JSON string.

Conclusion

Among the "musts" of JavaScript skills are Array methods/ manipulation and the ambiguity of the object datatype. This problem is an excellent exercise in those skills along with many others.

Figuring out the rest of the second part of the problem felt truly satisfying. I am excited to tackle even more complex, interesting problems.

Happy Coding!

Resources

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures

https://medium.com/better-programming/string-case-styles-camel-pascal-snake-and-kebab-case-981407998841

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Data_structures

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/JSON

Last week, I got to experience my first technical interview... ever! To be fair, there were some aspects of it that probably aren't typical of actual technical interviews. But nonetheless, I walked away feeling grateful. I wanted to write a little blog post about the experience in the hope that others can take something away from this, especially if you've never gone through a technical interview.

A Quick Refresher About Technical Interviews

The actual makeup of a technical interview depends from company to company. But they all pretty much have the same objective: evaluate the candidate's ability to solve problems and put the solutions to code. Before the emergence of COVID-19, technical interviews were almost always done with a whiteboard. For my particular interview, we used CodeSandbox instead.

The point of this kind of interview isn't necessarily about finding "the right answer". It's about showcasing what your thinking process is like as you tackle complex problems.

My Experience

As part of Flatiron School Career Services, I had the opportunity to be interviewed by a seasoned engineer in the industry. I was interviewed by a person who works at a large company in Boston who has been in the industry for 10 years. From the moment we started the virtual call, I felt like I was in good hands. They were kind, patient and incredibly supportive during the whole process.

I was tasked with turning all the keys of a valid JSON string from kebab-case to camel-case within 40 minutes. During the first 10 minutes, to my surprise, I had already decided how I was going to tackle the problem, I spoke out in pseudocode and then typed it out. Eventually, after stumbling through an important edge case, I was able to pass through the first part of the problem with about 10 minutes to spare.

Next, for the second and final part of the problem, I was asked how I would refactor my answer to account for nested objects (specifically, JSON objects with kebab-cased keys). This definitely leveled up the challenge of the problem, but I was able to almost solve the second part. However, I ran out of time and I was 1-2 lines away from solving it. There's gonna be an upcoming post about just that!

Aftermath & Final Thoughts

After the time ran out, my interviewer and I talked a bit about what subject areas the problem touched on. Among them were Array and Object methods/ manipulation, recursion, JSON and JavaScript's treatment of the "object" datatype.

All in all, I felt confident coming out of the interview because I was able to communicate my thoughts out loud and translate them to code. The few things I should work on to make the next technical interview even more successful:

• Practice common technical interview questions. A lot of them.

• When thinking out loud, do so one step at a time and don't rush into the solution.

  • This could lead to a time-consuming refactor later on. It's important to thinking about now but also about the future.

• Become familiar with Array and Object methods/ manipulation.

  • These are two of the most common datatypes in the software industry.
  • Depending on the language, look into things like map, reduce, transform, forEach, for..in, for..of, select, and filter.

Resources

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/Objects/JSON

Recently, I've been learning about React, an amazing Javascript library that allows for brilliant UI-building. It takes care of any frontend-centric duties and leaves the rest of the app is handled by whatever the developer decides to use. However, React can seem too heavy a tool to use depending on how big and complex we want our site to be. Similar to how Sinatra is a lightweight-alternative to Rails, we can use Gatsby!

Prerequisites

In order to get the most out of Gatsby, you should be familiar with:

• the command line & git
• Node.js
• React

Because Gatsby is built with Node.js, you must have Node.js installed in order to use Gatsby. This tutorial assumes you already have it installed. But if not, here is how to do so from Gatsby's official tutorial.

Step 1 -- Install Gatsby CLI

In order to work with Gatsby, you'll install the gatsby-cli package by running npm install -g gatsby-cli

After installing, you'll be able to run the gatsby command to perform a litany of subcommands. You see a list of commands and options by running gatsby --help

Step 2 -- Create a Gatsby Site

To create a new Gatsby site, run gatsby new [name-of-site].

It seems that if you have both npm and yarn installed on your computer, you'll be asked which one you'd like to work with in your new site.

After the necessary boilerplate is set up, cd into your site.

Step 3 -- Explore the Boilerplate

Here is what the general structure of a Gatsby site should look like:

Depending on which package manager you choose in the beginning, you'll either be set up with a package-lock.json or yarn.lock file.

If you've worked with React in the past, this structure will look familiar. You'll find the common public and src folders that contain the usual files and folders:

public
|____|icons
|____|page-data
|____|static
|____favicon_32x32.png
|____index.html
|____manifest.webmanifest
|
src
|____|components #includes header, image, layout and SEO components
|____|images
|____|pages # includes index.js (the first page you see when you run the server)

There are other familiar files like .gitignore and README.md, as well.

Now, if we want to see what the site looks like we can simply run gatsby develop to start a server in the development environment.

If you want to begin a fresh new Gatsby project (a production build), you can run gatsby build. To start the server in the production environment, run gatsby serve.

Conclusion

Congratulations! You now have a functional Gatsby running and ready for editing! What will you create with Gatsby?

My suggestion: Build a portfolio site and utilize the SEO aspects of the site to get noticed!

Happy Coding, Brandon

While reviewing the code, I decided I wanted a user to be able to upload images to go with a routine and/ or its exercises. To achieve this goal, I decided to configure image uploads and attachments through Active Storage.

What Is Active Storage?

Active Storage is a component of Rails that lets a user upload and attach one or more files to an Active Record object.

More specifically, Active Storage lets you:

• Transform image uploads via ImageMagick
• Render non-image files such as PDF and video

Setup

The only real requirement for setting up Active Storage properly is for the version of Rails to be 5.2 or higher. Other than that, the setup process is pretty simple.

1. Set up the migrations

Run bundle exec rails active_storage:install, then bundle exec rails db:migrate and take a look at the following code added to db/scheme.rb:

  create_table "active_storage_attachments", force: :cascade do |t|
    t.string "name", null: false
    t.string "record_type", null: false
    t.integer "record_id", null: false
    t.integer "blob_id", null: false
    t.datetime "created_at", null: false
    t.index ["blob_id"], name: "index_active_storage_attachments_on_blob_id"
    t.index ["record_type", "record_id", "name", "blob_id"], name: "index_active_storage_attachments_uniqueness", unique: true
  end

  create_table "active_storage_blobs", force: :cascade do |t|
    t.string "key", null: false
    t.string "filename", null: false
    t.string "content_type"
    t.text "metadata"
    t.bigint "byte_size", null: false
    t.string "checksum", null: false
    t.datetime "created_at", null: false
    t.index ["key"], name: "index_active_storage_blobs_on_key", unique: true
  end

Two new tables are created afterward. The first, active_storage_attachments, according the Rails Guides article on Active Storage, is a "polymorphic join table that stores your model's class name". It is the connection between the model at hand and the other table. activestorage_blob contains all of the key metadata pertaining to the uploaded file. The "blob" stores information such as filename, content_type, and metadata.

2. Attach the file(s) to a model

Now that we've migrated the necessary tables related to Active Storage, we need to set up the mappings between a given record and the file(s) that might be attached to it. There are two distinct ways to set up attachments in models

With has_one_attached, we are establishing a one-to-one connection between an Active Record object and a single file (represented as an instance of ActiveStorage::Attached::One)

class Exercise < ApplicationRecord
  has_many :routine_exercises, dependent: :destroy
  has_many :routines, through: :routine_exercises
  has_one_attached :image

  def exercises_attributes=(exercise)
    if exercise[:name] != "" && exercise[:exercise_type] != "" && exercise[:description] != ""
      new_exercise = self.exercises.build
      new_exercise.name = exercise[:name]
      new_exercise.exercise_type = exercise[:exercise_type]
      new_exercise.description = exercise[:description]
      new_exercise.image.attach(exercise[:image]) # ^^^
    end
  end
end

^^^If there are custom attribute setters (like in the snippet above), then the file(s) needs to be attached to new instance being built.

With has_many_attached, we are setting up a many-to-many connection between the Active Record object and multiple files (represented altogether as an instance of ActiveStorage::Attached::Many)

3. Incorporate Active Storage in controllers

If you're creating and updating records with strong params, then the Active Storage instance variable must be added in the list of permitted params attributes.

class ExercisesController extends ApplicationController 
  . . .

  private 
  # in this example, `image` is the AS variable we're adding to the strong params
  def exercise_params  
    params.require(:exercise).permit(:id, :name, :exercise_type, :description, :image, 
   :routine_exercises_attributes => [:id, :routine_id, :sets, :reps])
  end
end

If you're not using strong params, then the process of passing the Active Storage variable in the controller is taken care of. (Make sure it's attached, though! --> image.attached?)

4. Add a file_field in the new/edit views

You'll then want to incorporate uploading images via Active Storage in the actual forms. Whether the form is inside the actual views or separated into a partial, you'll want to add code similar to this:

# app/views/exercises/_form.erb
# inside the form

form.file_field(:image)

See the code for an actual example.

When the server is started, the rendered form will look something like this:

Do you notice the new button for uploading an image? We've successfully set up Active Storage!

Usage

After setting up, actually using Active Storage is a breeze. If we were to fill out a routine/ edit form like normal (except we're now uploading images) and submit, the new routine looks like this:

Cost/ Benefit Analysis

The Pros: Active Storage is the official Rails tool used for attaching files to Active Record models.

With the help of the special active_storage_blobs and active_storage_attachments tables, we can attach a file to a model without adding a separate column to the model's table itself.

The Cons: As of right now, I haven't really found any cons for Active Storage!

Conclusion

If you're looking fora quick way to upload images to go with your Active Record models in your Rails projects, this is the solution for you. Active Storage is easy to set up and implement. It's a tool I'll definitely keep close to me.

Happy Coding! Brandon

Resources

Active Storage Overview (Rails Guides)

Pros and Cons of Active Storage (StackOverflow thread)

Rails API

TL;DR -- I worked in customer service at the Carnegie Library of Pittsburgh for nearly 7 years prior to moving up to Massachusetts earlier this year. Prior to that, I majored in vocal performance from grades 6-12 at two distinguished creative and performing arts public schools in Pittsburgh, Pa. After leaving my full-time job at CLP, I began a 4 and a half months-long coding bootcamp with the Flatiron School and I recently passed my final project review!

Now, at this point in my coding journey, I can look back and realize how far I've really come. But I also look back and appreciate how those two big chapters of my life prepared me for this one.

Pictured Above: Recently, I was in Provincetown and I'd passed by their public library! Seeing this awesome building simply reminded me of how much I miss exploring a library's vast array of resources. *

My Origin Story

The Mechanics of Music

Prior to making the switch into tech, my background was originally in music (vocal performance, specifically). During my teenage years, I attended two of the City of Pittsburgh's creative and performing arts public magnet schools. I majored in vocal performance; my voice-type was tenor.

My first time ever playing a musical instrument was when I took my first piano class in 6th grade. After seeing that grand piano up close, I got to see what was going on inside and how the hammers were striking the strings to produce the sound. My family didn't own any kind of piano or keyboard at the house, so coming to this class was like a treat for me. While the mechanics of a piano were mysterious to a younger me, I was fascinated by how creative one could be with it.

Starting in 9th grade, I began taking what became two of my favorite classes in high school, piano and music technology. While both involved using keyboards, music tech focused more heavily on composing music with computer programs like Sibelius and Reason . What I remember most strongly was the first time I played the keyboard and the computer "composed" what I was playing in real time!

Besides singing at school, I was teaching myself to play guitar and learning to record my progress on my phone (or tablet or computer or whatever) using either a simple recording app or a recording software like Audacity or GarageBand. I was constantly interested in listening to new music, but I didn't have a job for most of high school so I couldn't buy it. One way I got to it, however, was by checking out CDs from my local public library!

The main Carnegie Library in the Oakland neighborhood of Pittsburgh had a vast amount of music CDs, vinyls, scores and other resources. They even had a baby grand piano available for use (with headphones, of course). What started as trips for new music to the Library became frequent visits as a regular patron, usually at the West End location (pictured below).

Sifting Through The Stacks

Libraries are special to me because they essentially raised me and kept me interested in learning about the world. My earliest memory of being in a library was going to swimming classes with my brother at the Carnegie Library of Homestead's underground pool. While waiting to be picked up after class, I'd get lost in the dinosaur section in the kid's area or go read about ring-tailed lemur's in Madagascar.

I started going to the library right after school to keep reading about anything that interested me. I've never been exposed to such a large collection of worldly knowledge and resources before. It was no surprise that shortly thereafter, I got my first library card.

When I was a high school senior, I ended up getting a job at the West End library working as a shelver. Like most people who were about to graduate high school, I had no idea what I wanted to do with my life. All I knew was that I loved working at the library because it wasn't too labor-intensive and it required a minimal amount of problem solving ("Where does this book go!?", "Where can I find this book?"). What started as a simple shelving job in November 2010 blossomed into a senior clerk job by February 2020 at the Squirrel Hill location (the cover photo for this post). I enjoyed being exposed to vast amounts of books, ebooks, learning resources and other media. I also learned a bit about JSON format because it was used when we would use our library system to make create lists for tasks such as withdrawing old materials.

A rough example:

// some variation of the JSON-formatted lists we'd create using JSON-formatted inputs

// the inputs
return { 
  recordType: "bibliographic",
  maxAmount: 100,
  properties: [
    id,
    title,
    author,
    createDate,
    checkoutCount
  ],
  status: "AVAILABLE",
  sortBy: "createDate",
  before: 08/03/2020
}

// the list
{
  // list of item records according to the input
  {
    id: 0,
    title: "A Title!",
    author: "An Author!",
    createDate: 03/11/2008,
    checkoutCount: 201
  },
  {
    id: 1,
    title: "Another Title!",
    author: "Another Author!",
    createDate: 04/11/2008,
    checkoutCount: 201
  }
  // and so on, and so on up till length `maxAmount`
}

While I didn't know it, I was becoming more accustomed to working on a computer. I became more familiar with text editors and spreadsheets. When it came to helping customers on the computer, I had to learn to be somewhat good at googling. I even once attended a special series of staff training sessions that taught us about how to use the R programming language to create more efficient stat workflows for understanding how our public collection was being used by patrons.

Time To Make a Change

One of the most common book genres I saw being checked out at work were ones about different programming languages and technologies. While living in California, I began to learn about Silicon Valley and how influential its contributions to tech were for the world. At first, I didn't understand most of what was in those books. But I had an itch that I couldn't ignore and I kept reading. Eventually, I started learning more about programming on platforms like Khan Academy, CodeCademy and edX. Python was the first programming language I ever learned how to code with.

At the beginning of 2020, I'd decided that I wanted to take the leap and jump into software engineering full-time. I became burnt out from my full-time work at the library. After a near-year of teaching myself to build websites, I wasn't closer to feeling ready to apply to jobs. So I decided to enroll in the Online Software Engineering bootcamp at the Flatiron School.

Next Chapter

Flash-forward to today and I have just recently passed my final project review! Looking forward, I can't help but reflect on how far I've really come since I first started getting serious about software engineering a year and a half ago. When I look back now, I see my life divided into three major chapters lived thus far:

1. Learning things like basic music theory helped me with skills such as pattern recognition. Behind any creative endeavor, there was a process that had a mix of tried-and-true strategies mixed in with the production's unique approach.

2. Going from being a regular patron to a staff-member of the Library exposed me to many interesting software tools used for a library's workflow. Because I was handling so many materials, I came across more tech-related materials that gave me that push to pursue it.

3. I'm now in the third and current chapter of my life where I'm fresh out of a bootcamp and ready to learn more than ever before. The job search is going to be hard and frustrating. There will be days, maybe weeks, where I'm not yielding any callbacks or succeeding in interviews, but I have to keep believing that everything is a learning opportunity.

I first learned how to code 6 years ago, when I came to Pittsburgh from California and went back to my job at the Library. While I was happy to be in a comfortable position with the Carnegie Library, I was ready for a change of course in my life. Now, with the endless help and support from my partner, Kristin, I feel more ready than ever to break and bring value into this industry.

Happy Coding!

Brandon

For my fifth and final project at the Flatiron School, I decided to create a podcast tracker application that lets a user view, add and delete podcasts. Each podcasts has properties such as a name and a link to the podcast itself. The project is specifically titled "spotify-podcast-react-redux-project" on the repo because the seeded podcast data all contain Spotify links. I also intend on building off of this application in the near future by incorporating Spotify's new batch of podcast API endpoints.

Technologies Used

Like my previous project, the frontend and backend belong in their own separate repositories and are both housed under the main project repo .

Frontend

I was tasked with creating a React application that is connected to a Redux store. Despite it being a single-page application, I went with [react-router's] (https://reactrouter.com/core/guides/quick-start) <BrowserRouter />, <Switch />, and <Route /> components:

// ...frontend/src/App.js

import React, { Component } from 'react';
import { BrowserRouter as Router, Switch, Route } from 'react-router-dom'

class App extends Component {
  render() {
    return (
      <Router>
        <div className="main-container">
          <Switch>
            <Route exact path="/" component={ Home } />
            <Route exact path="/podcasts/new" component={ PodcastsNew } />
            <Route exact path="/podcasts" component={ Podcasts } />
          </Switch>
        </div>
      </Router>
    )
}
}

Because the application state will be handled by a Redux store, I added a src/actions and src/reducers folder to house files whose job is to create actions and return an updated version of the state.

The actions I created were:

{type: "GET_PODCASTS", payload: podcast} //=> fetches the current state (the list of podcasts)
{type: "ADD_PODCAST", payload: podcast} //=> adds a podcast to the state ( becomes POST request to backend)
{type: "REMOVE_PODCAST", payload: podcast} //=> deletes a podcast from the database, removing it from the frontend (DELETE request)

Backend

As with some of my previous projects, I built the backend of the application in Rails (using the --api flag to skip creating view files -- just the "MC" part of "MVC" ;) ).

# in the backend repo

rails new spotify-podcast-react-redux-project --api

For the most part, there isn't a lot of code that was written on this end. Most of the work was done in the podcasts_controller, where requests from the frontend will go to be handled by the appropriate controller action.

class PodcastsController < ApplicationController
  before_action :set_podcast, only: [:show, :update, :destroy]
  def index
    @podcasts = Podcast.all
    render json: @podcasts
  end

  def show
    render json: @podcast
  end

  def create
    @new_podcast = Podcast.new(podcast_params)

    if @new_podcast.save
      render json: @new_podcast
    else
      render json: @new_podcast.errors
    end
  end

  def destroy

    @podcast.destroy
    render json: @podcast
  end

  private
  def set_podcast
    @podcast = Podcast.find_by_id(params[:id])
  end

  def podcast_params
    params.require(:podcast).permit(:name, :hosts, :genres, :link)
  end

end

Challenges Faced

Understanding React-Redux State-Flow

As famously noted , Redux can often be more of a burden for developers than a blessing. This is especially true of smaller, simpler applications and especially ones that are already fetching data from a backend API.

Despite how superfluous this may seem, the point of this project was for me to demonstrate my knowledge of React-Redux state-flow (just with Rails thrown in the mix!).

Essentially, react-redux state-flow is unidirectional in nature; the parent React component passes down it's store-accessed information to it's child components as props. Those children can then work with those props to render data in interesting ways. The "redux" part of the state-data flow is essentially this: Action ==> Reducer ==> New State.

Regardless of what technology Redux is paired with (even React), it always follows this flow. Actions are dispatched to the Redux store, where a shallow copy of the old state and an updated version of the state are merged or reduced, which then returns the new state (and thereby updating the store).

Asynchronous Programming w/ Redux Thunk

Another challenge for me was understanding the inner workings of Redux Thunk.

One of those unavoidable parts of programming is asynchrony).

In the context of a React-Redux application, in the src/actions/index.js file, it isn't enough to simply return an object with the action information (type and payload). Instead, thank in large part to the Thunk middleware, we can return a callback function that:

1. Makes an AJAX fetch request (like GET or POST)
2. Doesn't return anything until the fetched Promise object is resolved
3. Returns a dispatched action with the action object passed in

Even after this project, I'm still not feeling too confident with async programming. However, I definitely feel good about ultimately getting it to work in this project.

If you'd like to check out the project for yourself, clone the repo and enjoy!

Happy Coding, Brandon

Resources

Asynchronous Programming)

React Router

You Might Not Need Redux (Medium article by Dan Abramov)

Author's note (07/07/2020): This article was originally published on July 1st, 2020. Since then, I made changes to talk more about the specific functions I used on the frontend to allow for client-server communication.

For my fourth project at the Flatiron School, I was tasked with building a single-page application using Javascript on the frontend and Rails on the backend. I guess you could sort of call it "JS on Rails". For the backend, I chose Rails because it has an excellent ORM and it's incredibly faithful to MVC & RESTful conventions. While Rails would work for the frontend, Javascript has incredible flexibility when it comes to DOM manipulation thanks in large part to event listeners .

Getting Set Up

I decided to build an application called "FIFO Fridge". In it, a user can create "fridges" that can store multiple "food items". Each food item contains various information like its name and food_group. At the start of this project, I made two important decisions that would affect the experience from then on:

1. I went with a single repo ("monorepo") instead of using multiple repos ("multirepo") for version control. This was mainly because I wanted a "single source of truth" that I could push all my changes to. Personally, I haven't built a project large/ complex enough to warrant using a monorepo pattern. I'll reconsider this if/ when the project grows and becomes more complex.
2. I decided to stick with SQLite for database management since it is already supported in Rails. For future projects, I'm definitely open to using other DB systems like Postgres. However, as I begin to retackle the likes of React and Redux in the next few weeks, I'm going to make an effort to use it!

Building the Backend

As I said, Rails works wonderfully as a platform for building RESTful APIs.

After creating and changing into the working directory for my project, I specifically added the --api flag at the end of the following command so that Rails wouldn't create anything pertaining to views:

rails new fifo-fridge-app-backend --api

Because I'm going to have JavaScript handle the "V" in "MVC", I need a way to pass the data from the backend to the frontend in a JS-friendly format. Therefore, I ultimately went with Rails' inherent active model serializers to do the job!

class FridgesController < ApplicationController
  before_action :set_fridge, only: [:show, :update, :destroy]
  def index
    @fridges = Fridge.all
    render json: @fridges.as_json(include: {food_items: {only:[:id, :name, :food_group, :expiration_date, :quantity]}})
  end

  # ... other actions
end

I implemented most of the CRUD-controller actions for Fridge as well as a food_items#destroy action for FoodItem. I also incorporated strong params by limiting the permitted params data to only whatever fridge data was submitted from the frontend or supplied by the seed data.

Building the Frontend

The unique twist for this project was building a frontend that utilized JavaScript's amazing ability to work with the DOM and communicate with servers. Separate from the backend folder, I established a folder solely for the frontend: fifo-fridge-app-frontend.

This would house all my stylesheets, class files, markup and source code. All the rendering, eventListeners and fetches to the backend will be handled here. For the sake of staying faithful to SOLID design (make no mistake, I have much to learn ;) ), I abstracted the work of modeling Fridge and FoodItem objects in their own class files. I also created an API class file who's sole duty was to perform AJAX requests to the backend.

So far, my project is able to perform 4 AJAX requests: GET (fridges#index), PATCH (fridges#update), POST ('fridges#create'), and DELETE (fridges#destroy).

  // fifo-fridge-app-frontend/services/api.js


  // render all fridges to the index page
  static loadFridges() {
    fetch(`http://localhost:3000/fridges`)
      .then(res => res.json())
      .then(fridgeData => {
        for(let fridge of fridgeData) {
          const {name, capacity, food_items, id} = fridge;
          new Fridge(name, capacity, food_items, id);
      }})
  };


  // fetch a POST request with the submitted form data to add a new Fridge
  static addFridge(e) {
    e.preventDefault();
    let foodGroupSelectBox = e.target.getElementsByTagName("select")[0]
    let data = {
      'name': e.target.name[0].value,
      'capacity': parseInt(e.target.capacity.value),
      'food_items_attributes': [{
        'name': e.target.name[1].value,
        'food_group': foodGroupSelectBox.options[foodGroupSelectBox.selectedIndex].value,
        'expiration_date': e.target.expiration_date.value,
        'quantity': parseInt(e.target.quantity.value)
      }]
    };

    fetch(`http://localhost:3000/fridges`, {
      method: "POST",
      headers: {
        'Content-Type': 'application/json'
      },
      body: JSON.stringify(data)
    })
      .then(res => res.json())
      .then(fridge => {
        const {name, capacity, food_items, id} = fridge;
        new Fridge(name, capacity, food_items, id);
        document.getElementById('fridge-form').reset();
      })
  };

  // delete our fridges
  static deleteFridge(fridgeID) {
    fetch(`http://localhost:3000/fridges/${fridgeID}`, {method: "DELETE"});
    document.getElementsByClassName('fridge-card')[fridgeID-1].remove();
    return "The fridge was deleted!";
  };

  static deleteFoodItem(foodItemID) {
    debugger;
    fetch(`http://localhost:3000/food_items/${foodItemID}`, {method: "DELETE"});
    document.getElementById(foodItemID.toString()).remove();
    return "The food item was deleted!";
  };


  //add food item
  static addFoodItem(fridgeCard, fridgeID) {
    let newFoodItemForm = fridgeCard.getElementsByTagName('form')[0];
    newFoodItemForm.style.display="block";

    newFoodItemForm.addEventListener("submit", (e) => {
      e.preventDefault();
      let foodGroupSelectBox = e.target.getElementsByTagName("select")[0]
      let data = {
        'food_items_attributes': [{
          'name': e.target.name.value,
          'food_group': foodGroupSelectBox.options[foodGroupSelectBox.selectedIndex].value,
          'expiration_date': e.target.expiration_date.value,
          'quantity': parseInt(e.target.quantity.value)
        }]
      };
      fetch(`http://localhost:3000/fridges/${fridgeID}`, {
        method: "PATCH",
        headers: {
          "Content-Type": "application/json"
        },
        body: JSON.stringify(data)
      })
      .then(res => res.json())
      .then(result => {
        const currentFridge = document.getElementsByClassName('fridge-card')[result.id-1]
        const foodItemsContainer = currentFridge.querySelector("#food-items-container");
        let newFoodItem = result.food_items[result.food_items.length-1];
        FoodItem.addItemToFridge(currentFridge, newFoodItem)
      });
    });
  }

Using object-oriented programming to create Fridge and FoodItem objects from the fetched JSON data, we can render them in multiple ways.

  // fifo-fridge-app-frontend/models/fridge.js

  // sets up the container elements for the fetched Fridge (and FoodItem) data
  renderFridge() {
    const fridgeContainer = document.getElementById("fridge-container");
    const fridgeCard = document.createElement("div");
    fridgeCard.setAttribute("class", "fridge-card");
    fridgeCard.setAttribute("data-fridge-id", this.id);
    fridgeCard.innerHTML += this.fridgeCardHTML();

    // create "Add Food Item" button
    // button comes with event listener that invokes API.addFoodItem() when clicked
    const addFoodItem = document.createElement('button');
    addFoodItem.innerText = "Add Food Item"
    addFoodItem.setAttribute("class", "add-food-item-btn")
    addFoodItem.addEventListener("click", (e) => {
      e.preventDefault();
      API.addFoodItem(fridgeCard, this.id);
    });
    fridgeCard.appendChild(addFoodItem);

    // form for adding a new food item to the current fridgeCard
    let newFoodItemForm = document.createElement('form');
    newFoodItemForm.id = "new-food-item-form";
    newFoodItemForm.innerHTML = `
    <input type="text" name="name" placeholder="food name" />
    <br />
    <select name="food-group-options" id="food-group-options">
      <option value="Choose a Food Group" selected>Choose A Food Group</option>
      <option value="Fruits">Fruits</option>
      <option value="Vegetables">Vegetables</option>
      <option value="Grains">Grains</option>
      <option value="Protein Foods">Protein Foods (Meats, Poultry, Seafood, etc)</option>
      <option value="Dairy">Dairy</option>
    </select>
    <br />
    <input type="text" name="expiration_date" placeholder="expiration date (##/##/####)" />
    <br />
    <input type="number" name="quantity" placeholder="quantity" min=0 />
    <br />
    <input type="submit" value="Add Item" />
    `

    // form is attached to to current fridgeCard and set to "dislpay:none" by default
    // (changes to "dislpay: block" when clicked and back to "none" when submitted)
    newFoodItemForm.style.display="none";
    fridgeCard.appendChild(newFoodItemForm);


    // button for deleting the current fridgeCard when clicked
    // uses API.deleteFridge() to send AJAX request to Rails API to
    // delete fridge from database
    const deleteBtn = document.createElement("button");
    deleteBtn.innerText = "Delete";
    deleteBtn.setAttribute("class", "fridge-delete-btn");
    deleteBtn.addEventListener("click", (e) => {
      API.deleteFridge(parseInt(e.target.parentElement.getAttribute('data-fridge-id')))
    });
    fridgeCard.appendChild(deleteBtn);


    // create "food-items-container <div> for current fridgeCard"
    // invoke FoodItem.renderFoodItems() to populate the container
    const foodItemsContainer = document.createElement("div");
    foodItemsContainer.setAttribute("class", "food-items-container");

    // render the food items and then append to foodItemsContainer?
    // TODO: Build FoodItem.renderFoodItems(foodItemsContainer, this.foodItems) <-- returns updated copy of foodItemsContainer with added food items
    // renderedFoodItems = FoodItem.renderFoodItems(foodItemsContainer, this.foodItems)
    // fridgeCard.appendChild(renderedFoodItems)

    const renderedFoodItems = FoodItem.renderFoodItems(foodItemsContainer, this.foodItems);
    fridgeCard.appendChild(renderedFoodItems);


    // finally, we append the fridgeCard to the existing fridgeContainer
    // it is now rendered
    fridgeContainer.appendChild(fridgeCard);
  };



  // fifo-fridge-app-frontend/models/food_item.js

  // given a foodItemsContainer and an array of item-object data,
  // this render
  static renderFoodItems(foodItemsContainer, items) {
    for(let item of this.sortByDate(items)) {
      const {name, food_group, expiration_date, quantity} = item;
      let newFoodItem = new FoodItem(name, food_group, expiration_date, quantity);
      let foodItemCard = document.createElement("div");
      foodItemCard.setAttribute("class", "food-item-card");
      foodItemCard.id = item.id;

      foodItemCard.innerHTML += this.foodItemsCardHTML(item);

      const deleteBtn = document.createElement("button");
      deleteBtn.innerText = "Delete Item";
      deleteBtn.setAttribute("class", "food-item-delete-btn");

      deleteBtn.addEventListener("click", (e) => {
        debugger;
        API.deleteFoodItem(parseInt(e.target.parentElement.id))
      });

      foodItemCard.appendChild(deleteBtn);
      foodItemsContainer.appendChild(foodItemCard);


    };
    return foodItemsContainer
  };


  // takes an item and fridge and adds the item to that fridge
  static addItemToFridge(fridge, item) {
    const {name, food_group, expiration_date, quantity} = item;
    const newFoodItem = new FoodItem(name, food_group, expiration_date, quantity);

    let foodItemsContainer = fridge.querySelector(".food-items-container");
    let foodItemCard = document.createElement('div');
    foodItemCard.setAttribute("class", "food-item-card");

    foodItemCard.innerHTML += `
      <h4>${item.name}</h4>
      <br>
      <strong>Food Group: </strong> ${item.food_group[0].toUpperCase() + item.food_group.slice(1)} <br />
      <strong>Expiration Date: </strong> ${item.expiration_date} <br />
      <strong>Quantity: </strong> ${item.quantity} <br /><br />
    `


    const deleteBtn = document.createElement("button");
    deleteBtn.innerText = "Delete Item";
    deleteBtn.setAttribute("class", "food-item-delete-btn");
    deleteBtn.addEventListener("click", (e) => {
      e.preventDefault();
      API.deleteFoodItem(parseInt(e.target.parentElement.id))
    });

    let linkBreak = document.createElement("br");
    foodItemCard.appendChild(deleteBtn);
    foodItemsContainer.appendChild(foodItemCard);

    fridge.getElementsByTagName("form")[0].reset();
    fridge.getElementsByTagName("form")[0].style.display="none";
  };

Tying It All Together

As of this writing, my project has achieved minimum-viable-product status. The backend is handled by Rails and works with a JS frontend to pass along JSON data via AJAX programming.

My frontend utilizes object-oriented programming to better represent the data coming from the Rails API, lending to client-server communication.

Conclusion

There are a ton of features and other cool things I'd like to do with this app. This is honestly the first application I've built where I confidently see it growing and blossoming over time. After this project, I'm inspired to go back to previous projects, review them with a new perspective and try to improve them. Every great application that we know and love (and sometimes hate) started as a "minimum-viable-product".

If there's anything that I would take away from this project, it's that no matter how anxious I may get before starting, once I starts, it's gets better from there. I'm slowly learning to get comfortable with being uncomfortable; it's a skill in and of itself. But it's those moments of discomfort that will allow me to grow and become a great developer.

Happy Coding!

Resources

Arctic Color Palette
AJAX (MDN) Mono- or Multi-repo?
Using Rails for API-only Applications

The Story, Thus Far (TL;DR-style)

Up until this point, in the pursuit of building a Rails fitness tracker app, I have managed to accomplish the following:

I Incorporated 3rd-Party Auth via Devise/ OmniAuth

While going with Native user authentication would have been totally valid, I wanted to go with Devise for the following reasons:

1. It's a litany of tools (such as Registerable, Recoverable and OmniAuthable --> more on that next)
2. It comes with the OmniAuth gem out of the box, making 3rd-party auth setup smooth and easy.

I also had to configure my app in the developer pages of whichever providers I went with (like Facebook for Developers).

I Routed the Appropriate Controller Actions to the Appropriate Views

Understanding how I wanted a user's typical experience to go was tantamount to routing the right controller actions to the right views.

I don't need to worry about controllers for User or Session because that's taken care of by Devise. Awesome! However, I did need to include an omniauth_controller.rb file that contain callback actions for the various providers.

For Routine and Exercise, I chose to go with nested routing because I want my paths to have some sort of logical naming that implies "This is the exercise for this routine" --> /routines/1/exercises/4.

Since a user can create a routine, and then create/ add exercises within, and they should be able to edit/ delete that routine's exercise:

  resources :routines, only: [:show] do
    resources :exercises, only: [:show, :index, :edit, :update, :destroy]
  end

I Worked to DRY Out Code and Use Partials

By this point, I thought it was time to take a look over what was done so far and see if any concerns could be separated into their own methods or forms. This included providing a views/routines/_form.erb partial for routines#new and routines#edit along with a views/exercises/_form.erb partial for exercises#edit.

I also DRY-ed out the controllers by creating private methods that would set variables for a given routine, exercise and routine_exercise instance, set before any action is taken:

 # app/controllers/routines_controller.rb
  before_action :authenticate_user!, :set_routine, only: [:show, :edit, :update, :destroy]

  ...
   private
   def set_routine
    @routine = Routine.find_by(id: params[:id])
  end



# app/controllers/exercises_controller.rb
   before_action :set_exercise, only: [:show, :edit, :update, :destroy]
   before_action :set_routine, only: [:show, :edit]
   before_action :set_routine_exercise, only: [:show, :edit, :update, :destroy]
   ...

  private
  def exercise_params
    params.require(:exercise).permit(:id, :name, :exercise_type, :description, :routine_exercises_attributes => [:id, :routine_id, :sets, :reps])
  end

  def set_exercise
    @exercise = Exercise.find_by(id: params[:id])
  end

  def set_routine
    @routine = current_user.routines.find_by(id: params[:routine_id])
  end

  def set_routine_exercise
    @routine_exercise = RoutineExercise.find_by(routine_id: params[:routine_id], exercise_id: params[:id])
  end

Last Challenges

For this last leg of the project, there were a few more important project requirements to hash out.

Custom Attribute Setters & Persisting Data

Because I want to mass-assign nested-attributes for a routine's related exercise (that is being created anew within the form), I have some choices:

• I could go with accepts_nested_attributes_for :exercises in Routine or...
• Use custom attributes setters and manually populate the nested attributes for the newly created exercise (exercises_attributes=(exercise))

I don't necessarily want to risk having duplicate exercise data on the basis of its name (a validation in Exercise), so using accepts_nested_attributes_for :exercises won't work well in this case. Judging from my experience with them, custom attribute setters are harder to work with and get right. But they ended up doing the job a little better.

# app/models/routine.rb

class Routine < ApplicationRecord
    def exercises_attributes=(exercise)
      if exercise[:name] != "" && exercise[:exercise_type] != "" && exercise[:description] != ""
        new_exercise = self.exercises.build
        new_exercise.name = exercise[:name]
        new_exercise.exercise_type = exercise[:exercise_type]
        new_exercise.description = exercise[:description]
      end
    end
end

# app/models/exercise.rb

class Exercise < ApplicationRecord 
    def exercises_attributes=(exercise)
      if exercise[:name] != "" && exercise[:exercise_type] != "" && exercise[:description] != ""
        new_exercise = self.exercises.build
        new_exercise.name = exercise[:name]
        new_exercise.exercise_type = exercise[:exercise_type]
        new_exercise.description = exercise[:description]
      end
    end


    def routine_exercises_attributes=(routine_exercise)
      if !routine_exercise[:sets].blank? && !routine_exercise[:reps].blank?
        new_routine_exercise = self.routine_exercises.find_by(exercise_id: self.id)
        new_routine_exercise.update(sets: routine_exercise[:sets], reps: routine_exercise[:reps])
      end
    end
end

Validations and Error Messages

I wanted to have reasonable validations for my models to ensure that invalid data wasn't being persisted to the database. I added validations for a name for both Routine and Exercise to ensure a user can't submit an invalid form. I have added field_with_errors to those validated fields:

Scope Methods

In the routines#index page, I provided a filter that lets a user select from one of three options. Each of the options triggers a Routine-level scope method that filters @routines by how "intense" a routine is (using times_per_week as a metric).

# app/models/routine.rb
class Routine < ApplicationRecord
    def self.beginner_level_routines
      where('times_per_week <= 3')
    end

  def self.mid_level_routines
    where('times_per_week <= 4')
  end

  def self.intense_level_routines
    where('times_per_week > 4')
  end
end

They are then provided in a drop-down list of options on the index page for the routines:

<!-- app/views/routines/index.erb -->

<h2>List of Routines</h2>
<h4>Filter by: </h4>
<%= form_tag routines_path, method: "get" do %>
  <%= select_tag "routine", options_for_select(["Beginner-Level", "Mid-Level", "Intense-Level"]), include_blank: true %>
  <%= submit_tag "Filter" %>
<% end %>

<% if !params[:routine].blank? %>
  <% if params[:routine] == "Beginner-Level" %>
    <% @routines = Routine.beginner_level_routines %>
    <h3>Beginner-Level Routines</h3>
  <% elsif params[:routine] == "Mid-Level" %>
    <% @routines = Routine.mid_level_routines %>
    <h3>Mid-Level Routines</h3>
  <% elsif params[:routine] == "Intense-Level" %>
    <% @routines = Routine.intense_level_routines %>
    <h3>Intense-Level Routines</h3>
  <% end %>
<% end %>

Lessons Learned

Always Keep the Minimum-Viable-Product in Mind

When I'm working on any project, especially when I've just started it, it is important to always keep the minimum-viable-product in mind. It doesn't matter how humble or how modest the final product might be. What matters is that it is functionally on a basic, minimum level and ripe for adding new features in the future. This is how all the largest, most impactful websites were when they were born -- MVPs.

Don't Wait Too Long To Ask Questions

As I progress through this bootcamp, I am becoming more certain that collaboration is key in the world of tech. It makes sense, after all. Every thing we know and love about the Internet was built not be a single person, but by a team of people. And they asked questions and sought help from the peers when they knew they needed it. Waiting too long to ask a question could prove detrimental to the progress of any project. It halts everything and there's a standstill. Eventually, nothing gets done.

Always be willing to take a leap of faith and share your troubles with the tech community. They are more than willing to help and share their experiences and wisdom.

Don't Be Discouraged

There were a lot of times where I wanted to give up on this project. And by no means, this project is far from finished in my opinion. There are a lot of bells and whistles that I want to test and implement in the future. But for now, I'm proud of what I've built for my first Rails Project. And you should be, as well, if you're also new to Rails and are working on your first project.

Until then, Happy Coding!

Resources

My Rails Fitness Tracker App (GitHub repo)

At this point of the project, I have successfully pulled off 3rd-party authentication using Devise and OmniAuth!

So now, along with signing up/ logging in the "old-fashioned way", a user can do the same thing using an account they already have with another provider (like Facebook or Google).

Routes and the Controllers

With my user login/signup out of the way, I can now focus on routing the controllers to my views (more on the views later).

One of my pain points in this project was routing and working with controllers. By the end of this, I understood that routes are supposed to set up the endpoints of their related controller action. Those controller actions, then, perform a bunch of tasks with whatever data is available in the strong params. While I still have much to learn about controllers and Rails' MVC architecture, I feel I am coming out of this with a bit more understanding of them.

I also wanted to use custom attribute setters for a newly-created routine's nested exercises, to guard against duplicate exercises being created. While I could have gone with something like accepts_nested_attributes_for :exercises in my Routine model, I wanted to ensure that both the nested attributes for exercises (1-level deep) and the related routine exercise (2-levels deep) were mass-assigned upon creation of the routine. So I went ahead and created custom attribute setters for the following:

# app/models/routine.rb

  def exercises_attributes=(exercise)
    if exercise[:name] != "" && exercise[:exercise_type] != "" && exercise[:description] != ""
      new_exercise = self.exercises.build
      new_exercise.name = exercise[:name]
      new_exercise.exercise_type = exercise[:exercise_type]
      new_exercise.description = exercise[:description]
    end
  end

If a user decides they don't want to create a new exercise while creating a new routine, the outer-if statement allows for that.

# app/models/exercise.rb
  def routine_exercises_attributes=(routine_exercise)
    new_routine_exercise = self.routine_exercises.find_by(exercise_id: self.id)
    new_routine_exercise.update(sets: routine_exercise[:sets], reps: routine_exercise[:reps])
  end

When editing/ updating an exercise inside a routine, the Exercise model needs its own custom attribute setter for routine_exercises_attributes since it is stored inside of exercises_attributes (which is ultimately stored as strong params in the routine's routine_params).

Inside the controllers for Routine and Exercise, I added some private-level set methods to DRY out some of the controller actions:

# app/controllers/routines_controller.rb

class RoutinesController < ApplicationController
  before_action :authenticate_user!, :set_routine
      # other code here
    def set_routine
      @routine = Routine.find_by(id: params[:id])
    end
end

# app/controllers/exercises_controller.rb
class ExercisesController < ApplicationController
  before_action :authenticate_user!, :set_exercise

      # other code here
    def set_exercise
      @exercise = Exercise.find_by(id: params[:id])
    end
end

This is going to be covered in more detail later, but it should be mentioned that, in conjunction with these class-level setter methods, there is a form with two levels of data entry:

1. A nested form for if the user wants to create a new exercise while creating a new routine
2. A nested form within the previous nested form that records the sets and reps for the exercise's (and, by extension, also the routine's) RoutineExercise.

Speaking of nested, I also decided to go with nested resources for when I user is dealing with their exercises in a particular routine. In other words, in config/routes.rb, I added nested resources for :routines and :exercises, scoped to certain views, that allow for the

The Views

At this point in the project, it's time to start thinking about how I want the user experience to play out while they are creating, editing, updating and deleting routines and exercises.

In config/routes.rb, I have set nested routes that describe the relationship between the Routine and Exercise models. This provides for some nifty paths including routine_exercises_path.

  resources :routines, only: [:show] do
    resources :exercises, only: [:show, :index, :edit, :update, :destroy]
  end

My application should be nimble enough to "know" which routine and which exercise we're dealing with at a given time. (e.g. routines/1/exercises/3) As such, we should have the following views:

Routines

• new via routines#new *
• edit via routines#edit *
• show via routines#show
• index via routines#show

Exercises

• edit via exercises#edit *
• show via exercises#show
• index via exercises#show

*These views will be supplied with a _form.erb partial to DRY out the forms a bit.

For the next post, I'm going to write about the struggles that awaited me after this point in the project. This included things like keeping track of nested attributes in multiple models, preventing changed data from overwriting other data and a lot more.

Until then,

Happy Coding!

SIDENOTE: As always, if you want to check out the project for yourself, play around with it and maybe give some feedback, that'd be awesome!

Recap

For my first Rails app, I am going to build a fitness tracker that let's users sign up for an account where they can create routines and store exercises in them. They can then create more, edit and/ or delete those routines and exercises.

Initial Setup & Wireframing

The setup experience with Rails was pretty smooth. Unlike Sinatra, which doesn't usually come with an out-of-the-box setup process (with the fabulous exception of the 'corneal' gem, Rails does:

rails new flatiron_fitness_rails_app

This will create all the necessary files and folders to get the project to run on a server, on Rails!

I went ahead and made a flowchart that maps out the model associations and a typical user experience:

As shown above, a User can have many Routines. We have a join-table, RoutineExercise, that allows for each of a User's routines to have many exercises, which can also have many routines. One of my project requirements is for my join-table to have a least one user-submittable attribute (something besides a foreign key like routine_id). So I went ahead and added a reps and sets column for each RoutineExercise that is created for a Routine.

NOTE: Some of the file names I have in this image weren't used in the actual codebase

Here, I'm mapping out what a simple user experience would look like in the app.

• The user starts up the server and are directed to login or signup for an account
  • At this point, the user can opt for third-party authentication (though some :provider like Github or Facebook) instead of coming up with a new set of login credentials.
• They are then taken to an index page that shows a list of their routines. From there:
  • They could create a new routine, or...
  • Click on a specific routine to see more information
• Inside an individual routine, they are shown a list of exercises; each one can be clicked for more information.
• Whether they're looking at a specific exercise or routine, they can either:
  • edit it (and be redirected back to the appropriate view)
  • delete a routine (along with any associated RoutineExercise objects, but not the associated Exercises themselves)
• Inside an exercise show page, the user should be able to either remove it from the routine or delete it entirely (which will cause other instances of the Exercise object to be deleted).

Devise and OmniAuth

Next, I wanted to fulfill the user auth requirement for the project by going with the devise gem. Devise takes care of all the user- and session-related tasks including things like setting session cookies upon login, third-party authorization with OmniAuth(more on that, soon). I don't need to worry about creating a users_controller, sessions_controller or a separate migration for creating the users table -- Devise takes call of that!

To be honest, this was hard to set up at first. If you want to use more than one provider (more than one existing account to log in from), you have to do the following for each provider:

• Register your Rails app with the provider of your choice by heading to their developer pages and following the setup instructions.

• Each provider comes with their own special omniauth-<provider_name> that you must include in your Gemfile. In my opinion, it's best to do both that and also include the general 'omniauth' gem so that, for example, you're assured your login link for Facebook is omniauthable.

• In config/initializers/devise.rb, there is a section in the source code where you must set your configurations for your omniauthable provider against the environment variables that are ( safely supplied from an .env file.

• You have to refactor your config/routes.rb so that your user routes have access to an omniauth.rb (or callbacks.rb) controller (make sure you create the appropriate file in controllers ;). This gives your users table access to those provider links (allowing 3rd-party login/signup).

After much toil, it's incredibly worth. I can now simplify my life by not having to create a new set of login credentials by sticking with a set I use a lot more often.

Now, the only caveat I've found with this is that, imagine if a user could choose between Facebook and Google as an option for login/signup and they chose Google. If they log off and then try to login through Facebook, they are weirdly redirected to the signup page. In other words, they can only login through Google since that was the provider they chose the first time.

For now, I'm going to let that go and just note in the README that when a user first starts the application and creates an account, if they want to do so through 3-rd party authentication, they must stick whichever they choose. *

** I'm almost certain there is a way to fix that issue and make it so that a user can flexibly login to the same Rails application from multiple providers. There are websites that can do that. But there are also websites that don't have that flexibility. I think that, for a first Rails application, I should appreciate that I got this far and that there is always room to grow.*

End of Part 1.

Happy Coding!

Resources

How To Configure Devise and OmniAuth For Your Rails Application

How To Use Environment Variables In Ruby