DEV Community: Hal Friday

In the Gut: Reaching a Better Understanding of Recursion

Hal Friday — Fri, 09 Feb 2024 22:32:06 +0000

Often times people (me) get swung into the habit of solving recursion style algorithms in these neat little scenarios that you find on popular sites like LeetCode and HackerRank. And it will sometimes come in handy if you run into such a problem during a live coding interview, because the scenarios share a lot of qualities and you can carry over the specific skillset you learned on those sandbox sites into whatever IDE is being used for the interview.

That's got a limited helpfulness, but I'm not as interested in learning a cleansed version of the skill that mostly makes sense in the vacuum of performing interview tricks — I want to learn recursion "in the gut," to the point of it occurring to me naturally for solution building in a real-world setting, on a production-level job.

With that goal in mind, I set out to revisit recursion and develop and understanding of it that was more versatile and less pattern-based. I wanted to record some of my experience with exploring that here in this blog post.

It makes sense to start where you are — in my case, a review of popular problems I've solved with recursion. I'd like to go over each of the following three and capture some conceptual, overarching information from each before moving forward into a more unknown, creative space and apply these concepts.

toThePowerOf

Spoiler alert! Each section will show code solutions. If you'd like to try toThePowerOf yourself before reading, check it out here.

One of the simplest recursion problems which can be used to ground one's understanding of the whole thing, is the toThePowerOf function. Your function receives a base number (b) and power (p). It must return an integer, which is the result of taking b to the power of p.

For me, the important concept which we can carry forward into our creative space from this problem is that recursion is easier to think about in an upside down way. By that I mean, the first thing you need to know about your recursive problem is: what is the end like? At what point does your algorithm know when to stop recurring? That's called the "base case" which I honestly think it's kind of a confusing name for it, because it's the case at the very tippy top of the recursion stack. In my opinion it should be called the peak case. Doesn't quite have the same ring to it, maybe crest case is better.

Anyway.

How can we determine the crest case for an algorithm which returns b to the power of p? The function should continue to recur until the power variable (p) is down to 1. At that point, we know what can start climbing back down the stack which has been built, multiplying each result by the base variable (b). It's difficult to understand this without looking at it, so take a peek at the code:



const toThePowerOf = (b, p) => {
    if (p === 1) {
        return b
    }
    return b * toThePowerOf(b, p - 1);
}

Taking it chunk by chunk, you have the crest case, when the power becomes one. Any number to the power of one is itself, so we just return that. After that, we start heading back down the stack — the return value of the most recent function call is multiplied by b, and so on. Once the stack completes, it will spit out b to the power of p.

To make sure the mental model is complete, let's take a look at this visualization of the function doing its work when given the parameters 2 and 3 as b and p, respectively.

(You can look at this on Google Drawings directly if you would like, from this link.)

As you can see, call #3 is at the top of the call stack, and it ends the recursion and completes first. It is the shortest running function in the bunch. Call #1 is at the bottom of the call stack, and when all is said and done, call #1 will be the one to return the correct answer.

If that's not quite hitting, I recommend popping the function into this visualizer and watching it / stepping through the functions as they run. I will give a warning about that site, it isn't perfect and asking it to visualize denser recursion problems has produced bugs and/or incorrect results for me. But it works well for this powers one.

This type of recursion problem is what I'd like to call linear. It steps up the call stack; it steps back down the call stack. This isn't the common use-case for recursion as seen in the real world, because such problems can also be solved in an iterative way without sacrificing much speed or space. You could just use a while-loop.

A case where recursion is a little more useful might be..

nthFibonacciNumber

Check out the problem here if you'd like to attempt it before seeing any solution.

When visualized, the recursive solution for the nthFibonacciNumber algorithm does not have one single line of calls, so it takes a more branched shape. The call flow steps all the way up the call stack, then on its way back down, it must make separate branches off of the main stack which it completes along the way. Calling nthFibonacciNumber(5) has a result that looks something like this:

(Image generated on Recursion Tree Visualizer)

While studying the algorithm this go around, the concept that I focused on retaining revolved around the use of returns.

Recursive algorithms all have at least 2 options for returning:

The return that happens during the crest case; the return that ceases any further recursion, which should never change, and
The return that receives the bulk of the work and is sent on down the line, which changes with each completed call

Using these carefully and understanding what is needed from each before beginning to write out a solution will make the actual programming part a lot easier.

So, applying the first concept to the nthFibo problem, our crest case (and first return value) should be the point at which we stop adding recursions to the stack. Since the algorithm's argument is the number of times that we need to perform the fibo operation, then we will count backward from that to the end of the line and our crest case should be 1 and/or 0 -- it just needs to stop before anything negative happens.

As for the second return value, it needs to be the result of the operations to actually find a Fib number: the last two Fib numbers added together.

Here's what the whole thing looks like.



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

Structurally, you can really see the similarities between this one and the toThePowerOf algorithm. The big difference is that Fib is calling itself twice at the end, instead of just once. This creates the branching pattern that you saw from the visualizer. Aside from the crest case, each instance of the call must resolve two other instances before it can complete its function and produce an actual value. As difficult as it may be to follow the function calls and their resolutions in one's head, the final line of the algorithm winds up looking pretty intuitive once it's on the page.

With that we'll move on to an algorithm which has a lot more branching.

mergeSort

Check out the problem here on GeeksForGeeks.

With this algorithm, the factors are less simplistic and the application is a little more involved. But the two concepts mentioned previously, understanding the crest case and conceptualizing possible return values, are still super useful to start out with.

The third concept I'd like to anchor myself to and use in this solution and others is also a little more involved. This concept is the thoughtful headspace that one should be in when considering implementing recursion: what types patterns signify that recursion could be a useful solution? When is it powerful, and how can you look at a set of circumstances and transform that into something that fits the bill for a recursive function?

With all three problems so far, recursion can be used because one or two operations need to take place over and over again. But for the first two, an argument can be made that in terms of space and time complexity, it doesn't really give you anything to select a recursive solution over an iterative one (except bragging rights).

With mergeSort, a recursive solution makes a bit more sense. The algorithm has a lot of branches to resolve, and it's important that those branches be resolved in order. This type of data movement would be complicated and annoying to program an iterative approach, but it works pretty gracefully in a recursive approach. Take a look at the code and the tree of calls:



const mergeSort = (arr) => {
    if (arr.length < 2) {
        return arr
    }
    const mid = Math.floor(arr.length / 2);
    const leftArr = arr.slice(0, mid);
    const rightArr = arr.slice(mid);

    return merge(mergeSort(leftArr), mergeSort(rightArr));
}

const merge = (left, right) => {
    const sorted = [];

    while (left.length && right.length) {
        if (left[0] <= right[0]) {
            sorted.push(left.shift());
        }
        else {
            sorted.push(right.shift());
        }
    }
    return [...sorted, ...left, ...right]
}

Using mergeSort recursively like this still does have limited viability in real world programming, since this solution is not ideal for large data sets like you might see in a production level database, but there are many other circumstances where it can be applied and actually satisfy the requirements in the most elegant way, as long as you have a smaller data set.

To the Real World

With these three items in mind, one can start getting creative in the application space. I spoke with a mentor of mine recently with more than a decade of experience in the field, who told me that recursion is definitely a tool used in his regular engineering life, albeit sort of rarely. An example he gave fit the profile perfectly for the type of use case I had been imagining: he had recently made a solution to dynamically build URLs by recursing into an Angular object and collecting relevant breadcrumbs along the way. This is the ideal situation; the dataset is reasonably small and the flow of the data is relatively complex and follows a branching pattern.

