DEV Community: Amy Henning

Getting a Hash Value from a String of Concatenated Keys

Amy Henning — Mon, 23 Nov 2020 03:55:55 +0000

Recently, I was tasked with determining if an expected value was present in a hash containing an arbitrary (and unknown) number of nested keys, using a string containing relevant keys to search for. Here's how I approached the problem and some useful Ruby methods I used along the way.

The Input

The method I was working on would require a few things. First, a hash to be searched. For example:

pokemon = {
    :pikachu => {
        :id => 25,
        :height => 4,
        :types => {
            :one => {
                :name => "electric"
            }
        }
    },
    :kubfu => {
        :id => 891,
        :height => 6,
        :types => {
            :one => {
                :name => "fighting"
            }
        }
    }
}

Second, a string of keys, prepended with the name of the hash:

key_string = "pokemon.pikachu.height"

Finally, an expected value:

expected_value = 4

So in this case, I would need to check if the height value of pikachu within the pokemon hash was equal to 4. In code terms...

if pokemon[:pikachu][:height] == 4
    puts "Success!"
end

Questions

I usually write down questions that need answers when solving problems like this. Here are a few I considered:

What should I do with the prepended hash name, knowing I'd be passed a pokemon hash?
How could I make this flexible enough to handle an abitrary number of keys in the string? I.e. someone could pass in a string like "pokemon.pikachu.types.one.name" and this method would need to be able to handle that as well as "pokemon.pikachu.id".
How will I turn the keys in this string into a sensible way to search through a hash, especially knowing that the hash could have any number of keys and layers of nested keys?

Fortunately, Ruby has some useful methods built in that made for a pretty concise solution.

Step 1: Split the String

The first thing to do was make that string into individual keys. I used the String class' split method (aka String#split) to get an array of substrings.

strings = key_string.split(".") # break apart the string wherever a . appears
=> ["pokemon", "pikachu", "height"]

Step 2: Get Rid of the Hash Name

I didn't actually need the "pokemon" element of that array since I already had the pokemon variable in scope for the code I was writing. I removed it using the handy Array#drop(n) method, which returns a copy of the original array with the first n elements removed.

keys = strings.drop(1)
=> ["pikachu", "height"]

