DEV Community: Naftali Kulik

Using Active Model Serializer

Naftali Kulik — Mon, 01 Aug 2022 18:14:00 +0000

Installing the Active Model Serializer gem

In order to use Active Model Serializer, you will need to include it in your Gemfile. Simply add gem "active_model_serializers" to your Gemfile and run bundle install. Alternatively, you can run bundle add active_model_serializers from the root directory of your app to accomplish the same thing.

Serializer Basics

As part of my ongoing journey toward becoming a full-stack developer, I have begun developing Rails API. Rails has many great built-in libraries to handle everything from organizing and modifying databases to setting up routes and controller actions to handle requests to those routes. However, using controller actions to handle the data sent back in response to those requests has its limitations. The controller's job is to process the requests sent by the client, which includes but is not limited to authentication, authorization, updating the database in response to the contents of the request body, and actually sending the response. Using the controller to sort through the available data and decide what to send back would grow your controller actions into large, unwieldy, and difficult-to-read blocks of code.

You may be wondering, who cares? Just send it all back and let the client sort it out! That's not too practical though. You may find yourself dealing with large databases with complex many-to-many relationships which require nested data to be sent to the client. Sending everything back in a large chunk for every request doesn't make much sense. Additionally, it may be possible that some of your controller actions require authorization, and if so there's a good chance there's also data that you only want available to authorized users. You wouldn't want, for example, users#index to send all of your users' email addresses and phone numbers! That may be fine for other controller actions (for a hypothetical User model) that require authorization, but not for one that's available for everyone.

This is where ActiveModel::Serializer comes in. The acitve_model_serializer gem allows you to move all that code into a separate file, which will be accessed by the controller either implicitly (if the serializer shares the name of the model that it is connected to) or if explicitly specified. The serializer can be easily created with a rails generator, like this: rails g serializer <serializer_name>. At its most basic, a serializer will include the table rows, as attributes, that are to be sent back in the response, something like this:



class UserSerializer < ActiveModel::Serializer
  attributes :id, :first_name, :last_name, :username, :bio, :avatar_url
end

This is telling the controller to only include those attributes in the response. No sending the user's phone number to anyone who wants it! You can also define custom serializers. Let's say, using the above example, we wanted to send the user's full name as one string. we could write out a method that returns the full name, something like this:



def full_name
  "#{self.object.first_name} #{self.object.last_name}"
end

In this case, self is the instance of UserSerializer, and object is an attribute that allows you to access the current instance of User that you are dealing with. By accessing the user, you can in turn access the data for that user and incorporate it into a method that returns whatever information that you want to be returned. Now all you have to do is add :full_name to the list of attributes and it will be sent as part of the JSON data of the response.

What about the example we used before, with certain controller actions which, upon authorization, send data such as personal user information back to the client? The serializer we have here doesn't send that information, which is good, but we do want the user to have access to it once they prove it's them. Our users#show action, for example, may need to send the user their profile information, including information private to them. Our create and update actions, which allow the user to modify their profile, also need to return more detailed and personalized data.

To accomplish this, we can generate a new serializer and explicitly specify in our controller to use this new one. We'll start with generating the new serializer: rails g serializer user_profile. Now we can include the attributes we want to send, and specify in the controller to use this serializer, which might look something like this:



render json: user, serializer: UserProfileSerializer

In this specific case, it might actually make more sense for the custom serializer to be used for the index action, as that is the one that is apart from the others. In this case, we'd use each_serializer, like this:



render json: User.all, each_serializer: UserListSerializer

The most powerful use of serializers may be the ability to leverage Active Record associations to send nested data. In its most simple form, including associated data is as simple as sticking a has_many (or whatever the relationship is) macro in the serializer (assuming the relationship is set up correctly in your models). You can even specify a separate serializer for the nested data if, and this is often going to be the case, the data you need to send as nested data is not necessarily what you'd want to send in response to a request to the nested resource itself. For example, a book has_many many chapters. You may want to send some basic chapter information with the book (such as the names), but you don't necessarily need a comprehensive collection of information about the chapter, such as its word count, subject, etc, although you would want to send that in response to a request to chapters itself.

Displaying Deeply Nested Data, My Way

You can also send data that's nested even deeper, but that's a bit complicated and probably should be avoided if possible. I've found that often when I've felt like I wanted to nest data more than one layer deep, there was usually a better way to do it. Particularly, combining the features of custom serializers and Active Record associations can often get the results you need without resorting to writing complex code to send back complex data. Let's look at an example from my most recent project, game-center (deployed here).

This app allows users to browse, like, rate, and review free online games (game information obtained via the Freetogame API). The Review model has some pretty complex associations. It belongs_to a User (which has_many reviews), belongs_to a Game (which has_many reviews, and has_many users through reviews), and belongs_to a Rating. I'd like to be able to display a detailed game, which would include a list of reviews, along with some information about the user. A review from this list as displayed in the browser may look something like this:

You may see the potential problem here. We need, in addition to the actual review content, information about the user (name, username, avatar) and the rating associated with this review. This is on top of the fact that the review itself is being sent as a nested resource! This could get complicated and impractical quickly. Allow me to demonstrate how a bit of creativity can make this quite simple.

First, add has_many :reviews to the GameSerializer. This will send whichever attributes are specified in the ReviewSerializer, not including nested attributes, as a nested attribute of the Game. Now we can use custom serializers and Active Record associations to customize our Review objects as needed. Let's start with the basic attributes:



class ReviewSerializer < ActiveModel::Serializer
  attributes :id, :content
end

Assuming our client doesn't need access to the game_id and user_id, this is really all that needs to be sent back from the Review model itself. We also want the rating, which, as we've mentioned before, is a separate resource that the review belongs_to. Instead of trying to work out complicated nested attributes, let's let our association do the work for us in the form of a custom method:



def rating
  self.object.rating.rating
end

Here we have self.object, the review itself, .rating, the instance of Rating associated with this review, and .rating, the attribute that has the actual value of the rating. In short, this method returns the value of the rating associated with this review, without resorting to sending nested and/or unnecessary data. Now we can just add :rating to our list of attributes and there we have it! Now let's do the same for the user information that we need:



def user_full_name
  "#{self.object.user.first_name} #{self.object.user.last_name}"
end

