In attempting to define progressive web apps, I always end up stumped. Across the web I find vagueness and confusion, or authoritativeness lacking citation. So I went down the rabbit hole attempting to clarify the history of the term and cite the dang thing.
➡️ Read the post: Published on Medium, cross-posted on dev.to.
Note: I plan to keep revamping this blog, but until then I’m mostly publishing elsewhere, linking out from here.
Almost exactly a year ago, I first started writing about my pivot to working full-time as a web developer (aka The Road So Far Pt I). tldr; after dancing around the edges of embracing this career (in every possible way, for my whole professional life leading up to that point), it had become clear I wanted and needed to commit. I find that reflection is the only way to take stock of progress, and a year seems like a good time to look back.
Continue reading The Road So Far Pt II
Given our understanding of what async is, how the callback pattern manages async, and some of the deficiencies of the callback pattern, let’s dive into another, newer pattern — promises.
As with callbacks, for a new developer, it can be difficult to sift through the massive amount of information available online. For the benefit of anyone else newly exposed to promises, in this post I’ve attempted to cull the resources and posts that I have found most enlightening through my own learning.
Continue reading Async patterns: Promises
So what is a callback function?
A callback function, also known as a higher-order function, is a function that is passed to another function (let’s call this other function “otherFunction”) as a parameter, and the callback function is called (or executed) inside the otherFunction. A callback function is essentially a pattern (an established solution to a common problem), and therefore, the use of a callback function is also known as a callback pattern. (Source)
Continue reading Async patterns: Callbacks
Imagine you walk into a coffee shop to get a latte. If they’re busy, perhaps you wait in line. When it’s your turn, you place your order with the cashier, and pay for the drink. The cashier writes your order — maybe even your name — on a coffee cup, and places it behind the empty (not yet fulfilled) cup of the person who ordered before you. Perhaps the shop is quite busy and there are ten cups ahead of yours. That queue of yet-unfilled coffee cups allows for the separation of the cashier (processing and queuing orders) and the barista (fulfilling orders based on the information supplied by the cashier). This queuing process results in increased efficiency and output. (The original source expands on the metaphor and is quite interesting). This is an example of asynchronous, non-blocking behavior.
Let’s talk about organizing our code. There’s never just one way to accomplish something with code. This is both great, and sort of paralyzing. How do you choose?
When self-teaching, almost all of us start at the same point. Where do I start? How do I “pick a language”? What do I focus on? I know I did.
Continue reading Resources: Getting started & beyond
There are two types of people, those who understand recursion and those who understand that there are two types of people in the world… (r/ProgrammerHumor)
But really. There seem to be people who can very naturally digest the concept of recursion, and those whose brains absolutely reject it. I happened to be one of the latter. In this post, we’ll go over recursion generally, and then work through a diagrammed problem example.
Continue reading Recursion