DEV Community: James Walsh

PNPM has both Yarn & NPM beat.

James Walsh — Fri, 07 Jul 2023 19:12:04 +0000

Intro

One of the biggest complaints you'll hear about the Javascript ecosystem is the tendency of the community to reinvent the wheel. Admittedly, while I find this to be one of the biggest strengths of the community, the shade thrown our way is not completely unwarranted. I think this is most succinctly proven by the fact that at the time of writing this article we have 3 package managers. In any other language or runtime, this would be unheard of. And our package management isn't our worst offender. Right now by my accounting, there are 5-7 popular ways to build & transpile JS/TS so that it can run on a server or in the browser. Compare this setup to most other languages, where you just use the language's compiler, and we can maybe start to understand why our ecosystem can sometimes be justifiably on the end of some jokes.

History Lesson: Yarn vs NPM

At the same time, the competition in our ecosystem is unrivaled, and it consistently pushed us forward. There is no doubt that Yarn gaining popularity led to many big enhancements to NPM, including simple things we now take for granted.

For instance, you can thank the yarn team for the fact that NPM has a lock file. Yarn launched with a lock file out of the box with high praise.
Yarn also invented the idea of a workspace, which forced NPM to support workspaces too.
Yarn resolutions helped get developers out of security jams when dependabot wasn't enough.

All of these tools are industry standards, and we have the yarn team to thank for the pressure to get them into their current state. My point is that this competition is a good thing , and developers having a choice counts for something.

I hope that if you're using NPM or Yarn you'll install pnpm and give it a fair run. Yes, they reinvented the wheel. Again. But I think they did it justice. I've made the switch to pnpm painlessly, and I'm not looking back anytime soon.

What Makes PNPM Different?

All of this information is readily available in PNPM's Motivation White Paper. Here is the TLDR; so that you can make quick decisions.

Problems with Flat Node Modules

Both yarn classic & npm hoist all dependencies, including dependencies of dependencies to the root of the node_modules directory.
This is slow, and can sometimes create problems with resolutions that take up time as dependency graphs resolve.
PNPM only installs the specified dependencies in your package.json to the node_modules directory. All "dependencies of dependencies" are symlinked from the content addressable store.

Content Addressable Store

When using npm, if you have 100 projects using a dependency, you will have 100 copies of that dependency saved on disk. With pnpm, the dependency will be stored in a content-addressable store

All the files are saved in a single place on the disk. When packages are installed, their files are hard-linked from that single place, consuming no additional disk space. This allows you to share dependencies of the same version across projects.

Saving disk space is becoming increasingly relevant. In a world where we ever increasingly rely on GitHub Actions, GitLab pipelines, and other CI/CD vendors, this benefit can make a real world difference in your development flow. Since most of our web applications & services are running inside docker containers (or abstractions around docker containers) these disk space wins will also convert to time and money saved as our pipelines flow code into customer's hands. And this benefit costs nothing since PNPM is built on top of NPM and has compatibility with its CLI.

Symlinked Node Modules

In the last section, we talked about symlinking dependencies from the content addressable store. And I'd like to focus on why that's powerful. Check out this super common use case outlined in the white paper.

If you depend on different versions of the dependency, only the files that differ are added to the store. For instance, if it has 100 files, and a new version has a change in only one of those files, pnpm update will only add 1 new file to the store, instead of cloning the entire dependency just for the singular change.

This is fundamentally no different than how frontend engineers handle caching HTTP requests to improve SPA performance. Intelligent caching works hand in hand with improving your normal development flow.

Nice Features To Know About

You Can Get Rid of NVM

Thats right. You can completely uninstall tools like NVM or FNM and have pnpm manage which NodeJS version youre on. Here are some steps to test this out:

You'll want to uninstall both npm and node globally from whatever mechanism you used to install them. Be it nvm, brew, choco or some other means.
Next, you'll want to install pnpm using the pnpm install scripts mentioned in their documentation. On POSIX machines like Mac & Linux you can run the following:
Once you have a clean fresh machine with pnpm installed, use the env command to install the latest LTS version of node :

   pnpm env use --global lts

To make sure everything is installed correctly use the following:

   pnpm env ls

To double-check that your global node version is managed by pnpm directly run:

   which node

The output should be something like /<your-home-directory>/Library/pnpm/node.

If you ever want to change your node version as you would normally with NVM you can use the same command mentioned in step 5. In this example pin our global node version to 18.16.1

PNPM is Fast

At the end of the day, this is the feature that will make or break a package manager in my opinion. The only real job of a package manager is to deliver your dependencies from a registry in an efficient way. Rest assured that pnpm is fast. Plain and simple. Check out this link to openly maintained benchmarks by the Yarn / Meta team. They run every 4 hours and are administered against two use cases; a fresh Nextjs install and a fresh Gatsby install. The Yarn team broadcasts the performance honestly, even when yarn isn't always the clear winner (which has been the case up until recently). While I think it's important to let people read benchmarks and decide for themselves on interpretation, one small caveat I'd like to add here is that yarn's performance metrics come with a small catch. Most people right now are using yarn classic. At the time of this writing, the non-classic version of yarn still makes up a huge minority of yarn installs. While its performance looks promising, a more fair comparison of how people are using package managers in the real world would be to compare npm, pnpm, and yarn classic.

