DEV Community: Allison Kim

Indexes in SQL {Using Rails}

Allison Kim — Tue, 11 Oct 2022 14:39:37 +0000

Indexing in SQL is a useful tool to make querying database tables much faster and easier. It is ideal for when you plan to have large amounts of data in your table and often need to extract that data by certain column values. For example, when a record requires a different, maybe formatted, ID than what's auto-assigned in the database table, or you want to be able to pull a set of records by its value in a category column, indexing is the perfect tool.

You might be thinking, "Why not just use the WHERE clause?" The WHERE clause is not ideal because it causes the database engine to look through every single record in the table. This can result in a substantial amount of search time, especially if you have a table with, say, a million records (which is not hard to have). Why waste that kind of time when you can reduce it to one second with this simple step?

To add an index to a column via Rails Migration:

When first creating your table:

create_table :table_name do |t|
  t.integer :column_name_one, index: true
  t.string :column_name_two, index: true
end

If your column already exists:

add_index :table_name, :column_name

What's happening under the hood when you create indices is: a new table gets created to store each row's value of the indexed column and a pointer to its location in the database. Although it may seem like a questionable trade-off between storage and search time, the new table is considerably small in width since it only stores the index and pointer and not the records themselves. Then, when you use an index in your query, the database engine is able to use the newly created table to quickly obtain those records, instead of searching through every record one-by-one. As one might say, the benefits outweigh the cost.

There are more ways to modify an index to benefit your querying further, which are greatly outlined here. So be sure to check them out when you start implementing indexes in your tables. Hope this helped!

We Love Ruby {Method Chaining}

Allison Kim — Fri, 16 Sep 2022 15:56:18 +0000

A lot of developers love programming in Ruby because of its simplified and almost colloquial nature. For example, a line of Ruby code could read:

my_age = 26
puts "Unable to purchase alcohol" unless my_age >= 21

You can almost read it in normal English as "Put out to the terminal 'Unable to purchase alcohol' unless my age is greater than or equal to 21."

This was Ruby designer, Yukihiro "Matz" Matsumoto's goal: to make a language that's ultimately easy to use, intuitive to write, and make programmers happy.

I found I love Ruby through how simplified a complex line of code can become with Ruby's style of method chaining.

Method chaining is a convenient way to build up complex queries, which are then lazily executed when needed. Within the chain, a single object is updated and passed from one method to the next, until it's finally transformed into its output value.

-Jeff Kreeftmeijer

Let's go through a fun example together:

To set the stage, let's say we are a clothing store and we're using Ruby (along with ActiveRecord) to build and access a SQL database. For our framework, we have a one-to-many relationship between each customer and the products he/she purchases -- i.e., a product can only belong to one customer, but a customer can have many products. In our schema (SQL table build), each customer is given a unique ID, and the products table has the customer ID as a foreign key for each product.