def user_username
  self.object.user.username
end

def user_avatar
  self.object.user.avatar_url
end

def user_tier
  self.object.user.tier
end

Let's see the whole serializer at once:



class ReviewSerializer < ActiveModel::Serializer
  attributes :id, :game_id, :user_id, :content, :rating, :user_full_name, :user_username, :user_avatar, :user_tier

  def rating
    self.object.rating.rating
  end

  def user_full_name
    "#{self.object.user.first_name} #{self.object.user.last_name}"
  end

  def user_username
    self.object.user.username
  end

  def user_avatar
    self.object.user.avatar_url
  end

  def user_tier
    self.object.user.tier
  end
end

Now, the json response data for a game should look something like this:



{
    "id": 19,
    "title": "Game Of Thrones Winter Is Coming",
    "thumbnail": "https://www.freetogame.com/g/340/thumbnail.jpg",
    "description": "Game of Thrones Winter is Coming is a free-to-play browser-based RTS based on the George R.R. Martin novels and popular HBO series. In the game developed by YOOZOOGames, player take on the role of a Westeros lord set on putting a stop to the wars between the Seven Kingdoms.\r\n\r\nThe game is built in Unity and offers players a balanced mix of strategy and RP. Players build bases, grow their kingdom, train armies, and recruit characters from the show, all while living within the story set forth in the TV series.",
    "game_url": "https://www.freetogame.com/open/game-of-thrones-winter-is-coming",
    "genre": "Strategy",
    "platform": "Web Browser",
    "publisher": "GTArcade",
    "developer": "YOOZOO Games ",
    "release_date": "2019-11-14",
    "likes": 4,
    "rating": "3.4",
    "reviews": [
        {
            "id": 602,
            "game_id": 19,
            "user_id": 6,
            "content": "Id quia ut. Quas a accusamus. Non iusto et.",
            "rating": 4,
            "user_full_name": "King Hamill",
            "user_username": "OldRasputinRussianImperialStout",
            "user_avatar": "https://robohash.org/eligendiquaevoluptas.png?size=300x300&set=set1",
            "user_tier": "Hall of Fame"
        },
        {
            "id": 1093,
            "game_id": 19,
            "user_id": 10,
            "content": "Qui ut doloribus. Sapiente ut odit. Nemo placeat sequi.",
            "rating": 3,
            "user_full_name": "Virgilio Larson",
            "user_username": "OrvalTrappistAle",
            "user_avatar": "https://robohash.org/ducimusrepudiandaeet.png?size=300x300&set=set1",
            "user_tier": "Hall of Fame"
        },
        {
            "id": 1197,
            "game_id": 19,
            "user_id": 11,
            "content": "Molestias veniam beatae. Ex alias ut. Mollitia quasi natus.",
            "rating": 5,
            "user_full_name": "Jackson Lamar",
            "user_username": "QB1",
            "user_avatar": "https://robohash.org/facereminimavoluptatem.png?size=300x300&set=set1",
            "user_tier": "Hall of Fame"
        }
    ]
}

There we go! Nice, simple, and organized!

I have found that serializers can be an extremely powerful tool when used correctly, and I hope that I've demonstrated that here. Thanks for sticking around!

Ruby Bingo

Naftali Kulik — Thu, 07 Jul 2022 19:02:00 +0000

From the moment I started learning Ruby, I was able to see why so many programmers love it. I found the syntax intuitive and easy to understand, and its flexibility allows for many different ways to accomplish similar things, allowing programmers to write their code in the way that's most comfortable for them. The syntax is often so simple that even someone with no programming experience whatsoever can often look at a block of code and have a pretty good idea of what's going on. Here's a quick example, taken from the project that I'll be discussing in a moment: It doesn't take a genius to figure out what Board.generate_board until Board.all.count == 20 is supposed to be doing, even if you don't have any knowledge of the code in the generate_board method. In fact, Ruby's creator Yukihiro “Matz” Matsumoto said explicitly that "The goal of Ruby is to make programmers happy", and that goal shows in every aspect of the language.

Learning Ruby has also helped me develop a pretty good habit for programming in general. Ruby has so many built-in methods that memorizing them all is impractical and frankly a waste of time. Because of this, any time I am trying to accomplish a specific task the first thing I do is to Google if there already is an existing method for what I am trying to do (which there often is). Doing so allows me to avoid having to write unnecessarily complicated code, makes my code smoother and more readable, as well as expands my knowledge of the Ruby language in general. This habit has spilled over into my work with other programming languages, and I often find myself doing the same thing in JavaScript now. Although JS doesn't have quite as many built-in methods as Ruby, too often in the past I've stumbled on a method that would've saved me a lot of work in a previous project.

My most recent project was a Bingo game, with a focus on backend development. (The repo for the backend is here, and the frontend is here.) The frontend is a pretty basic React application, and the backend uses a SQLite database with the Active Record ORM, and Sinatra to handle the routes.

Here's a brief overview of what's relevant to this post. For a more detailed explanation of how the database and routes are set up see the README. I'm going to be building out instance methods for the PlayedBoards class, which is a model for a join table that establishes a many-to-many relationship between a players table and a boards table. Each Player instance represents a user, each Board represents a bingo board with a unique layout, and each PlayedBoard contains all of the information relative to a specific player playing a specific board. The PlayedBoard needs instance methods to handle the actual gameplay, as well as to simulate a complete game (for the seed file). I will be going through how we can build these methods, while (hopefully) sticking to good coding practices, such as the single-responsibility principle.

The information that we will be working with is as follows. We have the layout of the board, obtained from the board via Active Record's belongs_to: macro. This is stored as a string consisting of 25 random integers between 0 and 99, separated by spaces. It is in string form in order for it to be stored in the database, separated by spaces so it can easily be converted into an array using .split(' '). This is a useful trick I picked up online for storing arrays in a SQLite database. We also have a string from the unused_numbers column of all numbers from 0 to 99. This will be used to pick numbers for the bingo game and modified as the game progresses so that no number is picked twice. Additionally, there are columns with integers representing the turn_count, turns_to_line, turns_to_x, and turns_to_full. These are to keep track of how many turns were needed to hit a particular milestone (line, x, full) to calculate the user's score. There is also a filled_spaces string with the position on the board of any matching number, by index. Now let's write some code that will make it all work.

