Capstone prep is officially underway as of this past week, and with that you could really feel the momentum picking up as we barrel towards January 2nd, the official start date of the January '23 cohort. Friday we received all sorts of information related to our Capstone experience– expectations for communicating with staff, the daily schedule and the syllabus for each of the 17 weeks of the program, to name a few.

We also received our team assignments– the people with whom I'll be learning throughout the program and, starting in the second half of the program, building a project that tackles a real-world software engineering problem. Working with a team is a core part of Capstone, as it models the experience of a working software engineer– working with a group of people to research a problem domain and ultimately build a software application that solves a specific problem within that domain. And of course that brings with it all the various complexities that come with working on a team– navigating potential personality conflicts and differences in communication style, learning to debate trade offs and solutions to problems and ultimately learning to design and code an application together.

At the end of the day though I think everything will be just fine– great, even. The bar to get into Capstone is rather high, which means you can expect that your teammates will generally be of high intellectual caliber, and Launch School tends to naturally attract the type of student you want to be around– studious, committed and highly motivated with a positive attitude.

Reviewing Full-stack Web Development

I spent this first week reviewing topics in full-stack web development– frontend development with React, backend development with Node.js and Express, the HTTP request and response cycle, creating RESTful APIs for resource management, and data storage with MongoDB.

Fortunately all of this was review– HTTP and REST APIs were covered in Core, and I spent all of September and October learning React, Express and MongoDB as part of my 'pre-Capstone prep' work. And it's a good thing, too, as I'd otherwise need to spend a lot more time trying to understand some of the tougher concepts in React– specifically state management with useState, triggering side effects with useEffect, and how they each relate to component rendering and re-rendering (I'm sure that anyone who's learning React has improperly managed state such that it triggers an infinite render loop at least once in their journey).

One cool thing about the work this past week was discovering Fly.io, a PaaS Heroku alternative. In contrast to Heroku, which recently shuttered its free plans, Fly.io has a very workable free tier (including Postgres, if needed) which is great for students and small projects. To boot, Fly.io requires much less configuration to deploy to production, and the performance seems to me to be a bit improved compared to what was available on Heroku's free tier.

And the people rejoice…

Discovering the Convenience of Scripts in package.json

One thing I learned this week – which I suppose you could say has been sitting under my nose undiscovered until a few days ago, so to speak – is that you can configure scripts in package.json to make your development life easier, and sometimes by orders of magnitude easier.

Yes, I've known about configuring single command scripts for things like starting up a server or running a server from Nodemon. But what did not occur to me is that you can configure multi-step processes under a single script.

For example, the process of packaging code for deployment to production is a bit tedious– first you create a production build of the frontend code, and then you have to copy the production build to the backend to be served by Express. Then the entire backend needs to be deployed to production, whether that be Heroku or Fly.io or elsewhere. To do this manually entails submitting a command, waiting for the production build to complete, copying a directory and then submitting a final command for deployment.

But wait! Let's just throw all of that into a single script and call it a day. Here's an example:

// package.json
"scripts": {
    "build:ui": "rm -rf public && cd ../frontend && npm run build && cp -r build ../backend && cd ../backend && mv build public",
    "deploy": "fly deploy",
    "deploy:full": "npm run build:ui && npm run deploy"
  },

Actually, as you can see above it's really 3 commands: one to build the UI, one to deploy to production, and one final command that combines both the build and deploy commands together. So to build the frontend and then deploy the entire application to production, just run npm run deploy:full and that whole multi-layer process becomes just a single step.

Starting JavaScript Unit Testing…

Today I started learning about unit testing using Jest and will finish that up tomorrow. Conceptually it seems to me to be similar to testing in Ruby (which I learned using Minitest), which at its core boils down to testing results against assertions of what the expected result should be.

This article is part of a series writing about my experience going through Launch School's Capstone program.

• Capstone Prep Week 0: Getting Started...