DEV Community: merlumina

Redux Thunk For Dummies

merlumina — Sun, 10 Oct 2021 22:37:52 +0000

When you're going through a coding bootcamp, sometimes the material comes at you so quickly that it can be difficult for all the concepts to sink in. When certain concepts are building on top of other ones, if you don't get something right away you can quickly become lost.

Most recently, I found that tricky concept to be redux-thunk. However, I'm here today to explain what I've learned in hopes of helping anyone else who might be struggling to see it in a new light!

When working in regular React without Redux, making asynchronous calls is fairly straightforward. You can, for example, put a GET request with fetch() in componentDidMount() and update state with the response, which will in turn re-render the component with the new state.

The problem in Redux, however, comes down to dispatching actions to reducers. The benefit of async is that your program can keep running and doesn't get held up waiting for a request response, but the downside is this can lead to things happening in an order that you don't expect. Because of the asynchronous nature of fetch(), if you make a request inside an action creator function like normal, the action creator will return an action before the promise from fetch is resolved, meaning when your reducer goes to update state, it probably won't have the information you were expecting.

This is why we need redux-thunk: we need a way to delay the dispatch of the action, otherwise state will get updated before the promise from our fetch() call is resolved and we won't have the correct information.

As you might have heard, redux-thunk is a very small package. You can see the entirety of the behavior in the following code (reproduced here from the redux-thunk github repo):

function createThunkMiddleware(extraArgument) {
  return ({ dispatch, getState }) => (next) => (action) => {
    if (typeof action === 'function') {
      return action(dispatch, getState, extraArgument);
    }

    return next(action);
  };
}

const thunk = createThunkMiddleware();
thunk.withExtraArgument = createThunkMiddleware;

export default thunk;

That's basically all there is to it! If you're confused about what's going on here, the important thing to look at to start getting a handle on it is the if statement. As stated in the redux-thunk documentation, "Redux Thunk middleware allows you to write action creators that return a function instead of an action". So, looking at the conditional logic inside the thunk code, you can see that we're creating a queue of sorts. While the action it receives is a function, it will return that function with dispatch as an argument. It will do this until the action's type is just a plain Javascript object, rather than a function. In this way, we can queue up our actions, and make sure our reducer doesn't return a new state until we have the resolved response from our fetch() call.

And that's about it!

Boardgame Scheduler: React/Redux Project

merlumina — Fri, 08 Oct 2021 00:40:10 +0000

Today I'm going to talk about Boardgame Scheduler, my final project for Phase 5 of Flatiron School's Software Engineering Program. Boardgame Scheduler (admittedly, my least creative app name yet) is an application for managing boardgame collections and scheduling time slot for playing games. I got the idea to create an app like this because I want to hold a miniature "convention" as a wedding reception and thought having a feature like this for my website where guests can let us know ahead of times what game they'll be bringing would be a useful too. The app is built using React/Redux for frontend and Rails API for the backend. The frontend is styled using Tailwind CSS.

Backend

Models

Cardable has four models, Users, Games, Tables, and TimeSlots. Users log in with a username and password and can have many games. Games have a title, number of players, suggested play time, description, and can have many TimeSlots. Tables have a "location" and also have many TimeSlots. TimeSlots represent "events" and have a start time, end time, as well as an "All Day" boolean which are all necessary properties for configuring react-big-calendar, a package I used for the scheduling feature.

Sessions

I decided to implement logging in/out with session cookies rather than JWT tokens. Cookies are not available to API-only Rails configurations out of the box, but can be used by adding the following to your application.rb:

    config.middleware.use ActionDispatch::Cookies
    config.middleware.use ActionDispatch::Session::CookieStore

The React + Rails API Authentication series by edutechional on YouTube was immensely helpful in getting authentication up and running for this app! I highly recommend it for anyone struggling to get authentication for a React/Rails app.

Frontend

Example Redux flow for creating a game

We'll start with the game form.

// src/components/games/NewGameForm.js

import React, { Component } from "react";
import { connect } from "react-redux";
import { addNewGame } from "../../redux/actions/gamesActions";

class NewGameForm extends Component {
  state = {
    name: "",
    numberOfPlayers: "",
    time: "",
    description: "",
    user_id: this.props.user.id,
  };

  handleSubmit = (event) => {
    event.preventDefault();
    this.props.addNewGame(this.state);
    this.setState({
      ...this.state,
      name: "",
      numberOfPlayers: "",
      time: "",
      description: "",
    });
  };

