codyaprice.com RSS Feed

On Hobbies and Magic

Sun, 02 Aug 2020 09:57:53 GMT

Y'all ever have a hobby that seems magical? I mean something that you genuinely enjoy, and it feels like one of those books you cannot put down? Mine is photography. Specifically, my magical hobby is landscape photography.

Doped up

I recall an unmistakable jolt of dopamine when I lived in a studio apartment in Westport, Missouri. Armed with only a Pixel 2XL, I cherished moments that allowed me to capture my side projects in a crisp focus juxtaposed with a pleasant bokeh. Take a two-year scroll through my Instagram feed, and you'll find the occasional, semi-reasonably composed photo with ample bokeh abuse. I loved the portrait feature of the Pixel 2, but I rarely took headshots. I have progressed since and use it sparingly. However, my "daily-driver" continues to be that fantastic camera phone.

Many of y'all are familiar with the season where I regularly swapped between the West Bottoms and our Kansas City home remodeling project. I would joke with Kiley that I just pointed the camera while the Pixel did the real work. I loved sharing our progress with everyone, but the real joy came from each snapshot saved within my camera roll. I have an enormous cache of content that I have never shared with anyone, likely for a couple of reasons.

The first reason is that historically my primary channel for sharing has been Instagram, limiting me to ten photos per post. I don't always want to blow up everyone's feed with chains of multiple ten-photo posts. There's also some substance, integrity, and intent lost when too many things are shared concurrently. I enjoy sharing photos, but more so when the content tells a story or is mysterious or intriguing. During the remodel, I lived to hear feedback like, "You always show just enough to tease us." I hope to carry that spirit along through my landscape photography.

My photo cache grows exponentially, but I feel that it is typical with photography; you're always producing more than what you officially publish. I don't share everything because I don't think most of my photos are worth sharing; some are just terrible, while others are duplicates or perhaps didn't make the cut of the ten-photo Instagram limit. There are also limits to my daily driver. My Pixel 2 takes fantastic pictures of subjects that are close, say within 20 feet. However, anything past that proves challenging to capture any quality depth of field. The digital zoom quickly introduces noise through pixelation, and the sensor struggles with overexposure. There's no easy way to take RAW photos, which is exacerbated by the lack of expandable storage and communication dead zones. Lately, I'm more often than not left wanting more. I see something incredible that I want to immortalize, but my camera phone cannot take the picture. While I've been pleased with where the Pixel 2 has taken me, it's time to step up to a professional mirrorless camera.

PNWonderland

Bridge on trail to Trout Lake in the Alpine Lakes Wilderness

Since relocating to the enchanting Pacific Northwest earlier this year, the region has started to pour its spirit and essence into me; I am absorbing the caricature. I am a software engineer who is a fresh (and very out-of-shape) hiker that dabbles in photography. It's of no-fault because of my adventures through the captivating vistas and the fragrant and exalted pines that beg me to capture their beauty. What once was an occasional activity has morphed into an all-out passion. My downtime has turned into following every Instagram nature and photography account. I have started to watch YouTube tutorials on composition, editing in Lightroom, and tips and tricks concerning the mirrorless camera I haven't even purchased. I now work for the weekend, but only because it promises of opportunity to explore the next trail. I have three reasons to get back in shape now:

To be the best, healthiest man for my bride.
To be the best, healthiest father for my child.
To make it further into the wilderness.

Being engulfed in my pursuit means that I ignored my body and pushed myself too far. Approaching 30 means pain and being injury prone (read as: it sucks, y'all). Today, I slow down and rest and write this post while my right hip and hip flexor heal.

Circling Back

I want to circle back on something. I mentioned my downtime and what I have pursued: Instagram accounts and tutorials. These Instagram accounts have been truly inspirational, and most of them are Pacific Northwest specific. I long to take photos like them, hence the dive into photography and editing tutorials. This decision has become a double-edged sword, however.

On the one hand, I have more knowledge and tools at my disposal to take better photos. On the other, it has killed some of the magic because it can kind of feel like min-maxing. If you're unfamiliar with the term, it's generally tied to role-playing games like Dungeons and Dragons or World of Warcraft. The idea is to power up your character by maximizing specific stats and ignoring all others leaving with a glass cannon: outrageously powerful, yet brittle and unbalanced. This strategy is rather dull and flat and takes the fun out of the game.

A Short Aside

Years ago, I stopped at my grandmother's house, and cozy on the couch, she watched a movie. I don't recall why I originally intended to go there, but I remember staying for the film. It wasn't a spectacular movie, but enjoyable enough with a stellar cast, popcorn, and some quality time with grandma. The Big Year, starred Jack Black, Steve Martin, and Owen "Wow" Wilson and was about competitive bird watching. If that sounds boring, please don't close this tab or navigate away, there's a point I'm trying to make. From what I remember, Owen Wilson is the world's best bird watcher, while Jack Black is the new kid on the block trying to usurp Owen's throne. He used to be a computer programmer but hopes that bird watching is the calling that will lead to his sense of purpose. Owen, at the detriment of his marriage and plans of conceiving, obsessively pursues maintaining his title. Jack Black is closing in on Owen's title but realizes there's more to life and drops out to pursue a relationship with someone he met while birding. Owen ends up winning the title and breaking his record, but his wife leaves him.

It ends with Owen out bird watching alone in Asia and, with regret in his gaze, peering at a happy couple and child. Owen's character was a min-maxing birding over his relationship with his ex-wife and realized too late what he had lost. He let his hobby become his obsession, and he lost the meaning of everything else. Owen became disillusioned when he realized that he threw away his relationship with his ex-wife for something he presumably no longer enjoys.

Resonating

Last week, I watched a video that described how to edit photos in Lightroom, a pretty standard practice when shooting in RAW. Generally speaking, RAW images tend to look flat and require some (read as: as few as possible) edits to match what your eye perceives. I want to preface my critique. The content creator takes fantastic pictures and is successful in landscape photography. Their compositions are stunning; however, my gut and limited instinct say they tend to over-edit. Some of their photos look too good; they appear fake like a science fiction panorama complete with soft, glowing subjects and liberal use of perspective distortion and unnatural colors. I watched as they haphazardly dialed in the luminance and applied filters until the image echoed its original emotional intent. This is the spirit of min-maxing.

And that's what resonates with me.

I think I resonate with this because I want to take a purist and minimalist approach to landscape photography: beauty in simplicity. By min-maxing picture features, you reduce the art from a passion to a job. It takes the fun out of it. I don't want to min-max supposed quality at the expense of the enjoyment and love for photography. I don't want to take for granted the natural splendor of the world and ruin the magic. I appreciate and cherish it all.

God made Earth perfectly beautiful, with no filter or editing needed. Nature does not require me to interject with corrections and improvements to make a scene fantastical and appear out-of-this-world. That doesn't mean I should publish RAW photos directly. Instead, I should apply as few edits as possible to perfectly capture what God sculpted for us. In a bleak and abysmal world climate, let's keep the magic around as long as we can.

Conclusion

Photography is an art; it is visual storytelling. I intend to tell stories of the beauty and mysteries of nature. I hope to captivate y'all with the wonders of what I experience in the wilderness. I want to continue to tease you with photos encapsulating the miracles of the world.

I have thoroughly enjoyed my tour with my Pixel 2, but I feel I have pushed it to its limits, and I long for more. I cannot wait to get my hands on a mirrorless camera. Follow along, and you won't be disappointed. As always, thank you for reading.

Our Most Ambitious DIY Yet

Sun, 31 May 2020 19:31:35 GMT

Kiley and I have some BIG news 📰 that we cannot hold in any longer. We are pregnant! ❤️

We have been sitting on this, anxious to share since the beginning of April! In fact, we found out TWO DAYS before we set out on our adventurous move to Seattle. We weren't planning or expecting a baby, but we feel so incredibly blessed that a healthy baby is growing and cannot wait to meet them!

Our baby's first ultrasound!

Kiley's due date is December 10th. We find out the gender when we fly back to Kansas City for a week in mid-August. Kiley wants a girl, but my money is on a boy! #housedivided 😤

We're moving to Seattle, y'all!

Tue, 03 Mar 2020 22:42:49 GMT

I've been teasing this on my socials over the past couple of weeks. I have accepted an offer at ngrok, which means that my wife and I are moving from Kansas City to Seattle! My last day at Cerner will be Friday, March 20th, 2020, and I will start as a Software Engineer at ngrok on April 6th, 2020. I'm so stoked, y'all! 🙌

A Little Reflection

It's bittersweet, to say the least. Excluding college, I have lived in Kansas City all of my life. Hell, I remember going to Bannister Mall and visiting the Toys 'R Us as a wee tike. Those places exist no more; they are just memories that Cerner's Innovations campus now stands on.

If you know me personally, you know that I live and breathe Kansas City. The Plaza lighting ceremony is nothing short of magical 🧙‍♂️. I established a relationship with Jesus here. My wife and I were married here. We are die-hard First Fridays and Weekend Vintage Revival goers (❤️ Bella Patina). I proposed to her under the 12th street bridge in the West Bottoms 💍. Both of our families are rooted here. I've met so many kind and considerate, beautiful people here. I cried when Sporting won the MLS Cup in 2013, when the Royals won the World Series in 2015, and most recently when the Chiefs were crowned Super Bowl LIV champions. My blood is probably at least thirty-percent Jack Stack beans and the rest an amalgamation of BBQ sauce and Thou Mayest, Blip, and Messenger coffees. Without a doubt, I will miss all of these loKCal gems. At the same time, I am thrilled about what's to come. Neither my wife nor I have been to the Pacific Northwest before. We've been assured that it's gorgeous. And we cannot wait to embark on this adventure together!

Regarding the Local Behemoth

My work life at Cerner has been nothing short of a blessing. I have been afforded so many opportunities to grow professionally. As I've said before, my background was not in web development. Right from the get-go, I was placed on one of the best teams in the HealtheIntent organization. I learned JavaScript, React, HTML, CSS, and so many other technical skills throughout my tenure. It has been a huge stepping stone for my career.

It's sad to say goodbye to my current team, and I will miss them immensely. My manager is incredible, and my teammates are such a joy to work with (even the ones that can be... challenging. You know who you are 😂). I wish everyone the best going forward and will miss the Fika.

Am I good enough?

Wed, 12 Feb 2020 23:26:59 GMT

opportunities.reject { |person| person.is? :cody }

How do you handle rejection?

What do you do when something you've been working for and betting on ends in failure? How do you react to disappointment and a discouraging result?

I was on the receiving end of one of these situations today. This was something I had been preparing for and practicing over the past month and a half. This was an assessment that I did not pass. Allow me to journal for a moment and pour out my feelings.

I mixed emotions right now

To be honest, each of these competing emotions is fighting for the spotlight. At any given second, one wins out.

On the one hand, I want to sulk. I want to be sad and recognize my sadness. I want to be heard and understood by how I feel. I want to meditate on why I was not good enough. I feel like an imposter. Am I good enough? Are they right?

On the other, I am finding that fire burns within me. I know that I am good enough to pursue my passions. I know that I am beautifully and intelligently made with purpose and perfect intent. There is a time and a place for everything.

I cannot dwell

I know the path forward, but I need to be patient. My self-worth is not a function of what has happened. The process takes time. I'm going to take the night for introspection, but I cannot help but see this situation as a gift and an opportunity. I have my faults and my weaknesses, but they will not hold me back.

But he said to me, "My grace is enough for you, for my power is made perfect in weakness." So then, I will boast most gladly about my weaknesses, so that the power of Christ may reside in me.
2 Corinthians 9 (NET)

So yes, I am good enough. And I will be back.

Big O(no) ...tation

Wed, 22 Jan 2020 00:21:14 GMT

I felt inspired because of this twitter thread to make a dedicated post on Big O notation and what it means for runtime and space complexity.

TLDR: Big O notation, the "easy" way: Big O describes how things scale by their inputs, for both time and space complexity.

Commit this to memory: it only depends on your inputs.

It's dealing with growth. Just because a function is O(n²) doesn't necessarily mean that it's slower than O(n) or O(1). All that it means is that O(n²) grows much faster than O(n) or O(1).

As a consequence, Big O allows us to compare the scalability algorithms, even if they're completely different!

Technically speaking 🗣

So, technically speaking, the above introduction and TLDR is mostly true. The academic definition of Big O is an upward bound on growth. That means that a constant runtime algorithm is also both Big O linear and Big O quadratic. There also exists a lower bound, called Big Omega, labeled Ω, as well as the combination of O and Ω, Big Theta, or Θ. But, let's not get caught up in the academic details. In practice and industry, when we say Big O, we mean the lowest upper bound. So, if an algorithm is linear, we don't say that it's exponential because that's silly! If you want to dig more into the nerdy bits, there's a wiki article on it (but you don't need to 🙈).