Now, we - as the store - want to reward our most $$ lucrative $$ customer (the one who's bought the most products) with a gift as a thank you for all the business. In psuedocode, the way to do this is by counting all the products each customer has purchased and grabbing the customer with the max count. Solution here:

id = Customer.joins(:products).group(:id).count
  .max_by { |id,count| count }[0]
Customer.find(id)

Let's break this down:

Customer is the class we define to represent our customer model.

joins(:products) performs a SQL INNER JOIN to compile a list of customers where the respective customer from each product in the products table is returned.

group(:id) combines any repeating elements that share the same value in the column defined by the argument. In this case, it combines any customers that share the same unique ID and returns a list of unique customers.

count returns a count of elements in a list. But when applied in conjunction with group, it provides a count of repeating elements for each unique element. This is returned in a key-value pair for each unique element, like so:

# format: {id=>count}
{1=>2, 2=>1, 3=>1, 4=>2} ,

where element ID 1 has a count of 2, element ID 2 has a count of 1, and so on.

max_by { |obj| block } returns the object with the maximum value based on the block condition. In our solution, we're taking each object ({id,count}) returned by the count method to return the object with the maximum count. The object is returned in array format, [id, count] - thus, we tack on [0] at the end of our solutionto only grab the ID.

Now that we have the ID of the customer with the most amount of products, we can use the find(id) method on the Customer class to return the instance of that customer. And that's it!

It's your turn to experiment and further discover the power of method chaining in Ruby! Happy coding!

Where did my data go? {React Router}

Allison Kim — Fri, 26 Aug 2022 04:29:00 +0000

In this post, I'll be talking about an intricate nest of problems I dealt with while learning how to use React Router that took some time debugging and troubleshooting to understand.

To set the stage, a fellow developer and I were tasked with building a single-page application that utilizes client-side routing to render a different 'page' on the DOM with each route.

We built an application that accesses a free Pokémon API to render a Pokémon library as one route and a personal Pokédex as another route. The library lists the first 386 Pokémon from the API and the Pokédex lists whatever Pokémon the user saved (or caught, if you will). The user can also click on any of the Pokémon to link and route to a detailed page of that Pokémon. Each route has its own unique URL, including each route to a specific Pokémon (i.e. clicking on the Pikachu would change the URL to localhost:####/pikachu).

That was all well and done -- until we tried routing to the detailed Pokémon page by manually typing a Pokémon in the URL. The Pokémon data was not passing down and the page would show nothing. That begged the question: where did our data go???

To illustrate our framework:
Our parent App component holds the routing to our Library, Pokédex, and Pokémon Page components. In App, we fetch the data from the API in a useEffect hook and store that data in state. We then pass this data to all three child components as props so it's available to render data in those components.

function App() {
  ... //fetched data
  return (
    <div>
      <NavBar />
      <Switch>
        <Route exact path ="/">
          <HomePage />
        </Route>
        <Route exact path="/library">
          <Library
            pokemons={pokemons} //passing props to Library
          />
        </Route>
        <Route exact path="/pokedex">
          <Pokedex
            pokemons={pokemons} //passing props to Pokedex
          />
        </Route>
        <Route exact path="/:name">
          <PokemonPage 
            pokemons={pokemons} //passing props to PokemonPage
          />
        </Route>
      </Switch>
    </div>
  );

What's funny is when we manually type in the URL for the Library and Pokédex components, they load as expected. It's only when we manually type in the URL for a specific Pokémon that the Pokémon Page renders nothing.

To troubleshoot, I set several debuggers in my parent and child components to try and follow the path the code was taking. I also placed a console log of the props in the Pokémon Page component to check if it was coming through (it wasn't) - as well as console logs in certain places to see what lines of code were hitting. That's when I noticed something interesting.

Important background info:
When we initially fetch the data in the App component, we have it so there are two fetches happening asynchronously. This was necessary because of how the API is set up. The first fetch only provides the Pokémon names, so we use a second fetch to iterate through the names to get each Pokémon's details. Because the first fetch needs to finish before the second fetch can start, we leveraged async and await to accomplish this. This caused state to be set continuously, making our code go back and forth between rendering our App and Pokémon Page components so that Pokémon Page would only load chunks of data at a time.

function App() {
  const getPokemons = async () => {
    const res = await fetch({pokeAPI url})
    const data = await res.json()

    const createPokemonObject = (results) => {
      results.map(async pokemon => {
        const res = await fetch({pokeAPI url by pokemon name})
        const data = await res.json()
        setPokemons(pokemons => [...pokemons, data])
      })
    }

    createPokemonObject(data.results)
  }

  useEffect(() => {
    getPokemons()
  }, [])

  ... //returned JSX
}

The reason this stifled the Pokémon Page component is because the delay in fetching led the component to first load with empty props. This prevented our image elements from rendering due to undefined sources (which would've come from the props) and in turn stopped our component from rendering altogether. Even though we know the data will technically be sent later, the component doesn't. So it doesn't try to re-render the component after it thinks it failed the first time.

The solution I came up with to resolve this was to apply an if statement that wraps our JSX to return a different JSX (i.e. 'Loading...' text) if props are undefined, else return our original detailed page JSX. This allowed the page to continue attempting to render the asynchronously fetched data by tricking the component into thinking it's not failing anything so keep trying.

if (pokemon === undefined) {
  return <h1>Loading...</h1>
} else {
  return (
    ... //JSX for the detailed page
  )
}

Cocktail Library {vanilla JS}

Allison Kim — Wed, 10 Aug 2022 21:34:00 +0000

Related to my previous post - here is a link to a project I completed for school that helped me gain milestones in understanding vanilla JavaScript:

https://akimsahn.github.io/Phase-1-Project/

How it works:
This site functions as a one-stop database for all the different kinds of cocktails, with further info on their ingredients and how to make them.

You can filter the cocktails by specific ingredient or type of alcohol by selecting it from the dropdown menu
You can select an image of a cocktail to display its details, including the list of ingredients and recipe instructions.
You can add a rating and/or comment on the cocktail for personal documentation. (Ratings & comments will not persist between refreshes but will persist between selecting other cocktails.)

All interactivity on this site was set up using event listeners and pure vanilla JavaScript, as well as some CSS.

Hope you enjoy! It's 5 o'clock somewhere, amirite?

Credit to https://www.thecocktaildb.com/api.php for the API for fetching this data.

First blog post...ever {object pointers}

Allison Kim — Fri, 05 Aug 2022 17:49:00 +0000

Hello! Warm welcome to my very first blog post as an aspiring software developer - where I'm currently learning to code at the Flatiron School. I aim to use this blog to track my growth and progress in the coding world.

Full disclosure: I probably know about as much of coding as a brand-new driver knows what's under the hood of her car. I simply know how to get from point A to point B -- make the code do what I want it to -- but nothing on how to make the car use gas more efficiently or what parts it's even using at all.

To get an idea of where I'm at, one thing I realized most recently - that was a big stepping stone for me - is the ability to assign a variable to an already-defined object (as a pointer) in order to make modifications to said object in a different scope.

To illustrate:

let variable = {}; /* first, globally defining an empty object to
be used later */

/* The "parent function" that defines an object in it's own
scope and calls the function passed in as an argument to modify
said object */
function parentFunction(functionName) {
    const dataObj = {
        key1: "I want to change this value.",
        key2: "I want to keep this value.",
    };

    variable = dataObj; /* re-assigning (or pointing) our empty
object to the defined object */

    functionName(variable); /* calling the callback function and
passing our variable to be updated */

    console.log(dataObj); /* this is just to see what's in our
defined object after the callback function's been called */
};

//Callback function that changes a value of an object
function callbackFunction(object) {
    object.key1 = "This value has been changed.";
};

parentFunction(callbackFunction); //invoking the parent function

Then, in our console log, we'll see our defined-object has been updated to:

{
  key1: 'This value has been changed.',
  key2: 'I want to keep this value.'
}

Note: the argument that was passed into the callback function was the variable variable and not the actual dataObj. Yet the changes persisted on the dataObj, because variable acts as a pointer instead of a separate object. This was a breakthrough for me as the thought came to my head as I was trying to fall asleep one random night. Hope it can be of use to any new developers that come across this!

Also, quick note on another trick I learned:
To replace the space character in a string with another character, simply use:

string.replace(/\s/g,"<add character you want to replace with>")

Thanks for reading!