  handleChange = (event) => {
    const { name, value } = event.target;
    this.setState({
      [name]: value,
    });
  };

  render() {
    return (
      // insert form here
    );
  }
}

const mapStateToProps = (state) => {
  return {
    games: state.games,
  };
};

export default connect(mapStateToProps, { addNewGame })(NewGameForm);

While this app does rely on Redux for state, since the information about a new game is only needed within this component long enough to send it to the API and won't be used by other parts of the app, the values derived from the form are stored in the components state rather than being sent to the Redux store. The user_id is set from the current user saved in the store passed in as a prop to the form.

When the form is submitted, the addNewGame action is called:

// src/redux/actions/gameActions.js
export const addNewGame = (game) => {
  return (dispatch) => {
    fetch("http://localhost:3001/api/v1/games", {
      method: "POST",
      credentials: "include",
      headers: {
        "Content-Type": "application/json",
        Accept: "application/json",
      },
      body: JSON.stringify({
        game: {
          name: game.name,
          number_of_players: game.numberOfPlayers,
          time: game.time,
          description: game.description,
          user_id: game.user_id,
        },
      }),
    })
      .then((response) => {
        return response.json();
      })
      .then((game) => {
        dispatch({ type: "ADD_NEW_GAME", game: game.game });
      });
  };
};

Which in turn dispatches the "ADD_NEW_GAME" action to the reducer:

// src/redux/reducers/gameReducer.js
export default function gamesReducer(state = [], action) {
  switch (action.type) {
    // ...other actions...
    case "ADD_NEW_GAME":
      return state.concat(action.game);
    default:
      return state;
  }
}

With the freshly created game returned from the API and added to the games array in the store, the games page is refreshed to show that the new game has been added.

Table Time Slots with React-Big-Calendar

The last thing I would like to point out is the use of the react-big-calendar package, which I found to be quite interesting to use.

On my Tables page, there is a TableCard component generated for each Table object, and there is a Calendar component for each TableCard. The Rails serializer for my Table model includes all of the TimeSlots (scheduled play sessions for a particular game) associated with that table, so it is easy to get all of the TimeSlots from state. This is important because the Calendar component requires an "events" prop to be passed, so the list of TimeSlots for each table becomes the list of events displayed on the calendar.

Next, the Calendar includes an onSelectSlot prop which is a function that fires when a time slot on the calendar is clicked. Luckily, this event includes a lot of useful information, including a Date object corresponding to the time that was clicked on in the calendar. Using this, I created a setStartTime function that will set the start attribute for the TimeSlot to the start time from the event. It also pops up a form where you can choose the game and duration of the event. Here, the TimeSlot is already populated with a start time, and the end time is created by adding the duration (in hours) from the form.

// TableCard.js
          <Calendar
            date={new Date(2021, 9, 8)}
            onNavigate="defaultDate"
            localizer={localizer}
            events={this.props.table.time_slots}
            onSelectEvent={(slot) => false}
            onSelectSlot={this.setStartTime}
            selectable={true}
            startAccessor="start"
            endAccessor="end"
            timeslots={1}
            step={60}
            view="day"
            onView="defaultView"
            toolbar={false}
            header={false}
            min={new Date(0, 0, 0, 10, 0, 0)}
            max={new Date(0, 0, 0, 18, 0, 0)}
            style={{ minHeight: 200 }}
          />

  setStartTime = (event) => {
    this.setState({
      start: event.start,
    });
    this.toggleModal();
  };

// NewTimeSlotForm.js

  handleDurationChange = (event) => {
    this.setState({
      ...this.state,
      end: String(
        add(new Date(this.state.start), {
          hours: parseInt(event.target.value),
        })
      ),
    });
  };

Those are the highlights from my Boardgame Scheduler app! Please feel free to check out the repo here:
https://github.com/lizriderwilson/boardgame-scheduler

-Liz

Cardable: Basic Kanban Board made with Javascript and Rails

merlumina — Mon, 02 Aug 2021 02:52:37 +0000

Today I'm going to talk about Cardable, my Javascript project for Phase 4 of Flatiron School's Software Engineering Program. Cardable is a basic kanban board (similar to Trello) single-page application built using Javascript for the frontend and Rails API for the backend. The frontend is styled using a node-sass installation of Bulma CSS.

Backend

Models

