Income Sources :: Books :: Full-Stack Developer Fundamentals

readme.md

Income Sources :: Books :: Full-Stack Developer Fundamentals

⪼ Made with 💜 by realpolyglot.dev

• Income Sources :: Books

Inspiration

• Full Stack for Front-End Engineers, v3

Table of Contents

• Acknowledgements
• Introduction
• A Word of Encouragement
• Chapter 0 :: TypeScript
• Chapter 1 :: Vim & VSCode
• Chapter 1 :: Git & GitHub (Static Site Hosting, CI/CD Pipelines)
• Chapter 2 :: JavaScript Promises & Async Await
• Chapter 3 :: Regular Expression
• Chapter 4 :: Encryption createHash("md5").update(content).digest("hex") or use HMAC crypto.createHmac("md5", secret).update(content).digest("hex") (32 character hex string) MD5->1288-bit out
• Chapter 5 :: SQL
• Chapter 6 :: JavaScript Unit Testing
• Chapter 7 :: JavaScript Debugging
• Chapter 8 :: JavaScript Package Management
• Chapter 9 :: Docker
• Chapter 10 :: HTTP (cURL, Headers, Authentication, CORS), HTTPS, SSL/TLS
• Chapter 11 :: REST API (Methods: HEAD, GET, POST, PUT, PATCH; Authentiation: Bearer, ...)
• Chapter 12 :: GraphQL API (Mutations, Queries, nodes, edges, fragments, pagination)
• Chapter 13 :: Shell Scripting (Environment Variables, PATH, exit codes, shells, awk, sed, grep, find, xargs, pipe/redirection)
• Chapter 14 :: React
• Chapter 15 :: CSS (Selectors, Flexbox, Specificity, Important, Positioning, Cascading, Classes, ID, Role, SaSS/SCSS, PostCSS, Tailwind)
• Chapter 16 :: Node.js
• Chapter 17 :: npm Package Management (install, remove, linking, workspaces)
• Chapter 18 :: npm Library publishing (hosting, publishing)
• Chapter 19 :: React Native
• Chapter 20 :: Algorithms
• Chapter 21 :: Function Composition, Partial Application, Currying
• Chapter 22 :: App Store Publishing
• Chapter 23 :: AWS (Route 53, S3, EC2, DynamoDB, SNS, SQS, CloudFront, API Gateway, Cognito, ECR, Kinesis, SES, SFTP, CLI, Elastic Beanstalk, IAM, Secrets Manager, Lambda)
• Chapter 24 :: Netlify
• Chapter 25 :: ElasticSearch
• Chapter 26 :: Domain Registration & DNS
• Chapter 27 :: Google Mail for Domains (Google Workspaces)
• Chapter 28 :: State Machines
• Chapter 29 :: Kafka & Event Hubs
• Chapter 30 :: Audio
• Chapter 31 :: Video (CuePoints)
• Chapter 32 :: RabbitMQ
• Chapter 33 :: AWS Lambda (Serverless)
• Chapter 34 :: IaC (CloudFormation & Terraform)
• Chapter 35 :: Ansible
• Chapter 36 :: Python
• Chapter 37 :: SSH & SFTP
• Chapter 38 :: SVG
• Chapter 39 :: TestFlight
• Chapter 40 :: CI/CD
• Chapter 41 :: Package Publishing & Package Registries (GitHub Packages, Artifactory, Nexus)
• Chapter 42 :: Exponential Backoff
• Chapter 43 :: OAuth
• Chapter 44 :: HTML, DOM (Find, Add, Remove, Hide/Show), Window, Script Tags
• Chapter 45 :: XHR/Fetch
• Typescript
• Open-Source Contribution
• Package Publishing
• Pair Programming
• SaaS (multi-tenant application development)
• Computer Vision
• Data Science
• Freelancing
• Contracting
• Interviews
• Promises
• Error Handling
• HTML/CSS
• GraphQL
• SQL (connect, create, drop, grant, view, materialized, indexing)
• Caching
• Search
• Algorithms & Data Structures
• Ansible
• DNS & Domain Registration
• Linux Command Line
• Git
• Shell Scripting
• Text Editor
• Testing & TDD
• CI/CD
• Debugging
• Web
• Mobile
• Desktop
• Smart Contracts

Introduction

Hello, Winner. You've made an excellent decision in picking up this book as part of your journey toward becoming a confident, self-sufficient software developer. There will be NO-fluff and NO-hand-waving here.

A Word of Encouragement

The world of software development can be rough. Imposter syndrome is real ... it doesn't matter if you are a software engineer with decades of experience, a junior software engineer or a student learning at a software engineering bootcamp; these subjects can be tough, but don't let imposter syndrome hold you back. The key to overcoming it is to focus on building a solid foundation of fundamental knowledge and skills. Keep pushing through and you'll soon see your confidence grow.

Chapter 1 :: Regular Expression Fundamentals

You've been lied to about "Regular Expressions"

Yeah, you read that right; you have been lied to about "Regular Expressions". They aren't as hard to understand as some make them out to be. See for yourself...

Your task is to write a program that extracts the height as a number from a string of text such as "3 FT 10 IN". The expected output of such a program would be 3.

You could write a fairly simple (naive) regular expression to do that.

/\b\d+ FT \d+ IN/gm

The above regular expression, if said in plain english would read as: "Look for a word boundary, then immediately following that word boundary, look for one or more numeric characters, then expect a single literal space character, then "FT", then another literal space, one or more numerice characters, a space, then "IN".

The power of regular expression is that you can "express" all of the above, with just a few symbols. That is why I like to think of regular expressions as a domain specific language for matching textual patterns.

That being said, the more complicated the regular expression, the more difficult it is to read, debug, or update. For example, the text "3 FT 10 IN" is fairly simple; however, what if we were required to match all of the following with a single regular expression:

• 3 FT 10 IN
• 3FT 10IN
• 3FT10IN
• 3' 10"
• 3 ' 10 "
• 3'10"

The regular expression could no longer be naive. It would have to be a complex regular expression such as:

/\b(?<nfeet>\d)+[\s]*(?<feet>FT|')[\s]*(?<ninches>\d)+[\s]*(?<inches>IN|")/gm

This is where things start to get weird. There are several places where characters are optional, and if we were to intoduce even one more variable, this regular expression goes from somewhat hairy, to completely unmanageable.

If you haven't already come across the following quote, keep progamming long enough and you will:

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

That quote has been echoed by hundreds, if not thousands of programmers over the years advising other programmers to stay away from regular expressions. This is a lie. You've been lied to about "Regular Expressions". They aren't something to shy away from. They are a tool just like everything else in software. They are to be use carefully, but not to be abused. Complex regular expressions are an abuse. By keeping them simple, they will not only do the job better than anything else, but they'll also be easy to maintain.

Keep your regular expression simple. Don't try to match everything in a single pass. The grammar for text parsers generally are broken up into tiny patterns that match the smallest unit of characters that can provide enough context to be meaningful.

Chapter 2 :: Defining the Problem / Project

...