DEV Community: Anna Rankin

Framing your Narrative

Anna Rankin — Tue, 18 Feb 2020 01:01:48 +0000

As the number of folks transitioning into tech from previous careers climbs, I think it's important that we train ourselves to look at our pasts for the catalysts that lead us here. Over the years, I've noticed that the ability to create a coherent narrative out of my personal and employment history has been extremely helpful, both for staying personally motivated and for convincing employers that I'll be a good fit for their team.

What use is a narrative?

Human beings like narratives! Storytelling presents events in a logical, ordered way - as opposed to chaos, which generally makes us anxious. We can take advantage of this mental bias to help ourselves (and our future employers!) see ourselves as on a path to our new careers.

Consider these two stories:

Anna Rankin decided to pursue art in college after a clerical error put her in an "Art 101" class instead of Chorus. After graduating, she spent two years in a government internship doing graphic design. In 2011, she moved to China to teach English to young children. On her return to the USA in 2013, she worked as a Starbucks barista for several months before being rehired by her boss from her former internship. After taking a 12-week coding course, she took a job at the company that ran the class and has worked for them since.

...versus:

Anna Rankin still remembers her first programming experience at the age of four, when her father taught her how to make randomly sized circles appear on the screen of their monstrous desktop PC. From teaching herself how to code for an online game to creating websites in plain text to showcase her artwork at 12, her activities always tended toward technical creativity. After obtaining her degree in illustration and teaching ESL abroad, she felt herself drawn to both education and programming as a craft. While learning to code at General Assembly, she found a community of like-minded people. She joined their engineering team and now works directly on the ed-tech products that students (just like her in the past) use today!

What differences do you notice between these two descriptions? How does reading each make you feel?

To me, the first of these comes across as sterile; directionless. It's almost like someone took a LinkedIn history and turned it into sentences! There's no real sense of direction or agency. Since there's no reasoning provided for each new career choice, I might even think this Anna person is a bit flighty or scatter-brained.

The second tells a strong, coherent story with descriptive, relevant examples from the past. It leaves out irrelevant details in order to paint a concise picture of who I am now and what's important to me. More than that, it seems like a reasonable progression to a logical conclusion.

What if I don't have a consistent story?

You have a vast number of experiences that form who you are by the time you're an adult—the ones you choose to focus on shape who you are now. I'm not asking you to retcon your personal history or make things up to seem like a better potential employee, but instead, to sift through the things that are important to you and showcase them as steps toward to your current goal.

For example: If you're coming into technology as an artist, what processes and perspectives do you bring to programming? If you're a former chef, what analogies can you draw from your past experience to your current pursuits? Have you navigated difficult interpersonal relationships with skill and aplomb? No matter what field you come from, chances are that you learned something you can apply to your new career.

I still remember my first job interview. I was terrified; going in for a graphic design internship as a traditional (pastel, paint) artist. My interviewer (and later boss) hit me with a tough question:

"Why should I hire you when you don't have any experience with graphic design? What sets you apart from the applicants who have already worked with the programs we use?"

I told her that my experience as an illustrator and my ability to compose evocative images set me apart - that a program was just a tool, and I was confident that I could create quality graphics regardless of the medium (not nearly this eloquently I am so sure). My boss told me years later that this answer was why she chose me for the role. My ability to frame my capability in terms of my existing experience literally got me the job.

Can this help me with my impostor syndrome?

Framing your journey as a story can also help a lot with personal motivation. When all you can see in your history feels like a jumble of unrelated jobs and irrelevant skills, it's easier to get overwhelmed and want to throw in the towel. Discovering a consistent narrative is calming; inspiring. Looking back at my past through the lens of that second bio, it almost seems like landing at my current job was an inevitable result of everything that led up to it. In the same way, your past has been leading you inexorably toward exactly where you are now!

In her book "Rocking the Boat," Debra Meyerson presents her research into how individual and systemic change is created in organizations. When discussing how powerful it is to frame small wins as part of larger initiatives, she notes that "...people's understanding of what an action means can be every bit as important as the action itself." This holds true for our personal histories as well! Without framing, the events in your past are just stark facts, ready to be interpreted in any way your audience sees fit. As the only person in the world who has lived your life, you are the best suited individual to provide context on how it's unfolding. Providing this context gives you the power to assign specific meaning to your existence rather than letting other people define you.

Let's try it!

As an experiment, I'd like you to try and create yourself a quick elevator pitch (three to five sentences). Ask yourself these questions:

Can you remember the first experience that interested you in technology? What was that like?
What parts of your past experience or employment have prepared you to become a technologist? What are you really good at? What are you excited to bring to a team?
What moves you? What are you really excited about for the present or future?

I learned how to write a good bio and present my story in a compelling way at Global Diversity CFP day and Write/Speak/Code events—two excellent organizations ♥ Also, if you're in the market for a job, I highly recommend this read on showing off your hireability (and also this talk on storytelling because it's also good) from the inimitable Catt Small!

RubyConf 2019 Sketchnotes

Anna Rankin — Sat, 23 Nov 2019 16:20:22 +0000

I had a fantastic time this year at RubyConf in Nashville! This year, I committed to trying out sketchnoting, or visual note-taking. I had a great time at Write/Speak/Code this past August at Denise Yu's excellent workshop "Telling stories with doodles" and have been meaning to experiment ever since!

Other sketchnoters I highly admire:

Here's a selection of my notes from the conference:

Principles of Awesome APIs and How to Build Them

Keavy McMinn
Excellent presentation on API development best practices!

ElasticSearch 5 or and Bust!

[Deleted User]

Molly's talk walked us through an ElasticSearch upgrade gone awry - and the recovery process.

OOP in Pictures

Ivan Nemytchenko
Nemytchenko's presentation detailed creating and using a visual language to teach OOP concepts -- with robots!

Ruby & Sentiment Analysis

Ben Greenberg
Ben demonstrated how to use free tools to create an app that tells you the "mood" of the news for the day.

What Happens when a Linguist Learns to Code?

Erica Sosa
Erica gave an overview of her journey from linguistics to programming, as well as going over the concepts that language learners in both fields deal with.

Fixing Performance and Memory Problems

Frederick Cheung
Frederick's talk led us through the process of finding sneaky memory leaks and gave us tools for hunting down the culprits.

Fun, Friendly Computer Science