Cardable has only two models, Columns and Cards, with a basic association whereby a Column has-many Cards. I wanted a very simple application where a user could create and move cards around columns, all handled by Javascript, so the models don't have any additional methods.

Controllers

My columns controller contains only the #index method:

  def index
    columns = Column.all
    render json: columns, include: [:cards]
  end

I chose not to implement adding/removing/editing columns, so I only needed to be able to get all columns to display them. I chose to render JSON with associated Cards; this way, when initially loading the webpage, the application only needs to make a single GET request to /columns in order to build all the Column and Card instances.

My cards controller had basic implementations of #index, #create, #update, and #destroy methods.

Frontend

Classes

My Column and Card classes were structured similarly with the following characteristics:

Constructor methods that take in a JSON response from a GET fetch request and instantiate a Javascript Object
A static method for retrieving all instances of the class
Methods that essentially correspond to each method in the corresponding Rails controller. Both Column and Card have a method that build HTML structure for the model and render the instances to the page (using the GET response data from /columns). Additionally, Card has methods for POSTing, PATCHing, and DELETEing data, allowing the user to create new cards in a column, move cards to a different column, and delete cards.

I added a separate method to Column to create a form that would be added to each column and used to create new cards.

Running the Application

My index.js file is fairly simple, containing a fetch request to /columns that first instantiates Column and Card objects and then renders them to the page. It also has several methods for handling dragging-and-dropping (adapted from the MDN documentation). The important thing I needed to add to the drag-and-drop functionality was to trigger a PATCH request when a Card gets dropped so the Column it belongs to can get updated in the database when moving to a different column. This was handled accordingly:

//index.js

const cardToUpdate = Card.all().find(card => card.id == movingCard.getAttribute('id').slice(-1)); // find the Card instance with the id that matches the id of the element being dropped
cardToUpdate.moveColumn(el);