Let's see what we need to do to make this work, in pseudocode:

pick a number
remove that number from unused_spaces
increment turn_count
check board layout for match
if no match, end turn (for simulation, start next turn)
if match, add the index of the matching number to filled_spaces
check for a line (only if there isn't already)
if there is, update turns_to_line to current turn_count
check for x (only if there isn't already)
if there is, update turns_to_x to current turn_count
check if full
if it is, update turns_to_full to current turn_count (and end game in simulation)
end turn (in simulation start next turn if not full)

The first step, picking a number, is handled by the frontend during gameplay. In the simulation it's as simple as passing unused_nums.split(' ').sample into the play_turn method, which is going to handle running all of the methods we are about to define. In fact, once all the methods handled by the play_turn method were defined, all that needed to be done for the simulation was this:

def sim_play
    play_turn(unused_nums.split(' ').sample) until is_full?
end

Let's start making that play_turn method work. First, let's remove our newly picked number from unused_nums so it doesn't get picked again.

def remove_from_unused num
    unused_nums_arr = self.unused_nums.split(' ')
    unused_nums_arr.delete num
    update(unused_nums: unused_nums_arr.join(' '))
end

The new number is passed as an argument to the remove_from_unused method, which splits unused_nums into an array, passes the picked number to Ruby's built-in Array#delete method, and uses Active Record's update method to send the new unused_nums information back to the database. This doesn't interact with any other methods used to play a turn, so it is in fact the first line of our play_turn method:

def play_turn num
    remove_from_unused(num)
end

Next, we have to increment the turn_count:

def count_turn
    count = self.turn_count ? self.turn_count : 0
    update(turn_count: count + 1)
end

The ternary is necessary because in this case, the default value for turn_count is nil, so merely passing self.turn_count + 1 to the update method wouldn't work for the first turn. This too can be added as is to the play_turn method.

def play_turn num
    remove_from_unused(num)
    count_turn
end

Now we have to find a match. Let's see what we can do here:

def get_match num
    layout_arr = self.board.layout.split(' ')
    layout_arr.find_index num
end

This method accesses the layout from the board via the belongs_to: :board macro and splits it into an array. It then uses Ruby's built-in find_index method to find and return either the matched index of the layout array or nil if no match is found. The return value of this method will be used to handle a potential match. The next line of our play_turn method is ready:

 def play_turn num
     remove_from_unused(num)
     count_turn
     match = get_match(num)
     handle_match(match) if match
 end

That last line is a method we haven't defined yet which will take the index of the matched number and take care of updating what needs to be updated. If no match was found, the value of match is nil and the turn ends with no further action. In the event of a match, the first thing we need to do is update the filled_spaces:

def update_filled_spaces index
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    filled_spaces_arr.push(index)
    update(filled_spaces: filled_spaces_arr.join(' '))
end

First, we split filled_spaces into an array (or create an empty array if there haven't yet been any matches and the value of filled_spaces is nil). We then add the index passed as an argument to the array and update the database. The first line of handle_match is ready to be written:

def handle_match index
    update_filled_spaces(index)
end

Now we will have to build out several methods to handle the rest. First, let's give ourselves a way of checking if the board has been filled:

def is_full?
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    filled_spaces_arr.count == 25
end

Simple enough! Now let's check if we have a line or an X. Our Board class helpfully provides two class constants, Board::LINE_WIN_COMBINATIONS and Board::X_WIN. Board::LINE_WIN_COMBINATIONS is an array containing other arrays, each containing the indexes of the layout needed to complete a specific line. Board::X_WIN contains the indexes (indices? Dunno, according to Google either way works) needed to fill out an X on the board. Let's start with finding if there is an X:

def has_new_x?
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    !self.turns_to_x && (Board::X_WIN - filled_spaces_arr).empty?
end

This will return true if two conditions are met. If the value for turns_to_x is truthy, that means the X has already been filled on a previous turn, and has_new_x will return false because the X is not new. The right side of the AND expression takes advantage of an interesting feature of Ruby, which is that arrays can be subtracted from each other, and if all of the elements in the array being subtracted from exist in the array being subtracted, the return value will be an empty array. For example: [1, 2] - [4, 1, 3, 2] == []. In this case, we are subtracting filled_spaces_array from Board::X_WIN and checking if the result is empty. The return value of .empty? will help determine the return value of has_x?. We'll do something similar for our next method:

def has_new_line?
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    !self.turns_to_line && Board::LINE_WIN_COMBINATIONS.find { |combo| (combo - filled_spaces_arr).empty? }
end

Here we are iterating through Board::LINE_WIN_COMBINATIONS and checking if a similar expression as the one we used for has_x? returns true for any of the possible combinations.

Note: The elements of Board::LINE_WIN_COMBINATIONS and Board::X_WIN are represented as strings to avoid the complexities of dealing with two different data types

Now let's define a method that will handle updating the database in the event of a match. We need to do two things here. We'll need to update this particular instance of PlayedBoard, as well as check if the current user's score is better than the high score currently saved to the related instance of Board. Let's start with defining a method for the high scores:

def update_high_score high_score
    if !self.board[high_score] || turn_count < self.board[high_score]
        self.board[high_score] = turn_count
        self.board.save
    end
end

This takes a key for the Board class (:full_high_score, :x_high_score, or :line_high_score) as an argument and first checks if there is already a high score for this board (if not, congrats, you have the high score!). If there is, it checks if the current turn_count is lower than the current high score (remember, lower is better in bingo) and if it is, updates the board's high score accordingly. Let's build another method to handle updating the user's scores too:

def update_scores(turns_to_score, high_score)
    self[turns_to_score] = turn_count
    self.save
    update_high_score(high_score)
end

Now we can fill out the rest of handle_match:

def handle_match index
    update_filled_spaces(index)
    update_scores(:turns_to_full, :full_high_score) if is_full?
    update_scores(:turns_to_x, :x_high_score) if has_new_x?
    update_scores(:turns_to_line, :line_high_score) if has_new_line?
end

We are using conditionals to update the appropriate scores if the necessary conditions have been met. Let's see it all together now:

def remove_from_unused num
    unused_nums_arr = self.unused_nums.split(' ')
    unused_nums_arr.delete num
    update(unused_nums: unused_nums_arr.join(' '))
end

def count_turn
    count = self.turn_count ? self.turn_count : 0
    update(turn_count: count + 1)
end

def get_match num
    layout_arr = self.board.layout.split(' ')
    layout_arr.find_index num
end

def update_filled_spaces index
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    filled_spaces_arr.push(index)
    update(filled_spaces: filled_spaces_arr.join(' '))
end

def is_full?
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    filled_spaces_arr.count == 25
end

def has_new_x?
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    !self.turns_to_x && (Board::X_WIN - filled_spaces_arr).empty?
end

def has_new_line?
    filled_spaces_arr = self.filled_spaces ? self.filled_spaces.split(' ') : []
    !self.turns_to_line && Board::LINE_WIN_COMBINATIONS.find { |combo| (combo - filled_spaces_arr).empty? }
end

def update_high_score high_score
    if !self.board[high_score] || turn_count < self.board[high_score]
        self.board[high_score] = turn_count
        self.board.save
    end
end

def update_scores(turns_to_score, high_score)
    self[turns_to_score] = turn_count
    self.save
    update_high_score(high_score)
end

def handle_match index
    update_filled_spaces(index)
    update_scores(:turns_to_full, :full_high_score) if is_full?
    update_scores(:turns_to_x, :x_high_score) if has_new_x?
    update_scores(:turns_to_line, :line_high_score) if has_new_line?
end

def play_turn num
     remove_from_unused(num)
     count_turn
     match = get_match(num)
     handle_match(match) if match
 end

def sim_play
    play_turn(unused_nums.split(' ').sample) until is_full?
end

Beautiful! We've built a fully functioning bingo game! Let's look at the seed file to see how simple the code for seeding our database can now be (with some help from the Faker gem):

puts "Seeding..."

# generate 20 unique boards
Board.generate_board until Board.all.count == 20

#generate fake users and passwords
5.times do
    name = Faker::Name.name
    username = Faker::Beer.brand.gsub(/\s+/, "")
    password = Password.create(password: Faker::Types.rb_string)
    Player.create(name: name, username: username, password_id: password[:id])
end



#simulate each user playing each board (note: this will take a while. The puts are to help track progress)
Player.all.each do |player|
    puts "player #{player[:id]}"
    Board.all.each do |board|
        puts "board #{board[:id]}"
        unused_nums = (0..99).to_a.join(' ')
        new_game = PlayedBoard.create(player_id: player[:id], board_id: board[:id], unused_nums: unused_nums)
        new_game.sim_play
        puts new_game[:turn_count]
    end
end

puts "Done seeding!"

This takes a while, but when it's done you'll have twenty unique boards, five users, and one hundred played_boards! Please feel free to check out the repo, and tell me what you think!

Questions? Feedback? Drop it in the comments, connect with me on LinkedIn, or email me at naftalikulikse@gmail.com.

Book Wyrms 2.0: "React"ing to my First Project

Naftali Kulik — Wed, 15 Jun 2022 17:55:12 +0000

When I started working on my first big project, my goal was to hit it out of the park. I wanted to put all of my (admittedly limited) knowledge to use and build something I could be proud of. The result was 750 lines of vanilla JavaScript code that, while it worked beautifully, would be quite a challenging task to read for anyone other than me, who wrote it (and we'll see if even I can read it after I have a year or two to forget about it). Don't get me wrong, I am quite proud of the effort. However, even at the time, I was well aware that there was probably a better way to do it. My goal was to put the knowledge that I had to the test, and I did.

Enter React. Little did I know at the time, my project was a tailor-made React application, only without React. Let's take a look at some of the code and see how React could (and in fact did) allow me to completely refactor the code to make a much more organized application, while perhaps even adding or improving functionality. For obvious reasons, I will not be going through all 750 lines of code here, this is a blog, not a book. It's here if you want to take a crack at it yourself.

Let's quickly walk through the functionality of the app before we continue (or you can watch this walkthrough video). The app is essentially a knockoff of Goodreads. The user can search books by title or author (book information obtained via the Open Library API), and view detailed information about the book when a search result item is selected. Users can also log in or create an account, allowing them to rate and review books, as well as add books to a read list or wish list. Here's a screenshot of the app in action:

As you can see from the picture, much of the app looks like it could be made up of React components. The first and perhaps biggest advantage of using React would be the ability to use JSX so that something like this:

const ul = document.createElement('ul')
    ul.id = id
    document.getElementById(divId).appendChild(ul)
    books.map(book => {
        let rating
        const cover = book.cover.substring(0, book.cover.length - 5) + 'S.jpg'
        book.ownRating === 'none' ? rating = 'You have not yet rated this book' : rating = `You have given this book a rating of ${book.ownRating} out of 5`
        const li = document.createElement('li')
        li.className = `li-for-${id}`
        const bookCover = document.createElement('img')
        bookCover.src = `${cover}`
        li.appendChild(bookCover)
        const h4 = document.createElement('h4')
        h4.textContent = `${book.title}`
        li.appendChild(h4)
        li.appendChild(document.createElement('br'))
        if (id === 'readList') {
            const bookRating = document.createElement('p')
            bookRating.textContent = `${rating}`
            li.appendChild(bookRating)
            let review
            book.review === 'none' ? review = '<p>You have not reviewed this book</p>' : review = `<h5>Your Review:</h5><p>${book.review}</p><br><button id="delete-review-${book.id}">Delete this review</button>`
            const bookReview = document.createElement('p')
            bookReview.innerHTML = review
            bookReview.className = 'user-review'
            li.appendChild(bookReview)
        }
        if (id === 'wishList') {
            const addToRead = document.createElement('button')
            addToRead.id = `make-read-book-${book.id}`
            addToRead.textContent = 'Add this book to your read list'
            li.appendChild(addToRead)
            addToRead.addEventListener('click', () => {
                currentUser.wishList.splice(currentUser.wishList.indexOf(book), 1)
                currentUser.readList.push(book)
                updateBookFromUserEnd('wantToRead', book.id, currentUser.username, true)
                handlePostPatch('users', 'PATCH', currentUser, updateUserCallback)
            })
            const removeBook = document.createElement('button')
            removeBook.id = `remove-book-${book.id}`
            removeBook.textContent = 'Remove this book'
            removeBook.style.margin = '3px'
            li.appendChild(removeBook)
            removeBook.addEventListener('click', () => {
                currentUser.wishList.splice(currentUser.wishList.indexOf(book), 1)
                updateBookFromUserEnd('wantToRead', book.id, currentUser.username, false)
                handlePostPatch('users', 'PATCH', currentUser, updateUserCallback)
            })

can be drastically simplified by using JSX to simply write out the HTML syntax in your React component. This alone would've slashed the amount of code by half and made it significantly more readable.

However, it still would have been a mostly disorganized jumble of different functions responsible for accomplishing different tasks. Dividing these into separate files, or components can go a long way toward organizing and simplifying the code. Let's take a look at some of the functions from the code:

renderPageButton(pages, id, list)

renderSearchResultPages(i, id)

renderBookResults(book)

renderDetailedBook()

renderBasicUserInfo(user)

renderUserLists(books, id, divId)

Hmmm. Those look like they have much in common with React components! Each of those functions is responsible for rendering DOM nodes, and they even take arguments that are similar to props in that they allow the same function to be used for several parts of the same document by passing different information down to the function. One can easily imagine how this code:

bookList.map(book => renderBookResult(book))

can get lost somewhere in a 750-line code jungle. A separate file (component) can make this easy to read and easy to find if necessary. For example:

import React from 'react'
import BookCard from './BookCard'

function BookList({ books }) {
    return (
        <ul>
            {books.map(book => <BookCard book={book} key={book.id} />)}
        </ul>
    )
}

export default BookList

Now the BookList component lives in its own file and can be imported wherever it's needed, with the appropriate list passed as props. The imported BookCard component probably looks something like this:

import React from 'react';
import SearchResultBtn from './SearchResultBtn';

function BookCard({ book }) {

    return (
        <li className='book-card'>
            <img src={book.cover} alt={book.title} />
            <h5>{book.title}</h5>
            <p>By {book.author}</p>
            <SearchResultBtn />
        </li>
    )
}

export default BookCard

and is generic enough to be used for many different book cards.

There's one more feature of React that seems like it was made for this app, and that is state. Take the following code, copied from the Book Wyrm code:

let currentBook;

let currentUser;

function updateBook(book) {
    currentBook = book
    renderDetailedBook()
    return currentBook
}

function updateUser(user) {
    currentUser = user
    renderBasicUserInfo(currentUser)
    return currentUser
}

Let's run through what state does for a moment. State allows you to save information to a variable, and update that variable by passing the new value to a setter function. Additionally, the component will re-render every time the state variable is modified. Now take a look at the above code again. Isn't that what we're doing? The currentBook and currentUser variables are declared but not assigned, and the updateBook and updateUser functions assign whatever value is passed as an argument to the appropriate variable and re-render the appropriate DOM element to reflect the changes. Using state, we can write this:

import React, { useState } from 'react';

const [currentBook, setBook] = useState({});

const [currentUser, setUser] = useState({});

to accomplish the same thing. These variables and setter functions can then be passed down to whichever components need them via props, or, as I did in my own refactor, used with context.

In conclusion, one can easily see how not only was I able to completely refactor my code in a way that made it (mostly) more readable and organized, I was actually able to add functionality without sacrificing clarity, and even used react-router-dom (a topic for a different time perhaps) to make it appear as if the application consisted of several pages and to seamlessly navigate between them. I have deployed both the first version and the second version, which, if you compare the two shows that not only can React help you make your code more easily readable and organized, it (with a little help from React Bootstrap!) can also help drastically improve the functionality of your app, as well as the user experience.

Academic vs Intuitive Understanding Part II: Speaking the Language

Naftali Kulik — Thu, 19 May 2022 21:00:59 +0000

When I was a kid, I always pictured a computer programmer as someone sitting hunched over a black and white screen feverishly punching indecipherable combinations of letters and numbers into their keyboard, filling up line after line with what was essentially memorized gibberish. To my mind, the word "code" evoked images of a vast and immutable library of "codes", random character combinations intended to be entered into some part of a computer that I had never seen before to make my computer's programs do the stuff they were supposed to do. Let's just say that the idea of doing something like that for a living never really appealed to me much. The more I learn, the more I see how wrong I was about all that. Well, everything other than the part about sitting hunched over a screen all day. Code is flexible, versatile, and above all, it actually makes sense. Asking a program if 1 + 1 === 2 does exactly what you would expect it to do, and the built-in methods (specifically in JavaScript, I don't know anything else yet) have names that pretty much tell you exactly what they're doing. Want to find a specific element in an array? Well, chances are that even if you know nothing at all it won't take a genius to guess that the method called .find() might be the one that you're looking for. And it's not just the names. Digging under the hood of built-in JavaScript methods shows that they follow an intuitive and logical (if sometimes complicated!) process to do what they do. The fact that it's called a programming "language" is no coincidence. Language is fluid and flexible, and one can use language to express anything, often in multiple ways. To be fluent in a language is not to have a memorized list of words in your head, rather it's about having an intuitive grasp of how it works, allowing you to manipulate the language to express yourself in the way that you want. One who is not fluent in a language cannot express themselves in that language nearly as well, even if they have memorized many individual words. Making the jump from knowledge to fluency is something that can only be done with practice, which was something that I explored in detail in my first post.

I am not claiming to be anywhere near "fluent" in JavaScript. I am still a relative beginner who is learning new things every day. However, I am starting to see growth. At the time that I wrote Part I, testing code was more about seeing what would go wrong than it was about seeing if it'd work. Working on my first major project for Flatiron School, I was pleasantly surprised that for the most part, my code did what I thought it would do the first time. I definitely ran into my fair share of bugs, but most of the time it was either something I overlooked or something written early on in the program coming back to bite me later on.

As I've become more fluent, I find myself able to manipulate JavaScript in different, creative ways to accomplish my goals. For example, if you're dealing with multiple fetch requests that all do different things, you can write out a bunch of different requests with the appropriate callbacks, or you can write something like this:

function handleGet(url, callback) {
    fetch(url)
    .then(res => res.json())
    .then(data => callback(data))
}

this:

class Config {
    constructor(method, body) {
        this.method = method,
        this.headers = {
            "Content-type": "application/json",
            "Accept": "application/json"
        },
        this.body = JSON.stringify(body)
    }
}

and this:

function handlePostPatch(source, method, obj, callback) {
    let url
    method === 'POST' ? url = source : url = `${source}/${obj.id}`
    fetch(url, new Config(method, obj))
    .then(res => res.json())
    .then(data => callback(data))
}

Now all you have to do is build the appropriate callbacks and pass them as arguments in the above functions as needed. As a side point, in reference to what I wrote earlier about JavaScript methods generally having easy-to-understand names, sometimes that name sounds like it was the first thing that popped into the head of the person who developed it. I bring this up now because seriously, stringify?? It's still pretty self-explanatory though, so who cares? I definitely don't.

I'd like to share another neat trick that, while it probably wouldn't usually be necessary, demonstrates how disparate techniques can be combined to do what needs to be done in creative ways. Let's outline a hypothetical case. Say you have an app that renders data obtained from different sources, for example, information about books. Many or all of them were assigned a specific className when they were rendered to the DOM, and now you want to iterate over the HTMLCollection for that className to add some sort of event listener that would send data via a PATCH request, perhaps the contents of a <form>, and update the server accordingly. The problem you may be running into now is that to send a PATCH you need the id of whatever it is that you are updating. That may have come back as part of the request that originally was made to render the information, but how can you store that somewhere where it can be easily accessed and associated with the correct element? Generally, you'd add the event listener whenever the element was rendered to the DOM, while you're still working with the server's response and have access to the id. For argument's sake, let's say that isn't possible or practical for some reason or the other. How and where can you store the id in a way that it'd be associated with the correct element when the event listener is fired? One way to do this would be to create an object that contains the element and id in the callback that handles the original response and to push the object into an array. Then your event listener callback can iterate over the array to find the id that's matched with the correct element and use it for the PATCH. However, this involves a lot of iteration, so maybe instead of iterating over the HTMLCollection for the relevant className, maybe you can iterate over the array of objects itself to add the event listener and have the id right there. Then you'd end up with something like this:

bookArr.map(bookObj => {
    bookObj.book.addEventListener('submit', () => {
        callback(bookObj.id)
    })
})

But there's a way to do this without creating a whole new array, by creatively manipulating strings.

Quick disclaimer, many of these string methods use iteration under the hood, so there's a good chance this isn't any more efficient than the methods I just presented, and perhaps even less so. I just think it's a cool demonstration of the diverse things you can do with different methods. I still haven't fully wrapped my brain around how Big O notation works, so take anything I say about efficiency with a grain of salt.

While handling the original request and rendering it to the DOM, add an id to the element that you are planning to add an event listener to that looks something like this (assuming data is the object from the server response that you are currently handling):

submitForm.id = `form-for-${data.id}`

Then, in the event listener callback just to this:

const idSplit = event.target.id.split('-')
const id = idSplit.slice(idSplit.length - 1)

There's your id! Ok fine, it's not really any more efficient than the previous methods, but it's still cool.

The more you practice, the more you become "fluent" in JavaScript. The more fluency you have, the more versatile and flexible your code can become. Eventually, perhaps writing code can become as natural as talking or writing in your native language, and creating functional applications will just become a matter of "telling" JavaScript what you want to be done, in a smooth and efficient manner.

Edit 5/27/22: There's a lot I still have to learn, such as the name attribute which would probably render my little trick with the id completely pointless. I believe that the point I was trying to make is still valid though.

Academic vs Intuitive understanding (aka practice makes competent)

Naftali Kulik — Sun, 08 May 2022 16:37:46 +0000

Welcome to my first blog post!

I am just starting out on my journey as a student at Flatiron School, and I'd like to share a few insights that I've picked up so far along the way. Specifically, I'd like to discuss how much there is to gain from practicing your code and seeing how it works over just learning the rules, syntax, etc.

One thing that jumps out at me, again and again, is the vast gap between having knowledge (i.e. academic understanding) of something and actually getting (intuitive understanding) something in a way that the knowledge can be applied properly and practically. This in fact appears to be a major difference between the way Flatiron School teaches and the way many college courses are taught. Your average college course may teach you all there is to know about programming; Flatiron School makes you into a programmer. The difference is subtle but profound.

I'll give a quick example of this to demonstrate what I mean. It's hard for me to imagine now, but when I completed my prework for Flatiron I had no idea how iteration/looping could be useful. That's not to say that I didn't understand the basics of how it worked, but I hadn't intuitively grasped how it could actually be applied in a meaningful fashion. Because of this, when I was creating a website for my prework project, it never occurred to me that this:

flipCards(lineOne, 0, 0);
flipCards(lineOne, 1, 1);
flipCards(lineOne, 2, 2);
flipCards(lineOne, 3, 3);
flipCards(lineOne, 4, 4);
flipCards(lineOne, 5, 5);
flipCards(lineTwo, 0, 6);
flipCards(lineTwo, 1, 7);
flipCards(lineTwo, 2, 8);
flipCards(lineTwo, 3, 9);
flipCards(lineTwo, 4, 10);
flipCards(lineTwo, 5, 11);
flipCards(lineThree, 0, 12);
flipCards(lineThree, 1, 13);
flipCards(lineThree, 2, 14);
flipCards(lineThree, 3, 15);
flipCards(lineThree, 4, 16);
flipCards(lineThree, 5, 17);
flipCards(lineFour, 0, 18);
flipCards(lineFour, 1, 19);
flipCards(lineFour, 2, 20);
flipCards(lineFour, 3, 21);
flipCards(lineFour, 4, 22);
flipCards(lineFour, 5, 23);

with only a few minor modifications to my code could have looked like this:

for (let i = 0; i < allCards.length; i++) {
    flipCards(i)
}

Now I rarely write code without using some form of iteration or looping but at the time it wasn't so simple.

So how do you make the jump? How do you go from academic knowledge to intuitive understanding? I've found the answer to be practice, or more specifically making mistakes. "Learning from your mistakes" is a cliché that may be older than computer programming itself, but rarely can it be applied quite as literally as it can when it comes to coding. By working through your code and figuring out what it's actually doing vs what you think it should be doing you can gain more than you ever would by "book" learning alone. Allow me to take you through some code that's based on code that I wrote, and demonstrate how at every step every mistake I made led me to a deeper and more complete understanding of the code I was working with.

Say we have an object with car manufacturers as its keys, some with empty strings as values, some with an array containing some of the models of car that are produced by that company:

const cars = {
    honda: '',
    toyota: ['corolla', 'camry', 'avalon', 'sienna'],
    gmc: '',
    chrysler: '',
    ford: ['explorer', 'fusion'],
    hyundai: ['elantra', 'sonata', 'genesis', 'santa fe'],
    infiniti: ''
};

Now let's say I'd like to render these cars as a <ul> on my webpage, with a nested <ul> to list the models of car that are included for those manufactures that have them. If we were just making a list of manufacturers (the keys) that would be fairly simple. We have a <ul> in our html file with an id of #main-list. Let's build a function that would create a <li> tag and add it to this <ul>:

function makeLi(car) {
    const li = document.createElement('li')
    li.textContent = car
    document.getElementById('main-list').appendChild(li)
}

Now we can use a simple for...in to create the list:

for (const car in cars) {
    makeLi(car)
}

Now let's see what we get:

That was easy!

However, we'd like to add the nested <ul> so let's see how we can do that.

First let's add another parameter to makeLi:

function makeLi(car, id) {
    const li = document.createElement('li')
    li.textContent = car
    document.getElementById(id).appendChild(li)
}

Everything is the same, except that the id of the <ul> is passed as an argument instead of being spelled out in the function.

Now we'll start building another function. This one will start off the same as makeLi but will have a few extra steps:

function makeLiWithNestedUl(car) {
    const li = document.createElement('li')
    li.textContent = car
    document.getElementById('main-list').appendChild(li)
    const ul = document.createElement('ul')
    ul.id = 'child-ul'
    li.appendChild(ul)
    cars.car.map(model => makeLi(model, 'child-ul'))
}

Now let's update our for..in with a simple ternary statement:

for (const car in cars) {
    cars.car === '' ? makeLi(car, 'main-list') : makeLiWithNestedUl(car)
}

And let's see what we get:

Well... Seems like we just ran into our first learning opportunity! The error message is telling us that JavaScript apparently doesn't recognize our .map() method for what it is, rather it seems to be trying to give the word "map" some sort of value (which doesn't exist). It must be that cars.car, which should return the value of whichever key our for..in loop is passing as an argument to the function, is not being recognized as an array for some reason. Let's use console.log() to do some troubleshooting.

for (const car in cars) {
    console.log(cars.car)
    //cars.car === '' ? makeLi(car, 'main-list') : makeLiWithNestedUl(car)
}

Let's take a look at our console to see what we've gotten:

That's weird... It seems that cars.car is returning undefined. Have we misunderstood something about our for..in loop? We'll quickly make sure we haven't missed something here:

for (const car in cars) {
    console.log(car)
    //cars.car === '' ? makeLi(car, 'main-list') : makeLiWithNestedUl(car)
}

Let's check the console:

It seems that car does in fact return the keys to our cars object, so why is cars.car undefined? We've just learned our first lesson! Now I've realized the implications of something I already knew but perhaps never internalized the way I needed to. All keys are really strings. Our for..in is saving the keys of cars to the car variable as strings, and therefore our dot notation isn't working! In fact, if we look at our DOM, it seems the ternary expression didn't work properly either:

It seems that our <li> for honda has a nested <ul> despite its value in our cars object being an empty string. Our ternary statement was checking if cars.car === '' and was returning false, because cars.car was in fact undefined! Our code therefore called the makeLiWithNestedUl function on the first key of our cars object, honda, and then ran into an error when we tried using the .map() method on cars.car, which was undefined. Let's do a quick console.log(), this time with bracket notation, to confirm our suspicions:

for (const car in cars) {
    console.log(cars[car])
    //cars.car === '' ? makeLi(car, 'main-list') : makeLiWithNestedUl(car)
}

And here's the result:

Perfect! It's logging the correct values for all of our keys! (In some cases that's nothing, i.e. an empty string.)

Let's get rid of the console.log(), uncomment our ternary statement, change our dot notation to bracket notation (both in the ternary and in the makeLiWithNestedUl function), and see what happens!

Oy vey. Our bracket notation seems to have fixed our ternary statement and gotten our .map() method to work. However, for some reason, all of the nested <li> elements are being added to the first nested <ul>, under toyota. Let's take a look at our DOM to see if ford and hyundai aren't getting their <ul>s for some reason.

Hmmm. They definitely are getting nested <ul>s added, but I think our mistake is fairly obvious now. We've accidentally assigned the same id to all of our nested uls. There are two lessons to be learned here. First of all, although an html document isn't supposed to have more than one element with the same id, JavaScript apparently has no problem adding the same id to more than one DOM node if we tell it to. Secondly, if more than one DOM node or element has the same id, document.getElementByID() will return the first element with that id. Let's look at our functions again:

function makeLi(car, id) {
    const li = document.createElement('li')
    li.textContent = car
    document.getElementById(id).appendChild(li)
}
function makeLiWithNestedUl(car) {
    const li = document.createElement('li')
    li.textContent = car
    document.getElementById('main-list').appendChild(li)
    const ul = document.createElement('ul')
    ul.id = 'child-ul'
    li.appendChild(ul)
    cars[car].map(model => makeLi(model, 'child-ul'))
}

Our makeLiWithNestedUl is calling makeLi and passing 'child-ul' as the argument for the id parameter. Because of this, all of our nested <li>s are being added to the first <ul> with an id of 'child-ul', which is the one for toyota.

How can we assign different ids to our nested <ul>s while still effectively using iteration? Here's where we can use a simple tool that's way more powerful than I realized when I first learned about it. Some simple string interpolation should allow us to assign unique ids to each nested <ul>:

ul.id = `${car}-list`

cars[car].map(model => makeLi(model, `${car}-list`))

And here's our updated function:

function makeLiWithNestedUl(car) {
    const li = document.createElement('li')
    li.textContent = car
    document.getElementById('main-list').appendChild(li)
    const ul = document.createElement('ul')
    ul.id = `${car}-list`
    li.appendChild(ul)
    cars[car].map(model => makeLi(model, `${car}-list`))
}

Let's refresh our browser and see the result:

We did it!

Let's go a bit further. There's more code to write, more mistakes to be made, and more lessons to learn!

I'd like to be able to change the color of each car manufacturer name to blue when it's clicked on, and each car model name to red when its clicked on. I'd also like for both to be changed back to black when clicked again. Should be simple, right? We can create a relatively simple event listener. First let's modify our original functions a bit:

function makeLi(car, id, className) {
    const li = document.createElement('li')
    li.textContent = car
    li.className = className
    document.getElementById(id).appendChild(li)
}
function makeLiWithNestedUl(car) {
    const li = document.createElement('li')
    li.textContent = car
    li.className = 'parent-li'
    document.getElementById('main-list').appendChild(li)
    const ul = document.createElement('ul')
    ul.id = `${car}-list`
    li.appendChild(ul)
    cars[car].map(model => makeLi(model, `${car}-list`, 'child-li'))
}
for (const car in cars) {
    cars[car] === '' ? makeLi(car, 'main-list', 'parent-li') : makeLiWithNestedUl(car)
}

What I did here was add a parameter to my makeLi function allowing me to assign a className to the <li> element being created. This allows me to to assign separate classNames for the parent and child <li> elements. Lets make some arrays now:

const parentLiArray = Array.from(document.getElementsByClassName('parent-li'))
const childArray = Array.from(document.getElementsByClassName('child-li'))

Now let's add some event listeners:

parentLiArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        li.style.color === 'blue' ? li.style.color = 'black' : li.style.color = 'blue'
    })
})

childArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        li.style.color === 'red' ? li.style.color = 'black' : li.style.color = 'red'
    })
})