Mercedes Bernard
Mercedes walked us through several key computer science concepts in an approachable way -- very helpful for interviews!

Late, Over Budget, and Happy

Amy Newell & Nat Budin
I very much enjoyed Amy and Nat's heartfelt and honest presentation of the lessons they learned during a skunkworks project.

Lucky You

Sandi Metz
Sandi dropped a ton of data on us for the third day's keynote, reminding us how very lucky we are to be in software - and how the demographic someone is born into is even more important than luck.

You might think a pirate's favorite programming language is R...

Anna Rankin — Sat, 06 Jul 2019 03:58:05 +0000

...but his first love be the C! 🌊

Equality of Data Structures: Ruby vs. JavaScript

Anna Rankin — Sun, 07 Apr 2019 15:48:12 +0000

Skip to the TL;DR

In recent weeks I've been reading through JavaScript Allongé by Reginald Braithwaite (an excellent look at the fundamentals of JS through a functional programming lens) with a coworker. My coworker brought up something that didn't make sense to her:

In JavaScript, why isn't an empty array equal to an empty array? What's the difference between the two identical objects?

To someone who's been working with JavaScript for a while, the answer might seem straightforward: "They're two different arrays; of course one is not equal to the other!" A Rubyist like my friend, however, may see it differently: "These two arrays have the same content—what do you mean they're not equal?" As I see it, this is a philosophical difference between the meanings of the comparison operators in Ruby and JavaScript. One language uses the concept of object equivalence to compare data structures, while the other checks explicitly for object identity.

Note: I'm not going to discuss the JS double equal or Ruby's threequal operators, as these are more than just simple comparison operators (I also avoid using them because they can be confusing and misleading!).

Equality of Data Structures in Ruby

When you compare data structures using the built-in behavior of == in Ruby, you're really comparing the contents of the object—and in the case of an array, you're also checking that the order of the elements is the same in both. This means that two variables that point to different objects in memory could be equal.

> first_array, second_array = [1,2,3], [1,2,3]

> first_array == second_array
=> true

If for some reason you truly want to check and see that two variables refer to the same object, you can check object's ID—or preferably, use the .equal? method:

> first_array, second_array = [1,2,3], [1,2,3]

> first_array.object_id == second_array.object_id # 70176467875700 == 70176467875680
=> false
> first_array.equal?(second_array) # a clearer way to perform this comparison
=> false

Unlike in JavaScript, the comparison operator in Ruby is actually a method defined on the class you're comparing (awesome walkthrough of this concept here). Since == is just a method, you can even override it if you like! This is a reasonable practice if you're writing custom classes that need to be compared to each other. Silly example below:

> class Ditto
*   def self.==(other)
*     true
*   end
* end

> Ditto == 'Pikachu'
=> true
> Ditto == 2
=> true
> Ditto == false
=> true

Equality of Data Structures in JavaScript

Unlike Ruby, JavaScript does not expose a unique ID for objects because it doesn't need to. Data structures are compared by identity by default. If two variables are equal, you can be sure that they point to the same object in memory.

> const firstArray = [1,2,3]
> const secondArray = [1,2,3]
> firstArray === secondArray
false

If you want to check and see if two separate data structures have the same content, you'll have to write your own logic to check—or use a function from a library like Lodash.

// Super naïve implementation:
const arraysAreEqual = (array1, array2) => {
  return array1.every((el, index) => el === array2[index])
}
> arraysAreEqual([1,2,3],[1,2,3])
true
> arraysAreEqual([1,2,3],['a','b','c'])
false

TL;DR

JavaScript's === checks to see if the two variables it's comparing point to the same data structure, while Ruby's == method checks to see if the contents of two arrays or hashes are equivalent.

Ruby's [1,2,3] == [1,2,3] translates to [1,2,3].every((el, index) => el === [1,2,3][index]) in JS.

JavaScript's [1,2,3] === [1,2,3] translates to [1,2,3].equal?([1,2,3]) in Ruby.

References

Hopefully this helps you wrap your mind around what the two different languages expect when comparing data structures! If you're interested in going deeper, I've put together some references:

MDN docs on equality and sameness in JS
A fun JavaScript equality table (bonus points for the if() explanations!)
Intro to Ruby's Comparison Operators
RubyMonk's custom .== method example

Nevertheless, Anna Still Codes

Anna Rankin — Mon, 11 Mar 2019 20:20:08 +0000

In 2019, I continue to code, mentor, and write because I love the challenge—I've left previous careers due to boredom and lack of engagement. My job is a lot of things, but boring is sure not one of them!

I think I do deserve some credit for the amount of personal growth I've packed into the past year. I've practiced my writing, improved my knowledge around lower-level tools and infrastructure, and taken some big strides in demonstrating leadership and responsibility on my team and within my organization as a whole. I've pushed through some intense stress and anxiety to overcome my own limitations (and discovered brand new limitations!).

This year, I hope to see even more intermediate and advanced community-led programming training proliferate in tech! We could all use more mid-level and senior developers, but we won't see them shine until we help them grow.

Tips for Self-Reviews

Anna Rankin — Thu, 31 Jan 2019 14:52:36 +0000

It's performance review season for me and the rest of the folks at General Assembly — a time of year that lends itself to introspection (along with a host of other emotions). Everyone approaches reviews differently: with trepidation, excitement, annoyance, indifference. I try to look forward to sharing feedback with my manager and teammates — it's great to have a process, as well as regular, dedicated time to reflect on personal progress and performance, measured in a way that's meaningful to me.

Though not all review processes include the exact steps or methods I talk about below, I believe that general ideas (honesty, self-kindness, and specificity) still apply. I'm not going to talk about giving feedback to others (this post is long enough already 😂), but instead focus on self-evaluation, goal-setting, and making good use of the feedback you receive. Below are some tips that I've found useful as I've gone through this process over the years — what to include, where to look for salient information about your performance, and how to use feedback you're given in a valuable way.

At GA, our performance review cycle looks like this:

Employees write a self-review and a review of their manager
Coworkers review each other (anonymously)
Managers review their direct reports (along with writing their own self-review)
Managers and employees meet to discuss all this feedback and talk about next steps

Self Review

The dreaded self-review! 😱 Even with specific questions outlined for me to answer, this is the hardest part of the process for me. Rather than writing my responses as paragraphs, I generally create an outline of bullet points and fill in relevant supporting details as I go.

Calling out the good stuff