Space vs. Time Complexity

Big O can help describe the growth of both the time and space complexity of an algorithm. By the time, I mean the amount of proportional time it takes to run the algorithm given the input. This can also be interpreted as the number of operations given the size of the input. By space, I mean the extra space needed to hold stateful information to perform the algorithm given the input. Depending on the circumstances and constraints of the algorithm, you can sometimes tradeoff time for space and vice versa. This is a common approach in many algorithms, especially in dynamic programming, which I'll have a new blog post on soon!

The most common Big O orders of algorithms that you will find, in orders of growth rate from low to high, are:

constant: O(1)
logarithmic: O(log n)
linear: O(n)
linearithmic: O(n * log n)
quadratic: O(n²)
exponential: O(2ⁿ)
factorial: O(n!)

Here's a graph of the growth of each of these from Wikipedia. This shows what each order tends to as they approach larger n inputs.

Graphs of common orders of growth showing the number of operations N versus input size n for each. By Cmglee, CC BY-SA 4.0

I'll be diving into more detail soon on what each of these means, mostly in terms of time complexity below. But first, let's take a look at some comparative runtimes between all of the above orders. This picture comes from the Algorithm Design Manual, 2nd Edition:

Figure 2.4: Growth rates of common functions measured in nanoseconds. (pg. 50)

That picture is incredibly helpful for putting numbers to different common orders of Big O. For a little more context, each operation takes 1 nanosecond. To get the calculated runtime, you use the n on the y-axis with the formula on the x-axis to calculate the operations, then multiply by 1 ns per operation.

Notice that for n² and less, you don't notice a major difference until n = 1-10k items. But for exponential and factorial growth, it matters real quick!

Tweet: Bruce Dawson (@BruceDawson0xB) April 22, 2019

O(n²) is the sweet spot of badly scaling algorithms: fast enough to make it into production, but slow enough to make things fall once it gets there

Also, notice that at large n (10,000+), the size of larger orders trumps lower ones. Bigly! This is why you can drop all terms except the dominant (largest, highest growing) ones when categorizing an algorithm's Big O notation! For example, if you calculate that your algorithm runs at O(100 + 5n² + 3n), we say that it's an O(n²) algorithm. Notice that I also dropped off any constants too because they don't matter as well! We classify O(3n²) the same as O(10000n²) because, at large n, the n² will dominate the leading constants. It also makes the equations simple n' pretty! 💃

Common Orders: What They Mean With Examples

For now, let's focus on O(1), O(n), and O(n²). What kind of algorithms does each of these map to?

Constant: O(1)

Constant time and space complexity: the time/space does not grow with the input.

Time Complexity

Constant time access O(1) is what it takes to access an array element by index, or a hash map by key. It's constant. In other words, it doesn't matter how big the array or hash map gets, those operations are always constant time access.

Space Complexity

If you need to allocate the same amount of things regardless of input in your algorithm, then you have constant space complexity, or O(1). Notice that just like time complexity, the additional space needed does not grow when the input size grows. An example of this is holding primitive values as variables in your code, like:

const time = new Date().toString(); // a string literal, independent of any input
const count = 100; // an integer literal, independent of any input

Linear: O(n)

Time Complexity

For O(n), think about an array of items again. Let's say you wanted to print out every element. What does that mean? Well, you have to access every element (which happens in constant time O(1)), but there are n elements in the list, so this is an O(n) algorithm. Stated another way, it takes longer to print out the array when there are more items in the array (and specifically, this is a linear relationship). For every new item you add to the list, the time to print out the whole list grows by one. This is also the best conceivable runtime (BCR) for that: you cannot do better than O(n) for printing all elements of an array _because you have to touch all n items in the list.

Space Complexity

Say you want to write an algorithm that reverses the order of a list using a stack, which is a first in, last out list. This could look something like:

function reverseList(list = []) {
  const stack = new Stack();
  list.forEach((item) => stack.push(item));

  let reversedList = [];
  while (!stack.isEmpty()) {
    reversedList.push(stack.pop());
  }

  return reversedList;
}

The stack used grows proportional to the size of the given input list. It grows linearly with the input list size, so we use an extra O(n) space! What's the runtime of this algorithm? ¹

Quadratic: O(n²)

How about O(n²)?

Time Complexity

Well, let's say you want to print out every element of a 2D array (or grid). The grid is sized at M x N (rows x columns). So, this operates just like a single array sized M, but now you have to print out N of them! So, the generic runtime of printing out a 2D grid is O(M * N), but if M = N (if the grid is a square, e.g. 4 x 4), then you have N * N == n², or O(n²). And again, the BCR here is O(n²) because you have to touch every element in the grid and there are N * N of them.

Let's try an example!

function doSomeGridWork(grid, rows, columns) {
  for (let row = 0; row < rows; row += 1) {
    for (let col = 0; col < columns; col += 1) {
      for (let k = 0; k < 100000; k += 1) {
        console.log(`k = ${k}, grid[${row}][${col}] = ${grid[row][col]}`);
      }
    }
  }
}

What's the runtime of this code? ²

Space Complexity

Quadratic space complexity is similar to linear space complexity. If you have an MxN 2D grid, but use something like a queue or stack to keep track of all unprocessed cells, then you will need to store O(M * N) items. The space required in the storage grows proportional to O(n²).

Let's circle back to the other runtimes: O(log n), O(n * log n), O(2ⁿ), and O(n!). These are a little more complex but still fairly straightforward.

Logarithmic: O(log n)

Logarithmic growth is very slow-growing, nearly comparable to constant.

Time Complexity

Let's say you wanted to find an element in an array. How long should it take? Well, it depends. Are we talking a sorted or unsorted list?

If unsorted, you can't tell the order, which means you have to scan the array till you find the item you're looking for, if it exists. So, this is linear O(n). But, can we do better than that? Well, not if it's unsorted.

However, if we have a sorted list, we can use a binary search, which only takes O(log n) time. Binary search cuts the array in half each time and finds the middle element. If the middle is what you're searching for, return that index. If what you're looking for is less than the middle, look in the left half of the sorted list, else look in the right half. By cutting down the array by half each time, this produces a logarithmic runtime, or O(log n). It's a very slow-growing algorithm which means that it's very fast. You can tell if an item exists in a list of 1 BILLION items within 30 searches. Crazy! That's 30 vs 1B searches in the worst case!

Space Complexity

For the binary search, you can do it with an iterative approach, like so:

function binarySearchIterative(sortedList = [], key) {
  let start = 0;
  let end = sortedList.length - 1;

  while (start <= end) {
    const middle = Math.floor(start + (end - start) / 2);

    if (sortedList[middle] < key) {
      start = middle + 1;
    } else if (sortedList[middle] > key) {
      end = middle - 1;
    } else {
      return middle;
    }
  }

  return -1;
}

This runs in logarithmic time, but has constant space complexity. You can also use recursion to perform binary search:

function binarySearchRecursive(sortedList = [], key, start, end) {
  if (!sortedList || !sortedList.length || end < start) {
    return -1;
  }

  const middle = Math.floor(start + (end - start) / 2);

  if (key === sortedList[middle]) {
    return middle;
  } else if (key < sortedList[middle]) {
    return binarySearchRecursive(sortedList, key, start, middle - 1);
  } else {
    return binarySearchRecursive(sortedList, key, middle + 1, end);
  }
}

This also runs in logarithmic time. However, when it comes to space complexity, this is O(log n), can you tell why? ³

Linearithmic: O(n * log n)

This comes into play mostly with sorting: e.g. merge sort and quicksort. Both of these operate on n items in a list (hence the first n term in n * log n). But, what about the log n term? Well, that comes into play by borrowing the cut the array in half method from binary search. Take merge sort, for example. You keep dividing the array down until you have sorted subsections, which takes O(log n) time for log n sections, followed by merging them back together in O(n) time.

Exponential: O(2ⁿ)

Exponential growth is very easy to get caught in when using recursion if you ain't careful, especially with binary trees. The inverse of O(log n). This will make more sense when you get into binary trees, but if you keep doubling your size as N increases, you grow very fast. Think about the powers of two and how fast they grow (doubling):

2⁰ = 1
2¹ = 2
2² = 4
2³ = 8
2⁸ = 256
2¹⁰ = 1024
2²⁰ = 1 million
2³⁰ = 1 billion

Notice the exponent cleanly matches with the number of times you need to search in binary search!

Factorial: O(n!)

This is kind of hard to achieve, honestly... But it grows super freakin' quick and is ultra mega double-plus bad! Looking back at the table at the start of this post, at n = 20, it takes 77.1 years to calculate 😳🤯!

Conclusion

In practice, algorithmic time and space complexity follows common patterns that I have outlined in this post. Big O notation is simply a way to describe them in a way that is independent of environmental or system factors. I hope this has been helpful! Please comment below if you have any thoughts or questions and be sure to share on your favorite social media too! Thanks for reading! 👋

The runtime of this algorithm is linear, O(n). While we do loop list.length times twice, remember to drop the leading constant! As in: 2*O(n) becomes O(n).

If you said O(n³), then you are...incorrect! The answer is: O(n²)! How's that so?! Remember what I said at the beginning of this post?

[Big O] only depends on your inputs

The inner-most for loop runs the same number of times independent of the input. In our case, it will always run 100000 times. So, you can think of that as one incredibly slow operation that always runs the same number of times, even if rows and columns are small! This one is a tricky lil' curveball for sure! ⚾️

The recursive binary search algorithm has logarithmic space complexity because it uses recursion. With recursion, you get a "free" stack, the calling stack, which is used on each function call. Since the algorithm calls itself at most log n times, the stack will have at most log n entries on it. This space usage doesn't come for free, so you have to be aware of it and account for it! If you recurse too much, you can cause a stack overflow!

Plans for my site and content going forward

Sat, 18 Jan 2020 15:27:20 GMT

And no, this ain't a 'going away' post, y'all. I just wanted to provide an update on where I want to take this site within the foreseeable future.

Index /

For the homepage of my site, I would like to do something new, rather than just a slightly different /blog. The layout of this site is a derivative of the gatsby starter blog template. I have deviated from it over time, but I just haven't put in the time to design something better and customized to what I want. Ideally, it would just highlight the latest content, whether a blog post or a project with a short snippet of my /about page. This leads me to my next plan...

Instagram

If you're new here or unaware, I have a lot of physical side projects (e.g. fixing up my house) in flight and I post updates on my Instagram. I want to transition away from using Instagram as my content hosting platform for multiple reasons. It all boils down to being able to own my content.

In addition to hosting it myself, I want to be able to tell a story or describe what's going on in my mini-albums. I say mini-albums because instead of posting lots of individual photos, I like to group them under one post, like this one. The problem is, Instagram limits you to a maximum of 10 photos/videos per post. This leads me to a common scenario of having to pick the best 10 of many photos. It can be difficult to do this, especially when I want to show some context or scene that cannot be encapsulated within 10 items. Also, I want to be able to caption individual photos.

Will this hurt my discoverability? Sure. But, I doubt I'm getting that many impressions from Instagram hashtags. Who knows, maybe I'll just crosspost for a while and link directly to my site's posts.

Going forward, when I get around to building the infrastructure and UI, I will be hosting this content under /projects. Or maybe I'll separate out physical projects from digital ones... Who knows! I'll be a good engineer and iterate on it, but also be sure to provide updates as things change.

Blog Backlog

Up until now, I have been using the mobile and desktop note-taking app Bear to keep track of my blog post backlog. While it's great for taking notes, I find it lacking for this purpose. Sure, I can tag items with #blog and #blogpost, but as time has gone on, the amount of posts has grown past what the app is made for.

For starters, by default, it sorts based on last touched/edited. This is fine for notes (which I still take on the app), but not for blog posts that I want to sort in many ways. It's also difficult to mark posts as "done", figure out duplicates, and determine how many things are in my backlog (minor).