//card.js
moveColumn(el) { // el is the div the card is being dropped onto and is passed in from the drop method in index.js
  const columnId = el.id.slice(-1); // gets the id of the column the card is being moved to
  const cardId = this.id; // gets the id of the card
  const data = {
    id: cardId,
    column_id: columnId
  }
  fetch('http://localhost:3000/cards/' + this.id, {
    method: "PATCH",
    headers: {
      "Content-Type": "application/json",
      Accept: "application/json"
    },
    body: JSON.stringify(data) // sends the card id and column id to the API to get updated in the database
  })
  .then(response => response.json())
  .then(card => {
    if (card) { // if we get a response back, update the column_id of our Javascript Card instance
    this.column_id = columnId;
    }
  });

Table Talk: Creating a Roll20 Clone in Ruby on Rails

merlumina — Sun, 06 Jun 2021 17:46:15 +0000

Today I'm going to talk about Table Talk, my Ruby on Rails project for phase 3 of Flatiron School. Table Talk is a tabletop role-playing game campaign manager, in the same vein as Roll20 or DnDBeyond, where you can organize your Dungeons and Dragons (or any other TTRPG system) games.

If you're not familiar with tabletop role-playing games, they generally consist of a small group of people, with one person as the GM (game master) and the rest as players who each have a character they portray. The GM will narrate the story and the players will decide how their characters react to the story. The games are organized into campaigns, which represent the overall story that is being told, and sessions, which are the individual periods of time everyone gets together to play. With that in mind, I'll start by going over the models Table Talk uses.

My Models

I started by planning out my models and database schema. Since my Rails app was going to have more models and more complex relationships than my Sinatra app, I wanted to plan it out on paper ahead of time so I had a roadmap of where I wanted to go and how I would get there. This ended up being a really great decision (imagine that, they tell you to plan ahead and it is helpful!).

This is the diagram I came up with. It is not 100% accurate to what I finally came up with (as I'll explain below), but is pretty close.

Users

Users can have many campaigns, either as a GM, or through characters as a Player. They can also have many Characters and Notes.

Campaigns

Campaigns belong to a GM. They have many Characters, and many Players through characters. They also have many Sessions and Notes.

Sessions...er, Seshions?

Seshions belong to a Campaign and can have many Notes.
I ran into an issue with naming here, since Sessions are used in the application for maintaining state, logging in/out, etc. But I didn't see any way around using the term "session" for these scheduled play events in a campaign either, since that is just what they're called in the community. Sometimes people might use the word "game" as well, but that term is used more loosely and could refer to several different things, so "session" is just the best and most descriptive term to use. Because I didn't want any naming conflicts, similar to how you might have a Klass class, I used the spelling "Seshion" to refer to campaign-sessions. This is the name of the model and association, but to avoid any confusion I also tried to use this spelling in any other code (such as helper methods) that wasn't user-facing. To keep things easier to understand for users of the app, I made sure the URL in routes.rb was spelled "sessions" as they would expect:

resources :seshions, path: 'sessions'

Characters

Characters belong to a Campaign and to a Player.

Notes

Notes belong to a User and either a Campaign or a Session.

Associations

As you can probably guess from my outline above, there are a few associations I needed that were a bit more complex than just has_many and belongs_to. This was by far the trickiest part of the application. I had to do a lot of research online and find out how to tweak solutions for my specific situation, so I will highlight some of my solutions below.

Users and Campaigns

In the world of TTRPGs, for any given campaign you'll either be the GM or a player, but you can play in many different games and GM some and be a player in others. Because I wanted my User model both create/own campaigns and also play in them, I knew I had to use different names and specify the class name for the association. This is what the associations look like in my Campaign class:

class Campaign < ApplicationRecord
    belongs_to :gm, class_name: 'User'
    has_many :characters, dependent: :destroy
    has_many :players, through: :characters, class_name: 'User'

However, in the User class things get a little bit trickier. I want a User to have many campaigns, but in this case the same association would essentially exist twice - a User has_many Campaigns as a GM, and a User has_many Campaigns through Characters as a Player. Turns out ActiveRecord does not like that, so these associations need unique names on the User class as well.

class User < ApplicationRecord
  has_many :campaigns_as_gm, class_name: 'Campaign', foreign_key: 'gm_id', dependent: :destroy
  has_many :characters, foreign_key: 'player_id', dependent: :destroy
  has_many :campaigns_as_player, through: :characters, source: :campaign

Since one association is a has_many and the other is a has_many through, they work a little differently. If you try to define a class_name and foreign_key the same way as the has_many, ActiveRecord will complain that (in my case):
ActiveRecord::HasManyThroughSourceAssociationNotFoundError (Could not find the source association(s) "campaigns_as_player" or :campaigns_as_player in model Character. Try 'has_many :campaigns_as_player, :through => :characters, :source => <name>'. Is it one of player or campaign?) There is no player_id on the campaign table, and ActiveRecord isn't sure what table it should be looking at with the foreign key we've specified. Instead, :source tells ActiveRecord which table campaigns_as_player is referring to, so it can find the campaign_id on the characters table. (It took me a lot of fiddling to get this to work, but then while researching some terminology for writing this post, I found that the Odin Project has an article that explains how to do this perfectly. Wish I had found that sooner!)

Since I also wanted to be able to call @user.sessions to see ALL the campaigns a User is associated with (mostly for use in the users#show page), I created the following instance method:

  def campaigns
    self.campaigns_as_gm + self.campaigns_as_player
  end

Notes

I wanted a notes feature for the app which would serve multiple purposes. They could be for talking about scheduling, asking questions, or keeping track of items and story details. I thought it would be nice to have notes on both Campaigns and Sessions, where campaign notes would be more general and casual, and session notes would be for keeping track of specific things that happen each session. This is a perfect job for polymorphic associations!

class Note < ApplicationRecord
    belongs_to :user
    belongs_to :commentable, polymorphic: true

class Campaign < ApplicationRecord
    has_many :notes, as: :commentable, dependent: :destroy

class Seshion < ApplicationRecord
    has_many :notes, as: :commentable, dependent: :destroy

I chose to use the term :commentable instead of :noteable mainly because that seems to be the conventional term for adding comments, but also "noteable" has a different meaning, so "commentable" seemed to make more sense to me. I'm happy to listen to arguments for :noteable though!

Miscellaneous

Below I'll talk about a few other noteworthy snippets from my application.

ActiveRecord Scope Method

The project requirements included having at least one class-level method that could also be displayed in a corresponding URL. I decided to allow users to browse all the Users on the site and also look up which users are GMs and which users are Players in games.

class User < ApplicationRecord
  scope :gms, -> { joins(:campaigns_as_gm).distinct }
  scope :players, -> { joins(:campaigns_as_player).distinct }

#routes.rb
  resources :users do
    collection do
      get 'gms'
      get 'players'
    end

This lets you go to /users/gms and /users/players to see those filtered lists of users.

:campaigns and :seshions modules for Notes

I needed a unique solution for my notes#create action, since I wanted the new note form to be on the show page for the commentable it belonged to, not inside a nested route. A user should just be able to go to the show page for a campaign or session and post a comment directly on that page, not have to go to a special page with just a form on it. I also wanted to reuse the same form partial. The issue I ran into was in my #create action - I couldn't figure out how to pass in the correct information to specify if the commentable was a Campaign or a Seshion. I searched around for solutions using various keywords, and finally after searching "how to add comments with polymorphic associations" I found this great tutorial from GoRails. By creating a module for :campaigns and :sessions for each place I had specified the nested :notes resource in my routes, I could create a commentable-specific controller that knew ahead of time what the commentable type for the note was. The generic NotesController has all the behavior that all Notes need, but the Campaigns::NotesController and Seshions::NotesController can set the commentable based on either the :campaign_id or :seshion_id from the params, which is where I was originally running into trouble.

#routes.rb
  resources :campaigns, except: [:destroy] do
    resources :notes, module: :campaigns
    resources :seshions, path: 'sessions' do
      resources :notes, module: :seshions
    end
  end

class Seshions::NotesController < NotesController
    def set_commentable
        @commentable = Seshion.find_by(id: params[:seshion_id])
    end

class Campaigns::NotesController < NotesController
    def set_commentable
        @commentable = Campaign.find_by(id: params[:campaign_id])
    end

Helper Methods

Here are some fun helper methods I used!

#delete_asset

Generic delete button for different asset types.

def delete_asset(link_text, path, css_class, confirm_text)
    link_to link_text, path, method: :delete, class: css_class, data: { confirm: confirm_text }
end

#edit_or_join_campaign

Displays the proper button next to the Campaign name on the Campaign show page depending on if you are the GM, a current player, or not a player yet.

def edit_or_join_campaign
    if @campaign.gm == current_user
        link_to("Edit", edit_user_campaign_path(current_user, @campaign), class: "btn mr-2") + delete_asset("Delete Campaign", user_campaign_path(current_user, @campaign), "btn", "Are you sure?")
    elsif current_user && !current_user.campaigns.include?(@campaign)
        link_to "Join", new_campaign_character_path(@campaign), class: "btn"
    elsif current_user && current_user.campaigns.include?(@campaign)
        delete_asset("Leave Campaign", campaign_character_path(@campaign, character(current_user)), "btn", "Are you sure? Your character will be deleted!")
    end
end

#display_note_form_if_campaign_includes_current_user

Only displays the new note form if the current user is a member of the campaign. You can't comment on a campaign you aren't a part of!

def display_note_form_if_campaign_includes_current_user(commentable, path)
    if current_user && current_user.campaigns.include?(@campaign)
        render partial: 'notes/form', locals: { commentable: commentable, path: path }
    end
end

Conclusion

That's the basic writeup of the unique features of my app! I hope you enjoyed!

Github Repo: [https://github.com/merlumina/tabletalk/]

ArtBox: Sinatra Project Writeup

merlumina — Fri, 02 Apr 2021 18:25:41 +0000

Today I want to talk about ArtBox, my Sinatra application project for Phase 2 of Flatiron School's software engineering program.

For my MVC CRUD application, I chose to create a website for artists to create a digital library of their art supplies to help them keep track of their collections or share them with friends. I named my website "ArtBox".

The basic models the for application are Users, Supplies, and Categories. A users has many supplies and supplies belong to a user. Supplies also belong to a category, and users have many categories through supplies. The Category model exists to add additional functionality to the application, allowing users of the site to filter down by particular categories as they browse.

I chose to utilize the Bulma CSS framework to style my site. I've been interested in learning non-bootstrap frameworks, and I found that Bulma was really quick and easy to use for the most part. I wanted to make a good-looking site, but also didn't want to sacrifice the substance of my app by spending too much time on style, and I found Bulma was a great way to do that. My html views all ended up being a little lengthy with all the extra divs and containers and whatnot, but I didn't really find that hindered my process at all.

One of the bigger challenges I ran into was figuring out how I wanted to structure the relationship between Supplies and Categories. I originally imagined Supply and Category to have a :has_many_through relationship, and had a Supply_Category class to facilitate that with a join table. However, as I was building out my forms, I realized that didn't make much sense to me. A supply should only have one category - it might have many tags, for instance, but if you are breaking down art supplies into categories like "colored pencils," "markers," and "watercolors," it doesn't make sense for them to belong to more than one. So, I restructured my classes and got rid of Supply_Categories.

This ended up presenting an interesting challenge for my new/edit Supply forms. I wanted users to be able to either choose from an existing category or create their own. This requires two inputs, a select dropdown and a textbox. However, having them both visible on the page at the same time would be troublesome since a supply can only have one category. I could write a validation to make sure the input would only be accepted if one or the other was used, but that just felt like bad UX to me - a user would be confused why they can't use both fields if they are present. I ended up having to search online for how to toggle visibility based on dropdown selections using Javascript/JQuery. Not one tutorial was a perfect fit for what I wanted to do, but I was able to piece together a few different techniques and came up with the following:

<div class="select level-left" id="category_select">
  <select name="category[name]" id="category_name">
    <option value="" disabled selected>Select</option>
    <% @categories.each do |category| %>
    <option value="<%= category.name %>"><%=category.name%></option>
    <% end %>
    <option value="" id="new_category">--New Category--</option>
  </select>
</div>
<div class="level-right">
  <input type="text" class="input level-item"
  name="category[name]" id="new_category_name">
</div>

$(document).ready(function () {
  $("#new_category_name").prop("disabled", true);
  $("#new_category_name").hide();
  $("#category_select").change(function () {
    if ($("option:checked").text() == "--New Category--") {
      $("#new_category_name").show();
      $("#new_category_name").prop("disabled", false);
      $("option:checked").prop("disabled", true);
    } else {
      $("#new_category_name").prop("disabled", true);
      $("#new_category_name").hide();
    }
  });
});

#new_category_name is the text field for writing in a new category, and we start the script off by both hiding it (so the user won't see it) and disabling it (which is necessary for it to not come through in params when POSTing). Then, there is an event listener which waits for a click on the dropdown menu #category_select. If the text of the selected option is "--New Category--", it will reveal and enable the #new_category_name field and disable the select box (again, so its value will not come through as a parameter). If any of the existing categories is
chosen from the dropdown, the new category field will be hidden again, and that option will be re-enabled in the dropdown.

Making sure this app is as air-tight as possible in terms of user view/edit permissions and being able to access desired links from logical places throughout the site was a fun challenge. I had to re-record my demo video numerous times as I kept finding errors or bits of logic that didn't work quite the way I wanted them to, but in the end it was a useful process as I super comfortable with how it functions. Sinatra was a great intro-to-web-apps experience and I look forward to seeing what Rails has in store.

Github Repo: https://github.com/merlumina/artbox
Bulma CSS: https://bulma.io/

acnh-critterpedia: CLI Application Writeup

merlumina — Fri, 05 Feb 2021 18:58:54 +0000

Today I'm going to be talking about how I wrote acnh_critterpedia, my Ruby CLI application that interfaces with the ACNH API.

The purpose of the application is to be used in conjuction with playing the game Animal Crossing: New Horizons. In the game, one of the things you can do is catch fish, bugs, and sea creatures. The game operates on a real-world clock, so the sun rises and sets and the seasons change the same as in the real world, so the availability of critters will change depending on the month and time of day (and which hemisphere you live in!). A lot of people want to catch everything the game has available and complete their collection, but the game itself doesn't give you a list of everything. Players generally need to use fan-made online tools (like this one!) to look up what they need. Because the ACNH API is so extensive, I knew I would be able to use it build an app that performs functions players would want for all their critter-hunting needs.

I started out by planning out my app as follows:

# Project Structure

## Program Flow

1. Greets User, asks for hemisphere (northern or southern)
2. User provides hemisphere
3. Responds with hemisphere and local time, asks user to pick a selection:
    1. View Available Bugs
    2. View Available Fish
    3. View Available Sea Creatures
    4. List Bugs by Month
    5. List Fish by Month
    6. List Sea Creatures by Month
    8. Exit

## Classes

- Critters
    - Bugs
    - Fish
    - Sea Creatures
- CLI
- API

### Notes

https://acnhapi.com/v1a/fish/
https://acnhapi.com/v1a/bugs/
https://acnhapi.com/v1a/sea/

Some things, like the CLI menu options and classes, changed a bit as I developed the app, but I wanted to make sure I had an outline going in so my process had a bit of structure and I didn't get lost trying to figure out what to do next.

The project requirements included having at least 3 classes in the program, which in my case were a CLI class for creating the user interface, handling user input and performing selected tasks, an API class for retrieving data from the API, and a Critter class for storing and displaying critter attributes.

I had originally planned to make a Critter class that Fish, Bugs, and Sea Creatures would inherit from, since they all behave similarly, but I eventually realized they actually behave more or less identically, so if I give the API class the correct part of the URL to search when a search method is run, the Critter class itself does not need to change based on what kind of critter (fish, bug, sea creature) is being asked for. So for now, I decided to just have a Critter class.

In my CLI class, I start out by telling the user the time (which is important for knowing when things are available to catch) and prompting them to enter the hemisphere they are located in. This input is captured in a hemisphere variable, which is then used throughout the app to search for values in the API that are hemisphere-dependent (namely those having to do with availability by month). The CLI then instantiates the API class with the value of hemisphere. After that, the user is given options of what they would like to look for:

+-----------------------------------------------------------------------------------+
|                              Options (pick a number)                              |
+------------------------+------------------------+---------------------------------+
| 1. View Available Fish | 2. View Available Bugs | 3. View Available Sea Creatures |
+------------------------+------------------------+---------------------------------+
| 4. View Fish by Month  | 5. View Bugs by Month  | 6. View Sea Creatures by Month  |
+------------------------+------------------------+---------------------------------+
| 7. Search Fish by Name | 8. Search Bugs by Name | 9. Search Sea Creatures by Name |
+------------------------+------------------------+---------------------------------+
Type 'about' for more information.
Type 'exit' to close the program.

What would you like to do now? Type 'options' for a list of available commands.

Which is handled with a case statement:

case input
  when "options"
    list_options
  when "about"
    about_program
  when "1"
    available_critters("fish")
  when "2"
    available_critters("bugs")
  when "3"
    available_critters("sea")
  when "4"
    critters_by_month("fish")
  when "5"
    critters_by_month("bugs")
  when "6"
    critters_by_month("sea")
  when "7"
    critters_by_name("fish")
  when "8"
    critters_by_name("bugs")
  when "9"
    critters_by_name("sea")
end

Since I have just the one Critter class that will search a different part of the API depending on what critter type it is given, I was able to reuse these methods by just passing in different arguments ("fish", "bugs", or "sea", which are the corresponding sections of the API). These methods show some text to the user and then call on my search methods in the API instance. Here's an example of how that works:

    def initialize(hemisphere)
        @url = "https://acnhapi.com/v1a"
        @hemisphere = hemisphere
    end

    def search_critter_by_name(name, critter_type)
        req_url = "#{url}/#{critter_type}/#{name}"
        data = HTTParty.get(req_url)

        if data.message == "Not Found"
            "error"
        else
            critter_hash = {
                name: data["name"]["name-USen"],
                location: data["availability"]["location"],
                catch_phrase: data["catch-phrase"],
                month_range: data["availability"]["month-#{hemisphere}"],
                is_all_year: data["availability"]["isAllYear"],
                time_range: data["availability"]["time"],
                is_all_day: data["availability"]["isAllDay"]
            }

            critter = AcnhCritterpedia::Critter.new(critter_hash)
        end
    end

One thing I ran into that I plan to refactor is how I do my API calls. I was hesitant to store all the data I needed at the beginning because I was worried about app load times, but as a result I end up querying the API every time I do a search, which is not ideal. I also don't instantiate Critter objects at all unless the user asks for "Search [Critter] by name", so some functionality is being under-utilized. I think I will refactor this at some point to search all 3 APIs and create critter objects for everything at the start, which should make doing searches much simpler.

All in all, this was a great first project to work on my Ruby skills with. I learned a lot about planning my project, scoping it out, and working strategically. This gem is available for download, so if you are interested in downloading it to play around with, please do, and let me know what you think!

GitHub repo: https://github.com/merlumina/acnh-critterpedia/
RubyGems page: https://rubygems.org/gems/acnh_critterpedia

Why I Decided to Become a Software Developer

merlumina — Thu, 31 Dec 2020 16:47:16 +0000

My Background

I have been interested in computers and coding since I was very young, probably 8 or 9 years old. My earliest memories of coding are reading through my parents’ HTML For Dummies book and building a personal GeoCities page (filled with tons of context-less GIFs I had downloaded from random other sites) using Homesite 3. This was the late 90’s so still early internet days – I’m sure “90’s web design” triggers a very specific mental image, and yeah, it was just like that. I also made a few websites for some Sailor Moon and other anime forum communities I participated in, and of course, I made personal NeoPets pages as well.

At some point, my answer to “what do you want to be when you grow up?” was Computer Programmer – specifically, I wanted to make computer games. How I came to that idea, I honestly don’t remember. That said, growing up I wasn’t really exposed to much computer science, so I didn’t end up learning much about it (aside from the HTML dabbling). It wasn’t until I got to college that I was able to take my very first programming class – Intro to Programming with Java. I was SO excited to finally learn to code, but I ended up struggling a lot in the class. I found the basic concepts and syntax fairly straightforward, but had a hard time with some of the higher abstraction needed for projects where we had to write our own code. Most frustratingly, my TAs would only re-explain the basic concepts when I asked questions, so I didn’t get the help I really needed. I ended up getting my first ever C grade in that class, and I left it thinking I might just be “too stupid” to learn to program.

Looking For A Change

I graduated college with a degree in Linguistics and a realization that I didn’t have any qualifications for jobs that I actually wanted to do. This left me with insecurities that I struggled with for years. Eventually, though, I did manage to work my way towards a job that I could see myself being in for a while. I graduated college working at a coffee shop, then worked at a bead/jewelry store, and lastly found myself at a company that does print on demand custom fabric (where I have been for the last 5 years). It was here, where I worked in the operations department doing printing, packaging, and shipping, that I was reintroduced to the idea of pursuing programming. The company would, semi-regularly, allow employees to do internships with the engineering department which often lead to sponsoring enrollment at a local bootcamp. After completion, you would come back and join the engineering department. Being a college graduate, living on her own, and working full time for a low wage, this sounded like my best bet for getting the additional education I wanted, so it became a dream of mine to one day qualify for the internship. Unfortunately, due to some financial hardships at the company and later a poorly-timed job interview right before a new round of internships, I never got the opportunity to pursue that.

Fast forward to March 2020. I have been working in Product Development at this company for over a year, having upgraded from Customer Service (and before that, factory work). I enjoy my job fairly well, particularly some of the number crunching and spreadsheet formula building I get to do. On a Friday morning, two days after work-from-home COVID-19 lockdown was instated, and on the day of my 5 year anniversary with the company, I had my yearly review with my manager only to find I was being reassigned to my old factory job and taking a 25% pay cut. This was (and in many ways still is) one of the most devastating days of my life. It felt like everything I had been working towards over the past five years, the skills I had learned, the confidence I had gained through therapy but also encouragement from coworkers and managers had all just been burned down and thrown away. I was devastated, because I felt like I had finally “made it” to something that was comfortable for me, but now I was back to square one and not cut out for anything.

A Turning Point

It has taken months for me to heal from that experience, and it continues to be a challenge for me, particularly due to some major expenses that also hit me early on in the year. While I spent all this time feeling sorry for myself, I also never stopped thinking about improving myself and how I could move forward. I started to seriously consider pursuing coding again. I dove deep into some Web Development courses on LinkedIn Learning, but I had trouble finding a good rhythm and sticking with it (I have so many hobbies…but I plan to go back to them!). I also began my first foray into game development, making two micro games for game jams on itch.io – one with Game Maker Studio 2 and the other with Ren’Py. Somewhere down the line, I saw an ad for Career Karma, which promised to prepare you for the process of applying and getting into a coding bootcamp. This intrigued me, but as soon as I signed up I realized they were offering a little more handholding than I really needed. It did reintroduce the idea of bootcamps to me, and I realized that there were SO many more options than there were 5 years ago, when all they really had were full time immersive classes. Now there was part time, self paced, PLUS different financing options like ISAs. Once I realized that I could do a bootcamp while still working and not taking on massive debt, I began seriously considering doing it. And by seriously considering, I mean I thought about it for roughly two days before applying outright to Flatiron School. I did almost all the bootcamp prep work before my admissions meeting and LOVED it. I discussed all the program and financing options with my admissions counselor, and in the end decided that it was now or never! I was going to do this!

A Bright Future

I could not be more excited to embark on this journey with my Flatiron School cohort. I have spent too long dreaming of doing this but hesitating due to fear of not being good enough, but no longer! I love technology, I love problem solving, and I love bringing ideas to life by putting together the right pieces of information. I know this is going to be a great path for me, and I’m looking forward to working hard and learning a lot over the course of the next 10 months.