Forem: Claire Steinhoff

A Migration to the Backend

Claire Steinhoff — Tue, 22 Nov 2022 06:17:46 +0000

Last week, our cohort wrapped up the third phase of the software engineering program at Flatiron School. It’s hard to believe how far we’ve come already and how quickly we have progressed. During this phase we began to shift our focus from React.js, and the front-end presentation of content, to laying the basis for our work in the backend. We began by learning the foundations of Ruby and SQL syntax before moving into some libraries we can use to build and manipulate our databases without going through quite as much legwork.

By the end of the phase, we were able to use Ruby and Active Record to build databases in SQL, access them using custom built methods, and serve them to our front-end using Sinatra. The final result is a tailor-made API, which we used to seed and serve the data to the frontend for our phase-end project.

In this blog post I want to talk about how to build a SQL database using Ruby and Active-Record. A lot of these steps will be performed automatically when we start using the Rails framework, but there is value in knowing how they work so that when issues arise down the line, we are prepared to do troubleshooting. This walkthrough presumes active record and rake gems are installed and configured appropriately.

Step one is to create a db (database) if you do not have one in your project already. This is done using the command rake db:create

rake db:create

this command will create a directory to store your database and migrations.

The next step is to create a migration to begin
populating the db. We use the following command to create a db

rake db:create_migration NAME=<NAME_OF_MIGRATION>

By using the rake commands inherited from Active
Record/Sinatra, we are able to create files with the appropriate naming schema and basic inheritance already in place. Let's create an example migration to build a new table.

rake db:create_migration NAME=create_students

This will create a timestamped migration file in the 'migrate' directory with the named class and active record inheritance filled out automatically. Migrations are run in sequential order to avoid conflicts and enable seamless rollback functionality, so the naming convention here is actually very important. Luckily, it is taken care of for us. Here is the result:

class CreateStudents < ActiveRecord::Migration[6.1]
  def change
  end
end

In this file we will tell the migration what change we want to take place, in this case we want to create a table with a few columns for data. For this we will use the create table method, which requires one argument, the name of the table. Inside we are going to create columns by using the command t. :.

class CreateStudents < ActiveRecord::Migration[6.1]
  def change
    create_table :interactions do |t|
      t.string :first_name
      t.string :last_name
      t.integer :grade
      t.integer :graduation_year
      t.boolean :has_graduated
    end
  end
end

with the migration prepared, all we have to do is run it, using the following command:

rake db:migrate

this will add our change to the schema file and db, or create one to populate if the file doesn't exist yet.

By using migrations, we are able to rollback any changes using a simple rake command.

rake db:rollback

Using this feature, we can fix any mistakes we might have made in our migration before running it again. Changes and corrections can also be made using migrations to patch the existing table instead, but there are trade offs and benefits to each approach, that likely depend on the context of your project.

That was a simple walkthrough of creating a database using ruby and active record. Hopefully it provides some understanding of the general template for creating migrations and what the purpose of each component of the migration is.
I'm thrilled to begin learning Rails to streamline this process and open up all of the other capabilities it brings. For now, I hope this can help any other beginners, taking their very first steps into the world of API creation.

How I Learned to Stop Worrying and Love the DOM.

Claire Steinhoff — Tue, 11 Oct 2022 16:32:17 +0000

The first few weeks of class at the Flatiron school have brought a whirlwind of new concepts to learn, people to meet, and thrilling possibilities to consider. It’s hard to believe that we’ve already completed our first phase of learning and put together a project that incorporates each of the skills we’ve developed so far. It has been remarkable to watch the seemingly disparate languages and concepts we are learning come together to build something cohesive and usable. In this blog post I want to talk about how they all meet and work in tandem to create the modern web that we use every day.

Some of the topics we covered in this phase were how to give basic structure to a webpage with HTML, how to clad the content in the design that makes it readable and engaging, using CSS, and finally how to add functionality and dynamic tools to a webpage using functions and instructions that we create and import from JavaScript. Together, these three elements constitute something called the DOM, or document object model. Understanding the DOM is key to understanding how and why websites work the way they do – and of course how to find your mistakes when they do not.

I ran into some challenges during a few labs that at first baffled and frustrated me, but ultimately led to a better understanding of the concept which has helped me in all of the work since.

The DOM is a structure used when you import code into your HTML that defines the way the page is presented and how it can be interacted with according to instructions written in CSS and JS. These components work together as objects within the document, to define its behavior. But where is the DOM? When I first read about the term I thought of it as a purely conceptual description of the result of a process that renders these three distinct sources of code to a browser. Close, but not quite right. This understanding led to some confusion about how and where data could be stored in a page after being defined by our javascript. If my initial understanding were correct, then every piece of data on the page would need to be stored either in the plain HTML or in variables in the JS, right? Yet I found after implementing content to a page, we could reference information not contained in either. How could that be? Take the following code, for instance:

fetch("https://api.punkapi.com/v2/beers")
.then(res => res.json())
.then(beers => {
   beers.forEach(fillBeerList);
   return beers;
})

const fullMenu = document.querySelector("#full-beer-list");
const searchForm = document.querySelector("#search");

function fillBeerList (item)
{
   const menuItem = document.createElement("li");
   menuItem.textContent = item.name;
   fullMenu.querySelector("ul").append(menuItem);
   menuItem.addEventListener("click", () => renderBeerDetails(item));
}

In this code, from my project, we take information imported from a database – in this case a library of data about beers at a brewery – and use this data to create an interactable menu. After the data is returned, we use a forEach function to create a clickable list item for every menu option. When clicked, the website should display details about the selection, taken from the api, via the callback function “renderBeerDetails(obj)”. (see below):

function renderBeerDetails(brew) {
   currentBeer = brew
   beerName.textContent = brew.name;
   tagline.textContent = brew.tagline;
   firstBrew.textContent = brew.first_brewed;
   description.textContent = brew.description;
   abv.textContent = brew.abv;
   ibu.textContent = brew.ibu;
   image.src = brew.image_url;
   faveIcon.src = "./assets/beer/png/001-beer.png"
}

Finally, we append each of these items to a node representing the menu. – It’s clear enough how each new item is appended to the structure of the page, but if the code has to execute before passing on, and each pass of the function reuses the same variable, then how is the information on the specific beer-to-render stored and, more importantly, referenced, during the click event? The answer – as far as I understand it – is that each execution of the code, and therefore the details we pass through to the callback function, is stored in and can be referenced in a separate node on the document. Because the website consists of objects in this overarching structure, called the ‘document’, each event listener created in this code is able to instruct the website to render information on the correct beer without using a unique variable in JS.

The result of this code is an important tool in the functioning of our phase one project. take a look at the finished results below (complete with CSS styling):

When I first saw code like that in the examples above, I could not understand how it worked. How did our event listeners know which beer object to render if the content had been changed on each pass of the function. Now I understand that the DOM is more than a metaphor for the admixture of the three building blocks of the web, css and JS working on HTMl. It is an actual object, or structure which contains working sections of code and nodes of html that can be made interactable on myriad data.

This has been my attempt to make sense of the structure of the "document object model" and all of the capabilities it brings. The truth is, I still have so much to learn and my understanding is far from complete, but this small concept helped me to understand and write code better and I wanted to share that experience with everyone reading. Please feel free to reach out to correct any misunderstanding I may have included here by mistake. This metaphor was helpful for my understanding, but is obviously incomplete. Since my only goal in writing is to reflect, hopefully understand the topic better, and connect with others in the coding community, any info that brings that vision into clearer view, is abundantly welcome.