(If the concatenated string had only contained keys within the given hash, I wouldn't have needed to do this step.)

First question - answered! ✅

Step 3: Convert the Strings to Symbols

To search the keys in the provided hash (which are symbols), I needed the elements of keys array to be symbols. When I split them up, they were still strings, so I needed a quick way to switch their type. I settled on this:

keys.map(&:to_sym)
=> [:pikachu, :height]

The & in Ruby will convert a method (represented by a symbol - in this case, :to_sym) into a Proc - basically, finding a method with the same name as the symbol. Passing &:to_sym to Ruby's Enumerable#map resulted in the String#to_sym method being called on all elements of the keys array to produce the output above.

Step 4: Pass the Symbols to the `Hash#dig` Method

The last step involved looking for the value associated with the particular sequence of keys within the pokemon hash. I briefly became overwhelmed with how to take an arbitrarily long array and pass each item as a key to a hash before I learned about the Hash#dig method.

dig() takes any number of keys as arguments and looks for those keys, in sequence, within the hash. If any of the keys can't be found, it returns nil. I tried this, expecting it to return true:

pokemon.dig(keys) == 4
=> false

This did not work, though. Why? Passing keys to dig essentially amounted to saying "Find the value for the [:pikachu, :height] key within the pokemon hash." But there is no single key called [:pikachu, :height] in the pokemon hash. Enter the splat operator (*), which turns an array into arguments.

Doing the following was like saying "find the :pikachu key; then beneath that, find the :height key. Then, check if that value equals 4."

pokemon.dig(*keys) == 4
=> true

Second and third questions - answered! ✅✅

The Code

What does this look like when not broken down step-by-step? Something like this:

# Inputs
pokemon = {
    :pikachu => {
        :id => 25,
        :height => 4,
        :types => {
            :one => {
                :name => "electric"
            }
        }
    },
    :kubfu => {
        :id => 891,
        :height => 6,
        :types => {
            :one => {
                :name => "fighting"
            }
        }
    }
}
key_string = "pokemon.pikachu.height"
expected_value = 4

# Array of symbols from the key string, excluding "pokemon"
keys = key_string.split(".").drop(1).map(&:to_sym)

if pokemon.dig(*keys) == expected_value
    puts "Success!"
end
=> Success!

Reflections

I've been working with Ruby for over 2 years, and I certainly don't have every method memorized. Some of these methods are tools I reach for regularly, whereas others like drop were fun discoveries while I worked on this problem.

The code snippet on which this post is based was part of a larger feature at work, but it was fun to write and, in the process, use some Ruby methods that made my life much easier.

Of Webpacker Config and Failed Rails App Deploys

Amy Henning — Thu, 08 Oct 2020 03:28:38 +0000

Earlier this year, deploys of my team's main application began failing with this error:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

This is a Rails app with an AngularJS front-end currently being converted to React. In the months leading up to those failures, deploy times had steadily increased. Before they began failing, our longest deploys took 24+ minutes. 😱 Here's how we fixed the issue and what I learned about the cause.

Attempted Fixes

The `--max_old_space_size` Setting

We increased Node.js's memory limit to 2GB by setting --max_old_space_size=2048 as recommended in several Stack Overflow posts and Github issues. While this worked for many others, it did not solve our problem. Deploys continued to fail.

Node.js Upgrade

We next upgraded the app's Node.js version from 8 to 12 to take advantage of this feature:

This update will configure the JavaScript heap size based on available memory instead of using defaults that were set by V8 for use with browsers. In previous releases, unless configured, V8 defaulted to limiting the max heap size to 700 MB or 1400MB on 32 and 64-bit platforms respectively. Configuring the heap size based on available memory ensures that Node.js does not try to use more memory than is available and terminating when its memory is exhausted. (source)

Upgrading Node.js unblocked our deploys for several weeks. However, during that time, we continued converting our AngularJS code to React and added new features in React. Deploys took longer and longer, and after a while, they began failing again.

The Fix

Given the attempted fixes above and with the help of infrastructure monitoring already in place, we were pretty sure that we weren't running out of memory on our deploy server. As it turns out, the root cause for this issue was in our Webpacker configuration.

Our webpacker.yml contained this:

default: &default
    source_path: app-web
    source_entry_path: react
...

Because of the way our app is structured, this meant we were telling Webpacker to process ALL of our React and Redux-related files, which were increasing in number with every sprint. As I researched the deploy failures, I learned about a helpful of rule of thumb about Webpacker from Ross Kaffenberger's blog:

If any file in Webpacker's "packs" directory does not also have a corresponding javascript_pack_tag in your application, then you're overpacking.

Based on this rule, I should've seen just one file in our packs directory. What I saw, though, was essentially a replica of the entire structure of our /app-web/react directory. We were overpacking.

Ultimately, we moved only the two necessary files into a startup directory and reconfigured webpacker.yml to use that as its entry point:

default: &default
    source_path: app-web
    source_entry_path: react/startup
...

What I Learned

What is Webpacker, and what does it do?

Webpacker is a gem which allows Rails apps to use webpack to process and bundle assets, particularly JavaScript.

According to its documentation, webpack "is a static module bundler for modern JavaScript applications. When webpack processes your application, it internally builds a dependency graph which maps every module your project needs and generates one or more bundles."

Okay, cool. But what does that actually mean?

Webpack basically does the work of figuring out what depends on what in your application to generate the minimum "bundles" of assets required to run your app. You include these minimum packs in your application - in Rails, like below - so the app can load with the necessary assets already compiled.

<%= javascript_pack_tag 'application' %>

See this article for a much more in-depth intro to what webpack actually does and why module bundlers are needed.

Why was our configuration wrong?

Since webpack builds a dependency graph based on a specified entry point, the greater the number of items in that entry point, the more processing time and resources needed. Because our configuration told Webpacker to process ALL of our React files, this required more time and server resources as we added more files to the React directory.

So, basically, the idea was to not ask Webpacker to process every single file in our React application, but only the entry points to the React app (aka the files that have corresponding javascript_pack_tags), so that they and their immediate dependencies would be ready on initial application load.

Impact

This fix unblocked our deploys and dramatically reduced our deploy times and resource usage on our deploy server.

	Deploy Time	Max Deploy CPU Usage	Max Deploy Memory Usage
Before Fix	> 24 min	~90%	~2.2GB
After Fix	10 min	~60%	~0.28GB

So, lesson learned - don't overpack with Webpacker! 🧳

Photo by Erwan Hesry on Unsplash

Strong, Not Perfect: How I Overcome Perfectionism Paralysis

Amy Henning — Mon, 20 Apr 2020 00:04:32 +0000

Confession: Like Chidi from The Good Place, I am a person who often suffers from decision paralysis. As Chidi failed in life to make ethically-perfect decisions, I often find myself hampered by perfectionism.

According to the StrengthsFinder inventory (I've had to do this thing many times for different jobs), "Input," as defined below, is one of my top strengths:

People exceptionally talented in the Input theme have a need to collect and archive. They may accumulate information, ideas, artifacts or even relationships.

My need to gather lots of information to make the best decision certainly helps me make informed decisions; and of course, it fuels my desire to constantly learn (which ultimately led me to this career). At other times, it hinders more than helps me and causes an endless cycle of information-gathering in pursuit of a perfect answer or option, until I feel like this:

Case in point: a few years ago, I spent weeks evaluating and comparing two different half marathon training apps, comparing their features and reading countless reviews of them online, before ultimately settling on one. In hindsight, it's ridiculous that I spent so much time on a decision of such relatively small significance.

Decision paralysis creeps up on me in my work in tech, too. It took me several months to redo my personal site, partly because I was very busy moving across the country and settling into my first full-time engineering job, but also because I went back and forth on tiny design details like fonts and link colors and waffled between a .dev and a .codes domain. Late last year, I posted this on Twitter:

Amy Henning

@henningamy

So I decided to start working on my personal site again over this holiday break and was all ready to not obsess over little details (i.e. just finish this thing I started in like, January) yet here I sit, editing link colors after midnight.🤦🏻‍♀️

06:15 AM - 28 Dec 2019

When I finally deployed my personal site in early April of 2020, it was with the knowledge that it was almost where I wanted it to be. There's a long list of things I want to improve: I could have formatted the blog post listing more creatively, I could have tried more combinations of fonts, I could have implemented a more visually-appealing list of skills and tools on the work page, I could have done more research into CSS transitions for toggling light/dark mode, I could have spent more time understanding GraphQL deeply, I could have built things from scratch instead of using Gatsby plugins . . . you get the idea.

I'm still not super satisfied with all of the things on that list. So how did I overcome the indecision caused by the pursuit of perfection? Here are some things I've been trying to keep in mind.

Focus on Strong, Not Perfect

One of my colleagues in the education non-profit world often used the phrase "strong, not perfect" to describe the desired outcome of a project, knowing that we could never write a single curriculum that met the needs of every one of our over 10,000 students. We did, however, design something really good that we believed, based on research, would resonate with as many students as possible.

I've worked hard to apply this mantra to my work in tech. I used to worry about covering every edge case and fretted that I wasn't optimizing code as much as possible in every PR. While there is, of course, value in doing one's due diligence, I don't think it's worth it to allow perfectionism to hold up good work. Now, I focus on doing my research, opening a PR with well-functioning and tested code, and knowing that I'll likely get helpful feedback to make it even better.

Similarly, I could have outlined solutions to the long list of things I want to improve in my site, then started working on all of them before deploying. That would have meant a significant delay in having a live site, though. So instead of obsessing over relatively minor decisions (i.e., things the site could function without), I decided to go ahead and deploy something good and focus on the nice-to-have details later.

Define "Good Enough"

Another thing that has helped me is setting clear expectations for what I hope to accomplish with a feature. What does completion look like? When does my work on one thing end, and another begin? What is "good enough"?

The answers to those questions come in the form of acceptance criteria in every ticket I work on at my job, and I'm lucky to have great product managers on my team who I can go to for clarification on the exact scope of a ticket if needed.

But what about personal projects? For this site, I wrote mini "tickets" for myself with bare minimum acceptance criteria to achieve to ensure I was making steady progress. Completing these empowered me to move on with things in a good-enough state, even if they weren't exactly as I envisioned.

Improve in Iterations

That last point leads me here: the importance of iterating to make incremental, yet steady, change. Accepting that I can do multiple rounds of improvements on a thing helped me just get started instead of being paralyzed by the desire for perfection.

At work, we build large features iteratively, laying the groundwork for a feature in one ticket and improving it with subsequent work to eventually achieve the vision for the project. With my site, I used my definition of "good enough" to get it live, and have been making small tweaks to it when I have time.

* * *

These three ideas have allowed me to make more progress on personal projects lately than I have in a long, long time. Some of the ideas came from my career as an educator, and others are lessons learned as an engineer.

Don't get me wrong - I am not advocating for submitting half-finished code at work or not putting in time and effort. But things don't need to be utterly perfect for them to be good, and something good can be improved. It can be scary to let go of the desire to churn out perfect projects or perfectly optimized code, but in a way it is also liberating to let go of unrealistic expectations.

Recreating the Pokémon Red/Blue Pokédex

Amy Henning — Tue, 07 Apr 2020 03:21:23 +0000

When I started my current job last spring, my engineering team's onboarding curriculum involved (among other things) integrating with an external API to build a microservice in Python; I worked with the PokéAPI. I had grand plans for styling the final product that didn't come to fruition due to time constraints, but I knew I'd want to come back to those original ideas.

In this post, I focus on my thought process while building pokedexapp.com instead of sharing code snippets tutorial-style. This is an intentional choice I've made with myself as a true beginner in mind: when I was first learning to code, I craved insight into how and why engineers make technical decisions when not following a tutorial - and I am still learning more about this topic all the time. I hope this post is helpful in some way to others!

Getting Started

Last month, I found myself with the time and energy to focus on a personal project, so I decided to rebuild my Pokédex app.

Decision point: What were my goals in recreating this app, besides the '90s nostalgia factor?

I knew from the start that I wanted my app to look as similar to the original Red and Blue versions of the game as possible. I also knew I wanted to use this project to continue to practice front-end work.

Decision point: Which technologies could I use? Which were appropriate for the app's purpose and my goals?

I considered creating a Rails backend application and then using react-on-rails for the front-end. However, since the PokéAPI is GET-only (and my application would be as well), it didn't make sense to build a server-side application. I left behind my Rails comfort zone and decided to work with create-react-app to set up my Pokédex in React.

Design

As mentioned above, I knew I wanted my app to mimic the style of the 1990s GameBoy games as closely as possible.

Decision point: What exactly does "mimic the style of the 1990s Gameboy games" even mean?

I settled on a couple key screenshots from the first generation games to use as my "wireframes":

Screenshot that guided the first of two components containing data from the API

Screenshot that guided the second of two components containing data from the API

Throughout the development of the app, I returned to these images constantly to guide my work.

Data

Since I had used the PokéAPI before, I knew that it returns a LOT of data on a single request. I also knew that it has multiple endpoints for different and sometimes overlapping sets of information. However, I had completely forgotten where the relevant data would be in each of those.

Decision point: How did I want to approach figuring out how to work with the API's responses?

I could've created the different components of the application, then fetched the gigantic response objects and messed around with them in the UI. However, that would have entangled my process for getting better at React with my need to figure out the deeply-nested API responses.

Before even touching the React app, I instead combed through the responses from two endpoints: /api/v2/pokemon/${pokemon-name} and /api/v2/pokemon-species/${pokemon-name}. This meant lots of curl requests and command-line manipulation of the JSON responses to find the data I would need to bring the "wireframes" to life. I eventually mapped the specific data roughly to where I would want things to show up in the UI.

Some hand-drawn wireframes to map data to the UI

The "wireframes" I chose were key to helping guide me through this phase of planning the project. Without them, I would have been overwhelmed by the sheer amount of information that the PokéAPI can provide.

Components

From there, I started writing code. A major goal of mine was to practice thinking through how props are passed from component to component in something a little more complex than the tutorials I'd been doing but less complex than the giant application my team maintains at work. As I got deeper into developing the components, I started losing track of how the they were working together.

Decision point: How could I make my confusion into an opportunity to think more clearly about props and state?

I could have gone to the old standby of Googling for similar projects and mimicking their structure. In an effort to become more self-sufficient at React and application-level decision making, I instead roughly sketched what I wanted each component to know and do in order to fulfill my vision for the app. (If you couldn't tell already, I do a lot of my best thinking when sketching things out on paper.)

A rough sketch to keep components, props, and state straight

These sketches guided me to getting the app to a workable (if ugly) initial state, pulling in the right data from the API to the individual components:

The working app in its early, ugly stage

Since the minimal components were working at this point, I decided it was safe to move on to styling the app.

Styling

I will be honest - styling (if I'm doing it from scratch, as I was for this app) is, for me, usually the most time-consuming stage of developing any application. I am extremely detail-oriented, so I can end up spending a lot of time on tiny details. Knowing this about myself, I took an iterative approach without making a conscious decision to do so.

The first major iteration looked like this:

Lots of progress from the earlier iteration, but still not done!

I was pretty happy with this version, but there definitely was room to improve: tiny details (boxes and Pokéball illustrations) on each component were missing, the position of the arrows was weird, the arrows on the stats component were missing, I didn't have much good error handling (which is less visible but still important!), and the UX when awaiting a response from the API was pretty unhelpful.

Decision point: What did I want to prioritize while styling the application to avoid working on it forever?

Small deviations from the wireframes didn't bother me too much - I was fine with having separate Special Attack and Special Defense categories and using metric measurements for Pokémon height and weight (the PokéAPI returns weight in hectograms and height in decimeters, for some reason, so converting those to feet/inches and pounds would have been a headache). I also left off the little arrows on the stats component borders.

I invested a lot of time styling some more visual details and implementing a better UX while awaiting API responses and on invalid input. The whole thing involved quite a bit of experimentation, Googling CSS tricks, and trial and error (as engineering often does). The finished product wound up looking like this:

Bonus points to anyone who gets the Pokérap reference :)

Deployment

Despite having a working app, I put off deploying it because I wasn't sure how I wanted to do so. I knew of a couple options (namely, Heroku and Netlify), but wasn't sure if I should research others to learn something new.

Decision point: How should I deploy the finished app to production?

Almost every personal project I've worked on in the past has been deployed with Heroku. The Heroku apps I've deployed in the past are pretty slow, though, and I was interested in trying something new.

I ultimately chose Netlify to deploy the app and register its domain name. While there are many options available and I could've spent more time practicing getting DNS and certificates set up, it just wasn't the focus of this project. I also had been sitting on a complete project for a few days, and I just wanted to get it out into the world. There is nothing wrong with using existing tools to get a job done!

In addition to easy deployment and domain setup, I really liked that Netlify offers previews before a deploy and that the preview URLs essentially allow you to archive versions of your site. Their CLI was easy to use (I referenced this article). I'm also intrigued by their continuous deployment feature and plan to try it out with my personal site.

Wrapping Up

Tracking my process for developing this app proved how even an application as simple as this one contains many decision points (also that I can be indecisive!). I hope this post is helpful in illustrating the decision-making processes that engineers go through constantly. Feel free to check out the finished Pokédex at pokedexapp.com!

Overcoming Imposter Syndrome On My Journey Into Tech

Amy Henning — Sun, 08 Mar 2020 04:42:58 +0000

A little over a year ago, I transitioned into tech as a career-changer with a B.A. in English and an M.A. in teaching. It wasn't a straightforward or easy journey, but it's one of which I am proud. I'm particularly glad to be on the other side of some nasty, decades-old imposter syndrome.

Let's Start in 2012

My former apartment building

I once lived in this apartment building. In 2012, I was living here and dreaming of what I could do besides teaching - I was utterly burned out from teaching kindergarten.

A myriad of options occurred to me - working for a non-profit, teaching high school, going into fundraising, working at Starbucks . . . but I never considered coding as a serious career option. This was, in large part, due to intense imposter syndrome that had built up over the years. I'll have to rewind a bit further to explain the origins of that imposter syndrome, however.

The Early Days: A Fun Hobby

A journal layout I designed in the early 2000s

As a high schooler, I taught myself to code so I could customize layouts for online journaling platforms (Diaryland, Livejournal, Xanga, etc.) for myself and my friends. I also built a number of ~~official~~ fan sites for things like books and local bands, and had them hosted by people with their own domains (I was not nearly that advanced).

At the time, I found web design to be a fun after-school hobby. Being self-taught and driven to succeed in school, it wasn't something I took too seriously. But it didn't intimidate me, either.

A Whisper of Imposter Syndrome

> hello world
> goodbye, programming

As high school progressed, I focused more on my schoolwork than on building websites. I let my sites fall by the wayside.

I also started dating someone who was a talented programmer. I have very vivid memories of him guiding me through writing my first hello world program. I can't remember which language we used, but I distinctly remember thinking, "This is his world, not mine. I'm not good enough for this."

In my mind, coding was for people who loved math (I took every math class I could in high school but didn't like it very much) and gathered with their friends at LAN parties--not for clarinet-playing, book-loving girls like me. Thus, imposter syndrome stopped me from learning more about programming at age 17.

Becoming "A Humanities Person"

Spirograph art similar to what we created in my Intro to Comp Sci class - source

At some point early in college, I decided I was just not a science-y or technical person, despite excelling in AP science and math in high school. I eventually majored in English with a concentration (kind of like a minor) in Linguistics.

My mindset followed trends in the gender gap in STEM that has been widely researched and reported on. That isn't to say I didn't try - to be able to take a computational linguistics class, I had to take Intro to Computer Science.

I liked the class and problem-solving logically, but was frankly intimidated by such technical work that was seemingly without practical application. (We used Scheme to essentially generate spirograph images like the one above.) Thus, imposter syndrome and the mindset it engendered prevented me from even attempting to take the computational linguistics course or any other computer science classes. I focused instead on anthropological linguistics.

Doing the Same Thing Repeatedly Produces the Same Results

Fox spinning - source

Back to 2012: I was dreaming of new jobs and career possibilities. I wasn't bold (or jaded) enough to make a significant pivot, however; instead, I chose to teach high school.

I endured 6.5 more years in education, going on to lead curriculum design for a national non-profit after 2 years teaching high school English. The reasons I say "endured" (and why I eventually left) are significant enough to warrant their own series of blog posts.

Suffice to say, I realized in early 2018 that I would continue to get similar results if I continued doing the same things that made me so intensely unhappy. At this point, three of my former teaching colleagues had attended coding bootcamps and launched careers as developers, and I was intrigued.

Doubting Myself

> hello again, world!
> hello, programming <3

By the spring of 2018, I was 100% ready to give up my career in education. The final roadblock was largely mental: what would my friends and family think about non-technical me trying to go into tech? Would they scoff at the idea? Would they support me outwardly and keep their doubts to themselves?

At the end of the day, the person with the biggest doubts was me. Half a lifetime of imposter syndrome had reared its head and nearly prevented me from taking the leap. The alternative, however, was to continue facing the monster that was my education job (again, a story for another time). So I enrolled in a coding bootcamp to try and start fresh.

The Payoff

Mid-2018, I turned down a job offer in education with no prospects of a tech job but every hope that things would work out. In September 2018, I graduated from my program and was hired to do contract engineering work by an edtech startup. After working as a technical teaching assistant at my bootcamp for a few months, I was hired into my first full-time engineering job.

The view of my old building from my office

Today, from my office, I can see the same building I lived in while contemplating my future career. Imposter syndrome still gets me from time to time in my current work - and I'm sure it will continue to do so. But I have cleared the biggest mental hurdles that, for so long, kept me from digging deeper into something I enjoyed so much as a kid and still do today.