While I'm beyond happy with pnpm's performance (and think it speaks for itself), I'll add that recently the performance wins between pnpm, npm, and yarn are all beginning to reach a plateau. This is a good thing for the entire NodeJS ecosystem. But after careful consideration of the benchmarks you can rest assured that not only will pnpm not slow you down, but in common everyday use cases will speed you up.

Package Manager Interoperability

PNPM seems to play nicely with corepack. If you haven't heard about corepack don't worry, I'm still in the dark here too. At the time of this writing, corepack feels promising but still painful and early.

Corepack seems to promise to unlock some level of interoperability between package managers. If you want more information on this, Shalvah has a great blog post going more in depth. Using corepack to specify your package manager is sort of the opposite of using pnpm env. Instead of having pnpm manage your node version, node would manage all your different package management tools for interoperability. There are trade-offs to this approach, and Shalvah goes into more detail about what they are.

Wrapping Up

So you can ditch using node version manager, benefit from the full power of the content addressable store, and every time you run pnpm install you're gonna sleep easy at night knowing no meaningful amount of your day will be spent waiting for dependencies installation to finish. PNPM deserves your attention, I know it will continue to have mine.

Next.js - A React starter kit you can stick with

James Walsh — Mon, 18 Jan 2021 18:34:33 +0000

I've tried just about all the popular react starter kits. In 2016 the first npm package I ever installed to begin learning react was create-react-app. After ejecting the package my first time, I then quickly moved on to creating my own custom react starter kit, but quickly realized I had no intention of maintaining it. From there I built toy projects using Gatsby, react-redux-starter-kit, and the list goes on.

While I could compare Next.js to both Gatsby and Create React App, for brevity and showcasing its power today I'm choosing to pick on Create React App (CRA).

Picking on CRA

I've never used create-react-app without eventually needing to run "eject". When you do, you're met with a consortium of various configurations for webpack, babel, eslint, jest, and other tools, many of which you are not sure if you'll need. But this process leaves me feeling somewhat afraid about what is okay to remove. Once you do run "eject" you are completely on your own. So you get the choice between having a project which has one dependency, create-react-app which will conceal the bloat. Or owning all of the dependencies it conceals and managing the bloat yourself.