Like many developers, I deal with impostor syndrome on a daily basis. Initially, it was very difficult for me to call out my strengths and accomplishments without anxiety (or immediately diminishing them in the next sentence). I still struggle with the fear of coming off as arrogant or overconfident when I list the things I'm proud of doing. Some things that really helped me out were:

Find concrete records of your past work

If you use a system like JIRA or Trello to track what you do, you can use this to reflect on your completed work. A lot can happen in six months - chances are there are some accomplishments you forgot about hiding in that list of tickets!
About a year and a half ago, I started tracking my daily to-dos in a markdown file (I use Bear, but I've talked to folks who use Google Docs, the Apple Notes app, and Evernote to great success). I also use this file to track "shoulder-taps" (day-to-day requests for help or clarification), meetings, and other tasks along with the approximate time I spent on them. This kind of low-level detail is fun and useful for me to look back over when I'm thinking about what I spent the majority of my time doing (and is a good place to see patterns!).
If you don't have a robust work tracking system, try looking through work-related emails and dated documents. Chances are there's enough there to jog your memory!

Review past work artifacts

This is mostly applicable if you're involved in creating documentation or putting together proposals/project briefs, but can also apply to PRs you've created and features you've helped implement.

Look at new skills you've picked up

Maybe you converted your project's front-end to React from jQuery or debugged a hairy database problem; maybe you started working on server logic for the first time. Anything you've done for the first time should be recorded as a win!
Go beyond technical accomplishments. Anything that affects your performance and value as an employee is fair game — leading a project, giving a talk, participating in mentorship, or writing blog posts (😉) are all important to factor into your overall performance.

Being honest about areas that need growth

Looking at parts of yourself that need to change can be a painful and humbling experience, but is absolutely essential to your personal growth. It's vital to know what needs improvement so that you can best focus your efforts on moving to the next level (personally AND professionally). Dan Abramov's recent post "Things I Don't Know as of 2018" was a really cool example of an incredibly accomplished developer assessing gaps in his technical knowledge. With a concrete list of things you want to work on, choosing goals becomes a lot easier.

It's just as important not to dwell on your shortcomings. Like any bug, they should be acknowledged, triaged, and eventually a plan should be made to address them. Here are a few categories I've focused on in the past:

Technical skills

Is there a part of the codebase you wish you knew more about? Maybe you're interested in your team's deployment setup, but only have a cursory knowledge of what goes on. Do you want to work on application architecture skills or feel you lack an understanding of the tools you use on a daily basis? Anything you want to level up in is a good choice here.
Remember to be very specific — "I suck at Ruby" or "I want to get better at deploying things" are less valuable than "I want to improve my understanding of OOP at a high level and make better design decisions in practice (example here)" or "I want to understand how we automate deployments and the steps that go into pushing new code to production."

Workflow improvements

Everyone (well, almost everyone) says they need to get better at "time management." Drill deeper and question if that's really the problem. Maybe it's actually a problem with distractions, how you track your time, or how you plan out your day.
Think about parts of the development process where you frequently feel friction. For example, I struggled for some time to get my PRs reviewed and merged in a timely manner. I made a commitment to let no more than two days go by without movement on a PR, and am proud to say that I've gotten much braver about reminding my coworkers that I need their feedback and much better about taking action on that feedback quickly.

Leadership & mentorship

If you're interested in leading teams or projects, consider bringing this up in your review. Taking on even a small leadership role can be a powerful way to learn from your peers and demonstrate competence. For example, I took on the task of starting and leading our bi-monthly JavaScript "council" meetings at work. I was intimidated and anxious at first, but after some format failures and experimentation, we managed to find our groove! I love knowing that these meetings have real value to my coworkers (which also serves as a huge motivator to keep them valuable).
Mentorship is a very personal goal for me. If you're excited about education or want to help mentor folks who are newer to the field, you should definitely set a goal to do so. It doesn't need to be formal, either! I've learned a lot from "unofficial" mentoring and being mentored, and it can be very fulfilling to give back to the tech community.

Setting Goals

All this reflection (combined with the feedback you get from others) means nothing unless you do something with it! Once you've had some time to process (and look over, if applicable) any feedback you receive, talk with your manager about what your focus will be for the next six months. Set three to five concrete goals based on what you, your peers, and your manager laid out in the reviews. Good goals are:

Specific. Vague goals are harder to complete than goals with concrete acceptance criteria (much like work tickets 🤔). Consider replacing "Get better at Python" (for example) with a step you want to take in that direction, like "Attend two Python meetups a month" or "Finish that advanced Python course I bought three months ago."
Focused. Set yourself up for success rather than trying to improve every single thing you can think of. The saying that "If everything's important, nothing is important" is applicable here. Give the goals you choose to work on the importance they deserve by giving yourself enough bandwidth to work on each of them.
Personally meaningful. Avoid choosing goals based solely on what your manager/another party thinks you should do — or what you think you're supposed to choose. If your goals aren't truly yours, your motivation to complete them will be lacking (and they'll be more likely to go undone because of it). Even worse, you're choosing to invest your time in something you might not care about instead of something you're really excited about. (One caveat here: if your manager tells you that you need to work on something, you should absolutely work on it — and work on understanding its importance to your daily work.)
Out of your comfort zone. Don't be afraid to push yourself a little when setting goals. You might be surprised to find what you can accomplish in a single review period if you set ambitious goals! Do work with your manager to make sure they're attainable, though. For example, it might not be practical for you to give four talks in the next four months, or read ten new programming books (or maybe it is!). Just make sure you're got the time and support to achieve what you set out to do.

At the end of the day

Whatever your experience with performance reviews has been or what the process at your company looks like, I hope these tips are helpful to you. It's worth noting that this advice works best in organizations with a healthy, candid feedback culture. As with any bundle of advice, please use with caution and awareness of the environment you operate in.

Ways of Seeing: ORMS & SQL Views

Anna Rankin — Thu, 22 Nov 2018 04:51:03 +0000

This article assumes a general understanding of how databases, Ruby, and Rails work - the examples below use the ActiveRecord library to map database relations to Ruby objects in the context of a Rails application. Check out the example repository to see them in action! (Note: I have also set up a JavaScript example here if you're interested, but I haven't found a JS ORM that has first-class support for SQL views.)

Aggregation Aggravation

Web applications often display "summaries," or aggregated data, that may pull in information from and make calculations across several database tables. ORM (Object-Relational mapping) database modeling libraries are generally designed to read from one table at a time. While this pattern is useful for tons of use cases (basic CRUD for the win), we run the risk of complex application code and/or expensive DB querying when we try to aggregate data. SQL views can potentially help us cut down on the number of queries we make while pushing our data aggregation logic down into the database.

For example - imagine you've been hired to create an application that helps veterinarians communicate with their clients. A workflow like this (pared-down) example this might be familiar to you if you've created a server endpoint:

user = User.includes(:pets).find(1)

render json: {
  user: {
    id: user.id,
    name: "#{user.first_name} #{user.last_name}"
  },
  pets: user.pets.map do |pet|
    {
      id: pet.id,
      name: pet.name
    }
  end
}

The code above is pretty straightforward: it loads up a user, loads up their pets, and serializes the data in the format the front end expects. We're making two queries, but they're simple and (hopefully) fast — that's a reasonable expectation.

Fast forward a few weeks, and we've got a new requirement. Users can see which pets they have registered with you, but they also want to know "at-a-glance" when their next appointment is! So, you update the endpoint:

user = User
  .includes(:pets)
  .find(1)

# Pre-load the user's pets' appointments that are scheduled for the future
upcoming_appointments = user
  .appointments
  .order(date: :asc)  
  .where('date >= ?', Time.current)

render json: {
  user: {
    id: user.id,
    name: "#{user.first_name} #{user.last_name}"
  },
  pets: user.pets.map do |pet|
    # Use Array#find to return the first of this pet's appointments
    next_appointment_date = upcoming_appointments.find do |appt|
      appt.pet_id == pet.id
    end

    {
      id: pet.id,
      name: pet.name,
      next_appointment_date: next_appointment_date
    }
  end
}

Honestly, this still isn't too bad. We've added another query — this time for appointments — with some ordering and filtering logic. We're also adding in some looping logic in our serialization step to pull out the first appointment for each of the owner's pets. It's a bit untidy, but hey, it works.

Personally, I don't like encoding all of this behavior in the application code. It feels messy to me, and it's far too easy for something nefarious to sneak in. For example, imagine we'd done this instead:

render json: {
  user: {
    id: user.id,
    name: "#{user.first_name} #{user.last_name}"
  },
  pets: user.pets.map do |pet|
    next_appointment_date = user
      .appointments
      .order(date: :asc)
      .find_by('date >= ?', Time.current)
      &.date

    {
      id: pet.id,
      name: pet.name,
      next_appointment_date: next_appointment_date
    }
  end
}

🙀Oh no! Someone snuck a query into our serialization step, and while this might not ring any alarm bells at first (when you're dealing with one or two pets per user), what happens when the local animal shelter becomes one of your clients and registers over a hundred pets? Over a hundred queries per page load.

This is obviously a contrived example, but I've run into more complex cases where N+1 queries were hidden away in service objects and separate files. I personally like to push this kind of logic down a level — into the database - when it starts getting more complicated or when I need it elsewhere in my application. That's where SQL views come in!

What is a SQL view?

My mental model of a SQL view at its most basic is "a saved query in your database that acts like a table." There's a lot more to it than that, but this simple understanding can get you a long way. For example, if I executed the following statement in my database:

CREATE VIEW silly_users AS
  SELECT 
    id, 
    first_name,
    first_name || ' Mc' || first_name || 'erson' AS silly_name
  FROM users;

More on the || concatenation operator

I can query results from this view using the same syntax I would for a table:

# SELECT * FROM silly_users;
  id   | first_name |       silly_name       
-------+------------+------------------------
     1 | Melissa    | Melissa McMelissaerson
     2 | Colleen    | Colleen McColleenerson
     3 | Vince      | Vince McVinceerson
     4 | David      | David McDaviderson
     5 | Dennis     | Dennis McDenniserson
...etc

Because this view acts pretty much like a table, it can play really nicely with an ORM. We can create a view-backed model!

silly_user = SillyUser.find(1)
silly_user.silly_name // => 'Melissa McMelissaerson'

If you're using Ruby, I highly recommend the Scenic gem by ThoughtBot, which brings view versioning and other helpful features to projects that use the ActiveRecord ORM.

A New Perspective

Let's try writing a database view to grab the data we want instead of querying for it in our application code (more here on using DISTINCT ON with GROUP BY):

-- Grabs one record per pet, returning the earliest future appointment date 
CREATE VIEW pets_with_upcoming_appointments AS
SELECT DISTINCT ON (pets.id)
  pets.id AS id,
  users.id AS user_id,
  pets.name AS name,
  MIN(appointments.date) AS next_appointment_date
FROM users
INNER JOIN pets
  ON user_id = users.id
LEFT JOIN appointments
  ON pets.id = pet_id
  AND appointments.date >= CURRENT_DATE
GROUP BY (
  users.id,
  pets.id,
  pets.name
);

Great! Now we can read from this view:

# SELECT * FROM pets_with_upcoming_appointments;

 user_id | pet_id | pet_name |  next_appointment_date   
---------+--------+----------+-----------------------
       1 |      1 | Flannery |   2018-11-22 13:00:00
       2 |      2 | Porkchop |   2018-11-22 16:30:00
       2 |      3 | Gravy    |   2018-12-01 09:00:00
       3 |      4 | Magnus   | 
       4 |      5 | Huey     |   2018-12-15 10:45:00
       4 |      6 | Duey     |   2018-12-15 10:45:00
       4 |      7 | Louie    |   2018-12-15 10:45:00

# SELECT * FROM pets_with_upcoming_appointments WHERE user_id = 1;

 user_id | pet_id | pet_name |  next_appointment_date   
---------+--------+----------+-----------------------
       1 |      1 | Flannery |   2018-11-22 13:00:00

Now that we've got the view set up, we could create a migration using the Scenic gem mentioned earlier, then hook it up to a database-backed ORM model:

class PetWithUpcomingAppointment < ActiveRecord::Base
  self.table_name = 'pets_with_upcoming_appointments'
end

Since our view has a user_id field, it's trivial to hook up a relation in our User model:

class User < ActiveRecord::Base
  has_many :pets
  # wooooot
  has_many :pet_with_upcoming_appointments
  has_many :appointments, through: :pets
end

Now, we can clean up our data-fetching application code:

user = User
  .includes(:pet_with_upcoming_appointments)
  .find(params[:id])

render json: {
  user: {
    id: user.id,
    name: "#{user.first_name} #{user.last_name}"
  },
  pets: user.pet_with_upcoming_appointments.map do |pet|
    {
      id: pet.id,
      name: pet.name,
      next_appointment_date: pet.next_appointment_date
    }
  end
}

Not bad! We're back down to two queries and no ordering/date comparison logic in the controller 💪 Even better, we can re-use this model in other parts of our application without duplicating the querying logic. This really starts to shine when you start performing more complex aggregation and pulling in data from different tables.

Pitfalls of SQL views

While I'm clearly a fan, there are some things you should watch out for when you start thinking about views in your application:

Overzealous viewification

This is another facet of the "I have a hammer, everything's a nail!" problem. When you first start playing around with them, you can find yourself pushing too much logic down into the database (where it's abstracted away and harder to find). You wind up having to run a lot of migrations because every time you need to change what your application serves up, you need to update or create a new view. 😬 Before you turn whatever you're working on into a view, ask yourself if the benefit you're gaining is worth the trade-off.

Too many levels of cascading views

Views are generally made up of results from tables, but you can also create a view that pulls in data from another view (A META VIEW!?). This can seem like a good idea ("I'll define what an 'active' user is in this view and then pull that in everywhere I need a user!"), but in practice, I've seen it make updating views at all levels more difficult. You can also drive yourself up a wall trying to figure out how a change in one view can affect another one that pulls in data from several levels away 😵 This is one that's really only a problem in tandem with the first point.

Propagated inefficiency

If you're familiar with profiling your SQL queries and using EXPLAIN/EXPLAIN ANALYZE to find issues (or if that LEFT JOIN appointments in the view above made you squirm 😂), this is a good time to put those skills to use! If indexes, hash joins, and sequential scans make your head spin, you might end up with seemingly simple queries running very slowly once you start to get more records in your database. Inefficient queries can end up supporting a ton of your app's functionality if you're not careful, leading to sluggish performance overall. At the least, check out the impact introducing a view has on the speed of the process that's using it.

What now?

If you're interested, here are some resources I'd recommend (and the links I've referenced throughout this post) to learn more! Live long, prosper, and fear not the database 🖖

Building a Graph in SQL Land

Anna Rankin — Mon, 08 Oct 2018 01:38:47 +0000

In the spirit of sharing failures and learning from them, I'd like to tell you a story about a time a younger me helped create a "clever" system to organize a content hierarchy. This cautionary tale is mostly for fun, but also to document some of the neat things and painful lessons I learned along the way. Names and entities have been changed to protect the innocent 😜

But ...why?

Long, long ago in a product team far away, there existed a project to create a new, more flexible hierarchy for collections of books. Originally, our data was set up like so:

A user had access to a collection of books ("Fiction" in this case); a collection contained several genres, which in turn contained individual books. A user could be granted access to see everything within a collection, and could create "reading lists" so they could favorite/categorize books based on their own criteria.

This worked well - a user could see all the fiction books in the collection, and they could even add these books to a personalized reading list. Later on, however, our product team started testing out a new collection:

We didn't initially want to allow all users to access the new "Nonfiction" collection, so we granted access to that separately.

We had a few issues - mainly that a user could only access and create reading lists from one collection at a time, and they had to switch between them manually in the UI. This worked well when we only had one collection, but lacked flexibility when we started adding more. Additionally, if a book appeared in more than one genre, its entry would need to be duplicated - our data structure didn't expect a book to have more than one genre 😬 Users were also prevented from adding books to their reading lists that didn't belong in any of our collections at all yet. If they wanted a one-stop shop to track what they were reading, they'd be out of luck.

The idea was that as we added more collections, we needed a better way to categorize our content and avoid duplication. Folks from across the organization worked together to create a new content structure:

Rather than segmenting our content into "collections," we'd house everything in a mega-collection - called the "library" - and allow books to appear in multiple genres. We hoped this would make our content more discoverable in searches, less duplicative, and would allow users to have reading lists with both fiction AND non-fiction titles on them.

Technologies

We were already working with some tried-and-true technologies in this application:

Postgres database (most SQL databases have some form of support for database views)
ActiveRecord within a Ruby on Rails application as an ORM

Now, our job as engineers was to implement the product vision and provide the tools our coworkers needed to interact with this new model. We had a choice: Do we create a series of discrete tables linked to each other by standard relations, or do we try something new?

(spoiler alert - we tried something new.)

Going Graph

It didn't take us long to decide that if we were going to create this new "world view," we wanted to play with some cool new technology along the way - and to be fair, it did seem like a graph model would serve the current use case well. We drew out some concepts of what we expected our entities and relations to look like.

Users would be able to add their own books to their reading lists if they so chose - but that didn't mean they belonged in the library's collection.

That done, we discussed implementation - how would we bring this into our application? How would this fit into our current codebase? After some research and exploration, it was decided that we'd avoid bringing in a true graph database (like Neo4j, OrientDB, etc.). Cost was potentially an issue, and we wanted to avoid forcing our developers to learn new concepts and a new query language until we were sure this model was something that we really wanted to stick with.

That having been decided, we drew up our approach to storing our graph entities and relations ("nodes" and "edges") in our relational database:

The Good

Once we got our new hierarchy set up, rendering nested relationships became simple. We could easily convert a higher-level model (like a genre) into a tree-like JSON representation (in the real world, we had several additional levels to deal with - think category, subcategory, etc. - so this was pretty helpful).

library.to_json
# => 
{
  id: 1,
  name: 'Library',
  genres: [{
    id: 1,
    name: 'Fantasy',
    books: [{
      name: 'Book 1',
      id: 10
    },{
      name: 'Book 2',
      id: 20
    }]
  }]
}

Interacting with the data also became pretty simple - our nodes all had the same attributes, so we used pretty generalized views and services to display, create, and edit everything from the library and reading lists to genres and books.

<h1>Editing <%= @node.name %></h1>
<%= render 'node-edit-form', node: @node %>

Another bonus was getting to understand graph structures pretty well. We learned how to traverse a graph, how to filter a graph, how to check for cyclical references - and more.

The Bad

Everything worked well in the beginning - when everything looked the same. Before too long, though, we found that we needed additional information in the payloads we sent down to the front end.

# Our data model started to become more complex...
{
  id: 1,
  name: 'Library',
  genres: [{
    id: 1,
    name: 'Fantasy',
    book_count: 2,
    books: [{
      name: 'Book 1',
      available_for_checkout: true,
      author: 'Bob Bobberson',
      id: 10
    },{
      name: 'Book 2',
      available_for_checkout: false,
      author: 'Frances Farina',
      id: 20
    }]
  }]
}

We started mixing behavior and additional attributes in with structure of the library hierarchy rather than allowing the graph structure to do what it was good at - defining the relationships of entities to one another. We started shoehorning in details about individual nodes, complicating the logic required to render our over-generalized views. These views quickly became complicated and full of switches on node type.

<h1>Editing <%= @node.name %></h1>

<% if @node.type == 'Genre' %>
  <p>Book count: <%= @node.book_count %></p>
  <%= render 'node-edit-form', node: @node %>
<% elif @node.type == 'Book' %>
  <%= render 'book-node-edit-form', node: @node %>
<% else %>
  <%= render 'node-edit-form', node: @node %>
<% end %>

After a while, it became clear that our application was a graph database that we'd smashed into the shape of a bookstore, instead of a bookstore that utilized a graph database to store data. Our codebase was littered with overly generic, meaningless methods and controllers that were difficult at best to understand.

# Instead of this...
def save_book(book_data)
  # Clearly saving a book to the DB
  save_to_graph(book_data) 
end

# we ended up with this:
def save_node(node_data)
  # What are we saving here??
  Nodes.save(node_data)
end

The Awful

As the library grew in size, querying became downright awful. Queries ballooned in complexity; complicated preloading was required in order to avoid making hundreds of queries. Many of our services relied on recursion to generate serialized JSON or aggregate data, which added mental overhead when trying to figure out what your bug was, what was causing it, and where your extra queries were being made. When new devs joined our team, it was harder for them to ramp up on what we were doing, which caused frustration and wasted a lot of time. We used tools like recursive SQL views and terrifying "octo-UI" (see below) admin tools that caused more grief than joy.

This graph is similar to a stopgap admin interface we implemented to allow admins to interact with the graph - screenshot taken from the D3 example gallery

The last straw(s)

All told, we worked with this psuedo-graph structure for a little under a year before we gave up the ghost and started ripping it out. Some notable reasons:

As mentioned above, writing services and views for a general idea of a "node" did not work well once our data model evolved
This idea of graph-like structures stored in a relational database was certainly not supported by ActiveRecord - this resulted in inefficient and confusing queries
Super importantly, we (as developers) didn’t create tooling that would have made these concepts easy to work with, for other developers and for the end users of our product.

Lessons learned

While I wouldn't do this again, I certainly learned a few things along the way.

Recursive views are cool 🤓
Never put your personal curiosity ahead of someone else's livelihood.
Use the right tool for the job!

The next time you find yourself looking at a shiny new technology and feel the desire to use it in a product that's critical to your company's day-to-day business, I encourage you to consider your choices carefully.

Do I even need INSERT SHINY THING HERE? ...do I really?

Most often, it's in your best interest to choose "boring technology" (Choose Boring Technology, Dan McKinley) over "the new hotness." If you consistently opt for exciting, innovative technologies over longer-lived and widely-understood systems, you're going to increase the cost/headache related to onboarding new engineers and maintaining your entire system.

I would argue that this also applies to the patterns we use to build our software. When we hid the implementation details of our graph structure poorly, we introduced code that felt unintuitive and confused new developers. If we had done a better job isolating that code, it would have been much easier to swap out our "homegrown" version for the real thing later on.

The article linked above makes a great case for limiting the number of technical solutions you use as a team. Instead of spending your energy troubleshooting and maintaining a homegrown solution, you can choose to focus on solving business problems - actual people's problems. Add too many unfamiliar technologies, and you run the risk of having one or two "experts" (masters of the arcane) on how your application works rather than a straightforward codebase that most folks can get up to speed on in a reasonable amount of time.

If the honest answer to "do I need this?" is "yes, this is by far the best solution for my problem," ensure you have the time, support, team bandwidth, and expertise to do so. If these conditions are met, then you need to do your research - and please, use the right tools for the job 🙇‍♀️

Finally in Promises & Try/Catch

Anna Rankin — Wed, 19 Sep 2018 00:43:06 +0000

Lately, I've been experimenting more with the async/await keywords in JavaScript. I noticed that I sometimes struggle to reconcile the strategies I use with Promises with the way I need to write code in the newer syntax. Most recently, I was playing around with finally in some try/catch blocks and came upon some behavior I didn't expect.

This post assumes a general understanding of how asynchronous JavaScript code works - particularly, how Promises work. (If you're looking for an in-depth explanation of async JS from callbacks to the async/await keywords, there's a pretty good overview on javascript.info - you can also check out Mostafa Gaafar's article for some of the neat features of async/await.)

For context - in the JavaScript codebase I spend a lot of my time in, we've historically dealt with asynchronous actions by using Promises heavily. Generally, this pattern is a lot more familiar to me:

const loadSomething = () => {
  return fetchSomeData()
    .then(data => doSomethingWith(data))
    .catch(error => logAndReport(error))
}

And this is less familiar:

const loadSomething = async () => {
  try {
    const data = await fetchSomeData()
    return doSomethingWith(data)
  } catch (error) {
    logAndReport(error)
  }
}

`finally`...?

You'll notice that a finally callback/block is missing from both of the examples above. I don't use either often in my code, which led me to a misunderstanding (of both, really). Let's dive into the differences between this concept in Promises and in try/catch!

`finally` in Promises

When you use the somePromise.then(x).catch(y).finally(z) pattern, your business logic is generally happening in the then callback (x, above - what you want to do once somePromise has resolved) or in the catch callback (y above - returns what you want to pass along in case something goes horribly wrong). You might never have even used finally in your code - and that's fine.

According to the MDN docs, a finally callback allows you to execute logic once your Promise has been settled - resolved or rejected - one way or the other. It has absolutely no impact on the value that your promise will resolve to - it doesn't even have access to it. In fact, the documentation states that:

Promise.resolve(2).finally(() => {}) will be resolved with 2.

This means (somewhat counterintuitively) you can sprinkle finally callbacks liberally throughout your promise chain without changing the final result that it will resolve to:

// Please don't do this 😅

Promise.resolve({ some: 'data' })
  .finally(() => { console.log('WHALE HELLO THERE 🐋') })
  .then(data => ({ ...data, anAdditional: 'key'  }))
  .finally(() => { console.log('Looks like we made it past the first step 🙏') })
  .then(data => ({ ...data, yetAnother: 'thing added' }))
  .finally(() => { console.log("We're done I think 🙌") })
  .then(data => {
    console.log('Final result:', data)
  })

If you run this code, you should see this:

`finally` in try/catch blocks

The try/catch/finally pattern has been around for a long time in JavaScript - since version 1.4 (ES3 specification, around 1999). There are a couple of logical parallels I'd drawn between this pattern and how promises are handled:

try/then:
This is where our "happy path" logic goes - if nothing breaks, all the action happens here!

catch:
This is where we end up when things go wrong, and gives us a chance to redeem ourselves 🙏

finally:
This logic will execute after the try/then (and possibly catch) logic has completed. This code runs no matter what, whether we've encountered an error or not.

The difference here that tripped me up is related to return statements. If your finally block does not include a return statement, it has no effect on the return value. However, if you return a value from a finally block, that value will override all other returns and be the final result of your function. (Check out this example from the docs!)

// This worked as I expected.
const returnFromTryCatch = (someFunction) => {
  try {
    return someFunction()
  } catch (error) {
    return `Caught an error: ${error}`
  } finally {
    // This block has no effect on the return value.
    console.log('All done!')
  }
}

// This was a surprise to me!
const returnFromFinally = (someFunction) => {
  try {
    return someFunction()
  } catch (error) {
    return `Caught an error: ${error}`
  } finally {
    // Wait... so I'm just swallowing my return and error handling?
    return 'All done!'
  }
}

This makes sense, but it felt inconsistent to me. My experience with Promises reared its head - why should a finally block ever be allowed to override the value a function returns?

Finding the Reason

Finally, I pinged my tech lead detailing my annoyance, and he sent me a link to a related StackOverflow discussion. Seeing the ECMAScript specification (emphasis mine) for this behavior helped it settle into place in my brain:

The production TryStatement : try Block Finally is evaluated as follows:

Let B be the result of evaluating Block.
Let F be the result of evaluating Finally.
If F.type is normal, return B.
Return F.

(It's worth noting the "completion types" according to the ECMAScript spec are "One of normal, break, continue, return, or throw" - I have assumed that a function that does not include a break, continue, return, or throw keyword qualifies as "normal." Kind of weird semantics there.)

Note on Multiple Return Statements

The code samples in this post do not utilize a single return. I'm not going to get too far into the debate around multiple return statements - I will say that in general, having a single return for longer functions has served me well in the past, but I've found them less helpful in shorter blocks. It probably would have made my life easier in this case, though!

"No Config" Bundling with Parcel

Anna Rankin — Fri, 10 Aug 2018 18:40:03 +0000

This workshop will focus on using Parcel - a web application bundler - to bundle up and serve a Typescript & React project without writing a configuration file! Parcel is a quick and lightweight alternative to bundlers like Webpack and Rollup. We'll discuss bundling in general, dive into some source code, and go over the steps required to set up and add dependencies to our application.

All levels are welcome! Prior experience with a bundler is helpful for context, but not required.

Timeline

0:00: Introduction
4:30: TLDR; Bundlers
5:55: Ways of creating production code
7:40: Enter the Webpack!
10:12: What you get with Parcel
11:55: Let's try it! Starting from Scratch
20:00: "Automagically" Installed Dependencies
29:30: What about production?
30:35: Writing a configuration file
33:25: The Takeaway

Click here for slides!

This DEV Live Stream was recorded on July 23, 2018
Join the next Live Stream. See all upcoming events here.

How Art School Prepared Me for Programming

Anna Rankin — Tue, 22 May 2018 03:39:05 +0000

At the startup where I work, a lot of my coworkers in the engineering department have great stories about where they came from - organic chemistry, education, computer science, publishing, data, etc. - the list goes on. My personal experience before transitioning into software was in traditional illustration: mostly pastels, oils, and acrylics.

While I don't normally catch flack for having a non-traditional background, I know a few folks who associate art solely with emotional expression, and technology exclusively with math and logic. I'm of the opinion that programming is as much an art as it is a science or a utility. In that vein, I wanted to share a few lessons I learned in art school, but use in my job every day.

You can often communicate better through abstraction.

When I mention "abstract art," a lot of folks bring up Jackson Pollock, Mondrian, or some of the more "out-there" (read: usually cubist) works of Pablo Picasso. Personally, I'm really digging this quote I saw highlighted on Mondrian's page (linked above):

"I wish to approach truth as closely as is possible, and therefore I abstract everything until I arrive at the fundamental quality of objects."

That idea is extremely appealing to me as a developer - the idea that I could strip away all the unnecessary details in a project until only the bare, beautiful, unconvoluted minimum remains. The less code there is in a project, the cleaner the lines of the whole; the simpler the shapes, the less muddied the colors. This doesn't mean there's a "right" number of lines or characters or methods for a project to have; only that I strive for elegance through simplicity (actually achieving that admittedly lofty goal is another matter 😁).

As a pixel artist, I think about abstraction a lot - how much detail can I take away before my doodle becomes unreadable? What's important to include? I ask the same questions when I'm designing an interface for a class or when I'm writing documentation. I think (a lot 😳) about how much flexibility to allow for - how much configuration is too much? Not enough? How much complexity can I abstract away while maintaining the functionality and usefulness of a service? Documentation is hard, too - distilling nebulous chunks of shared and individual knowledge down into a manageable set of bullet points, examples, and/or diagrams is an art form all its own.

The same concept holds true when you're trying to explain something verbally. Choosing the right level of detail for your audience - whether it's your co-workers or a class of programming newbies - allows you to communicate with them clearly.

We sometimes talk about libraries or workflows as "black boxes" - I think this is a valuable tool and a great abstraction for working with beginners as well as experienced folks. It's nice to remember sometimes that we don't need to know how everything works right now - we can give ourselves the luxury of tighter focus on what we're doing.

Don't be precious with your creations.

There's a story that circulates through the students and alumni of my alma mater of one instructor's particularly challenging drawing class. For an entire semester, students work in pencil on paper, drawing the same model in the same pose for six hours a week. They pour their hearts and souls into this drawing, obsessing over light, form, and subtle gradations of shadow for months. At the end of the class, after a group critique, the instructor gives his final instruction:

"Erase it."

After all that hard work, the students rub out every painstaking pencil stroke until their papers are gray and featureless. Some call it cruel (I won't say it's not, honestly), but it teaches a very important lesson in an indelible way. Don't be precious with the product of your work - the important thing is that you did it. You've learned from the experience and (as the instructor would say) - "You drew it once, you can draw it again."

This idea has served me well in my work as a developer, from being critiqued in code reviews to seeing thousands of lines I wrote deleted from a project all in one fell swoop. You'll hear folks say "You are not your code!" and it's true! The amount of amazing (and sometimes bizarre) knowledge I've gained from my past work is invaluable to me regardless of where it lives now. When someone points out a strange pattern or opportunity for improvement in my work, I have no compunctions about erasing my old "sketches" in favor of a better solution.

Dissatisfaction with your work is a sign of developing taste.

This one is very close to my heart. When I was in art school, I noticed a pattern in how I felt about my work:

I'd work really hard and create some pieces I was super proud of.
I'd see the amazing work that my peers, mentors, or even famous artists created and start comparing my own output to theirs.
Cue depression and dissatisfaction with my own work - everything I'd done before was childish and crude; my hands weren't capable of creating what I saw inside my head.
After days/weeks/months of struggling with my own skill level, I'd start to create things I was proud of again.

This probably sounds familiar to anyone who's learned how to code - at least, it was common among my students when I taught web development. One of my drawing teachers told me that taste and skill develop at different speeds, and at different times. If you can't see the flaws in your work, then you probably need to refine and develop your skill further. If you feel that what you've created is lacking, then your level of taste has simply progressed beyond your current level of ability. Thinking like this has helped me deal better with doubt and (mostly) fend off the dreaded impostor syndrome.

Thank you for reading! If you've got any other stories of lessons you brought to your tech job from a seemingly unrelated field, I'd love to hear them.

Supplying Placeholder Data by Catching Promises

Anna Rankin — Tue, 08 May 2018 00:14:55 +0000

Recently, I wrote a simple Slack bot that queries an API for feedback on our products, then posts that feedback into a specified channel. The bot also allows users to vote on whether or not a piece of feedback is actionable for them (ie: "there's a typo in this lesson" vs. "ok" or "no comment").

Since this was a "Hack Day" project, the initial implementation lived up to its name and was very hacky - votes were not stored by the server; users could vote as many times as they wanted. The voting was handled by modifying the string that came in with a POST /handle-vote request (Slack as a persistence layer 😂).

// text => 'Yes: 0 No: 0'
// value => 'yes' || 'no

function updateAttachmentText(text, value) {
  votes = text.split(' ')
  if (value === 'no') {
    votes[3] = parseInt(votes[3]) + 1
  } else if (value === 'yes') {
    votes[1] = parseInt(votes[1]) + 1
  }
  return votes.join(' ')
}

const updated = updateAttachmentText('Yes: 0 No: 0', 'yes')
// => 'Yes: 1 No: 0'

This hacky little bot turned out to be quite useful for our product team - but I knew its dark, terrible secrets and decided to write a more robust version that used Redis for storage of vote data - it would store voters' Slack user ids and prevent one user from voting multiple times.

The bot itself uses a cron job to post new feedback to the channel. While upgrading, I added a step to that script to create a new "blank" record with that feedback's ID.

const initialVotes = { votes: { yes: [], no: [] } }
redisClient.store(id, JSON.stringify(initialVotes))

Once a user hits a button, the server receives the request, looks up the piece of feedback by its ID, adds the user's id to the correct list ('yes' or 'no'), then saves it back to the Redis store after performing some logic to ensure users can only vote once, and only one way.

The issue here is with messages from the original bot - these bits of feedback don't have records associated with their IDs in our application; so the following code would fail if the user clicked on a vote button:

// Imagine our Redis client setup...
class Redis {
  // setup, etc

  fetch(key) {
    return new Promise((resolve, reject) => {
      this.client.get(key, (err, response) => {
        if (err || !response) { 
          return reject('Unable to find result for', key, err) 
        }
        return resolve(response)
      })
    })
  }
}

// ... and a Vote loading class...
class Vote {
  constructor(id, redisClient) { 
    this.id = id 
    this.redisClient = redisClient 
  }

  loadVote() {
    return this.redisClient.fetch(this.id)
      .then(voteData => JSON.parse(voteData))
  }
}

const vote = new Vote(someId, someRedisClient)

vote.loadVote().then((vote) => incrementCounterAndSave(vote)) 
// Uncaught rejection :(

Initially I thought this would be an annoying problem where I'd need conditional logic to handle the record not existing somewhere in my server code. Looking at the Vote class's code itself though, reveals a neater option:

class Vote {
  // ...
  loadVote() {
    return this.redisClient.fetch(this.id)
      .then(voteData => JSON.parse(voteData))
      .catch((err) => {
        console.log('Encountered an error, returning placeholder data:', err)
        return { votes: { yes: [], no: [] } }
      })
  }
}

const vote = new Vote(someId, someRedisClient)

vote.loadVote()
  .then((vote) => {
    console.log(vote)
    incrementCounterAndSave(vote)
  }) 
// Encountered an error, returning placeholder data: 
//   'Unable to find result for someId (error here)
// { votes: { yes: [], no: [] } }

I figured I'd write this up since, while I've worked with Promises for a while now, this concept wasn't my first instinct: I didn't think to use catch anywhere but at the very end of my chain of then calls.

Here's some code you can play around with in the console that demonstrates this pretty simply!

class DataFetcher {
  constructor() {
    this.count = 0
  }

  fetch() {
    this.count += 1
    return new Promise((resolve, reject) => {
      // Cause this Promise to be rejected/fail every other time the fetch function is called.
      this.count % 2 === 0 ? resolve('data from DB!') : reject('data not found')
    })
  }
}

const client = new DataFetcher()

const getData = () => {
  return client.fetch()
    .then((res) => {
      return res
    })
    .catch(err => {
      return 'placeholder data'
    })
}

getData.then(console.log) // placeholder data
getData.then(console.log) //data from DB!

As a side note, you could totally write this code in a less nested (and arguably more readable) way using async/await - I don't feel super strongly about it either way, so I just went with Promises.

Happy coding!