So, going forward, I will be using GitHub issues to keep track of my backlog (like a good ol' JIRA queue). This will allow me to still use tagging and descriptions, but also expose a pseudo-schedule of what's coming up. And, I will be able to support writing requests this way too (if any of y'all have any 🤷‍♂️). It will also be nice to have the schedule/backlog local to the site source too. Maybe this will hold me accountable as well!

If you want to submit a post request, you can here.

If you're curious about what's in my blog post backlog, you can find it under this milestone and this project. I will be migrating from Bear to GitHub over the coming days/weeks/<insert-timeframe-here>.

The rest of the site

I still need to finish the other two locations on my site: /essays and /about. Truth be told, I do not know what I will put under /essays that will be different than /blog. When I started, I loved and took inspiration from James Sinclair's site.

As for the /about, I'm not sure exactly what I want to put there. I mean, I do know, but it's kind of like when someone puts you on the spot during an icebreaker:

So, tell us about yourself!

Mind proceeds to go blank.

Last, but not least, I need to finish out the UI and infra when you click on a TAG.

Conclusion

Stay tuned! There's a lot of things to come.

👋

someTruthyVar && "A new post on boolean coercion"

Thu, 09 Jan 2020 23:03:56 GMT

~~Click now~~ Keep reading to see the beginner's guide to what computedValue && "One Truthy Boi" evaluates to!

To truthy, or not to truthy?

Let's do a little code experiment. How does the value of computedValue affect what the expression computedValue && "One Truthy Boi" evaluates to? Well, let's take a gander in ${insertYourFavoriteJavascriptConsole} (I'll run mine in the Chrome browser console).

When computedValue is truthy:

let computedValue = true;
let result = computedValue && 'One Truthy Boi';
console.log(result); // "One Truthy Boi"

Versus when computedValue is falsey:

let computedValue = false;
let result = computedValue && 'One Truthy Boi';
console.log(result); // false

And to prove it, a screenshot of it running:

Console output of running the above code snippets.

Strange. So, result will either be false or "One Truthy Boi" depending on what the left-hand-side of the && boolean operation evaluates to. Interesting... 🤔

Why this is weird to me

It turns out this is a pretty standard feature in dynamic languages like JavaScript, Ruby, and Python. However, if you're coming from the land of types, this is... odd. To understand why let's take a look at a little history...

Normally, when performing (left expression && right expression), you're checking for a true or false evaluation, like in a conditional expression for an if/else block. This is called a boolean expression and evaluates to either true OR false (two values only; one or the other, not both).

In the ~~ancient manuscripts~~ C language, boolean primitives weren't a thing until C99. By that I mean you couldn't assign a type of bool_t to a variable before C99. Before the boolean types were added, other things acted as true and false. Instead, boolean operations were done on integers, where 0 is false and any other number is true.

Similarly, in dynamically-typed languages, many things can act as true and false, even though they aren't literally true or false primitive values. The expression true && "not a boolean" works in dynamically-typed languages because true is, well, true and "not a boolean" is truthy. And by truthy, I mean that it ain't an empty string ""!

A few more examples of...

Truthy things:

non-empty arrays (in JavaScript)
non-empty strings (in JavaScript)
anything non-nil in Ruby, including 0! 😳

Falsey things:

Empty strings (in JavaScript)
Empty arrays (in JavaScript)
nil, null, undefined

But here's the kicker: in C, boolean expressions are just that: boolean, one of two values.

You can tell that it's a boolean because of the way that it is.

In other words:

if (boolean_expression) {
  // run this code if boolean_expression == TRUE
} else {
  // run this code if boolean_expression == FALSE
}

But, the astute reader will notice that, for the typical dynamically-typed language, our boolean expressions evaluate to... anything! (Kind of...)

What's going on here?

Let's look at a quick example:

const leftHandSide = 'some value here';
const rightHandSide = 'One Truthy Boi';

const result = leftHandSide && rightHandSide;
// result = "One Truthy Boi"

In this case, the dynamically-typed runtime is coercing the left-hand side of the boolean expression into a boolean value, like:

const leftHandSide = 'some value here';
const rightHandSide = 'One Truthy Boi';

if (Boolean(leftHandSide) === true) {
  return rightHandSide;
} else {
  return false;
}

This is mostly true, but we'll clarify how it actually works next. The main thing to take away is that if the leftHandSide expression evaluates to false, then a falsey value is returned. Let's take a deeper look.

So far, we've only looked at && (AND), but there's also || (OR) and ! (NOT). According to MDN on logical operators, each of these behaves like the following:

Logical AND: expr1 && expr2
- If expr1 can be converted to true, returns expr2; else, returns expr1
Logical OR: expr1 || expr2
- If expr1 can be converted to true, returns expr1; else, returns expr2
Logical NOT: !expr
- Returns false if it can be converted to true; else, returns true

Take my word for it, but Ruby boolean expression behave pretty much identically.

So, did you catch it?

There's a big difference in what I, coming from a strongly typed background, would expect versus what the actual boolean operation defines:

In the case where the expression short-circuit evaluates, instead of returning a boolean literal (i.e. true or false), it returns the value that forced the short-circuit path, e.g. undefined && true returns undefined instead of false

This is why in the original example we saw computedValue && "One Truthy Boi" return either false or "One Truthy Boi".

This is also why, in React, you can short circuit return jsx like:

function Example() {
  const [showGreeting, setShowGreeting] = React.useState(false);

  return (
    <div>
      <button type="button" onClick={() => setShowGreeting(!showGreeting)}>
        {showGreeting ? 'Hide greeting' : 'Show greeting'}
      </button>
      {showGreeting && <p>Hello there! 👋</p>}
    </div>
  );
}

Conclusion

There's an immense amount of flexibility gained from operating as dynamically-typed languages do. Often though, it can produce surprising results if you're not careful. Usually, it works out well, but there are cases where short-circuit evaluation of boolean expressions (logical operators) can produce unexpected results.

I'll leave you with an example. Take for instance the following React code. What do you think happens when list.length === 0? Have a look for yourself below 👀:

function Example() {
  const [list, setList] = React.useState([]);

  function addItem() {
    setList(list.concat(list.length + 1));
  }

  function clearList() {
    setList([]);
  }

  return (
    <div>
      <p>List length: {list.length}</p>
      <button type="button" onClick={addItem}>
        Add One
      </button>
      <button type="button" onClick={clearList}>
        Clear List
      </button>
      {list.length && (
        <ul>
          {list.map((item) => (
            <li key={item}>{item}</li>
          ))}
        </ul>
      )}
    </div>
  );
}

List length: 0

Planning to fail

Tue, 07 Jan 2020 18:43:26 GMT

Planning may be valuable, but the plan is worthless the moment it is created.

Ah, here we are again. 😏 New year, new... quarter. New quarter, new... planning cycle. New planning cycle, ~~new...~~ same old, archaic process to appease the ~~gods~~ management.

From my perspective, as a developer, four things bother me about quarterly planning, especially so in E N T E R P R I S E:

Big Room Planning, aka BRP
Plans are consistent
The weeds 🌿
The 70% mark

This article perfectly sums up my main issues with scaled "agile" planning, but I want to focus on my experience. I'll air my grievances below. 👇

Please don't BRP at the table, it's impolite!

So, big room planning. It's this "wonderful" two days at the beginning of each quarter where the entire organization crams into auditoriums and meeting rooms to ~~fight to the death~~ plan for and commit to client requests. At a glance, it sounds great.

The problem is, it's chock full of rigid processes, structure, and bureaucracy.

We plan because planning is valuable. Without a planning phase, we wouldn't be able to meet the business needs, opportunities, and priorities of our clients.

However!

The plan. The one that is committed to should be thrown out as soon as you create it. Maybe that's a bit harsh. At the very least, it should not be as rigid as it is.

Here's the thing: as time goes on (as it tends to do 💅), priorities shift, things come up, and requirements change. Maybe your client decided they don't want a racecar?

What's dope is that through agile development practices, you can meet their new needs, requirements, and/or problems head-on as opposed to being locked in.

The plan is a high-level, coarse-grained, hand-wavy pass that only has a value at the moment of inception. And that's because...

Plans are consistent(ly wrong)

Let me paint you a picture. 👨‍🎨

Morning scrum. The air is thick and uncomfortably familiar. It's halfway through the third sprint of the quarter and your product manager is trying not to overdose on anxiety medication. You hope they're doing alright, but you know their manager is barking at them to corral their ~~resources~~ engineers. It's nearly your turn in the speaking rotation and you know what's coming. Your neck hair is alert, knees weak, arms heavy 🍝. As you explain why you're four days rolled over from the estimate, your PM lets it out:

"What's taking so long on X? Are you blocked by something or someone? Do I need to log a R I S K?"

To them, you are behind. Well, you're not behind, but according to the plan you are. If only they understood that development ain't linear...

Does that sound familiar? If not, bless your heart. ❤️

The thing about plans and estimates is that they are consistently wrong about 90% of the time. I'll be honest, I pulled that percentage out of my gut.

The fact of the matter is that you cannot account for what happens in the future, no matter how hard you try. This is especially true when you have external dependencies on other teams or, as my manager so eloquently put it, you're building the plane as you fly it ✈️.

Go ahead and pad your estimate with an extra ten, thirty, or fifty percent. It's still wrong.

Go ahead and try to break your task down into pieces as small as possible. Estimate each of those pieces. It's still wrong.

Don't believe me? That's fine. Let's try to estimate the complexity of tasks.

We're getting lost in the weeds 🌿

How can I plan for something if I don't know the inner details?

Here's a scenario that pretty much played out verbatim this morning (I've anonymized it):

"Hey, so do you think you can do X?"

Well, that depends on the scope of X.

"Cool. So you can? Do you have any concerns?"

Well, I do have some concerns. I see Y and Z as bottlenecks. Can we talk through that?

"Hey now, we're getting into the weeds, don't you think? Are you confident we can commit to this?"

For 🤬sake!

And we wonder why "things come up" or "never go as planned"? How can I confidently plan for something if I don't know the inner details? No, I'm not suggesting I know every fine-grained detail. On the contrary, I just want to know more than just the hand-wavy requirements because, as they say, the devil is in the details 👿

During planning, we should aim to align ourselves with the intent to design and implement the solutions to the problems the client has at this time.

And if the client changes their mind? Not if, when. When the client changes their mind, adjust because you're agile.

The 70% mark; Or, 70% of the time it fails every time

In my organization, there's a division that produces patient-facing applications. I used to work directly in this group and one of their mottos during planning was to only commit to 70% of your capacity.

As a developer, your capacity is an imaginary metric that determines how much stuff you can implement over a given period, generally a quarter. So, let's say you can complete 10 units of work. You're only supposed to commit to 7 units of work because the remaining 3 units, or 30%, are to be allocated to "the unknown" (which includes PTO, sick days, unforeseen events, etc).

So, we're back to padding estimates? 😅

Here's my issue with the above ~~rule~~ suggestion (and I don't mean for this to sound as aggressive and abrasive as it may end up). So far, management has linearly distributed all 10 units of work throughout the quarter. In other words, the first 70% of the quarter is design and implementation and the last 30% of the quarter is free space for no-op stuff. This isn't explicitly stated anywhere, but it is reflected in the JIRA dashboards and charts that track quarterly progress.

When you're "behind" it could be because you took two weeks of PTO at the beginning of the quarter. Or because you got sick and your JIRA sat in the "in progress" column for two or three days without any development. Or because last week a production incident brought down critical infrastructure so you had to shift priorities mid-sprint and shelve your in-progress JIRA.

If you're going to shave off 30% of capacity, you cannot assume it will be equally distributed throughout the quarter. Also, who are we kidding with this capacity metric? 🤔

Conclusion

As it stands, I strongly dislike the planning week. It feels like a waste of time past the initial hour or two of the first day.

Going forward, I would love to approach planning differently. Luckily, this time we were able to deviate even though we're still tied to the bureaucracy and paperwork 🤙.

Instead of the churn and burn, let's maintain a priority queue backlog of work. Planning should be a continuous process, like recurring scrum and retro meetings. A priority queue is great for this because it's not an immutable source of truth. If a task shifts priority, the queue adjusts accordingly, and thus we do too. That's true agility.

And please, let's skip the estimations because they're never correct.

Cool UI Tricks: Pointer Event Passthrough on my Site's Primary Navigation

Fri, 20 Dec 2019 01:18:49 GMT

"You have to be transparent so you no longer ~~cast a shadow~~ block clicks but instead let the ~~light~~ clicks pass through you" - Kamand Kojouri...ish

Post Mortem: Or, Hey Friends 👋

Look. 👀 I really tried to keep this article short and sweet. But, I failed. It may seem long (because it kinda is 😬), but stick with me! It's worth it, trust me. 🤞

Also, you can skip around if you already know some parts or if you ain't interested in the juicy deets. 💅

Ight imma head out. 🧽🚶‍♂️

Back to the post.

What's up Cody?

I recently updated my primary navigation. You know, this thing:

Primary navigation, with minor annotations.

Underneath the primary navigation is a stripe inspired header. Inside the clipped header is a <canvas> element that renders a starry background that you can interact with through hover and clicking. Hovering produces a "brightening" effect on stars adjacent to the mouse, like so:

Navigation mouse hover animation

And clicking allows you to "blow up" the stars, blasting them in all directions:

Navigation mouse click interaction

The Problem

The navigation is rather delightful to play with. Unfortunately, you originally could not click or hover on the region between my name and the navigation links.

Call my navigation Sprint because this was a dead zone, my friend. 🤙

Even though there doesn't appear to be anything between my name and the list of links, pointer interactions fail to register!

The navigation blocks any interactions with the stars! 🙅‍♂️

Bummer! 😢

How do we fix that!? 🧐

Interactive Example Time ⏰

Let's play around with some interactable examples! In each example, you can click and hover on things within the dashed boxes. I've created a mock navigation header that loosely resembled the primary navigation on my site. Think of it like if you turned the graphics settings way down.

For this first example, I want to demonstrate the way my navigation originally worked; or, what happens when the navigation blocks interaction as if there's an invisible wall.

As you click on items, the "Last clicked" element will update to display what you last clicked on. You can do the following:

The background is both clickable and hoverable
The avatar circle is both clickable and hoverable
The navigation region is clickable
You can toggle on/off the visibility of the navigation bounds (note: this does not remove them entirely; they are still rendered, but will just be completely transparent or invisible)

Isn't it odd that there's a central region where an interactivity dead zone exists?

Show navigation bounds?

Last clicked: nothing

What Went Wrong

The above behavior is unsurprising if you're familiar with DOM flow and stacking contexts. But, to the average person, it provides a bad user experience because it breaks the Principal of Least Astonishment. You would expect the starry background in my primary navigation to be interactable in all of its rendered regions. It is jarring to experience that "invisible wall". I want to explain more on why this wall exists, but first, here's the same example from above, but now you can also toggle on/off the "invisible wall's" "presence".

Show navigation bounds? Remove "invisible wall"?

Last clicked: nothing

When the navigation bounds are visible, but we remove the "invisible wall", the background can receive our click!

Still image: The click passes through the navigation region and registers on the background!

How it Works

TLDR: pointer-events!

There is a CSS property called pointer-events which allows you to manipulate if a DOM element receives pointer events (e.g. clicks, hover, etc). If you set it to none, then that element and all of its children will no longer process pointer events!

🤯

Let's look at the simplified DOM of my navigation with minimal styling using emotion, an incredible css-in-js library:

/* top level element sets pointer events to none */
<div css={{ pointerEvents: "none" }}>
  <div css={{
    display: "flex",
    alignItems: "center",
    position: "relative" {/* 👈 this is important */}
  }}>
    {/* The starry background 👇*/}
    <div css={{ position: "absolute" }}> {/* 👈 this is important */}
      <canvas>✨</canvas>
    </div>
    <nav
      css={{
        display: "flex",
        justifyContent: "space-between",
        position: "relative" {/* 👈 this is important */}
      }}
    >
      {/* manually enable pointerEvents for all children after here */}
      <a href="#" css={{ pointerEvents: "auto" }}>
        Cody A. Price
      </a>
      <ul
        css={{
          display: "flex",
          listStyle: "none",
          margin: 0,
          pointerEvents: "auto"
        }}
      >
        {/*
          These will inherit `pointer-events: auto;`
          from the parent <ul> by default
        */}
        <a href="#">Blog</a>
        <a href="#">About</a>
      </ul>
    </nav>
  </div>
</div>

Notice that we turn off all pointer-events on the parent element and then selectively turn pointer-events back on for specific children.

If you're saying I play favorites, you're wrong. I love all my children equally.

Unpacking it All

There's a lot to unpack here, so let's get down to business.

Let's get down to business!

We need to talk about DOM flow, the box model, positioning, and stacking contexts. Be warned, I am going to gloss over a lot of the details because these topics deserve a post in themselves. There's a ton of nuance at play, so readers ye be warned 🏴‍☠️, but please bear with me 🐻. Each one is tightly coupled to one another because it is how layout is performed in your browser! Feel free to skip this section (or any of the sub-sections) if you're up to speed on these topics.

Also, keep in mind that this section is pure background information. You don't need to read it, but I highly suggest that you do! It's informative and has some cool and insightful interactive examples. 🤓

Skip link

The Box Model
DOM Flow
Positioning
Stacking Contexts

For everyone else, let's go! 🏌️‍♂️ First, let's talk through the box model.

The Box Model

The boxing model, probably a derivative of or adjacent to border-box 🥁🤷‍♂️😂

In HTML and CSS, everything is a box or rectangle (even circular things)! You can manipulate each box's size, position, and presentational styling using CSS. According to MDN's box model docs:

Every box is composed of four parts (or areas), defined by their respective edges: the content edge, padding edge, border edge, and margin edge.

MDN's Box Model Graphic

You should also be aware of the difference between inline or block elements. What's described above is directly applicable to block elements. MDN also has a great doc on inline vs block flow, but the main takeaways are that inline elements:

They are only as big as they need to be, e.g. all of the words or text in this post! Think of them as a box, but shrinkwrapped up nice and tightly to take up as little space as possible.
When placed next to one another, they "flow" together in the document's text direction, e.g. left to right. Think about how words flow together within a paragraph.
They are still "boxes", but you can't determine their size directly. Instead, it's inferred from how much "stuff" is inside them!

Lastly, for understanding the box model, let's go through an interactive example of box-sizing. In the following rendering, you can change the properties of each box and see their size and visual properties update in real-time. It should give you a good idea of how the box model works in general!

Background color: Border color: Border width: Color: Height: Padding: Width:

Note: 1rem === 16px

Summary

Content Box

Height: 0 px

Width: 0 px

Border Box

Height: 0 px

Width: 0 px

Content box (initial & default value)

Border box

Box Model: The Takeaway

With HTML and CSS, it's boxes all the way down! Even if it doesn't appear that way, everything is a box. This is part of why the navigation box originally blocked inner pointer interactions!

Next, we're drifting into DOM flow. 🌊

DOM Flow

For starters, there's normal flow, which MDN says is:

Normal flow is how the browser lays out HTML pages by default when you do nothing to control page layout.
Note here how the HTML is displayed in the exact order in which it appears in the source code, with elements stacked up on top of one another

By default for English locales (bear with me 🐻, I'm glossing over a lot of details), the markup is rendered from left to right, top to bottom. We've already touched on this briefly above in the box model section. Now, you can stack elements on top of one another visually with CSS, namely through positioning and the use of stacking contexts. Conveniently, these are the two upcoming sections!

DOM Flow: The Takeaway

Without changing any CSS, elements will render in the order that you define them in the DOM (your code).

Now, let's position ourselves to understand the remaining two sections.

Positioning

Position yourself well enough, and circumstances will do the rest
Mason Cooley

If you ever find yourself wanting to do interesting things with a website (read as to make it pretty and not look like it came out of 1995), then styling paired with positioning will probably be of interest to you.

By default, DOM elements will be rendered with position: static;. You don't need to set this, the browser will do it for you! All it does is makes the element participate in its normal layout behavior, e.g.

<h1>Mr. Booshded Neynaleavun</h1>
<p>Date: September 11, 2001</p>

will behave identically to:

<h1 style="position: static;">Mr. Booshded Neynaleavun</h1>
<p style="position: static;">Date: September 11, 2001</p>

even though we've explicitly "positioned" (but, we haven't 😉) both elements!

I must sound like a broken record, but again, MDN comes in clutch with amazing docs on positioning. I'll summarize the main points below. We've already talked about static (or default) positioning and while it has its place, it can be rather boring. In the upcoming subsections, I'll explain the gist of relative, absolute, and fixed positioning. I'll leave out position: sticky for now, just so this post doesn't become a full-on DOM layout rendering 101 tutorial 😂.

Top, Bottom, Left, and Right

When set, these properties are used to offset an element from its normal position. This will make more sense in upcoming examples, I promise. Read on! 📖

Relative Positioning

Relative positioning can take a second to wrap your head around, but once you get it it's really neat.

So, remember howstatic positioning just means "Hey browser, put me where I fit"? Well, relative positioning behaves the same.

Until you set top, right, bottom, and/or left.

When you set one or more of those properties (assuming to a non-zero, default value), then the position: relative; element will shift in the direction you told it by the amount you told it to!

Here's an interactive example to drive this point home. Try setting the top field to -4rem, for example. What do you see? 👀 What happens if you turn off position relative, but still set one of the positional properties, e.g. top?

Use position relative?

Top:
Right:
Bottom:
Left:

Background color: Color:

Note: the movable element below will appear below these form elements on purpose 😉

Dolor quis excepteur dolor cillum ipsum cupidatat incididunt tempor non cillum anim irure occaecat.

Move me around!

Fugiat velit est proident nostrud consequat est quis excepteur exercitation exercitation labore.

Note: positioning direction with top, right, bottom, and left follows a potentially confusing pattern. If you give one of those properties a positive value, it shifts the element in the opposite direction, e.g. top: 10px will not move the element UP 10px, but instead DOWN 10px. Negative values shift the element in the specified direction, e.g. top: -10px will move the element UP 10px.

Notice that the Move me around! element appears to hover over other elements (except for the form elements 😉). This is a cool side-effect is of setting position: relative;: you get a z-index for free. It's really z-index = 0, but it becomes and appears positioned above static elements! This will come in handy down below in the stacking contexts subsection.

Absolute Positioning

Only a Sith deals in absolutes.

Unlike relative, an absolute element no longer exists in the normal DOM flow. Instead, it is bound to its containing element. The containing element is determined by a fancy algorithm described here. Basically, for position: absolute;, the containing element is generally (here comes ~~dat boi 🐸~~ the nuance) nearest ancestor whose position is not static. If one doesn't exist, it becomes the initial containing block, which is the block that contains the documentElement, or the <html> tag. The initial containing block has the size of the browser viewport.

As is tradition, here's an interactive example! 💃 Which element is the containing element of the position: absolute'd one?

Use position absolute?

Top:
Right:
Bottom:
Left:

Background color: Color:

Note: the movable element below will appear below these form elements on purpose 😉

Dolor quis excepteur dolor cillum ipsum cupidatat incididunt tempor non cillum anim irure occaecat.

Move me around!

Fugiat velit est proident nostrud consequat est quis excepteur exercitation exercitation labore.

Play around with the positional attributes top, right, bottom, and left to get a feel for how the position of the Move me around! element works. For those playing along, the div (box) with the solid black border is position: relative, so it is the containing element of the Move me around! element. This is because it is the first parent that isn't position: static!

Fun fact: the starry background in my site's navigation is set to position: absolute;. Can you guess what its containing element is? 🤔

Fixed Positioning

This is similar to position: absolute;, except instead of being offset relative to its parent, a fixed positioned element is offset relative to the browser viewport (bounds). I haven't used this in my navigation code, but I figured I'd call it out since it's useful! 🗣

Positioning: The Takeaway

Positioning is one tool in our toolbox for massaging the DOM into the correct looking shape that we desire. It allows you to do cool things like move things around and stack elements on top of others (like for a modal, popup, or tooltip).

And finally, it's time to rack em', stack em', and pack em'.

Stacking Contexts

You can do anything with stacks and iteration that you can do with recursion
Steve McConnell

As we saw when discussing positioning, positioned elements win over non-positioned elements. In cases where there are multiple positioned elements, the way to control which has overlapping precedence is with the z-index CSS property. The z-index CSS property is an integer value that describes how "high" the element would be elevated off the page if it were in 3D space.

Let's check out a simple interactive stacking example. There's a non-positioned (i.e. position: static) blue box, a red position: relative box at z-index: 2, and a green box that you can control which defaults to z-index: 1. At the start, the red box is visually "on top" of the other two boxes, followed by the green box, and finally the blue box. What happens when you set the green box's z-index to 2? To 3? To 0?

Green zIndex:

Blue

Red

Green

Stacking Contexts: The Takeaway

We saw before in the positioning section that anything that isn't position: static has the ability to use z-index. The z-index CSS property allows you to manage how elements overlap others. The higher the z-index (if not position: static), the more likely an element will visually appear on top of others.

You Got Your Chocolate in my Peanut Butter 😔

Does it make sense to use CSS for disabling an element and its children's pointer-events? It seems kind of odd to me that such behavior is delegated to CSS instead of Javascript. I mean, it's not like cursor: pointer where it's a purely "presentational" effect. With Javascript, (examples following being of the React flavor) you enhance DOM elements by adding event listeners which trigger on interactions providing the desired functionality. By setting pointer-events: none; on a DOM element, you are turning off all cursor interactions for it and its children! This is crazy to me! 😜 Sounds an awful lot like a Javascript concern, namely something like:

function DestroyAllClicks() {
  const [count, setCount] = React.useState(0);

  function increment() {
    setCount((c) => c + 1);
  }

  function preventAllClicks(event) {
    event.preventDefault();
    event.stopPropagation();
  }

  return (
    <div onClickCapture={preventAllClicks}>
      <button type="button" onClick={increment}>
        Increment count
      </button>
      <p>Count = {count}</p>
    </div>
  );
}

Count = 0

It pushes me further and further from the misguided belief that your ~~peanut butter shouldn't mix with my chocolate~~ UI concerns should be separated. The lines are so blurred now. Javascript isn't just for adding "functionality", it's also for rendering and animations. CSS isn't just for presentational styling, it's also for interactivity/functionality. And with web components, well, the lines continue to be blurred!

Conclusion

I strive for great UX, but it's a constant battle. This site, as of writing this article, still has a long way to go, but iterators gonna iterate. It's all too easy to get caught up in the technical details when developing something.

What should ${it} do?
What are the requirements?
Do you provide a good user experience?

Initially, I thought I hit the mark for my navigation bar (technically I still haven't because my mobile nav is atrocious 😲🤷‍♂️😂). But, only by taking a step back and looking at the full context of where the navigation was rendered and how it should interact with its adjacent elements (in the DOM order or stacking order) was I able to fully address my requirements and provide a good user experience. And I got to learn about and use a cool, but odd CSS property along the way!

Indifferent With Ruby Hashes

Fri, 13 Dec 2019 20:41:12 GMT

I miss plain old JavaScript objects... 😔

sigh Ruby hashes

A Ruby hash is a key-value pair container which can be made with either a hash literal {} or constructor Hash.new. They're known as dictionaries or associative-arrays and allow you to store values that can be accessed by a key. If you're acquainted with JSON or JavaScript objects, this should look familiar. When it comes to values, they can be anything, even other nested hashes! Keys are generally either strings or symbols (like a Ruby string, but stronk, docs here) for simplicity, but you can use anything that is an "object type". Reaching for the Ruby docs, we see that:

A user-defined class may be used as a hash key if the hash and eql? methods are overridden to provide meaningful behavior. By default, separate instances refer to separate hash keys.
A typical implementation of hash is based on the object's data while eql? is usually aliased to the overridden == method

This just means many things, even complex objects you or others write, can evaluate to hash keys.

Accessing Hash Values

In the beginning, I mentioned that hashes are referred to as associative-arrays. This is because while arrays, or lists of items, are indexed by numbers, e.g.:

# list has 3 items (a .length equal to 3)
list = ["first", "second", "third"]

# notice below that we are accessing the list items by a number index
# ruby arrays use 0-based indexing, or the first item is the 0th index
first = list[0]
second = list[1]

hashes, on the other hand, use generic keys, e.g.:

# declare a new hash using a hash literal
# I'm only using strings as values here, but
hash = {
  nested: {
    "look ma" => "I'm in a nested hash!"
  },
  foo: "bar", # symbol notation
  "three" => 3, # fat arrow notation, which is necessary for string and number keys
  4 => "four"
}

# get the nested hash using a symbol key
nested_hash = hash[:nested]

# get the three value using a string
three = hash["three"]

# we can even use numbers as keys!
four = hash[4]

Where's the beef? 🐄

So far, hashes look pretty neat, right? Well, for the most part, they are. They're used all the time, especially in Rails applications. However, what do you think happens when you try the following?

hash = {
  foo: "bar" # a symbol key, :foo
}

# notice: the foo key is a symbol,
# but instead we're trying to access using a string
foo = hash["foo"]

The answer?

Example: Hash access using a string when the key is a symbol

We can't access the foo value using the string "foo", but instead have to use the symbol :foo. Mildly put, this is annoying.

Coming from JavaScript land, objects have shorthand property names, which looks strikingly similar to symbol notation for Ruby hash keys:

const hash = {
  foo: 'bar',
};

// accessing with object destructuring works
let { foo } = hash;

// as does with a string works
foo = hash['foo'];

// as does named property access
foo = hash.foo;

Example: Node object access

Keep in mind that I've purposefully left out ES2015 Symbols, as they are different from Ruby symbols. Mainly, they don't coerce to strings easily. And, when converting them to strings using .toString(), for example, they produce "Symbol(<VALUE>)", e.g.:

What do you want Cody?

I'll tell you what I want, what I really really want!

hash = { foo: "bar" }

this = hash[:foo]
that = hash["foo"]

this == that #=> true

Rails to the Rescue 🛤

Rails has a weird symbiotic relationship with Ruby and will constantly monkey-patch the core library, or at least provide extensions to it. The extension that will save us is ActiveSupport::HashWithIndifferentAccess, where:

Implements a hash where keys :foo and "foo" are considered to be the same.

A hash of this type can be made either using:

# the ActiveSupport::HashWithIndifferentAccess constructor
hash = ActiveSupport::HashWithIndifferentAccess.new

# or, a hash literal followed by `.with_indifferent_access`
hash = {}.with_indifferent_access

Here it is in action:

Example: Using the Rails Hash With Indifferent Access Extension

And I LOVE it.

Conclusion

TLDR: Indifferent access hashes are what hashes should have been in the first place.

I shouldn't have to care whether you give a hash :foo or "foo" to access something. Both of those cases should behave identically. If it did, APIs that return hashes wouldn't need to use something like deep_symbolize_keys. Also, why are these highly valuable things not in Ruby core yet??

And that's why I miss POJOs: Plain Old JavaScript Objects. And why I'm so indifferent 😉with Ruby hashes.

Sort it out, JS 😒

Thu, 12 Dec 2019 02:59:09 GMT

Fell for the ol' default JavaScript sorting algorithm trap when working with numbers. 😲

It's been a little while since my last post (about a month and a half). This wasn't intentional since I have a lot of things in flight right now. That being said, I do have a lot of things in the pipeline for upcoming posts.

Tonight I made a script to automate the boring stuff when creating a blog post. It's a small-ish node driven command line script that scaffolds out a new blog post using a template. In my website's repo, like most (if not all) Gatsby driven static sites, my posts are located under content/blog. The directory names for each are prefixed with a zero-padded index, followed by a kebab-cased path (which is generally similar to the title and happens to be what makes up the slug).

For example, 0005-git-commit-m-write-more, which maps to this post.

For each new post I make, I simply increment that prefix number for superficial sorting within my content/blog directory. While I do order them by date on my site, I like seeing my directory listed in posted order, since without the number prefix, the order is alphabetical. While alphabetical is fine, I'm gaming the system since numbers are "alphabetically before" letters.

Sorted blog directory

Given the above context, my next blog post will be prefixed with "0009".

Who Wants to be a JavaScriptonaire?

So, what did I fall for? Well, to explain, let's play a game. The stakes are high. The prize... knawwwledge. Let's consider the following code snippet:

const list = [10, 9, 8, 7, 6, 5, 4, 3, 2, 1];

const sortedList = list.sort();

Sorting a list of numbers in JavaScript.

What will the result of the sortedList variable be?

(A): [1, 2, 3, 4, 5, 6, 7, 8, 9, 10]
(B): [1, 10, 2, 3, 4, 5, 6, 7, 8, 9]
(C): "Bush did 911"
(D): None of the above

I'll wait... No peeking 🙈. Or, you can cheat and scroll down to the answer 😉

Countdown from 60 seconds ⏳

Array.prototype.sort(of?)

Let's go to my favorite site south of Reddit, MDN:

The sort() method sorts the elements of an array in place and returns the sorted array. The default sort order is ascending, built upon converting the elements into strings, then comparing their sequences of UTF-16 code units values.

Emphasis mine. Did you catch it? While there are plenty of things to talk about here (like sorting in place), let's focus on what happens when you don't provide your comparator function. Let's .reverse() and replay that back:

The default sort order is ascending, built upon converting the elements into strings, then comparing their sequences of UTF-16 code unit values.

So, the following list of numbers from ten down to one will be converted into strings when sorted. Let's pretend we can see pseudo-intermediary steps, so that:

const list = [10, 9, 8, 7, 6, 5, 4, 3, 2, 1];

const sortedList = list.sort();

Sorting a list of numbers in JavaScript.

turns into something like:

const list = [10, 9, 8, 7, 6, 5, 4, 3, 2, 1];

// convert list of numbers to strings
const listAsStrings = ['10', '9', '8', '7', '6', '5', '4', '3', '2', '1'];

// sort the list, convert back into numbers
const sortedList = listAsStrings.sort().map((number) => parseInt(number, 10));

Sorting a list of numbers in JavaScript, but with pretend intermediary steps shown.

Again, the default .sort() behavior is:

comparing their sequences of UTF-16 code units values

which means that a comparison between two strings in the list is done character by character (really, code point by code point) until one of them is considered alphabetically before the other, e.g. "abc" comes alphabetically before "xyz".

The Correct Answer Is...

If you answered (A), you're...

...INCORRECT!

If you answered (B), you're...

...CORRECT! sadly... 😢

Surely you can't be serious.

I am serious and don't call me Shirley.

The Problematic Code

The reason why this bit me is that I initially wrote the code to calculate the next prefix number using .sort().

Here's the old way I wrote it:

function newPostNumber() {
  const postNumbers = fs
    .readdirSync(blogsPath) // read the content/blog directory, like `ls`
    .map((filename) => parseInt(filename.split('-')[0], 10)) // get the prefix, as a number
    .filter(Boolean) // remove any falsey things, like things that don't match our pattern
    .sort() // sort the list in order
    .reverse(); // reverse the list so I can pick the first one (last number)

  // increment the last number used by one
  const postNumber = postNumbers[0] + 1;

  // pad the post number with up to 3 zeros (4 number slots)
  return `${postNumber}`.padStart(4, '0');
}

Problematic code

I used .sort().

So, the list of numbers was converted to strings and then... well, you know the rest. After "0009", I would have been stuck generating "0010-..." directories! 😳

The Fix

To fix the above code, all I needed to do was provide my own comparator function:

 - .sort()
 + .sort((lhs, rhs) => lhs - rhs)

Custom comparator function

This comparator function returns true when the first argument is less than the second, forcing a swap between the two. In other words, we're incrementing in ascending order, what we originally wanted.

function newPostNumber() {
  const postNumbers = fs
    .readdirSync(blogsPath)
    .map((filename) => parseInt(filename.split('-')[0], 10))
    .filter(Boolean)
    .sort((l, r) => l - r)
    .reverse();

  const postNumber = postNumbers[0] + 1;

  return `${postNumber}`.padStart(4, '0');
}

The working code using a custom comparator function.

Conclusion

Look, I get it. It works for strings. The default sorting algorithm is pretty generic. But maybe that's the problem?

In the wise words of the Letterkenny gang:

JavaScript, you figure it out.

Figure it out.

Wild React 🦒: useForceUpdate()

Wed, 30 Oct 2019 04:14:10 GMT

Y'all wanna see something wild? 🦒👀

A little known method

There is a method in the React component class API that is fairly unknown and rarely used: forceUpdate(). As the React docs state,

By default, when your component’s state or props change, your component will re-render. If your render() method depends on some other data, you can tell React that the component needs re-rendering by calling forceUpdate()

In a normal React application, changes to props, state, and even context is the main driver of component render cycles. However, you can tell React to re-render your component without updating any of those things. And one special way to do that is to call forceUpdate().

Let's take a glance at what this may look like:

class BadExample extends React.Component {
  callJGWentworth = () => {
    // call J.G. Wentworth, or just tell React we need it now 👇
    this.forceUpdate();
  };
  render() {
    console.log('877-CASH-NOW!!!');

    return (
      <>
        <h2>I have a structured settlement</h2>
        <button type="button" onClick={this.callJGWentworth}>
          AND I NEED CASH NOW
        </button>
      </>
    );
  }
}

React component forceUpdate() example usage

Yeah, I know the code is bad, but it's only ~~a reflection of my daily code production~~ an example. It actually doesn't do anything. kinda

Be a lot cooler if it did

Here's what running the above code looks like:

I have a structured settlement

🎶 877-CASH-NOW!!! 🎶

One thing to be aware of is that forceUpdate() will skip shouldComponentUpdate() (which by default just returns true).

Going back to the React docs:

Calling forceUpdate() will cause render() to be called on the component, skipping shouldComponentUpdate(). This will trigger the normal lifecycle methods for child components, including the shouldComponentUpdate() method of each child. React will still only update the DOM if the markup changes.

That last sentence simply means that calling forceUpdate() could end up being a no-op function, e.g. () => {}. If nothing in the DOM will change by forcing a re-render, then you've done some wasted work on the UI thread. And we don't want that.

Use forceUpdate() sparingly and with intention.

forceUpdate(), the React hooks hway

If you've used React hooks, you've probably noticed that:

They're awesome 😎
They don't have a hook corollary to componentDidCatch or forceUpdate() (hey, what gives??)

Alright, well maybe you haven't noticed point #2. That's alright, alright, alright.

It may not exist as a first class hook, but that can't stop us! Let's write a custom hook!

function useForceUpdate() {
  const [, forceUpdate] = React.useState();

  return React.useCallback(() => {
    forceUpdate((s) => !s);
  }, []);
}

forceUpdate(), but as a hook: useForceUpdate()

So, what does this hook do?

Well, it first calls React.useState() and passes nothing, or undefined, to the initial state. Notice however, that it doesn't care about the first argument returned in the useState() tuple, which is the state variable. We will soon see that this is okay though, because our initial state is falsey, which is just a funny way of saying that it evaluates to false. It's important to note that we've effectively made the state variable private to the custom hook, or hidden to the outside users. The state variable still exists, but we just don't expose it for use. Here's what happens in React DevTools:

useForceUpdate() in React DevTools ⚛️

The last thing that the useForceUpdate hook does is return a memoized callback that simply toggles the unnamed state variable. Just like in the React class component method setState, you can pass an updater function to the React.useState() setter, as I've done here. This updater function just happens to return the inverse of what the unnamed state variable currently is, e.g. false ➡️ true.

If you're unsure about what I mean by "memoized callback", that's okay. In this case, we just want the function () => { forceUpdate(); } to always refer to the same underlying object reference. So, we're caching, or remembering, what the function is, even across separate calls to useForceUpdate. If you're curious for more info on memoization, check out this Wikipedia article.

To answer the question "What does this hook do?", it allows you to force a re-render in your functional component without actually changing props, state, or context.

I have misled you a bit, however. The useForceUpdate() hook isn't quite a 1-to-1 comparison with the forceUpdate() class component usage above. That's because there's no shouldComponentUpdate() hook. Hooks require a different mental model of React.

Example Time! ⏰

Here's the part I've been wanting to show you. But, before I reveal the code we will be running, I want to talk about a couple of things.

First, let's touch back on what causes a React component to re-render. As I mentioned before, a component will re-render if:

its shouldComponentUpdate() returns true
its own internal state changes
it receives new props
the context it hooks into changes
it's a class component that calls forceUpdate()

Notice that changing React refs don't cause a re-render. Refs are nice for imperatively mutating DOM nodes. I primarily use them for focus management: ref.current.focus(). But, you can also use them to store instance-like-variables, even in functional components! Keep in mind that changing these kinds of instance-like-variables won't trigger a re-render.

Next, I wanna briefly talk about one of my favorite hooks: React.useEffect(). And by briefly talk about, I really just mean referencing a tweet from @ryanflorence.

A quick and helpful guide on React.useEffect():

Tweet: Ryan Florence (@ryanflorence) May 5, 2019

Now that that's out of the way, let's see some code, Cody! 🤓

function UseTheForce() {
  const forceUpdate = useForceUpdate();
  const renderCount = React.useRef(0);

  React.useEffect(() => {
    renderCount.current += 1;
  });

  const onClick = React.useCallback(() => {
    forceUpdate();
  }, [forceUpdate]);

  return (
    <>
      <button type="button" onClick={onClick}>
        Use the Force 👋
      </button>
      <div>Render count: {renderCount.current}</div>
    </>
  );
}

And here it is, running (((wild))). Go ahead, give it a click. 👇

Render count: 0

Well there it is

The oddball UseTheForce component, rendered in all its glory.

How neat is that? 🌲

Let's break it down 💃

First, we get our forceUpdate() callback:

// get the forceUpdate() callback by calling the useForceUpdate() hook
const forceUpdate = useForceUpdate();

Get the forceUpdate() callback by calling the useForceUpdate() hook

Now, let's grab a ref to a pseudo-instance-variable counter, initialized to 0:

// let's retain some counting state without useState()... with refs!
// initialize the ref.current value to 0
const renderCount = React.useRef(0);

Use state without useState(), ya dig?

Using our handy dandy ~~notebook 📕~~ React.useEffect() guide from Ryan Florence, let's increment the counter on each render:

// add one to the render count ref's current value on each render
React.useEffect(() => {
  renderCount.current += 1;
}); // don't pass any dependency array here, not even empty list []

Add one to the render count ref's current value on each render

A simple click handler is necessary for the <button>:

// When I click, you... don't click, just force the update!
const onClick = React.useCallback(() => {
  forceUpdate();
}, [forceUpdate]);

Force an update when we click the button

And finally, ~~draw the rest of the ****ing owl~~ the markup:

// render the button and our "state variable" render count
return (
  <>
    <button type="button" onClick={onClick}>
      Use the Force 👋
    </button>
    <div>Render count: {renderCount.current}</div>
  </>
);

The example markup

Conclusion

TLDR: Don't do this.^*

This was definitely an exercise in what if? territory. While there are certainly use cases for forceUpdate(), odds are you're better off using hooks, props, state, and context to declaratively render what you want and when.

If nothing in the DOM will change by forcing a re-render, then you've done some wasted work on the UI thread. The UI thread is a precious resource and we should be using it as little as possible for maximum performance.

Again, use forceUpdate() sparingly and with intention.

And if you're thinking about reaching for something like the custom useForceUpdate() hook above, then you're probably holding it wrong.

Thanks for coming to my TED talk. After all, all the cool kids are doing it.

^\*Unless you have good reason to. ~~Terms and conditions~~ Nuance applies.

Update: Event Loop Article is coming

Thu, 17 Oct 2019 16:51:49 GMT

Update: I have a working MDX configuration on a feature branch! Interactive examples are coming! 💪💪💪

Example: React Component Embedded in Markdown

React Counter Component

Count: 0

This is rendered inside markdown (using MDX!) 🤓

Turns out good content takes a lot of time and effort. Who knew? 🤷‍♂️ 😂

TLDR: It's coming...soon

Soon... 🦉

So what's the deal? Why didn't the article drop at 11am local time? It's Thursday after all. Well, I feel that in order to explain some of the more complicated topics it requires either animated or interactive elements. A lot of concepts related to the JavaScript event loop are much easier to explain when you have more than simple, static content.

And that's what I want to provide.

Excuses, excuses... 😒

I want to have the ability to give you, the reader, an opportunity to really understand what is going on with each, transient step in the event loop workflow. Things like describing a stack, queue, and what a specific function call did are much easier with dynamic content (animations and interactive content).

How will you provide interactive content?

First off, I could rip off some prior art as gifs, but that seems wrong.

Good artists copy; Great artists steal
Pablo Piscasso

Also, I'm rusty on my digital art, so making my own gifs or videos seems really time consuming. Instead, I'll be making React components which I'll be able to embed directly into the article's page. And you will be able to play with them!

Neat, right?

Well, I think so! 🌝 And that's what's taking so long. I have all the content I want to write. I know what I want to say and how I want to say it. However, I don't want you to get lost in the nuance of the details.

It can and may get highly technical

And when it does, my weapon for clarity and against glazed over 👀 is interactivity. I just need to make some website configuration changes to allow for embedding this kind of content.

So, while I may have missed the mark this week, it'll be ready next week.

I promise. 🤞

git commit -m "write more"

Tue, 15 Oct 2019 23:27:33 GMT

It's about time. ⏳ At least, it's about the commitment to stick to a certain time. And I'll keep this post short and quick.

TLDR: I have a Public Accountability Statement. I'm officially committing to writing a new article every week and posting on Thursday at noon local time, starting this week. And let's be real, this post is short enough that a TLDR wasn't really necessary, but here we are 🙃.

I haven't written anything new for the past (nearly) two months. Even though my backlog of blog post thoughts, insights, and ideas continues to grow daily (around 30 items strong now). It's kinda starting to look like my JIRA backlog at work 😅.

I've already posted about this on the socials, but it's time for action. So, in my attempt to get a head start on abandoning my New Year's resolutions, I'm going to begin a few now. A major one, which happens to be the reason for this particular post, is to write more and consistently.

Teach us to number our days, that we may gain a heart of wisdom. Psalm 90:12

So, I'm numbering my days and committing to writing at least one article per week and publishing it on Thursdays at noon. My first entry will be a big and exciting one: the JavaScript event loop.

I'm not going to constrain myself to write a set amount, just that I do write.

Electrical Reflections: What he learned will SHOCK you!!!

Fri, 11 Oct 2019 11:19:00 GMT

Currently reflecting on how thankful I am for all the opportunities I've been blessed with. Specifically, the ability to recognize subpar electrical work and the capability to fix it for the safety of my family.

I was reading up on electrical subpanels on my lunch break since our home has one in the basement.

WHAT I LEARNED WILL SHOCK YOU!!!

With what I learned, well just call me shocked (pun intended ⚡️) that we haven't had an unfortunate incident ☠️. Such an incident where, as someone online so eloquently put:

"All it takes is a preexisting fault, one rainstorm, or wet feet, whatever... and you touching something energized - and you're doing the 60 cycle shuffle."

Arcing. Electrocution. Bad shocky things.

What is an electrician's favorite flavor of ice cream? Shock-a-lot.

⚡️️️️️️️️️⚡️⚡️

I've been shocked (embarrassingly, multiple times) from being careless around my main panel. It's not fun.

Our home's basement, an ill-planned afterthought-addition, prefers to remain wet. This is primarily because of two things.

First, the basement was added after the home was built. So, they dug out from beneath it and used regular old concrete cinder blocks for the foundation walls.

Second, surprisingly, concrete is a rather porous material and water loves to penetrate it. And when this happens, it can build up a lot of pressure which forces the water into places that it doesn't belong, like a basement.

Hence, our wet basement.

Our basement's electrical subpanel is definitely not wired correctly. Oh and there definitely exists a potential parallel path for ground currents. Don't even get me started on how a 30 amp breaker is supplying 3 15s and a single 20.

First off, I have about 5 or 6 open slots on my main panel, so this subpanel is completely unnecessary. Second, that 30A breaker is connected to 4 or 5 outlets, a separate half bath attached to the living room (lol, right?), and the air conditioning. 😒 This breaker solely exists to bring power to the AC, yet it has all these extra, unsafe connections/additions.

What's the definition of a shock absorber? A careless electrician.

The state of all this makes me angry and scared. I'm scared for those who've inherited such an unsafe mess as we have. How many other homes exist with similar, or worse, electrical work?

This fault exists because of multiple people along the chain-of-command, so to speak, who were either unqualified, negligent, or more likely both who wired up the home. And unfortunately, it can be really expensive to fix faults as time goes on. Most likely, it involves running new line, disposing of and installing new drywall, and maybe even framing work. So, even if you can recognize such failures, you may not have the resources available to fix them.

Let's be clear: I'm not a licensed electrician. I'm just an engineer with a thirst for knowledge and doing what's right. However, thankfully I took enough electrical engineering courses to be dangerous (and earn a degree). I have also had the opportunity to shadow those more qualified than me as a contractor during the summers between semesters. Lives are at stake here. Electricity is dangerous.

We have to do better.

The Best Practice is Shipping

Thu, 22 Aug 2019 05:56:08 GMT

TLDR: I'm pivoting.

I'm pivoting to a new framework. Which one? Which one?

I've always wanted to have my own lil' corner on the web. A spot to show off my accomplishments and projects, share knowledge and insights, occasionally blog, and house my portfolio. About two weeks ago, August 8th to be exact, I pulled the trigger and bought my domain, codyaprice.com, from Google Domains. After that, I needed a way to deploy it. I had heard great things about zeit and gave them a shot (can't recommend them enough btw!). So, within fifteen minutes and twelve dollars later, I had a domain and deployment/cdn service. Awesome!

I have a domain.. now what?

GET /framework

A few weeks before I got my itchy trigger finger, I found @Rich_Harris' talk about rethinking reactivity and fell in love with svelte. This is what a UI framework should be!

Don't get me wrong, I love React. I love how easy it is to create beautiful and flexible interfaces with a declarative, straightforward approach. I love working with ES2015+ JavaScript and it has somehow become the language I think in. My pseudocode is pretty much JS now. However, it's always bothered me that you have to include the universe with any React app, while reconciliation and the virtual DOM ain't free.

Just give it another `rm -rf` for good measure.

React needs to figure out how to efficiently update the UI to match the most recent tree...[and] implements a heuristic O(n) algorithm.

The virtual DOM is pure overhead! Reconciliation is at least O(n) and runs on each render cycle. It's true that, in general, React apps can consistently output 60 fps, but surely we can do better than O(n) on top of what the browser already does and giant chunks of JavaScript runtime right?

So back to svelte. What drew me to svelte was that it is component based, not unlike React, and compiled to just JavaScript without polluting your bundle with production dependencies. It builds fast, ships fast, and runs fast. It's got a beautiful API and is performant enough to run on embedded devices!

That's incredible. I mean, I went to school for Electrical and Computer Engineering and cut my programming teeth on C and microcontrollers. Before becoming a full time web developer, I was an Embedded Systems Engineer who worked on extremely memory-and-power-constrained microprocessors. Some of them had 32kB of memory, operated at 32MHz on a good day, and didn't even have a heap! We did everything on the stack 📚! So, with that background, I can confidently say that by definition, I'm a perf nerd 🤓.

I was sold enough on svelte to use zeit's sapper template. At least at first.

Float Like a Rock, Sting Like a Fly

As I've said before, I basically live and breathe React. I write it M-F 9-5 @cerner. So, transitioning to svelte was slow. Even though it's similar to React and has a similar development mouthfeel, it's still different. There's a small learning curve and there's not nearly as much community support (yet). This isn't svelte's fault, but it plays a factor in how fast I can iterate on features and development for my website.

Why aren't we talking about the mouthfeel, y'all? 🤔

At the beginning of this post, I mentioned what I want my website to contain: blog posts, tutorials and knowledge sharing, projects, portfolio, content, etc. Blog posts are great to pad websites with when fresh. Generally, they're just text and images. Simple content. Being that I write a lot of documentation in markdown, I wanted to be able to write my posts in markdown and then have a build time pipeline that renders them to markdown. I also wanted syntax highlighting for code snippets, since a lot of what I have to share is code-centric. So, I found prism for syntax highlighting and unified for markdown to html parsing and conversion (and so much more). Both of these tools are incredible, but there isn't a first class solution or plugin for sapper. And I fought with getting prism to work properly with svelte since css modules are a first class feature and on by default (one of the things I love about svelte). I worked on this in my spare time for nearly two weeks without producing nor hosting any meaningful content.

My website was dormant, vacant, and quite naked. 🙈

I was getting kind of frustrated and felt like I wasn't moving fast enough. I just wanted to start with my medium articles and go from there. I needed some help and perhaps some guidance. When I woke up yesterday around 6am, I opened twitter on my phone and at the top of my feed was a @ken_wheeler tweet:

Ken Wheeler spittin' facts: Best practice === ship it

And that's when I decided I needed to move on from svelte and sapper.

Great Gatsby

“And so with the sunshine and the great bursts of leaves growing on the trees, just as things grow in fast movies, I had that familiar conviction that life was beginning over again with the summer.”
-F. Scott Fitzgerald, The Great Gatsby

I can ship something that is good enough now and iterate on it quickly. If I use what I'm familiar with and make my content framework agnostic, I can produce a working, non-naked website while leaving the future open for change. So, making like Sony with Spiderman, I rebooted my website repo using the Gatsby starter blog template. All it took was:

gatsby new codyaprice.com https://github.com/gatsbyjs/gatsby-starter-blog

Can’t repeat the past?…Why of course you can!

and I was up and running 🏃‍♂️. Even though svelte is more performant than React, my development agility suffered when using it. Gatsby may take significantly longer at build time than svelte, but I had my first Medium article self-hosted and deployed faster than I could with native sapper. That's extremely valuable. And so far, there's no reason to complain. Now I'm freed up to focus on adding features that matter, like post tags and categories, side/secondary navigation, and other routes.

Closing Remarks

It's best to deliver as quick and as often as possible. A boss of mine has this cartoon pinned on his office door and I think it's a perfect metaphor for this:

Agile, but like this: 🛹➡️🚲️️➡️🏎

In this scenario, you develop, ship, and demo to the client over and over (iterate) until you arrive at what they want. The key is speed and you can't go fast without the right support and tools. For me, that's React and Gatsby. For now.

In one of Rich Harris' tweet threads about his rethinking reactivity talk, he explains the ideas behind what makes svelte so great. Dan Abramov replied with some insights into what's to come with React + Suspense and the caveats/ nuances of his incredible and jaw-dropping jsconf Iceland talk. Sounds like React, like JavaScript, will be a safe bet for the near future.

Svelte is probably maybe better.. at some things.

That being said, I believe that the direction svelte took is the future of web development. In my spare time, I can revisit using svelte and sapper. Maybe they'll have more support and features by then? Maybe then I'll have enough time and experience to roll my own solutions that mimic what the Gatsby starter blog gives you out of the box. 🤷‍♂️

I'm still working on my personal website, but it's deployed live now and it has (some) content on it. I can quickly add more without fighting a learning curve and that's the most important thing right now. Who knows, maybe React and Gatsby will satisfy my needs for years to come? One thing's for sure, knowing the JavaScript scene, there will always be a new hot thing to try out. Today it's svelte, tomorrow it's ${hotNewJavaScriptFramework}. As long as I'm learning and growing along the way, that's all I can ask for!

Thanks for reading! ✌️

Stop Testing Implementation Details

Thu, 08 Aug 2019 17:00:00 GMT

This was originally posted on Medium on August 8, 2019

Yes, even you, object oriented peeps. 🐤😉

I’m so into the idea of testing code well right now, especially when it comes to best practices, methodologies, and philosophies. A lot of what I do on the daily revolves around presentational (UI) code, specifically React. My org at work has standardized around using enzyme and jest. While I enjoy using jest, enzyme and I have a complicated relationship (read as: I strongly dislike enzyme). So, I’ve been on the lookout for better tools and methods to test our UI code so we can have confidence that it does what we want. I’m currently writing up an initiative to switch over to react-testing-library because it allows us to write tests that resemble the way our software is used and it makes it difficult to test implementation details, unlike enzyme which often encourages it. In this article, this second point is what I want to focus on.

Kent C. Dodds on Twitter: "The more your tests resemble the way your software is used, the more confidence they can give you."

Don’t write tests that are coupled to or leak out your implementation details

In my quest for improving my org’s tests and testing practice, I’ve come across many great articles/blog posts on testing ideologies, like:

Eric Elliot: Mocking is a Code Smell (preach! 🙏🗣)
Kent C. Dodds: Testing Implementation Details.

A common theme in these posts is that your tests should be black box tests that don’t leak implementation details, or things your consumers don’t care about or are even aware of. As Kent C. Dodds put it, when you test implementation details, it can lead to:

False negatives: Can break when you refactor application code.
False positives: May not fail when you break application code.

Contrived example time! ⏰

Let’s say you’re a startup with limited resources (capital 💰) and you have an idea for an awesome application which runs in an embedded environment. A key feature of your application is that you can multiply two numbers. It’s imperative that you get to market quickly so you can get paid.

Gotta go fast!

Seeing as you are broke and you need to get to market first, you choose the cheapest microprocessor available, but the catch is it doesn’t have a multiplication hardware unit. However, it does have hardware accelerated addition. Tradeoffs 🤷‍♂️. So, you get to work and write some code to multiply two numbers using loops and addition:

function multiply(a, b) {
  let acc = 0;
  const sign = Math.sign(b);
  const N = Math.abs(b);
  for (let i = 0; i < N; ++i) {
    acc += a;
  }

  return acc;
}

Looping multiplication function between two numbers

You’re a sane developer who follows TDD, so you write some tests for this as well.

import multiply from './multiply';

test('given any number and 0, it returns 0 regardless of order', () => {
  const a = 0;
  const b = 1;
  const expected = 0;

  let result = multiply(a, b);
  expect(result).toEqual(expected);

  result = multiply(b, a);
  expect(result).toEqual(expected);
});

test('given any number and 1, it returns the other number regardless of order', () => {
  const a = 5;
  const b = 1;
  const expected = 5;

  let result = multiply(a, b);
  expect(result).toEqual(expected);

  result = multiply(b, a);
  expect(result).toEqual(expected);
});

test('given any two positive numbers, it returns the positive expected result regardless of order', () => {
  const a = 5;
  const b = 2;
  const expected = 10;

  let result = multiply(a, b);
  expect(result).toEqual(expected);

  result = multiply(b, a);
  expect(result).toEqual(expected);
});

test('given one positive and one negative number, it returns the negative expected result regardless of order', () => {
  const a = 2;
  const b = -10;
  const expected = -20;

  let result = multiply(a, b);
  expect(result).toEqual(expected);

  result = multiply(b, a);
  expect(result).toEqual(expected);
});

test('given any two negative numbers, it returns the positive expected result regardless of order', () => {
  const a = -3;
  const b = -4;
  const expected = 12;

  let result = multiply(a, b);
  expect(result).toEqual(expected);

  result = multiply(b, a);
  expect(result).toEqual(expected);
});

Testing multiplication module

But wait ✋! Your boss comes back and is furious 😡 because you don’t have 100% test coverage! So, following orders 🤖, you add the following test:

import multiply from './multiply';

// pretend we can "spy on" for loops, or worse, that
// you refactor your code to call an add() method which
// you spy on and then expect it to be called N times..
test('given 2 and 5, it should loop 5 times', () => {
  spyOn(for); // hol' up: pretend we can spy on for loops 🕶

  const a = 2;
  const b = 5;
  const expectedCount = 5;

  multiply(a, b);

  expect(for).toHaveBeenCalledTimes(expectedCount);
});

Testing multiplication module implementation details

Hurray! We’ve hit 💯% coverage! Surely this isn’t foreshadowing! Now, you can finally release to prod, get clients, and that first paycheck you’ve been promised. 😎

Enter competitor B

Competitor B promises the same features as your application, but with huge performance benefits (especially when it comes to multiplication). Oh no 😰! Well, at least your company can now afford to purchase a beefier microprocessor that has hardware accelerated multiplication built in. So, you convince your boss to buy new silicon, build up a prototype, and load your existing code on it. Initially, itdoesn’t run any faster though. No worries, we just need to change out the implementation of multiply so that it utilizes that hot new * operator!

function multiply(a, b) {
  return a * b;
}

Simple (typical) multiply function between two numbers

Easy. Clean. Solid. It runs beautifully on the new hardware. So fast!

Before opening a PR to bless your colleagues with the performance gains 💪, you run your tests:

✅✅✅✅✅❌

What?? It’s just multiplication. The test that failed? The last one we wrote. The one that tested and leaked implementation details. This was a false negative. So long 100% test coverage.. 😩

What value did the test that leaked implementation details give us? None

Actually, you can argue that it gave you negative value, or in other words, it cost you. It cost you because it added noise to your tests and wasn’t testing anything that actually mattered. It failed when the functionality remained the same, but the hidden details under the covers changed. It failed when we should’ve been celebrating the magnitudes of performance gains.

Cody, surely this is just a hypothetical

While the above example may be contrived, you can easily replace the application and feature with any given idea or functionality in your own app’s core feature set or internal business logic.

For example, let’s say that you’re wanting to keep a list of tags for an item in your product catalogue. Do you implement this as an array of strings? A hashmap? Linked list? Should we persist this in a database? Put it in the cloud? Install one more dependency to manage it? Does it matter?

Well, according to my favorite engineering answer ever:

It depends.

Let's talk about trade-offs

There’s always trade-offs for any given decision, implementation or otherwise. Are you burdened with memory constraints? Does this code run in a hot path, so anything O(n) or worse is a no go? Those are implementation concerns that should definitely be addressed, but not within your tests. There’s another talk about pre-optimization in here somewhere, but I digress.

When you test something, you should strive for testing its functionality, or its public API. This does not include internal state, if a certain method was called N times or with certain arguments, etc.

As Kent C. Dodds states:

Implementation details are things which users of your code will not typically use, see, or even know about.

The first five tests above are examples of testing the public API. They didn’t fail when refactoring or changing the internal plumbing. Multiplication has a public API, its properties. The above tests that target the properties of multiplication gave us confidence that our code functions properly and weren’t fragile.

Conclusion

In closing, as developers, it is imperative that we strive for less fragile tests that provide actual value to us. We need tests that prove functionality and aren’t brittle. They shouldn’t reduce the signal-to-noise ratio.

How iOS VoiceOver Demonstrates The Power and Flexibility of React 💪

Fri, 07 Jun 2019 17:00:00 GMT

This was originally posted on Medium on June 7, 2019

I was recently blessed with the opportunity to work on an extremely high-priority project which aimed to fix an accessibility bug in a multi-select component. First I’ll discuss what we were dealing with and why it was an issue. Then I’ll go into how we solved the underlying problem.

TLDR: iOS VoiceOver is the new IE 🙅‍♂️ and React is awesome 😎

Let's get started!

Let’s say there exists a legacy solution that is currently in production and is in maintenance mode. This solution uses a tech stack that your company has moved away from and you are not familiar with it at all. There’s a weird structure, templates, and a bunch of code you don’t understand. All you know is is that there’s an accessibility bug in a non-browser-native select/dropdown that is rendered via some jQuery.

Okay, hypotheticals aside, this component is actually first rendered via a Django template and then enhanced/decorated with an external dependency. The component in question was actually using a popular JavaScript dropreadown library: Select2.

Select2 MultiSelect Example

The problem is that Select2 doesn’t provide a good user experience for iOS VoiceOver users. Why is this? Well, it all comes down to two things: Apple’s heuristics for the iOS VoiceOver virtual indicator are notoriously bad, and there’s not an accessibility API to access when you’re a web app (thanks Apple 😒). But, putting the blame on Apple (while justified 😤) doesn’t fix the problem that the client has identified. As an engineer, we’re supposed to fix problems, so let’s fix it! Before we can fix it, we must understand the problem.

Understanding the Problem 🤔

So how does the virtual indicator work? For the most part, it follows the normal DOM structure and tabIndex ordering. In general, where the focus is is where the virtual indicator is (except when it’s not!). Where it breaks down is when something in the DOM is only a sibling visually. This is generally achieved by rendering content outside of the normal DOM flow (e.g. at the end of the body) and applying CSS transforms to make the new content appear alongside the sibling content.

How could you get into this kind of situation? Modals, popups, and drop-downs. For better or for worse (definitely for worse 🙃), our UX department loves to build complex workflows with modals, popups, and drop-downs. In all seriousness though, shoutout 🗣 to them for being a wonderful help in guiding us through this problem 🙌.

Web-development is a type of engineering and with engineering comes trade-offs. Select2 is not immune to this.

How does Select2 work? Well, here’s a simplified explanation. Let’s say you have a multi-select workflow in a form and you have a list of data to select from like:

const data = ['Red', 'Orange', 'Yellow', 'Green', 'Blue', 'Indigo', 'Violet'];

Example list of colors

Given this list, in a simplified world, when you render a Select2 multi-select around a hidden input (used for your form submission), your screen will look like:

Example Select2 rendering given the data list of colors above

And your corresponding DOM may look like the following:

<html>
  <body>
    <div class="content">
      <form>
        <label for="color">Select a color</label>
        <div class="select2-container select2-container-multi">
          <ul class="select2-choices">
            <li class="select2-search-choice">
              <!-- a selected choice here -->
              <div>Red</div>
            </li>
            <li class="select2-search-field">
              <!-- the Select2's input field -->
              <input type="text" class="select2-input" />
            </li>
            <!-- the hidden input that is decorated with Select2 that will be used in the form submission -->
            <input type="hidden" name="color" value="red" />
          </ul>
        </div>
        <button type="submit">Submit Form</button>
      </form>
    </div>
    <div class="select2-drop select2-drop-multi ...">
      <!-- this is the actual dropdown content, notice it's not a direct sibling of the Select2 itself -->
      <ul class="select2-results">
        <li class="select2-result">Red</li>
        <li class="select2-result">Orange</li>
        <li class="select2-result">Yellow</li>
        <li class="select2-result">Green</li>
        <li class="select2-result">Blue</li>
        <li class="select2-result">Indigo</li>
        <li class="select2-result">Violet</li>
      </ul>
    </div>
  </body>
</html>

DOM layout of a trivial Select2 Example

Notice that the Select2 results aren’t a direct sibling of the Select2 container. This is the part that iOS VoiceOver trips up on.

Take another look at the screenshot of the Select2 dropdown above. How would you expect the iOS VoiceOver virtual indicator to behave?

If you answered that the next navigation swipe lands on the dropdown options, then you are sadly mistaken my friend 😢. WAT. WAT indeed..

This is NOT what iOS VoiceOver navigates to next when focused on the input

A keen eye will notice that there’s another focusable element between the Select2 container div and the Select2 dropdown div: the submit button. In more complicated forms, you’ll have many different fields between your dropdown and the submit button which will just exacerbate the problem.

What iOS VoiceOver actually does is navigates through the rest of the entire DOM and THEN the dropdown options. Yes, it’s THAT bad.

Fixing What’s Broken With React 🛠

Now that we understand how we got here, how did we fix this with React (and the native browser APIs)?

Remember how there was a hidden input in the example above? Well, we had one of those generated from the Django template too. The specific hidden input we were working with was given some handy data attributes which we were able to use to pass as props to a React tree. There were attributes for things like a placeholder, maxSelection count, and a searchUrl if the data was asynchronously fetched. There was also an attribute we could use as a selector which would be one of two things: data-dynamic-list or data-dropdown-list, the former being asynchronously loaded data and the latter a typical static dropdown list.

One of the coolest things about React is that it’s so flexible. You can incrementally add it to a website. What makes this so cool is that as long as there’s a container, you can render React components inside it. In our case, we have a container, which is the parent component of our hidden inputs labeled with data-dynamic-list or data-dropdown-list attributes! All we need is a little native browser API magic and we’ve got ‘em 🎯:

import { dynamicList, dropdownList } from 'codys-cool-react-stuff';

// wait for Django to load and render everything before we try to decorate with our custom React components :)
window.addEventListener('load', () => {
  // get all the dynamic lists on the page
  document
    .querySelectorAll('[data-dynamic-list]')
    .forEach((dynamicListElement) => {
      // render a new React tree with this specific dynamic list
      dynamicList(dynamicListElement);
    });

  // get all the dropdown lists on the page
  document
    .querySelectorAll('[data-dropdown-list]')
    .forEach((dropdownListElement) => {
      // render a new React tree with this specific dropdown list
      dropdownList(dropdownListElement);
    });
});

Get all the dynamic and dropdown lists on the page

Now that we have each of the lists on the page, we can replace them with a container and render our custom React code inside them! Notice that this will produce multiple React trees on the page if there are multiple dynamic and/or dropdown lists 😉

Before we do that, we just need to extract the datasets from the list elements and then we can pass those as props down to the React tree. This can be done as simple as:

const { dataset } = element;
const {
  isMultiple,
  placeholder,
  maxSelection,
  // etc,
} = dataset;

Extracting the container's metadata from its dataset

And now, since we want full control of the tree and therefore the hidden input or select that is used for form submission, we can replace it with our container:

export default function replaceNodeWithContainer(node) {
  const { parentElement } = node;

  const container = document.createElement('div');

  parentElement.replaceChild(container, node);

  return container;
}

Replace the given node with a React tree container

Now all that’s left to do is put it all together and render our custom component.

import React from 'react';
import { render } from 'react-dom';
import getContainer from './utils/getContainer';
import SearchableSelection from './components/SearchableSelection';

export default function dynamicList(node) {
  const { name, id } = node;
  const dataset = { ...(node.dataset || {}) };
  const {
    placeholderText,
    maximumSelection,
    searchUrl,
    additionalQueryParams,
    isMultiple,
  } = dataset;

  const placeholder = placeholderText || undefined;
  const maxSelection = isMultiple
    ? parseInt(maximumSelection, 10) || undefined
    : 1;
  const container = getContainer(node);

  const props = {
    selectId: id,
    name,
    searchUrl,
    placeholder,
    isMultiple,
    maxSelection,
    additionalQueryParams,
    searchThreshold: 2,
  };

  const component = <SearchableSelection {...props} />;

  render(component, container);
}

Render Our Custom React Select2 Dynamic List Replacement

With this full control, we can use the magic of refs to manipulate the hidden input and/or select nodes.

Noice!

The Result: Drumroll Please.. 🥁

So, with all that work, what do we have to show for it? Well, I can’t show the rest of the code (company secret 🤫😉). However, we now have a responsive and accessible multi-select asynchronous dropdown!

Responsive and Accessible Asynchronous MultiSelect Dropdown

We ended up responsively rendering a modal where the dropdown options are a direct sibling of the search input. There are a few interesting gotchas that we ran into, however.

Normally on the web, window size is sufficient for mobile device detection. However, our clients frequently operate on iPads, which can be much larger than the typical mobile screen size and appear as if it was a desktop device if we only paid attention to the window width. So, we detect if we were at a mobile breakpoint or if 'ontouchstart' in window (better than User Agent string parsing 🙌).

When we open the modal, the virtual indicator wasn’t initially moving to it.To fix this, we used a ref to focus on the close button in the top right. We initially tried to focus on the h1 title, but iOS VoiceOver really only likes it when you programmatically change focus onto interactable elements. 🎶Easy like Sunday mornin’ 🎶

The presence of both the X (close) and Apply buttons was an interesting choice by UX. This implies that clicking on the X will cancel your changes, while clicking on Apply will commit them. So, while the state of what was selected in each dropdown was lifted up, we needed to maintain a local state within the modal component when it was open. Only when we clicked submit would we commit (apply) our changes. So, we initialized the local selections state with the current state of the parent and then maintained local selection state as normal (shameless plug for hooks 🎣). We would pass the local selection state back to the parent through an onApply callback when the user clicked the Apply button. Pretty neat 📸

import React, { useState } from 'react';
import PropTypes from 'prop-types';

const propTypes = {
  // ..., other props
  onApply: PropTypes.func,
  selections: PropTypes.arrayOf(
    PropTypes.shape({
      id: PropTypes.string.isRequired,
      text: PropTypes.string.isRequired,
    })
  ),
};

const defaultProps = {
  // ...,
  onApply: () => {},
  selections: [],
};

function Modal({ selections, ...otherProps }) {
  // initialize localSelections state with selections prop given :)
  const [localSelections, setLocalSelections] = useState(selections);

  function handleOnApply() {
    // pass the localSelections onto the parent component through
    // the onApply callback prop :D
    onApply(localSelections);
  }

  return (
    <div>
      {/* hidden stuff ;) */}
      <button type="button" onClick={handleOnApply}>
        Apply
      </button>
    </div>
  );
}

Modal.propTypes = propTypes;
Modal.defaultProps = defaultProps;

export default Modal;

Handling Local Modal State

In Conclusion 🎬

This project was definitely one of my favorites to work on so far. It has been challenging and really rewarding. As engineers, it can sometimes seem that a limitation in an OS or API prevents us from proceeding forward. Often times though, this is simply an opportunity to flex our thinkin’ muscles and provide a novel solution to a complex problem. In tackling this, I’ve definitely learned a lot about the power of the browser APIs and React, as well as how hard it can be to get accessibility right. I also want to thank the engineers that have helped me along the way, as well as our UX department for providing us with visuals and a different workflow on such short notice 🚀.

I was already a huge fan of React ⚛︎ before this, but it definitely solidifies my appreciation for the framework. I hope you have learned something and have enjoyed the read. Let me know what you thought in the comments below! ✌️