This process often leads me to throw my hands up in the air and saying "well fine, I'll just make my own simple webpack config for this small project I'm working on". CRA is inherently opinionated. I should be clear, I don't think that's necessarily a bad thing (especially if you're just barely getting into React and need to hit the ground running quickly). If you like the out of the box tooling CRA ships with then you should have pretty smooth sailing.

My Needs

For context, I decided to revamp my portfolio site. I wanted to do this quickly, in a week or less. It didn't make sense to tinker with client configs for days on end getting things "just perfect" only to discover once my project was out in the wild that it was sorely unoptimized. So a bootstrapper was needed and made sense.
I wanted a starter kit that was testing agnostic. Jest is great and has come a long way over the last few years, but I still prefer to use something on top of Jest like react-testing-library, paired with some smokescreen e2e tests written in Cypress. Because of this need, I would prefer to manage the test setup code completely on my own.
I wanted a lot of control over the client-side libraries I chose to use and needed something flexible.
Typescript. I love TS what more can I say. While CRA does include support for Typescript, the support isn't the best. You have to initialize CRA with a custom template command. Afterward, CRA then attempts to use Babel and Typescript together, which has some interesting side effects, like for example, no enum or namespace support.
I don't want to ever have to worry about being involved with a process like "ejecting". I want a client-side starter kit that will shallowly allow for me to disagree on some things, and use my own customizations for things one would expect.
For most of my side projects, like my portfolio site, a completely separate server written in Express, GraphQL, etc is just way overkill. Some level of serverside support goes a long way for a project like this, so I can write some simple light-weight API endpoints as a cherry on top.

Enter Next.js

The first magical moment with Next.js was the second I wanted to add Typescript to the project. The Next.js philosophy is "no config needed". And that's what they try and do. Stay out of your way while you build. I followed the short setup guide for TS, and it was one of those apple moments where "it just worked ™". I didn't have to worry about what webpack was doing under the hood, or concern myself with any constraints on Typescript (like enums and namespaces not working in CRA).
The second magic moment was how Next.js handled clientside routing. The next/Link component can be used anywhere and will handle any and all internal linking that you want to do. React components placed in the /pages directory are automatically registered as a route based on the naming convention of the file. Non-page components (like reusable, shared components) can be placed outside of the /pages directory in a directory of your choice to avoid exposing them as a route.
The API layer. Inside of the /pages/api directory Next.js includes support for writing your own thin Next endpoints. In my case, a paper-thin client API was all I needed so this worked great. As the project grows they have support for adding custom middlewares, following the express/koa-like syntax of using function callbacks that contain a (request, response, next) argument convention. In addition, there is no need to worry about cross-origin requests as the same server which serves up the client also serves up the client API. Vercel also owns the SWR package, which they recommend pairing with the Client API. SWR follows the stale-while-revalidate cache invalidation strategy through easy to use react hooks which assist in client request caching.
The areas where Next lacks in opinion was refreshing. I threw together my own testing suite and didn't have to worry about magical test frameworks behind the scenes stepping on my toes. I began adding font libs, animation libs, prettier, eslint.
Secret sharing. Next.js has a built-in mechanism for sharing secrets. It's a fairly standard procedure here. Environment variables specified in a .env.local are attached to process.env and can be used on both the client/server in that manner.

When You Need To Go Beyond

Vercel seems to understand that eventually you may just wanna dip out from their defaults and try your own thing. When that happens, rather than "ejecting" from next, you can specify some of the traditional build flows in a webpack config through using the next.config.js file. Vercel's docs include examples of swapping out the defaulted CSS Modules setup with JSS, or Sass, as well as adding PostCSS support and more.

Benefits

I won't go too deep on all of the benefits Next.js promises. But there is a whole slew of features that Vercel has packed in here.

Pre-rendering components leads to better performance and SEO.
Fast Refresh feels like webpack hot-reloading decided to start taking performance enhancement drugs.
Image serving/caching is a really fantastic experience using the next/Image component.
Vercel's deployment platform was built specifically for paired use with Next.js, and has a really compelling free tier. The two when used together provided yet another "magic moment" for me.
To learn more I recommend looking at [Why Next.js].(https://nextjs.org/)

Caveats & Dislikes

While I believe Next.js is a great tool for my needs, no npm package ever deployed is a silver bullet. There are some downsides, and admittedly a few strong opinions that Next.js has.

JSS. Next ships with default support for CSS Modules. While there is nothing stopping you from going your own way, there is one technical constraint put on using JSS. Namely that you cannot use it in server-side components. Decisions like this do push the codebase toward the direction of using CSS Modules and being okay with it. Ultimately this tradeoff didn't impact me, but that may not be the case for you.
TS Config, if you change it, Next.JS will just re-generate the config back to what it's expecting. This isn't all the way bad though, as the standard TS Config is pretty flexible for most project needs. I wanted to make my compiler a bit more strict, and that was where I started running into issues. There are workarounds (like using good eslint rules which TS plugins). I ended up using the following which I was happy with:

"extends": [
    "airbnb",
    "plugin:cypress/recommended",
    "plugin:react/recommended",
    "plugin:react/recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier/@typescript-eslint",
    "plugin:prettier/recommended"
  ],

TLDR;

I've never moved faster on a side project than when I picked up Next.js. It got me out of the boilerplate and into writing the more interesting parts of my codebase fast. The package was able to do this in such a way that I still felt like I was in control and never had to worry about any process like "ejecting". I'm completely won over, and moving forward I would have to look for good reasons not to use Next.js on any new front end project that comes my way.

Tenets of Functional Programming

James Walsh — Tue, 01 Dec 2020 02:58:44 +0000

Over the last year, I've experimented with a handful of different programming languages. Some of these have been functional (which I will refer to as FP), some object-oriented, and most of which are hybrid languages. A few days ago I asked myself the question, if I were first being introduced to FP concepts today, what would I want to know first? The following is my response to that question.

First, Some FP Wins 💙

I'm going to make four claims that I'll back up later. So here's the elevator pitch on why embracing FP concepts is going to make you as happy as a dog eating a hot dog.

By adhering to these tenets I believe you will win:

Testability
Refactorability
Readability
Better Control Flow

Next, Some Baby Steps 🐣

"James, what makes a language an FP language, OOP language, or a hybrid language?" I'll try to make this clear as mud by illustrating some language features from technologies I've explored.

Functions as a First-Class Citizen

All popular programming languages have support for functions. But not all of them have first-class support for functions. So what exactly does it mean for a function to be "first-class?".

Here are some simple rules for you to suss that out:

Functions can be declared at the top level.

Functions can be assigned as values to variables.

A function may accept another function as a parameter.

You may declare nested functions within functions (turtles all the way down).

The language allows you to "compose", or arrange smaller functions into larger functions.

While FP patterns DO exist in the languages below, functions are treated as 2nd class citizens. With that in mind let's eliminate them as a thought exercise.

C# (OOP):
- We have the ability to assign functions to variables, and pass functions to other functions (using anonymous methods, LINQ, etc).
- But only within the scope of a method inside of a class inside of a namespace. So while some functional patterns exist, functions are not "first-class".
Ruby (OOP):
- Similar to C#, lambda expressions (anonymous functions) exist. These can be defined inline and assigned as a value to a variable.
- You can declare methods within methods (function nesting)
- But ultimately whatever is being defined must exist within the scope of a class and its methods. Functions cannot exist on their own.
JS (Hybrid): You can declare functions, objects, and classes at the topmost level. Functions can be assigned as values to other variables and accepted as parameters. Function nesting is also allowed. But there is a fascinating little quirk about JS that isn't immediately recognized.
- In your browser devtools run the JS code (function(){}).constructor. Did you catch it? Every JS function is actually just a Function object. Function itself is not the base type.
- That's right, at the end of the day you are actually constructing JS objects when you declare new functions. This has led many engineers to say "JS is actually Object-Oriented".
- While I think there is merit to the statement above, because these Function objects behave like traditional functions, pass every check in the first-class citizen test, and the language does not enforce the same strict namespacing/class encapsulation strictness in other OOP languages, I sit firmly in the "hybrid language" camp.
Scala (Hybrid): In Scala it's the same story as JS, but with a slightly different flavor.
- Every function is a value. Functions may be nested. Functions may be declared at the top level and passed as parameters. For brevity, the first-class test is met.
- However, types and behaviors in Scala are defined by classes, traits, sub-classes, mixins, and all those other mechanisms you've come to expect from an OOP language.
- As you can see in Scala, similar to JS, they leave things completely up to you how deeply you decide to take one approach.
Elixir (Strict FP):
- functions are first-class citizens.
- Functions actually replace classes & objects as the root level data type.
- No support for classical inheritance but instead, expect you to use something called "Function Composition" to achieve similar goals.
- Functions may be treated as values, but when you inspect under the hood you won't find an "object" type being used ephemerally.
- No support for popping back into OOP Land when you want to use traditional dependency injection, inheritance, or class instantiation.

After reading this blog post, I don't expect you to run off and convert your Ruby project to Elixir. In fact, the opposite. I wanted to introduce the idea that most modern tech stacks have sprinkles of FP across their language features. As we jump into the meat of these tenets I hope you can find something that applies to you wherever you're working.

Tenet 1: Higher-Order Functions 🧗

If you have experience with React you've probably heard the term "we favor composition over inheritance". What's being described here isn't just a React best practice, it's the first Tenet of FP.

Imperative VS Declarative Programming

In classical OOP, shared functionality & state is often defined in classes that can be inherited. The Dog class may inherit from the Canine class which defines useful universal methods like Run(), Bark(), Pant(). You can write something like Dog extends Canine and some level of base functionality & state management will be inherited. This type of thinking is referred to as "imperative" thinking.
In the following article, CodeBurst Declarative vs Imperative Programming, the bit of knowledge to glean is:

Imperative programming is a programming paradigm that uses statements that change a program’s state.
Declarative programming is a programming paradigm that expresses the logic of a computation without describing its control flow.

In functional programming, developers prefer "declarative" thinking. Functions aren't concerned about when they are called or by whom they are called, and aren't concerned about the program state.

Where an imperative approach may look like: new Dog().Bark()
The declarative approach may look more like: bark(() => dog).

The bark function isn't really concerned about who is barking when they are barking during program execution, or why. It's only a function that takes in another function as a parameter, and barks on whatever the return value of that function parameter is. What you may have already realized is that we just inadvertently composed our first function.

Function Composition 🎼

Function composition is the process of combining two or more functions to produce a new function. Composing functions together is like snapping together a series of pipes for our data to flow through.

Or to illustrate the point differently, I like to think of function composition in similar terms to music composition:

Musical notes simply exist, much like functions. But it is up to the composer to arrange the notes in their proper order to make up a song.

To go back to the Dog example, bark(), run(), bite() are all arranged as individual pieces. They can be arranged in any order. You may arrange (compose) them so that a dog runs up to someone, barks at them, and then bites them, but you may also "compose" these functions in any number of interesting ways. It may not be a dog that bites the user, but it may actually be biteUser(() => cat). In this case, biteUser is the Higher-Order Function which takes in the entity that is doing the biting.

Testing 🧪: You can imagine how using these higher-order functions allow for a pretty great testing experience. biteUser() can be tested in isolation, as can dog(). Later on, you can write an additional unit or integration test to figure out what happens when these functions are composed together in different ways.
Control Flow ⚙️: You can imagine how we might change the order of bite, run, etc. That is because what is now separated from when.

Tenet 2: Function Purity 😇 (Side Effects)

What makes a function pure? There is a simple test you can run to determine if a function is "pure" or "impure".

A function is considered pure if given the same input it always produces the same output.

To illustrate this point:

// pure
function addTwoNumbers(num1, num2) {
    return num1 + num2
}

// impure
function getRandomNumberWithMax(maxNumber) {
    return Math.floor(Math.random() * maxNumber)
}

If we run addTwoNumbers(2, 4) we will always get 6.
If we run getRandomNumberWithMax(10) we might sometimes get the same output, but very rarely.

Side Effects 💥

It's obvious that using Math.random would make for an impure function. But in the real world, there are usually really good reasons why our functions might not produce the same output.

That reason is side effects. Side effects are things that happen outside your function or local environment that you cannot control including:
- Referencing the global state
- Updating a record in the database
- Making an external HTTP request
- Querying the DOM
- Logging to the file system

The first time I was exposed to this idea, I threw my hands up in the air and said:

"So any time any real work needs to be done, I have a side effect, so what's the point?"

I think it's important to understand that the goal isn't to eliminate all side effects or to shame yourself when you write an impure function. But rather to think about testing, flow control, and encapsulation.

Thinking about things this way leads to questions like:

"How can I encapsulate side effects so that they don't' trickle out across the entire codebase".

Practicing Side Effect Forgiveness

In many cases we can use composition to inject side effects through function parameters rather than declaring them inline in the function body. This helps keep the function pure and side effect free.
There is nothing wrong with a properly encapsulated side-effect producing function. As long as we keep striving to isolate our side effects to just a few spots instead of everywhere.

Tenet 3: Immutability 💾

Immutability is pretty straight forward to understand but has some powerful ramifications. Immutability simply put is defined as:

Data that may not be mutated, only copied

// this works, however, this var can be changed later on
let myMutableString = 'James Walsh'

// first change 😭
myMutableString = ' is a really cool guy!'

function changeString() {
  // second change
  myMutableString = 'something entirely different'
}

const immutableString = 'James Walsh'

// Throws the error Uncaught TypeError: Assignment to constant variable.
immutableString = 'J. Walsh'

That's pretty much it. Because we strive to have side-effect-free & "stateless functions", when we need to change data we copy the data first, then modify it. This achieves function purity by eliminating the temptation to modify a state outside of the function's direct scope.
In redux, immutability enables features like "time-travel" debugging that allows you to see how data is changing as each function manipulates a given data set.

Tenet 4: Referential Transparency 🧮

"If a function references another function, it may be swapped out with that function's implementation and will still return the same result."

When we work with immutable data and pure functions, we gain referential transparency. We can substitute out a function call with the function body and nothing should change.

Consider this simple example:

function add(num1, num2) {
    return num1 + num2
}

function divide(num1, num2) {
    return num1 / num2
}

// Same result is produced in many different ways with referential transparency

// Ex 1: Using function references
const result = divide(add(2, 2), add(2,4))
// Ex 2: Replace function references with values that are function references
const num1 = add(2, 2,)
const num2 = add(2, 4)
const result = divide(num1, num2)
// Ex 2: Replace values with add function refs, with the function implementation
const num1 = 2 + 2
const num2 = 4 + 2
const result = divide(num1, num2)
// Ex 3: Replace divide function ref with the function implementation
const num1 = 2 + 2
const num2 = 4 + 2
const result = num1 / num2
// Ex 4: Replace all references with pure single line implementation
const result = (2 + 2) / (4 + 2)

No matter which implementation or reference we substituted, the value of the result will always be 0.66 (repeating).
Referential transparency delivers on the promise of being able to refactor, as well as write comprehensive tests where you can use test data in your test case, or mock functions which return appropriate test data, without fear that results will look wildly different in production.

Tenet 5: Functors ⚡️

Now that you have a good foundation, we can learn about Functors which are going to give you an insane amount of readability with tons of expressiveness. Functors are the primary way we are going to modify any immutable data.

Functor Definitions

So what is a functor? Ask any developer and I guarantee they will each give you a different answer. So in order to cover my bases, I'm going to give you a few different definitions to work with:

A functor is a set of values arranged in a shape that can be mapped over (or changed).

A functor is a collection that can be passed a function and apply it non-destructively to all of its elements, returning another functor.

Functions or Objects which have implemented .map or variation of map.

Little confused? You're not alone. Let's take a look at an example you may already be using. Let's explore the JavaScript Array.map.

Scenario

Let's say our user is an animal shelter that wants to be able to provide a new pet owner with a list of the names of all the cats that are female that don't have long hair. They'd also like this list sorted by kitties that are used to being indoors.

Here is our data set:

const cats = [
  { name: 'Tony', coat: 'long', gender: 'male', isIndoorCat: false },
  { name: 'Tinkerbell', coat: 'short', gender: 'female', isIndoorCat: true },
  { name: 'Whiskers', coat: 'short', gender: 'male', isIndoorCat: false },
  { name: 'Snickers', coat: 'short', gender: 'female', isIndoorCat: true },
  { name: 'Nala', coat: 'long', gender: 'female', isIndoorCat: false },
  { name: 'Selina', coat: 'short', gender: 'female', isIndoorCat: false },
  { name: 'Gusto', coat: 'short', gender: 'male', isIndoorCat: true },
]

Imperative Code 🤮

let catsToShow = [] //mutatable state we can reference from inside our loop
  for (let cat of cats) {
    if (cat.gender === 'female' && cat.coat === 'short') {
      if (cat.isIndoorCat === true) {
        catsToShow.unshift(cat) // sort indoor first
      } else if (cat.isIndoorCat === false) {
        catsToShow.push(cat) // sort outdoor last
      }
    }
  }

  for (let cat of catsToShow) {
    console.log(cat.name) // only display the names
  }

What's wrong with this code?

We're mutating a lot of state.
Control flow is hard to keep track of.
We can't reason about one part of our requirements without reasoning about the whole of the program.

Let's see how Functors can make simple tasks much easier to look at and think about.

Using Functors (Round 1)

Now since Array is a functor it returns (itself) another functor.
The Array Functor provides a few useful methods that perform mappings.

.filter() which takes a function as a parameter that returns a truthy value to specify which items in the collection should be included in the new Functor.
.map() which takes a function as a parameter that returns a new copied and changed version of index in the collection which will be included in the new Functor.
.sort() which takes a function that's return value specifies the sort order of the items returned by the new Functor.

const filteredCats = cats.filter(cat => {
    return cat.gender === 'female' && cat.coat === 'short'
  })
const sortedCats = filteredCats.sort(cat => {
    return cat.isIndoorCat
})
const namesOfCats = sortedCats.map(cat => {
    return cat.name
})

console.log(namesOfCats)

Isn't that a little easier on the eyes?

Using Functors (Round 2)

We can simplify this further.

Functors always return a new Functor, so we can use function chaining to pipe outputs to new functors as inputs.
Let's also add some syntax sugar that lots of popular languages support including implicit function returns, & removing function braces.

const result = cats
    .filter(cat => cat.gender === 'female' && cat.coat === 'short')
    .sort(cat => cat.isIndoorCat)
    .map(cat => cat.name)

console.log(result)

TLDR;

Function Composition (Higher Order Functions which compose other functions) help us achieve things we'd achieve through Inheritance but with the advantage of achieving some sweet de-coupling.
Pure Functions help us increase our code predictability, testing, simplicity, and force us to think about how to properly encapsulate volatile parts of the codebase.
Object Immutability helps us achieve function purity through "copying data first" before changing state. And also helps enable us to practice time travel debugging.
Referential Transparency helps us mock data during testing, refactor our code with confidence, and structure our code in flexible ways.
Functors help us change immutable data with ease, usually end up shortening the amount of code we need to write, and further help us de-couple control flow.

Extra Credit: Monads, Memoization, Currying, Recursion

I view the 5 tenets above as a good way to begin exploring FP concepts. But you will find that they serve as a good baseline to explore more interesting behaviors.

Exploring Functors will eventually lead you to Monads (which are a type of functor which makes working with side effects easier).
Composition will lend itself well to function currying
Function Purity can lead to memoization which has the potential to offer system performance and tuning wins.
Recursion is useful when performing data branching logic, but use cases outside of that may be on the rarer side.

From BootCamp to College

James Walsh — Wed, 10 Jun 2020 23:00:17 +0000

At the time of writing, I am 26 years old.
I'm a college drop out.
I’m a boot camp grad.
I've been working as a software engineer for 5+ years full time.

I adore my career in software development.

I’m beyond happy with how everything has panned out and the success I’ve personally felt. I love this field.

Now time to queue the click bait. As of a week ago I’ve committed to going back to school to finish my CS education.

A Moment of Caution

I'd like to spend some time explaining how I got here. But before I do I'll start by painting a picture around my current, unfiltered worldview:

I do not believe a Bachelors Degree in Computer Science is a requirement for becoming an excellent, productive software engineer who can write clean code and deliver value to the business. (Especially if you already have a degree that would be considered complementary toward a transition into tech)
I do not believe that all boot camps adequately prepare their students for the onslaught of responsibility that is about to be thrown their way. I do not believe bootcamps are a shortcut or a replacement for college. However I do believe that bootcamps are a more capitalistic approach to education that allows you the freedom to take your learning and accountability toward success into your own hands. I also believe boot camps do a better job than colleges at teaching you "how to teach yourself".
No one really knows what they are doing. We are all trying to learn from each other. There is no 1 size fits all solution to starting your career. I don't believe my experience will be true for everyone. The following is not a recommendation. Just a cautionary tale about how I arrived here.

The Boot Camp

From time to time I've heard friends, family members, colleagues, and acquaintances ask about my boot camp cohort with sincere desire for understanding. I've personally felt whether perceived or projected a plethora of responses both positive and negative toward pursuing the bootcamp life. I've sensed that some have felt some level of envy (esp after a 4 year investment at a large institution). While others have may have expressed in some sense an understanding that fresh bootcamp grads may not be as qualified as their graduate counterpart. Others yet may take a more middle of the road approach and feel that each candidate is expressly unique and dig at their true qualifications.

The truth is all are correct.

Pros of Bootcamps

Personally, I do not regret breaking into the industry as young and as unskilled as I was (Barely 21 and with only a basic understanding of JS and a tiny bit of Ruby on Rails). I was able to get an entry level web developer position with no debt, and one semester's worth of really hard work. Do I regret that? No.
I'm confident in my ability to teach myself and ask questions of mentors when I find gaps. Boot camps are fundamentally all about this. They give you some direction then send you off to fail on your own. Afterward they expect you to come back with answers, or questions that will get you closer to the truth. This style is much more applied and hands on which jives my personal style.

Cons of Bootcamps

Despite the praise I've given above, and even years later I still find myself occasionally plagued by knowledge gaps and imposter syndrome. And each time I've felt that imposter syndrome. I've been able to alleviate it through self lead education. Which sometimes leaves me puzzled as to what I actually paid for when most everyone knows how to google.
Even if you find success with a bootcamp you will still be required to pursue the right books, the correct mentors, and most importantly of all learning on the job. In my case by being able to write code with experienced devs on healthy teams was crucial. My coworkers helped foster my skillset and grow talent organically outside the classroom.
Bootcamps are unregulated. No two bootcamps are created equal. In my conversations with other bootcamp grads our education varied from cohort to cohort, company to company, and even instructor to instructor. The truth is some people are just going to luck out with their instruction and some people aren't. I don't like to admit it, but I played the lottery and happened to win. My experience was better than others.

What left me with an overall positive impression of boot camps was that my cohort left me with strong basic fundamentals to build upon later. Fast forward to day and I owe my current skillset not to the bootcamp, but rather to my coworkers who mentored me, the business problems that we're thrown at me, and the companies that were willing to take a chance and invest on me. Did the boot camp help kick start all of that? Absolutely. And fast as hell.

The Failings of Modern Education

So what's the answer then? Here I've gone giving a mixed review on boot camps. But do I feel any better about colleges? Generally speaking no. Modern education has failed us. It's expensive. It's hard. You are required to learn things that are not applicable to the job you will have. Modern testing has proven to be a terrible indicator of knowledge retention and job preparedness.

So if I feel as strongly as I do about why #CollegeSucks what would cause me to re-enter the educational cog as I approach my late 20s?

Enter WGU & Targeted Self Paced Education

Full disclosure. This is not a plug for WGU specifically, but rather the underlying principle. This is not an endorsement and I'm not being paid by the University. There are many other programs similar to this one across the country that mimic these principles. But I do think WGU is a great working example of what to do and how colleges can better adapt to a changing generation with different demands.

Because I have the job experience that I have WGU will allow me to potentially do the following:

Before starting a course, student's are given the ability to take what is called a "Pre-Assessment". The pre-assessment tells you which areas of the curriculum you can skip, vs which areas of the course you need to study hard at. These pre-assessments are all about the student proving that they understand the concepts. If however, you pass the Pre-Assessment with flying colors, the course final is unlocked for you immediately allowing you to complete the class in record time (In my case this is useful as some of the more basic programming courses I would intend to fly past as quickly as possible)
Ditching the idea of traditional semesters in leu of self paced education, moderated at the individual level. At WGU students are responsible for their workload. You come up with your own incremental schedule rather than be beholden to the traditional college semester paradigm. You take as many or as little classes as you can manage within a given time period, and go at a self-paced cadence to complete courses you've started. It may take 1 year, it may take 3 years. You decide.
And most importantly... Getting rid of the fluff & busy work. WGU helps students work towards super targeted Bachelors & Masters programs only. There are no needless generalized courses. All courses listed on their SD program are cohesive & work directly toward my major of choice (in my case BS in Software Development). For example, take the math credit that is required for this diploma.

Ex: Math Credit (Applied Algebra)

Applied Algebra is designed to help candidates develop competence in working with functions, working with the algebra of functions, and using some applied properties of functions...

It doesn't make sense for me at this point in my career to be taking intro algebra classes, nor advanced calculus. However, one could make the argument that programming languages are fundamentally just applied algebra. When I saw the syllabus this clicked for me. Each course credit is working toward me, not needlessly against me.

I do believe programs similar to this one pose a healthy middle of the road solution to CS education. Coding Bootcamps that promise that in 12 short weeks they will take you from zero to hero are just plain false. Conversely spending 4 years of your life and potentially many thousands of dollars on outdated principles and high level theory before joining the workforce seems excessive at best, and totally unreasonable at worst.

Our education system is broken. But I do think things are changing for the better. And I intend to be the guinea pig.

Loose Opinions Loosely Held

The decision to go back does not come from a desire for career growth. Most employers support the concept of learning on the job. Especially where our tech stacks and tooling are every changing month by month and year by year. If you are a boot camp grad who has found success, please don't think my argument is for you to pursue higher education. It isn't.

What it all boils down to is this... In the last 5+ years my love for computer science has grown to a point that furthering my education is the logical next step. I feel a drive to harness deeper knowledge about how computation works. It fascinates me, it frustrates me, and it continues to humble me.

I want to learn more. I want to be more. I feel that I can take this deeper. I’ve justified not going back on a physical, mental, spiritual, and monetary level (and just maybe I'll be proven right in that justification). But when it comes down to it this is just something I feel I’ve left undone.

So what's the answer? Boot camp or college? Ask me in 2 years and I'll let you know.

A Mac Guy’s Guide to Windows Development

James Walsh — Thu, 29 Aug 2019 01:40:03 +0000

I've been writing NodeJS on a 2016 Macbook Pro since well... 2016. And the experience has been gr8. Except for one small problem....

I am an avid PC gamer. And I'm not holding my breath for a "Gaming Macbook Air" to come out any time soon... Beyond that, I also love building PCs. I know each and every component in my gaming rig because I hand picked everything. There is a certain craftsmanship aspect to it that has always intrigued me.

When I come home at the end of the day and need some time to decompress 2 things come to mind. Do I want to pwn N00bs, or work on side projects? Depending on my answer I'll be on entirely different hardware, which SUCKS. So for years I've been trying to make my experience at home with gaming & writing Node just a bit smoother.

The fact remains that beyond gaming there may be many reasons why you are interested in moving to Windows. This is my journey 🚀.

The Alpha Solution: "Cordy McCord Face"

The alpha solution is one I'm pretty sure many reading this article already do or know... I call this solution "Cordy McCord Face". What you do is buy a nice laptop stand, a display switcher, and a USB hub that connects to a central keyboard and mouse. That way you can dock your MacBook, press 3 buttons total (switch display, switch USB, power on device) and BOOM. Now you're cooking with avocado oil, and can 👏 "seamlessly" 👏 switch 👏 between 👏 your 👏 gaming 👏 rig 👏 and 👏 mac.

Cordy McCord Face Problems

If you like to re-arrange your office, ever move, have the ports on your laptop change, or have lots of dongles... it can just be a huge pain. Cable management also sucks if you need to have your office look "clean".

The Beta Solution: Dual Boot

Dual boot Ubuntu (or some other distro). The thing that makes NodeJS development so great on Mac is because Linux & Mac are so closely related. After all, MacOS is Unix based. I love using tools like zsh, and most of the dependencies I need for app development are available via homebrew or a simple apt-get. So I felt like I would feel right at home on Ubuntu.

Dual Boot Problems

Let's face it. No matter how good the Linux desktop environment is getting, it will never be as polished as Mac & Windows. Maybe that will change some day. I hope so. I personally ran into an obscure issue with Grub, where it would reset my Ubuntu OS instance to a fresh install whenever I switched between operating systems. Ugh... I'm sure there was a solution. But I dont want to spend time debugging those things. Those are issues I know I will never have on Windows or Mac. And if I'm going to write code on my PC the development experience needs to be just as good as Mac otherwise I know I won't do it.

The Solution: Going All In On Windows

For me to go all in on Windows I needed a few things to happen.

I needed to be able to usebash, or even more preferable: zsh with oh-my-zsh
I needed all of my editor settings to seamlessly transfer over.
I needed Node through Node Version Manager
I needed Yarn for package management.
I needed Docker.

The Shell

The best part about going all in on Windows, is that I actually bypassed Windows all together. My development environment is totally isolated from my gaming environment.

Download the Ubuntu app from the Windows Store. Once this install is complete, you will have the Windows Subsystem for Linux running on your PC. (WSL also supports a handful of other distros, I just prefer Ubuntu)

Install the new Windows Terminal app from the Windows Store.

The new terminal app is sleek. It's minimal, it stays out of the way, it actually supports re-sizing (cough cough command prompt), and here's the best part... If you have WSL installed it has automatic support for WSL. Just open a new WSL tab and boom. You're running Linux bois.

Drops Mic.

Please note that the Terminal app is still in Preview. I haven't had any issues with it as of 08-28-2019.

From there the rest was history. I could fly free. I followed the Ubuntu specific guides for installing docker, git, yarn, node version manager, and all my other dependencies. sudo apt-get worked great with no hiccups. I tried to find things to poke at, but in my personal experience things worked exactly the way they did when I was using the terminal in Ubuntu natively.

The Editor

I use VS Code. But I had so many small details configured just the way I wanted on Mac that I didn't want to have to setup again.

I discovered a handy extension in the marketplace called Settings Sync that has worked wonders.

Because all settings in VS Code eventually become some sort of json object. What Setting Sync does is save your VS Code Settings to a Github Gist. You can then push settings up to a gist and pull settings down to a new editor instance on a different machine. It's a thing of beauty.

Potential "Gotchas" 😳

If you're coming from Mac/Ubuntu then all of your line endings are LF. VS Code uses CLRF on Windows by default. You will want to make sure you go user settings and set files.eol: 'lf'
The code command works great inside of WSL. If you are using Webstorm, or a different IDE, it can be a bit tricky to setup commands in your path to be able to open up the IDE from the command line.
You may want to set up symlinks from /mnt/c/** -> your User directory in Windows so that you can find your files inside of the File Explorer.

TLDR;

Use WSL
Use the new Windows Terminal App
Use VSCode.
Switch between gaming & coding like an absolute bad ass.
Profit.

I had such a great experience switching to this setup that I was even able to generate a super small portfolio site completely in windows with my Mac tightly closed in my backpack. I took plenty of Overwatch breaks because for the first time... I could.