Had to take some time to give myself a shout out. I have been doing this #100daysofcode challenge for 2 YEARS = 730 Days! Before I get to my thoughts on the 2 year journey I want to state what I worked on today. Work before reflection LOL. Today I worked on understanding how the debug package works. I used it in the Local Library application but I did not fully understand how it was being used. So I thought I should cover it before finishing up my inventory management application.

Now back to the topic of 2 YEARS!! Honestly, I am proud of myself. I am far from where I want to be, have taken longer to progress than I originally thought, but I am definitely making progress. I can say that I have strived to be genuine and not fake in the presentation of my daily work. I have also tried to be humble and not over embellish my daily accomplishments. As a result, I know I likely come off as slow and boring. At least that’s how I think I look.

The reality for me is that learning alone is not easy and some of these topics are dry! I wish I was faster and I wish I could just build out cool UI’s that I could share a video for but I can’t. In this journey I had to face the tough reality that I am flawed as a developer. I knew a few things at a decent level but I lacked the fundamentals. The further I progressed in the journey the more I couldn’t hide behind hype or encouragement. Basically I exposed myself for being a “meh” dev.

The problem I had, stemmed from learning how to code online with all the hype. I was pushing for accomplishments and not skill development. This lead to me hitting walls often. I knew how to do very specific things but outside of that I was damn near clueless. For example they say you need to know HTML, CSS, JavaScript, and a front-end library to be a front-end dev. The reality is that you need to know so much more. It’s like someone giving you a burger with just a bun and a patty. You will look at them and say where are the condiments?? Where is the lettuce, tomato, ketchup, mustard, mayo, etc. The reality of dev work is that you need to be skilled enough to produce in at least one area and versatile enough to remove the blockers that stop you from producing with that specialized skill. I lacked that versatility and so on this journey I have been working to address that.

I need to get to bed so I will not continue rambling on for too long. This journey has been amazing and if I were to start over I would definitely start by reviewing the fundamentals of how computers work, then move on to the basics of operating systems, then go through a full-stack web development course again. Basically what I have done for the last year. My first year was a mess tbh. I still have an A.I. rock paper scissors game to finish LOL. I am going to get back to that or die trying!!!

Overall, I am blessed, can’t complain, and I am so thankful for the opportunity to improve on myself and keep grinding. Although it has been two years it feels like I am just getting to my real starting point rather than the finish line. I am excited for what comes next. The grind never stops!!!

TLDR;

Okay, so here are the highlights of what I did:

• Practice -> Continued working on the Inventory Management Application project from The Odin Project. Add the error handling middleware and starting taking notes on how to use the debug package. I am still confused about how to call it from the within the app.js or bin/www executable files.

debug Package Notes

debug is a tiny JavaScript debugging utility modelled after Node.js core’s debugging technique. Works in Node.js and web browsers. I have used the debugging tools available out of the box with Node.js

Install with:

$ npm install debug

Usage

debug exposes a function; simply pass this function the name of your module (‘It can be almost any name, made up, does not matter although there is a syntax preference for pattern matching’), and it will return a decorated version of console.error for you to pass debug statements to. This will allow you to toggle the debug output for different parts of your module as well as the module as a whole. This toggling is done by using the DEBUG environment variable for Node.js is then used to enable these based on space or comma-delimited names.

Basically we can have a bunch of different decorated debug (a.k.a. console.error) calls and trigger them to look at all or only some of them by providing their names as DEBUG environment variable arguments.

Example:

/* app.js */
const debug = require('debug')('http')
const http = require('http')
const name = 'My App'

// fake app
// Remember the debug binding is now a docrated version of the console.error method with the 'http' module passed to it.
debug('booting %o', name);

http.createServer(function(req, res){
  debug(req.method + ' ' + req.url);
  res.end('hello\n');
}).listen(3000, function(){
  debug('listening');
});

// fake worker of some kind

require('./worker');

/* worker.js - Referred to above */
const a = require('debug')('worker:a')
const b = require('debug')('worker:b')

function work() {
  a('doing lots of uninteresting work')
  setTimeout(work, Math.random() * 1000)
}

work()

function workb() {
  b('doing some work')
  setTimeout(workb, Math.random() * 2000)
}

workb()

If we run these scripts from the CLI we would set the environment variable like so:

# Using Bash and toggling debug for the http module in the app.js file

$ DEBUG=http node app.js

Example 1 output:

$ DEBUG=http node app.js
  http booting 'My App' +0ms
  http listening +9ms
  http GET / +13s
  http GET /favicon.ico +158ms

# Using Bash and toggling debug for all the worker wrappers  module in the app.js file

$ DEBUG=worker:* node worker.js

Example 2 output:

$ DEBUG=worker:* node worker.js
  worker:a doing lots of uninteresting work +0ms
  worker:b doing some work +0ms
  worker:a doing lots of uninteresting work +315ms
  worker:a doing lots of uninteresting work +871ms
  worker:b doing some work +1s
  worker:a doing lots of uninteresting work +437ms
  worker:a doing lots of uninteresting work +12ms
  worker:a doing lots of uninteresting work +68ms
  worker:a doing lots of uninteresting work +470ms

# Using Bash and toggling debug for all the worker wrappers  module in the app.js file

$ DEBUG=worker:a node app.js

Example 3 output:

$ DEBUG=worker:a node app.js
  worker:a doing lots of uninteresting work +0ms
  worker:a doing lots of uninteresting work +507ms
  worker:a doing lots of uninteresting work +44ms
  worker:a doing lots of uninteresting work +708ms
  worker:a doing lots of uninteresting work +854ms
  worker:a doing lots of uninteresting work +374ms
  worker:a doing lots of uninteresting work +122ms

How to run it in windows cmd:

On Windows the environment variable is set using the set command.

set DEBUG=*,-not_this

Example:

set DEBUG=* & node app.js

How to run it in windows PowerShell:

PowerShell uses different syntax to set environment variables.

$env:DEBUG = "*,-not_this"

Example:

$env:DEBUG='app';node app.js

How to run it from npm Scripts:

npm script example:

"windowsDebug": "@powershell -Command $env:DEBUG='*';node app.js",

Goal For Round 8 of the #100DaysofCode Challenge

This is my eighth round of the “#100daysofcode” challenge. I will be continuing my work from round five, six, and seven into round eight. I was working through the book “Cracking the Coding Interview” by Gayle Laakmann McDowell. My goal was to become more familiar with algorithms and data structures. This goal was derived from my goal to better understand operating systems and key programs that I use in the terminal regularly e.g. Git. This goal was in turn derived from my desire to better understand the fundamental tools used for coding outside of popular GUIs. This in turn was derived from my desire to be a better back-end developer.

I am currently putting a pause on the algorithm work to build some backend/full stack projects. I primarily want to improve my skills with the back-end from an implementation perspective. I have improved tremendously in terminal and CLI skills but I lost focus due to how abstract the algorithm concepts got. I wanted to work on things that were more tangible until I can get to a position where I could directly benefit from improving my algorithm skills and theoretical knowledge. So that’s the focus right now. Build my backend skills and prove my full stack capabilities by building some dope projects.

Again, I still have no idea if my path is correct but I am walking down this road anyways. Worst case scenario I learn a whole bunch of stuff that will help me out on my own personal projects. Best case scenario I actually become one of those unicorn developers that go on to start a billion dollar company… You never know LOL.