By framing the circumstance and visualizing it before beginning to program anything, one would be able to see recursion as a satisfying solution for situations like building a dynamic URL, and I'm sure many others. This post is mostly just a journal entry for my own adventures in becoming more comfortable with recursion, but I hope it's able to help anyone else who is in the position of wanting to "level up" in this particular category. Please feel free to leave a comment with any questions or thoughts, I'd love to chat about others' experiences!

Are BigInt Math Calculations More Expensive Than Using Numbers in JavaScript?

Hal Friday — Mon, 29 Mar 2021 16:50:15 +0000

YES.

Had to dig through quite a few articles to get a simple answer to this one, so I figured I'd put it right at the beginning. Yes, regular math calculations using BigInt cost more for the computer to execute than if you were just using Numbers.

For a little more detail on that, please read on.

JavaScript, like any programming language, is made up of a bunch of different types -- I went into a little depth on the topic of types in this blog post over here. Two of those types are "BigInt" and "Number". So first off, we'll give a clear picture of both:

NUMBER

Ol' fashioned integers. 0-10. Your grandad's math. Numbers are....

Primitive (meaning they cannot be changed no matter what)
64-bit (meaning there is a size limit)
Imprecise at a point (meaning if a calculation gets past 17 decimal points, JavaScript will stop math-ing and round the number)
Is always a float (meaning 17.0 === 17 returns true)

And just for fun, here are some examples of numbers.

17
1234.123123123123
NaN
Infinity

There are those who think it's weird that NaN, standing for Not-A-Number, is of type Number -- but honestly, it provides more detail about itself as an error if it's still associated with Number.

BIGINT

Large, hefty numbers. Could eat your grandad's numbers for breakfast. Here are some BigInt facts:

Also Primitive
Represents anything beyond the 64-bit limit (which can be checked for using JavaScript's method Number.MAX_SAFE_INTEGER)
Does not like to mix with numbers (10 * BigInt(10) will result in a type error)
Does somewhat mix with Strings
Puts a fancy little n at the end of the number

It's helpful to play around with BigInts to get a feel for them. In whatever JavaScript environment you're used to, you can get your computer to print out some BigInts with the following:

BigInt("32787835783895638958923489124891234")
- note that the BigInt method here will accept a string
BigInt(5)
1n

So, why is `BigInt` math more expensive than `Number` math?

Your intuition probably led you to this already, but there is the one obvious thing: BigInts are bigger. Not in the way that 100 is bigger than 10, but in the way that your computer receives and handles the BigInt data type. The memory set aside for a BigInt is always larger than a regular Number, regardless of the value of the BigInt itself. So, if you have two variables:

let optionA = 15
let optionB = 15n

Both are 15, but optionB is clunkier. Thicker. BigInter.

A side note on equality:
JavaScript does recognize that optionA and optionB are equal to 15, but a strict equality operator will return false because of their differing types. If you need to compare between BigInts and Numbers, you should use loose equality (==).

The other reason BigInt calculations take more time & space is that the instructions for handling these calculations are in the software of JavaScript. When you do a Math calculation like 10*81, your computer uses its hardware, which is easily accessible and requires almost no searching or computational power. When you try something special like 10n * 81n, it has to go and find the BigInt JavaScript functions, feed your input in, and calculate the result at a high level. You can read more about that from this TekTutorialsHub post.

You can prove this by benchmarking JavaScript methods using both types of math. Check out this Repl.it and hit Run to see it in action.

What's the practical use of knowing this?

The only reason I went down this rabbit hole was for interview prep: practicing algorithms. There is an interesting LeetCode problem (found here) which asks you to add two linked lists together and return their sum as a linked list. After solving the initial prompt, my code was still failing because some of the test cases resulted in massive....some might say BigInt numbers.

To resolve this problem, my first instinct was, "Well, what if we treat every single number like it's gonna be a BigInt?" And the answer to that question is that the solution will pass, but it will be slower than a...car that's slow...or...whatever, it'll make your algorithm super slow. So you really need to allow for and handle BigInts separately, giving them the attention they deserve as unique circumstances.

Interview prep is a huge practical reality for software engineers of all levels, but there are also real-world applications for BigInts, such as massive database management, precise math with large numbers for financial applications, high-accuracy timestamps, and anything else people do with fancy and elaborate math. Who knows, maybe rocket science.

There is a lot more to the story with the BigInt datatype, but hopefully this gave a useful and concise introduction. Have fun & feel free to drop a comment with any additions, questions, or thoughts!

Other Resources...
V8
BetterProgramming.Pub
BigInts on MDN
Numbers on MDN
GitConnected

Writing Your First React Test

Hal Friday — Wed, 17 Mar 2021 20:35:32 +0000

Cover image unrelated -- nice to look at though, right? Discovery Park, Seattle, WA.

This post will assume that the reader has a good understanding of the React basics. It will also involve some coding, which you are welcome to code along with. The repository for the starter code can be found HERE. To view the finished product with tests, use the same repository, but switch to the with-tests branch.

Before we make any changes, take a moment to poke around the code. It's fairly simple -- just two components & a little bit of state to swap the image between a dog and not-a-dog.

Since this repository was created with create-react-app, there are some testing tools which are already in the code that we don't have to build or add ourselves.

Firstly, there is a file called setupTests.js, which contains the basic import for the Jest test runner. This file can be edited for fancier, more complicated tests in the future, but we won't need to do much with it right now.
Secondly, you'll see a file called App.test.js. Now, I know this is crazy, but that's where we'll write the tests for the App component. The file extension matters, as when we input the command to run the tests (either npm test or yarn test depending on your package manager), anything with a .test.js file extension will get read & executed.
There is also some code which already lives inside of the App.test.js file, which we can use to make some basic assumptions about how tests look. We might as well check it out.

import { render, screen } from '@testing-library/react'
import App from './App'

test('renders learn react link', () => {
  render(<App />)
  const linkElement = screen.getByText(/learn react/i)
  expect(linkElement).toBeInTheDocument()

})

Let's break down what we are looking at before changing it.

I think the most confusing and, potentially most important part to recognize with this small snippet is that there are two different testing packages being used. The first package we are using is the React Testing Library. It's the more obvious package, because the import is right at the top, like normal. We are importing render, which will allow us to access an instance of any component, and screen, which will allow us to make queries off the DOM similarly to vanilla JavaScript, after said component is rendered.

The second package is Jest, which is a "test runner". Jest ships out of the box when you make a project using create-react-app, but it is a third party library. You don't have to use Jest if you discover that an alternate test runner offers more applicable functionality, but it's the most widely used and a great place to start.

What's a test runner?

Test runners are not all the same, but their overall purpose is to read the test files and print some output based on whether or not the expectations, otherwise known as assertions, are met for each test.

Jest itself is a runner (meaning you can read tests with it), assertion library (meaning you can write expectations with it), and a mocker (meaning you can create a fake replica of outside functionality to mess around with in the testing space). Now let's look at another picture of landscape really quick.

Discovery Park again!! What a nice damn place to be.

Okay, back to the code snippet:

import { render, screen } from '@testing-library/react'
import App from './App'

test('renders learn react link', () => {
  render(<App />)
  const linkElement = screen.getByText(/learn react/i)
  expect(linkElement).toBeInTheDocument()

})

We can now determine which parts are Jest: test and expect (assertions)

and which parts are the React Testing Library: render and screen.

One last thing you may be wondering... why don't we have to import test and expect from Jest?

And that the answer to that would be... that Jest sneakily adds its methods into the global scope of your .test.js files. If you pop a console.log(global) into one of your test files and then run it, you can physically see every single method available to you in that space. Be warned, that is a huge console.log you are about to see. But expect and test are in there.

At this point, go ahead and run yarn test if you haven't already. Our app doesn't have the learn react link, so of course the original test won't pass.

Determining What to Test

Now that we've got a taste of what tools create-react-app grants us, we can begin to think about what tests to write. There are three main types of tests:

Unit - Tests one single piece of functionailty, like a method or a piece of state, in a vaccuum.
Integrations - Tests a group of methods or components together, to make sure they work properly in combination.
End-to-End - Begins where the site user would begin and tests the entirety of the available app.

⚠ Which type of test do you think is currently being rendered in App.test.js?

I've read differing opinions on which style you should begin your testing with, but the one that makes the most sense to me is to write integrations tests. Overall, the prevailing philosophy is to test your app the way that it might be used by a user. So let's take that and look at what our app does. Go ahead and spin up the app from a second terminal using yarn start.

Wow, it's a dog.

While running the app, you should be able to click on the image to flip it back and forth between a dog, and not-a-dog. So there you have it: seems like we should write a test to make sure that clicking on the image switches it back & forth. After all, that's what our users are doing.

Writing the Test

We'll start by rendering the app. That part we don't have to change.

import { render } from '@testing-library/react'
import App from './App'

test('Switches image upon clicking', () => {
  render(<App />)

})

Next, we need to grab the image from the DOM, so we can simulate a click. The screen import from React Testing Library is pre-bound to the document.body, so conceptually, you can query screen like you would the document.body in vanilla JS. The methods are a little different, but the idea is the same. If you are using VS Code, there is a quick way to check out all the methods available on the screen object. Head over to your App.test.js file and type screen., and you should see some options pop up in a drop down that you can scroll through with the arrow keys.

You may notice that "getByTagName" is not available -- so how do we grab an image? Well, images have alt texts.

import { render, screen } from '@testing-library/react'
import App from './App'

test('Switches image upon clicking', () => {
  render(<App />)
  const img = screen.getByAltText(/My dog, Beany/i)
  console.log(img)

})

Since this is our first time poking around with tests, I recommend console.logging as much as you need to in order to prove that your ideas are working. If you run the above code, you should see a log in the test server that looks like a React Node.

Now we've rendered the App and we have ahold of the image, so it's time to simulate a click.

import { render, screen, fireEvent } from '@testing-library/react'
import App from './App'

test('Switches image upon clicking', () => {
  render(<App />)
  const img = screen.getByAltText(/My dog, Beany/i)
  fireEvent.click(img)

})

We can import the fireEvent object from the React Testing Library and use its click method. By passing it the image, we would expect that the image on the screen is now changed. So for the final part of the test, we're going to write out that expectation.

import { render, screen, fireEvent } from '@testing-library/react'
import App from './App'

test('Switches image upon clicking', () => {
  render(<App />)
  const dogImg = screen.getByAltText(/My dog, Beany/i)
  fireEvent.click(dogImg)

  const notDogImg = screen.getByAltText(/Rainbow frowny face/i)
  expect(notDogImg).toBeInTheDocument()
})

And there you have it: you have written your first test in React. Hopefully you have also gained some tools for understanding the testing libraries and the ability to write more!

Might as well sign off with a nice picture of some landscape.

Another one of beautiful, sunny Discov- just kidding! This one is from Whidbey Island.

Happy coding!

Part 2: Creating Models for MongoDB with Mongoose

Hal Friday — Tue, 26 Jan 2021 18:55:01 +0000

The fully complete codebase for this project is public at THIS github repo, if you would rather just poke around than reading this whole walkthrough.
__

Here's the overview of the two part series. The steps in bold will be covered in this second installment:

Initializing a folder with a package manager
Adding necessary dependencies (and discussing the purposes of each)
Establishing a connection to MongoDB through Atlas
Establishing an Express application & selecting the local port on which to run it
Creating A Model
Creating CRUD routes for that model
Testing your code out with an API tester like Postman or Insomnia

Where we left off in the last post, you should at this point have a successful connection with a MongoDB database hosted on the Atlas website, and a running local server on port 5000. What a time to be alive.

Creating A Model

Organizationally, it is up to you how you arrange your files inside of this app. This sort of backend is not as opinionated as something like Ruby on Rails, so you can exercise a little more freedom with the structure.

To keep my files project organized, I like to keep related items in separate folders, so I'll firstly create a new folder named models, and nest a file called user.model.js inside of that.

This is where we will define the requirements of the data model that we intend to map to our database on MongoDB. Remember that we are using the Mongoose library as the messenger between our Express app and our database, so the first thing to do inside of this file is require Mongoose, and grab the Schema class out of the Mongoose library.

const mongoose = require('mongoose')
const Schema = mongoose.Schema

Now we can begin to write the format for our User model, by creating a new instance of the Schema class.

const userSchema = new Schema()

The first argument for the schema is an object containing the attributes for your data model. Our user model will have 3 attributes: a username, an email, and an age (which is optional). Each attribute will be defined using a key:value pair, with the key being the name of the attribute, and the value being its type. You can check out all available schema types for Mongoose from THIS page. We will just need the String and Number types.

const userSchema = new Schema({
    username: String,
    email: String,
    age: Number
})

This by itself would work, but remember that we wanted the age to be optional. Well, good news, it already is. The default for each model attribute sets required to false. So rather than specify that the age is optional, we should specify that the username and email are not.

const userSchema = new Schema({
    username: { type: String, required: true },
    email: { type: String, required: true },
    age: Number
})

We are allowed to open the value of any attribute out into a full object which specifies further detail for the attribute. For fun let's say you can't use our app unless you're 18 years or older, as well.

const userSchema = new Schema({
    username: { type: String, required: true },
    email: { type: String, required: true },
    age: { type: Number, min: 18 }
})

Validations: easy as that. Any time you make an instance of the user model, it'll run through this Schema to make sure your input attributes meet the requirements.

The last step is to solidify this Schema as a data model with mongoose, and export it from this file for use in other areas of our project.

const User = mongoose.model('User', userSchema)
module.exports = User

Now we can move onto making some CRUD routes for the User.

Creating CRUD routes

In keeping with my organizational choices, I'll now create a folder called controllers which houses the file user.controller.js. This will be the central hub for making any of the activity involving the User model; predictably, controlling what happens when you try to Create, Read, Update, or Delete a model instance.

There are two necessary items to import into this file. Since the User model is going to be needed repeatedly in here, we'll need that one. In addition, we will be using express to define some routes that will live on the local port.

const User = require('../models/user.model')
const router = require('express').Router()

Take a look at that router import -- notice that every time you require the Router, you are calling on a function, which creates a totally new instance of the router within this file. So if we had more than one model, we would have the same code inside of its controller file, but that other router object would be totally different. We are going to define some changes to this instance of the router to make it specific to our User model, then export this instance of the router for the rest of our Express app to use.

With that said, let's lay down the boilerplate for the routes we need, and export it at the bottom.

router.route('/new').post()

router.route('/').get()

router.route('/delete/:id').delete()

router.route('/update/:id').put()

module.exports = router

Now we can get to customizing those routes. Notice that you must first pass the path to the router's route method, then clarify what type of HTTP method will be made to that path. The method, in the first case a post, will accept one argument: a function to run when this path is hit. We will use anonymous functions so that we can keep each route's functionality encapsulated in this one router.route call.

router.route('/new').post((req, res)=>{

})

The function is automatically handed a few arguments: the request (req) information, and the response (res) information. The request comes from your frontend (or Postman/Insomnia), and the response is what your backend should send in response. Each argument has some built-in functionality that we will make use of here. If you have made post requests before, you should be familiar with the format. Your frontend will make a request to your backend and send with it a body attribute which contains the information that is to be posted to the database. The body attribute should look something like this: { username: "Hal", email: "Halrulez@halgoogle.com", age: 247 }. Using that information, we will make a new instance of our user model.

router.route('/new').post((req, res)=>{
    const newUser = new User(req.body)
})

This line will use our Mongoose model to create something that should be acceptable to our MongoDB database. The next step is to actually contact the database and try to save the new instance.

router.route('/new').post((req, res)=>{
    const newUser = new User(req.body)

    newUser.save()
        .then(user => res.json(user))
})

Assuming that the database entry is successful, MongoDB will send us back the newly minted User. There is one key difference between this user instance and the one we created called newUser -- the User that is sent back from MongoDB will have an ID, which we need to use to do all other sorts of operations on this User instance in the future. Once we receive this verified User instance, we use the line res.json(user) to complete the cycle by filling our response's json with the user itself.

The code we wrote should work, but it is a little frail. We did not handle for the case that our new user gets rejected by the database, which could happen for a myriad of reasons. So let's add in some error handling before we move on:

router.route('/new').post((req, res) => {
    const newUser = new User(req.body)

    newUser.save()
        .then(user => res.json(user))
        .catch(err => res.status(400).json("Error! " + err))
})

Now that we have that written out, there's one more step before we can test it. As of right now, the Express app that we created inside server.js doesn't know anything about these model or controller files we've made. So we need to head back over to the server and tell it about our new code.

// inside server.js
const userRoutes = require('./controllers/user.controller')
app.use('/users', userRoutes)

By specifying that the app should use '/users', we are able to nest any routes that are defined in the user controller under the '/users' resource first. So in the case of creating a new user, our frontend should make a post request to 'http://localhost:5000/users/new'.

And now, we can test it!

Testing your code out with an API tester like Postman or Insomnia

I've used both of these apps and enjoy them each equally. No endorsement either way. They do things.
HERE is the link to the Postman tester, and HERE is the link to the Insomnia one.

Right now I happen to be using Insomnia, because the name's cool. Once you've gotten all logged in to your tester, you should create a new request, specify that it is a POST request, copy http://localhost:5000/users/new into the resource section, and select JSON for the body type. Then you can add some raw JSON into the body -- this will match up with what you expect to see from the body portion that your frontend sends. So again something like { username: "Hal", email: "Halrulez@halgoogle.com", age: 247 }. Then send the request! If you've got it all set up properly, you should see a response like this:

We got an ID! Massive success.

With the completion of this route, we have a working MEN backend. Of course, we need to complete filling out the other CRUD routes, but the hardest work of ensuring that Express, MongoDB, and Mongoose can chat nicely is over. Now might be another good time for a rousing glass of water.

Since the rest of the routes are simply variations of the first one that we made, I'll put them all in one chunk together that we can look at as a whole:

router.route('/').get((req, res) => {
    // using .find() without a parameter will match on all user instances
    User.find()
        .then(allUsers => res.json(allUsers))
        .catch(err => res.status(400).json('Error! ' + err))
})

router.route('/delete/:id').delete((req, res) => {
    User.deleteOne({ _id: req.params.id })
        .then(success => res.json('Success! User deleted.'))
        .catch(err => res.status(400).json('Error! ' + err))
})

router.route('/update/:id').put((req, res) => {
    User.findByIdAndUpdate(req.params.id, req.body)
        .then(user => res.json('Success! User updated.'))
        .catch(err => res.status(400).json('Error! ' + err))
})

Some items to pay attention to:

You can retrieve the ID from the request URL by accessing req.params
The update method requires the frontend request to include information for all fields aside from the id -- this is the most straightforward way of updating our database at the present
You're in full control of what response is sent back to the frontend. If you wanted to hide the server errors for security reasons, all you would have to do is change what your catch sends back.

And that's it. Congratulations on conquering MEN!

Part 1: Setting Up Your Backend with Mongoose, Express & MongoDB

Hal Friday — Mon, 25 Jan 2021 20:15:31 +0000

The fully complete codebase for this project is public at THIS github repo, if you would rather just poke around than reading this whole walkthrough.

I've been a big fan of React for a while, but that part of the MERN stack isn't involved in this post. If anyone does have a specific question about how to hook the backend we are about to build up with a React frontend, please leave a comment and I would be happy to make a new post with that information as well.

Since this is focused on MERN without the R, the acronym we'll use for this post is MEN. Why not. 😄

Here's the overview of the two part series. The steps in bold will be covered in this first installment:

Initializing a folder with a package manager
Adding necessary dependencies (and discussing the purposes of each)
Establishing a connection to MongoDB through Atlas
Establishing an Express application & selecting the local port on which to run it
Creating A Model
Creating CRUD routes for that model
Testing your code out with an API tester like Postman or Insomnia

It should be a good time. This post will assume that you have a medium level of JavaScript/programming capabilities -- that is, if you are just starting out with learning JS, this post might knock you on your ass, so bookmark it for later and revisit when you're pretty good with the basics. This post also assumes you have NodeJs installed on your computer already. You can check if you do by running the command node -v in your terminal. If it does not spit out a version for you, please install Node from HERE before beginning this walkthrough.

Other than that, if you're ready to go then let's go!

Initializing a folder with a package manager

This part is pretty straightforward.

From your terminal, navigate to whatever directory you want this project to live in
Make a new folder with mkdir MEN-backend
cd into that folder
Enter the command yarn init or npm init, depending on which package manager you want to use.

The differences between yarn and npm are negligable for our circumstances, but I use yarn because the word's cute. Once you've done that, your terminal will ask you a series of questions -- you can just slam on the enter key a bunch of times to stick with the defaults, or you can change the versioning/name/licensing info at your discretion. These details will not affect the project.

Once that's complete, you'll notice a package.json file appear inside your MEN-backend directory. This is where your project will keep track of necessary dependencies and libraries that we'll be installing, like Express.

One that note, let's get to installing.

Adding necessary dependencies

One important tip for this section: the words dependency, library, and package are going to be used pretty much interchangably. I'm just using these phrases to reference any outside code base that we'll be making use of in our project.

The first thing add is Express, of course. Very necessary for MEN. Adding packages to your established package.json file is pretty easy; from inside of our backend directory you can run the command yarn add express and watch as your terminal does the work of adding it. Once it's done, you will notice that a new folder, node_modules has appeared in our directory, as well as a file called yarn.lock.

These two items help your project keep track of not only the libraries that you want to use in your project, but any libraries that those libraries are using. Do not edit these items directly. If something goes wonky with your yarn lock or node modules, just delete both of them and run yarn install to have 'em regenerate.

Here are the other packages you should install. With each you can just run yarn add <package name> to add it to your package.lock file:

cors
- CORS stands for "cross-origin resource sharing" and the package allows you to configure which domains are trusted and which ones are not. We will be making requests to our backend from a separate origin (that's where insomnia or postman will come into play), so we need to install CORS to allow us to do that.
dotenv
- We are going to need a sort of secret key to access our MongoDB database on the Atlas website. If you plan on uploading your project to Github or some other code sharing site, you shouldn't upload your secret key as well. Best practices dictate that you should keep that kind of information in a local environment variable. The dotenv package will allow us to add a file called .env to our project and put our secret key in there. The library will configure environment variables to your process.env object, which makes it global for your project. We aren't going to go through uploading this project to Github, but if you are doing that, you'll want to add the .env file to your .gitignore list.
mongoose
- Mongoose allows us to: map the model attributes and requirements to the database, create new collections and documents in our database, and make queries to retrieve info from the database.
nodemon
- We will use nodemon to actually serve the backend routes locally on whatever port we choose. If we were to choose port 5000, say, we can run nodemon to have our app served on http://localhost:5000/

Establishing a connection to MongoDB / Establishing an Express App

There are different ways to use MongoDB, but using the Atlas website gives you a pretty clear and easy tools for interacting with your data, and you get one free database to fiddle around with so you don't have to pay to use it for our purposes.

First, set up an account. Head to https://www.mongodb.com/cloud/atlas & fill out the Start Free steps. Pick the free options of course, and select "Shared Clusters" when prompted.

Under provider and region, select Google Cloud, and then pick whichever region is closest to you. This is where the server is located, so the closer you get the less latency between requests. Make sure your Cluster Tier is set to "M0 Sandbox", name it whatever you'd like, and click Create Cluster.

You can just let that sit while it creates -- don't mess with the webpage or close it until it's done. While you're waiting, maybe listen to a song. Have some water. Stretch your back & unfocus your eyes for a second.

Okay, now it's time to write some code.

In the topmost directory of your project, create a file called server.js. This is will act as the main hub for your app and its connections to the DB. The first thing we need to do is get Express in there. Here's what it looks like to actually establish an Express app:



const express = require('express')
const app = express()

The invoking parentheses following express call a constructor method from inside the Express library which builds the boilerplate for our app.

⚠️ Reminder! Express is a framework using NodeJs. It's the most important part of allowing us to use JavaScript as a backend server. ⚠️

Now that we've actually got an app to fiddle around with, let's tell that app that it should be allowed to accept requests from outside sources by handing it the CORS library.



const cors = require('cors')
app.use(cors())

Next we will tell the express app that it should expect to serve and receive data in the JSON format. Our MongoDB backend will take care of that for us, so we don't need to configure it on that end, just this one.



app.use(express.json())

Okay, the next thing is to actually connect your DB with your Express app. Here we have a group of libraries coming together to make ends meet. Firstly, we need to get Mongoose in there to usher the data back and forth for us -- we can think of Mongoose as a messenger which speaks to our Express app, travels over to MongoDB, delivers some info, then carries Mongo's response back to the app. Begin by requiring it --



const mongoose = require('mongoose')

and then calling upon the connect function to open a connection.



mongoose.connect(source, {
    useNewUrlParser: true,
    useCreateIndex: true,
    useUnifiedTopology: true
})

const connection = mongoose.connection
connection.once('open', () => {
    console.log("DB connected.");
})

Okay, that's a chunk of code, so let's chat through it. The connect function accepts two arguments: the first is the the URI which points at our actual database on Atlas, and the second is a configuration object for how it should talk to that database. It's not highly important to memorize the details of the config object, but there have been some updates to both Mongoose and the Atlas setup which caused bumps in the road, so these configurations are just some standard fixes to make sure the communications still go smoothly.

The second part, where we grab mongoose.connection out of the Mongoose library, is simply a listener. It listens your connect function, and throws up a little message on the server logs once that connection is successful. You can log whatever message you like. Maybe just a put a Shakespeare quote on there or something. The world's your oyster.

You may have noticed that source is not defined anywhere in our code yet, so let's fix that. Head on over to the Atlas website again. It should have had plenty of time to finish setting up, so hopefully you see a screen that looks something like this:

Click the "CONNECT" button. Add your current IP address (since you will be making requests from your own computer), then make up whatever name and password you want to use for your secret connection URI. This doesn't really have to be that secure, since we are just using it to learn. I'm going to set mine to something pretty simple; username: "Hal", password: "Hal". Whatever you pick, keep ahold of it as we will use it. Click the "Choose a connection method" button.

We won't be installing the mongo shell or MongoDB Compass, so let's just pick "Connect your application". After clicking that you'll see the URI we want! It'll look something like this:

mongodb+srv://<username>:<password>@testercluster.m7k7n.mongodb.net/<dbname>?retryWrites=true&w=majority

Fill in the username/password and whatever you named your DB (I named mine TesterCluster). Now, we could just pop that URI into the connect function, and it would work just fine, but as was mentioned at the beginning, you shouldn't actually put your credentials and/or DB connection secrets out there in the open. So now we get to use the dotenv library. Add this to server.js to do so:



require('dotenv').config()

Calling on config() allows it to set up using the out-of-the-box configurations, which is totally fine for our purposes. With dotenv required, we can now create a file in our directory called .env which will house the new URI we just grabbed. The inside of our .env file just has a single line:

ATLAS_CONNECTION = mongodb+srv://Hal:<Hal@testercluster.m7k7n.mongodb.net/TesterCluster?retryWrites=true&w=majority

Once that is saved, the dotenv library will read your .env file and add a key of "ATLAS_CONNECTION" to your process.env object, with the value of the correct URI there. Remember that the process.env is globally available -- so all that remains is to add this line into your server.js file:



const source = process.env.ATLAS_CONNECTION

Now for the moment of truth. Head to your terminal and enter the command nodemon server. If everything is set up correctly, you should see some startup messages from nodemon, and then your own console log, "DB connected." Or a Shakespeare quote. Whatever you went with.

The last step for this post to set up our express app to serve our data locally.



const PORT = process.env.PORT || 5000
app.listen(PORT, ()=>{
    console.log(`Successfully served on port: ${PORT}.`);
})

The first line is saying, "check if our process.env object has specified a port to use, and if not, default to using port 5000." Once you hit save, you should see the nodemon server reload in your terminal, and the second message confirming that our local server is working too.

And that's it for the first installment in this two-part series! Follow my posts to get a notification for the release of the second installment. And please submit a comment with any questions, improvements, or corrections!

JavaScript Stuff I Thought Was Weird Which Just Turned Out to Make Sense After All

Hal Friday — Tue, 15 Dec 2020 16:03:43 +0000

When I first started learning JavaScript, I definitely had a beat-it-to-fit, paint-it-to-match mentality. My wrangling of code was basically just elbow grease and duct tape, and I filed a lot of things away as cute little mysteries, assuming that JavaScript kept as them a personality quirk.

But it turns out, most of the stuff that I thought was totally bonkers, actually does make sense when you get down to the brass tacks of it.

I'm writing this post about a favorite example of this. Here are two code snippets which are true:

let uno = 1

function topple (arg){
    arg += 1 
}

topple(uno)

console.log(uno)
    => 1

and

let arr = []

function topple (arg){
    arg[0] = "toodledoo"
}

topple(arr)

console.log(arr)
    => ["toodledoo"]

As a newbie programmer, this made absolutely no sense. In one case, you pass an argument and perform an alteration, and it does not change the variable. In the second case, it totally does change the variable. I'm also a bootcamp grad, so at the time I really had to pick my battles for which topic I could do a deep dive into, and this was not one of them. I settled for memorizing the truth that you could change arrays and hashes, but for some reason you couldn't get the same functionality out of variables pointing to a string or a number. I'm...perhaps a little too good at going with the flow, so for a while I chalked it up to a silly weird thing left it at that.

Since I've had a little more time and a lot more freedom to explore topics of interest, I've found some super fascinating things out about that code.

Firstly, I learned that in JavaScript, there are a limited number of types that any one piece of code can be. Here are all of them:

String
Number
Boolean
Object
Function
Undefined
Null
Symbol
Bigint

And that's it. Everything you touch and see and get slapped with in the form of an error message is gonna be one of these things. For the purposes of explaining the weirdness above, I'm really just going to talk about Numbers and Objects.

Before moving on, it's paramount to define Objects, because I feel like that gets thrown around a lot with different meanings. In terms of the underlying skeleton of JavaScript, MDN Docs defines an Object like this:

In computer science, an object is a value in memory which is possibly referenced by an identifier.

Which, is just, so useless. What does that even mean? You may have heard elsewhere that "everything in JavaScript is an object," and I feel like that's closer. That's almost true. Arrays, hashes, regex, these are all objects. Importantly, Objects are mutable. Changeable. Hashes and arrays can alter their contents constantly.

There are a few things in JS that are not objects, and numbers are one of them.

Numbers are considered a special sort of thing in JS, called a "primitive." Primitives are immutable. Can you change the value of one? Think for a sec, what if you add 1+5...Does 1 stop being 1? Nope, 1 will always exist, in its primitive state, unchanging.

So, that brings us back around to our examples. Let's take a deeper look into the first example.

let uno = 1

function topple (arg){
    arg += 1 
}

topple(uno)

console.log(uno)
    => 1

Step One: Set a variable called uno which points to the primitive number 1.

Step Two: Define a function which accepts an argument, and in the body of the function, permanently increases that argument by 1.

Step Three: Call function. Hand it our uno variable. This step is where the secret magic happens that I previously didn't understand. I was saying things like "hand it a variable" but failing to realize that you can't hand anything a variable in JavaScript. You hear that craziness? You go around for a couple years of your life thinking that you pass information in your code around using variables and it's a total lie. You can't hand anything a variable in JavaScript.

It's because variables are instantaneously evaluated. In step three, we aren't handing that function anything called uno, we are handing it a tiny puzzle, which JavaScript works out right then and there in the arguments. It follows uno back to the source and finds out that we set it to point to the number 1, and it actually just passes the number 1 through to the body of the function. The reason that our variable is unchanged on the other side of the function is that our body never saw nor touched the variable.

Okay. Now, that is super cool, and very exciting to be able to see the secrets of JavaScript happening in real time -- I imagine this is how I would feel if I could watch human bones and tendons interacting with perfect clarity under the skin of a living person. I wonder if surgeons get this feeling.

But we still have another mystery on our hands: If this first example can't alter the variable, why in God's green earth would it be able to alter the second one, in a nearly identical example?

Remember what we talked about with the mutable items versus the non-mutable items. As we said before, there is only one 1. You can't change the number 1, and any time you reference it, you are always pointing at the same ol' number 1. One symptom of being mutable is the ability to be multiple. Because arrays can change, they can have many different instances that exist in different places in your computer's memory. You can get a really good visual of this by running a short test in your browser's console. First, run this code:

for(let i=0;i<10;i++){
     console.log(1)
}

Notice the result. Now don't clear your screen, and run this code:

for(let i=0;i<10;i++){
     console.log([])
}

With the first one, you see the number 1 with a little 10 to the left of it, indicating that the number was logged 10 times in a row. What's up with the next one? Why does it show ten arrays logged on separate lines?

Right, it's not repeating anything. Those are all different arrays.

Cool, so it's possible that you've already put together where I'm going with this, but might as well finish it out. Let's dive into the second example like we did the first.

let arr = []

function topple (arg){
    arg[0] = "toodledoo"
}

topple(arr)

console.log(arr)
    => ["toodledoo"]

Step One: Set a variable called arr which points to some new object.

Step Two: Define a function which accepts an array, and in the body of the function, permanently adds "toodledoo" to that array.

Step Three: Call function. Hand it our arr variable.

But! As we know, you can't pass variables anywhere in JS. So arr will get evaluated right then and there, and JavaScript will instead pass the array itself into the body of the function. And here's where it all comes together:

Because you can have multiple arrays in a single coding project, and because each individual array holds a different place in memory, when our function adds "toodledoo" into the array that it's given, that changes its value in the actual computer. So when we go to check the variable again, it doesn't try to grab a new array, it goes back to the place in memory where our array was stored and finds that this particular instance has been changed.

To recap: If you pass a function the number 1, it can't change that number at all. Even if you set 10,000 variables to the number 1, they'd all be pointing to the same place in memory, cause nobody can mess with math. However, if you pass a function an object such as an array, all new objects point to a different place in memory, so if you change that array you can still see the changes later down the line.

Fascinating, like I said. Now, one last thing. This code is also true:

let uno = 1

function topple (){
    uno += 1 
}

topple()

console.log(uno)
    => 2

Why do you think that is?

All credit to Dan Abramov and his wonderful newsletter for helping me become a more enlightened programmer.

scalability in system design -- lazy post style!

Hal Friday — Tue, 07 Apr 2020 01:02:28 +0000

when this started out, it was not but a journal entry. after re-reading it for studying purposes, i determined that there was enough information involved so as to be considered useful in the world. i did NOT, however, determine that i should go back and add in capitalization, or a professional tone. this here is a rundown of some Very Basic stuff that one should consider if one is interested in making one's system scalable. enjoy!

in terms of system design, when you are making a personal project, you are probably gonna start out with the whole thing on your one computer. that makes sense. you don’t have 50 computers. you don’t have 100 hands.

but, if the project that you are making gets crazy popular, and starts getting a ton of hits, what happens if your one single computer goes down, or the one web host that you are using has a pause in service, or something? your site goes down and all your users turn their backs on this project and every project you will ever make, never to trust again.

you’ll want to prevent this with a little proactive planning. maybe you decide to host with TWO web servers. eh? good for you. now, how do you decide which user will go to which web server? the client comes in, clicks something on your site, sends a packet of information and…unless you plan on hooking every client up to every server that you have, you will need a way of managing these requests, and sending them in a balanced way to your separate servers. you will need a load balancer. this is sometimes referred to as a black box. its relationships can be visually represented like this.

cool. you will need to determine some way that the load balancer makes its choices, based on how busy the servers are, just the next one in line (which is called round robin style), or what information each server is responsible for (for example, if one server only has information on images and the other server only has information on text files). how you divvy up the requests is totally up to you, that’s between you and God. and your company. and your servers. and well, also your load balancer.

the next problem is that if a client who is initially directed to server 1, somehow gets shunted off to server 2 (say, if they log in from a different device, or they use an incognito window, or something), that client will wind up with two different sessions, thereby defeating the power of sessions. the client might have a cart filled up with stuff on one session, log onto their phone, and be frustrated to see that none of their items are there anymore.

what we need are sticky sessions.

how do we get that? unless we want to do some trickery with "shared state", we need to store this information somewhere on the user. we could house the data for the specific server that the client belongs to inside of a cookie set by the load balancer. this way when the client comes back to log on, it presents its cookie, and the balancer can say oh! looks like that cookie says server one, off you go.

so that’s fantastic. but, if these servers are operating independently, and each one is trying to persist data, we will wind up with two separate databases. so instead of letting each one keep a DB, we will want to pull that out and have the DB live separately. so our chart will look like this:

and this looks really good. i can filter clients, they can have sticky sessions with server-filled cookies dispensed by the load balancer, and i can ensure that all DB information is up to date. but there are a lot of vulnerabilities to the system, due to something called single point of failure — that is to say, there are two sections of this which depend fully upon one single machine to not fail or the whole thing goes down. It’s a replication of our original problem of only using one host. if the load balancer dies, or the DB blows up somehow, the whole operation is doomed.

counteracting that vulnerability can be surprisingly straightforward: buy two of the things that are single.

or, buy several. buying more of the thing is called horizontal scaling. You can also try a method of making your one single thing indestructible — installing the most RAM, the best software, more CPU, etc. that would be considered vertical scaling.

you get the picture. you can choose to house everything in one glimmering skyscraper, or you can choose to install fifty ground level buildings that don’t have the fanciest amenities but can handle the smaller workloads they are given. i think most opt for the ground levels, as spreading out your assets is just, inherently more secure.

with your typical load balancer that you can buy off the market for, anywhere between $3,500 and $70,00, it does usually get you two load balancers. these balancers “listen to each others’ heartbeats”, I read somewhere, which just means that they can each detect if the other is down. in an “active-active” system of load balancers, each of them always handle all the requests, and one is just temporarily given all responsibility if the other goes down. in an “active-passive” system, the active one is on the job for forever, and if the passive one ever hears of trouble, it automatically promotes itself to active, and takes over until its downed teammate is able to res.

with your typical DB…well…there are a lot of options there, but they come in a similar format to the active-active/active-passive setups. you might go with the master-master, where both databases have all information and can be read and written to, and share changes with each other. if one goes down, no biggie, the other one just manages all read and write requests. or, you might go with the master-slave approach, which just has the absolute worst name, and i think they should consider renaming it. for my own mental health, we will refer to this one as the master-understudy approach. the master stores all the information, and the understudy or understudies all store exact copies. any time something is written to the master, it is written to all others as well.

this setup is powerful for sites that have read-heavy requests, because any one of the understudies can take those requests — the master only really HAS to worry about the write requests.

if the master goes down in this case, it is only unavailable for long enough for one of the understudies to promote itself to master. then you can go to the store and grab another drive or replace the cable or fix whatever went wrong with the original db.

bear in mind that with multiple DB’s you’ve got another need for a load balancer — one to manage the which server request goes to which database at what particular time.

so now you have something that looks like this:

and they all live together in a happy family in their house, in the middle of their street. if the house burns down, well, that’s another single-point-of-failure-fish you would have to think about frying. perhaps, something something something The Cloud, and another house.

Passing Functions as Arguments in Ruby

Hal Friday — Thu, 13 Feb 2020 22:27:30 +0000

It can be done! As per my last blog post, with no further ado, here is how you do it:

def first_option
    puts "space jam"
end

def second_option
    puts "dogs rule"
end

def receives_function(func)
   method(func).call
end

receives_function(:first_option)

It is imperative to notice that you must pass the function through as a symbol when you are ready to send it along.

There are a few things about this setup that you may find interesting. When I first started looking into this, I assumed that you could just pass them through normally, using receives_function(first_option). I figured, Ruby is nice right?

Wrong.

Just kidding, I mean Ruby is nice, but it's not magic. Because Ruby is a synchronous language and function calls only require the name of the function, Ruby will read receives_function(first_option) and immediately invoke the first_option method, before it enters receives_function method at all.

So let's dive into the other stuff. The symbol terminology is Ruby's built-in way to allow you to reference a function without calling it. By placing the symbol in the argument for receives_function, we are able to pass all the info along and actually get into the receives_function code block before executing anything.

The next step is to figure out how to call a function which has been sent as a symbol. It gets a little hairy here because once we are inside of the receives_function code block, all we have to work with is a variable called func. Not a symbol at all. This is where Ruby's method method comes into play.

As a side note, googling "Ruby method method" is marginally annoying, so here is the link to the Ruby Docs to save you the time if you're interested.

The method method takes an argument of a symbol and returns information about that symbol. When you pass it a symbol of another method, it will return something like this:

[5] pry(main)> method(func)
=> #<Method: main.first_option>

With this it's saying hey, you passed me a method, and its name is first_option. You can chain a few commands on the end of this return value to determine other information about the symbol. For example, you could add .source_location and it would give you the file name and the line on which the original first_option function was defined. That's very useful for debugging, but in our case we don't care about that -- we just wanna invoke it. So, as you saw in the example, we chain a .call on there and "call" it a day.

Sigh.

So that's that! Have fun out there.

Passing State to Components Rendered by React Router (and Other Fun Things)

Hal Friday — Wed, 17 Apr 2019 18:54:52 +0000

One of the most frustrating thing about clicking on blog posts is having to scroll through people's long winded explanations of stuff when you can just put the answer at the top. Here's how you do the thing in the title:



<Router>
  <NavLink to="/homepage">Homepage</NavLink>
  <Route path="/homepage" render={props => 
  (<Homepage {...props} pieceOfState={this.state.pieceOfState}/>)
}/>
</Router>

If you want details on that, please feel free to read on :)

The Router itself you can put in whatever place you want -- but it makes the most sense to pick a pretty top-level part of your app, so usually in the render method of your App.js file. As you can see above, the NavLink we are using points to the homepage of this particular site or app, and the route is the driving force which will actually do the work of rendering the component. If you don't need to pass the component any state, you would usually just see the router like so:



    <Route path='/homepage' component={Homepage} />

But in React, passing state (or helper methods) is where all the power comes from -- it's what makes React so reactive. So you will want to use the first code snippet to get the functionality you want. The Route path in that code is using the render method to pass an inline function which will render the Homepage -- you may be wondering, why can't we just pass an inline function using the regular component method from snippet #2 and get the same result? The answer is that the component method will actually unmount and remount the entire component every time the state changes if you use an inline function with it. This creates an unnecessarily energy-expensive program when you could just use the neat render method that the friendly React devs intended you to use.

Now that that part's out of the way, here are the aforementioned Other Fun Things:

1. Passing the whole dang state

Sometimes, when writing in React, it's hard to keep the code DRY. You may find yourself writing this.state a ton of times while passing specific state pieces to the components you want. A fun little tip to help avoid that issue: you can pass the whole dang state over without specifying pieces. It looks like this:



<Homepage state={this.state}/>

That's pretty straight-forward. That's pretty state-forward? At any rate, you can then access the state pieces inside of that component by using this.props.state.pieceOfState.

2. Active links

Stylizing a link so that it responds when a user is on the associated page has never been easier. You can simply give the NavLink a class of activestyle (along with whatever CSS you want to occur) like so:



<NavLink to='/homepage' activeStyle={{fontWeight: "bold", color: 'blue'}}>Homepage</NavLink>

React will handle listening for which page the user is on.

3. Rendering a 404

Sometimes the users of your site will get wayward and decide that they can probably guess the available paths, so they will just type that path in expecting to see it come up. React is nice, and it won't break your site, but it won't tell the user that the page doesn't exist. To render a 404, it's useful to group your routes with a Switch tag.



<Switch>
    <Route path='/homepage' component={Homepage}/>
    <Route path='/profile' component={Profile}/>
    <Route path='/seaturtles' component={Seaturtles}/>
    <Route component={NoMatch}/>
</Switch>

In the above, the component "NoMatch" is not given a route, so all routes which are not defined will render the component, which you can build out to render whatever you want your 404 page to look like. You can put anything there. An image of Johnny Bravo. A link to the Wikipedia page on 404's. A never ending scroll loop of the Constitution. The world is your oyster.

4. Redirects

Intuitively, if your user is logged in, you won't want them to be able to navigate to the '/signin' page. BUT, you also don't want them to see a 404 page there. It's time to implement a redirect. This is accomplished by specifying another Route to '/signin' and giving it the instructions to render a Redirect. Observe:



<Route path="/signin" render={()=> (<Redirect to='/search'/>)}/>

This code shows the Route using the same render method as with passing props, but without the props themselves. The anonymous function points to our Redirect, and we get to specify the URL to which we want our user sent.

An Important Note

You will have to import any and all Router elements into whatever file you are intending to use them. For example, to do everything listed in this post, you would need to import the proper items at the top of your file:



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

Thanks for stopping by, and happy routing!

The Consequence of Sound

Hal Friday — Thu, 04 Apr 2019 16:09:12 +0000

Sound is powerful. With no prior training, sound can make you happy, or angry, or calm at the drop of a note. Certain sounds can make you go insane, or hallucinate. Often we go through the day thoughtlessly experiencing sound, or allowing others in our lives to control what we hear and when. This doesn’t have to be the case!

There are many, many ways that you can latch onto the power of sound and make your life more pleasant, and your day ore productive. Two of the phenoms that always come to mind for me (and which I find incredibly useful) involve using sound with state-dependent memory and classical (or Pavlovian) conditioning.

State-dependent memory was first tested in 1937 in Illinois, where Edward Girden and Elmer Culler discovered that dogs who were in the same “state of consciousness” while learning a particular trick were much less likely to remember the trick if their state of consciousness was altered. In this case, the dogs were high.

Altering a “state of consciousness” can have a lot of different meanings. It can mean transitioning from sleeping to awakening, from sobriety to inebriation, from relaxed to alert, or, in our case, just listening to a really excellent song. Music and sound have the power to affect your state of consciousness as quickly as any other drug might.

In application, this means that if you turn on the same particular ocean noise while you are learning to code javascript, you will be much more likely to remember javascript down the line if you turn that ocean noise back on while you’re doing it. It’s an interesting and effective way to categorize your skillset and “hack” your brain into the right groove at the right time.

State-depending memory and classical conditioning go hand in hand. If state-dependent learning is a mental hack, classical conditioning is its physical counterpart. As we’re all familiar with, classical conditioning was popularized by that one guy, also with the dogs. Pavlov’s work really took off when he noticed the fact that dogs cannot consciously drool on command, and yet, they could be trained to do so. In the same way, you can’t always wake up motivated and ready to work. But if you keep an awareness of when you are feeling most motivated and always play a particular noise, you can eventually train your body into productivity as a reaction to that noise.

It’s important to note that in practice, it’s easy to accidentally get this training cycle reversed. If you turn consistently turn on a noise and tell yourself to “be productive, damnit!” then you are actually going to train yourself into dreading or disliking that noise. So try to avoid that one. No personal experience there or anything. 🙄

With all that said, here are some of my favorite noise-based resources that I highly recommend:

Noises.online

Noisli.com

CalmyLeon.com

Purrli (This one is a cat)

And you can actually skip all of those, because here is the best website on the internet:

MyNoise.net

MyNoise offers a basic rain noise out the gate that you really don’t have to mess with if you just need to blank out external sounds, but beyond that, it is a truly dynamic, user-friendly, simple, brilliant website. You can save sound settings to a URL, download sounds, publish sounds, check out other user’s published settings, turn it on with Alexa, Spotify, Google Play, and other music services. There is also an app for android and iPhone. The whole project was created and is owned by Dr. Stéphane Pigeon, an engineer, programmer, and sound designer who can be found on on his website here.

Invader Vim

Hal Friday — Wed, 20 Mar 2019 23:44:02 +0000

Every day is a new adventure in code exploration lately. I grew up using computers for their true purpose: video games. The extent of my knowledge on how to navigate a computer reached all the way from how to install a video game to how to play one. That is, until I took an interest in code about 6 months ago. Now, the computer IS the video game, and there are so many Easter eggs my basket is overflowing.

For another frame of reference, back in September I was reading through my first bit of code and it told me that I could copy and paste some stuff into my favorite text editor. So I opened Text Edit, Mac's lightweight notepad.

"I am a master hacker," I thought. It didn't take long to figure out that this was NOT what was meant by text editor, so I re-situated myself with a fancy new code text editor (VS Code).

These days, there are a ton of choices available for which text editor to use. Honestly, I just picked the most popular. Check out this graph from StackOverflow on 2018's top editors:

Navigating through text editors, as a super new practice for me, feels how I imagine my grandfather must have felt the first time he tried to use a keyboard. Hunt and peck, hunt and peck. Recently in my coding journey I was observing one of my instructors fly through his text editor, manipulating lines of code more quickly than anything I'd seen before. Throughout the lecture I was writing this fat list of questions down to ask him how on earth he got around so quickly -- how to pop to the front of the word? The end of the line? The end of the document? Select inside brackets? The list went on.

It turns out, all of these questions point to the same answer: Vim.

Vim was first released on November 2nd, 1991. If you notice on that graph up there, 27 years later, Vim is still the 5th most popular text editor available. In 2015, it was the 3rd. "But hang on," my brain protested, "that guy wasn't using Vim, he was using VS Code."

The solution to that mystery begins with the fact that Vim wasn't originally built for mac. Vim was built for the Amiga, the raddest looking computer of all time:

Just look at that floppy disk port. Vim was used in those days to edit your code inside of the command line in an efficient, legible manner. The setup (which works most fluidly with QWERTY keyboards but can totally be used with whatever keyboard you want) is designed to let you hop around the page without having to use the mouse. Vim has been ported for use with a ton of different devices at this point, and you can definitely use it as your primary text editor. It doesn't have all the bells and whistles you might find in a newer editor like Atom or Sublime but it does it's job and it does it damn well. Ok, so next question:

What my instructor was doing was emulating the Vim commands with an extension in his particular text editor. According to him, most all text editors have some way of emulating Vim, because it's so OG.

I added the emulator into my own VS Code extensions, but as a tribute to my programming elders, I decided to check out the Real Deal as well. I quickly asked Google where the Internet keeps its Vim. To my surprise, Google replied,

"Look inside. It is you who has the Vim."

Apparently Vim comes pre-installed with any Unix-based OS (such as Mac OS or Linux). I felt mildly invaded by this, but it did make using it pretty simple. To get started, you just have enter your terminal and open up a file with it using the command "vim filename.ext".

Learning the Vim Basics

At first, I tried to wing it. While the advantages of being fluent in Vim are undeniable, the on-ramp for understanding what the hell is going on in Vim is a little steep without help, so I sought some tutorials instead.

The most important thing to know is that Vim has two main modes: normal and input. Normal is the navigational mode, while input acts as more of a regular typing mode. You can toggle between the two modes by using the i and esc keys. The third mode, visual mode, is used primarily for selection commands.

The following super quick tips are some key examples that you can use while you are in Vim's normal mode:

The h and l keys for left and right movement respectively
The k and j keys for up and down movement respectively
The w key to skip to the next word
The b key to skip to the previous word

There are an absolute %&$#-ton of other commands, but a bullet point hay day ain't great blog content. You can find a cheat sheet on Vim commands from this super helpful page, and you can use this interactive Vim tutorial to begin your journey into navigational masterdom.

More importantly, however, video games. You can actually play your way to Vim literacy with this stellar, throwback-style adventure game which only allows you to use Vim commands.

This little bit of history on Vim and keyboard navigation gave me a delightful wave of nostalgia and a deeper sense of understanding for what a Text Editor is and does. In reading through the articles and comments about Vim, you could really feel peoples' attachment to the program. It's easy to see how the soft spot was developed -- after 27 years, Vim has only had 8 total versions released, because it was just built so well in the first place. Now if you'll excuse me, I'm off to my VIM Adventures!