Great! now let's check the result:

Oops. We forgot that styles applied to a parent will also apply to the child unless otherwise specified. When we click on hyundai it's also turning its child elements blue. Let's give a default style to all of our <ul> elements to prevent this:

Array.from(document.getElementsByTagName('ul')).map(ul => ul.style.color = 'black')

There we go! Uh-oh. We seem to be running into other issues though.

Why are our nested <li>s also turning blue? To make matters worse, they're not changing back to black when they are clicked again. Let's get some console.log()s going again.

parentLiArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        li.style.color === 'blue' ? li.style.color = 'black' : li.style.color = 'blue'
        console.log(e.target.style.color)
    })
})

childArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        li.style.color === 'red' ? li.style.color = 'black' : li.style.color = 'red'
        console.log(e.target.style.color)
    })
})

Now we can check the console for some clues as to what's going on:

Now that's interesting. There are two values being logged when the nested <li> is being clicked. The first is red, as it should be. The second is blue. Apparently our code is changing the color to red as it should, but then immediately changing it to blue. Clicking it again logs the same result. (You can take my word for it). Let's try a different console.log() to see if our event listeners are behaving the way they should:

parentLiArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        li.style.color === 'blue' ? li.style.color = 'black' : li.style.color = 'blue'
        console.log(e.target)
    })
})

childArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        li.style.color === 'red' ? li.style.color = 'black' : li.style.color = 'red'
        console.log(e.target)
    })
})

Let's check out the console again:

Fascinating. The clicked element is being logged twice! Making this mistake originally taught me something I actually hadn't known. Adding an event listener to a parent element will automatically add the same event listener to its children. When I clicked the child <li> element, it first fired its own event listener, which checked if its style was set to red (it wasn't) and then changed it to red. That part worked perfectly. The problem was that after that the event listener for the parent fired, checked if the style was blue (it wasn't), and changed it to blue. The reason it didn't change back when clicked again was that it kept repeating the same process, checking if it was red, changing it to red, then checking if it was blue and changing it to blue. Now that we realize this maybe we only need one event listener for both! How can we do that? Let's see... We need some way for JavaScript to differentiate between the parent and child elements and act accordingly. I'm going to get rid of the event listener for the child <li> elements because we don't need it anymore. Now let's change up our other event listener a bit:

parentLiArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        if (li.className === 'parent-li') {
            li.style.color === 'blue' ? li.style.color = 'black' : li.style.color ='blue'
        } else {
            li.style.color === 'red' ? li.style.color = 'black' : li.style.color = 'red'
        }
    })
})

Now our event listener is first checking the className of its target and acting accordingly, changing between blue and black if its className is 'parent-li', and changing between red and black if not. Let's try it in our browser again:

Great! Now let's click a few of them again to make sure they change back to black:

Perfect! We did it! Here's the completed, functioning code:

const cars = {
    honda: '',
    toyota: ['corolla', 'camry', 'avalon', 'sienna'],
    gmc: '',
    chrysler: '',
    ford: ['explorer', 'fusion'],
    hyundai: ['elantra', 'sonata', 'genesis', 'santa fe'],
    infiniti: ''
};

function makeLi(car, id, className) {
    const li = document.createElement('li')
    li.textContent = car
    li.className = className
    document.getElementById(id).appendChild(li)
}
function makeLiWithNestedUl(car) {
    const li = document.createElement('li')
    li.textContent = car
    li.className = 'parent-li'
    document.getElementById('main-list').appendChild(li)
    const ul = document.createElement('ul')
    ul.id = `${car}-list`
    li.appendChild(ul)
    cars[car].map(model => makeLi(model, `${car}-list`, 'child-li'))
}
for (const car in cars) {
    cars[car] === '' ? makeLi(car, 'main-list', 'parent-li') : makeLiWithNestedUl(car)
}

Array.from(document.getElementsByTagName('ul')).map(ul => ul.style.color = 'black')

const parentLiArray = Array.from(document.getElementsByClassName('parent-li'))

parentLiArray.map(li => {
    li.addEventListener('click', e => {
        const li = e.target
        if (li.className === 'parent-li') {
            li.style.color === 'blue' ? li.style.color = 'black' : li.style.color ='blue'
        } else {
            li.style.color === 'red' ? li.style.color = 'black' : li.style.color = 'red'
        }
    })
})

I've now demonstrated just one small example of how practicing code, messing up, and figuring out what went wrong is the best and perhaps only way to truly understand and internalize how your code is really working. The mistakes I made in this example are based on real mistakes I made and the steps I took to fix them. (It was quite frustrating at the time, let me tell you!) I am just starting out on my journey as a programmer and I am looking forward to many future mistakes! Thanks for hanging in there with me until the end of my first ever blog. Any and all feedback is welcome!