DEV Community: Meg Gutshall

Everyday Inspiration

Meg Gutshall — Fri, 20 Nov 2020 16:21:32 +0000

For my fourth portfolio project during what is beginning to feel like my tenure as an online coding bootcamp student, I decided to create a tool specifically for my particular track at the Flatiron School—at least that's what my project started out as, but I'll save that story for a different blog post. I'm (still) enrolled in Flatiron School's online software engineering self-paced track and unlike the part-time and full-time cohorts, we aren't beholden to a set schedule where we have to keep up with the rest of the group week to week. Instead, self-paced students are allotted a 15-month period to complete their coursework and graduate, after which they have the option to purchase time extensions.

When I enrolled at Flatiron School, there was no hard and fast time period in which self-paced students had to complete their coursework, which is part of the reason why I'm still steadily working through the curriculum to this day. I like to jokingly refer to myself as a "lifer." I made use of this flexible schedule to dive deeper into topics that I didn't fully understand as well as take advantage of unique opportunities that came my way. However, the flexibility does make it difficult to prioritize coursework over other things such as open source collaboration, networking, and side projects, which is probably another reason why I haven't completed my coursework yet. Nonetheless, I've reached the final stretch and I'm determined to finish this curriculum within the next few months.

Being a self-paced student has its pros and cons, but the main concern of this project is the support we receive from our instructors. When I began this project, we had a team of four dedicated self-paced instructors sharing the duties of holding office hours and conducting topic-based lectures, among other tasks. These sessions were held live over Zoom to enable student interaction and the topic-based lectures were almost always recorded for students who couldn't attend the original study group session. I experienced some absolutely incredible learning breakthroughs in these study groups that I know I never could have had by watching a video recording alone. Actually, the very fact that Flatiron School provided these study groups was a huge influence in my decision to enroll in their program over another coding bootcamp I was considering.

Since these sessions have impacted my learning experience so profoundly, when I had the idea to create a tool that would fulfill the requirements of the curriculum's fourth portfolio project and add value to Flatiron's self-paced student community, I got right to work!

The Original Idea

As I alluded to in the first sentence of this post, right now I'm talking about my original project idea, not what the finished product turned out to be (sound familiar?). Keep that in mind as you read through the rest of this post.

Originally, I wanted to create a web app that would enable Flatiron students in the online self-paced software engineering track to make study group topic requests. They would then be able to see all topic requests and upvote the ones they like. This way the Flatiron instructors would be able to better tell which topics their students need more support with and plan their study groups accordingly.

Models

I decided to create three models for this project: User, Upvote, and Req.

Below, you can see my model map which displays each model's attributes and associations.

Confession Time: Okay, truthfully my original app used the model name Request instead of Req, but when I got to the frontend part of my project I hit a major issue. I had errors popping up all over my console and had no idea where they were coming from! Then I got the notion to look up JavaScript's reserved words and—what do you know—Request is one of them! I changed it here because I didn't want to use examples of bad code through my blog post. I promise the rest of this post is all factually accurate, exactly as it happened!

Enum Attributes

There's one thing I want to highlight in the User model before we move on. Since this app is meant to be used by different types of users, I created a user enum attribute called role, which assigns the user one of the roles I predefined: student, instructor, or super_admin. See example below:

# app/models/user.rb

class User < ApplicationRecord
  enum role: [:student, :instructor, :super_admin]

  # Alternatively you can use...
  # enum role: { student: 0, instructor: 1, super_admin: 2 }
  # This is a more explicit way of defining an enum attribute
end

NOTE: You must define the enum attribute's values in the model before adding the enum attribute to the model in the database (aka running a migration). In other words, run your migration for the model as normal except leave out the enum attribute. Then in the model file, define the enum attribute's values as shown in the example above. Now run another migration adding the enum attribute to your model as an integer value. It's a good idea to set the default value to 0 as well so that each new instance of the model automatically takes on the first value in the enum attribute's list of values. Below is the migration code I used to add role as an enum attribute after I created my User model and defined role's attribute values.

# app/db/migrate/date_add_role_to_users.rb

class AddRoleToUsers < ActiveRecord::Migration[6.0]
  def change
    add_column :users, :role, :integer, default: 0
  end
end

Using the role enum attribute allows the different types of users to interact with the app in different ways depending on which role they've been assigned. I won't go any further into enums, but in the future I plan to write a more detailed post about this handy type of attribute and its many built-in methods.

Associations

As you can see in the model map above, Upvote acts as the join table between Student (an alias for User) and Req. This creates two types of student-owned requests:

Type 1: When a Student creates a new Req

  # app/models/user.rb

  class User < ApplicationRecord
    has_many :reqs, foreign_key: :student_id
  end

  # app/models/req.rb

  class Req < ApplicationRecord
    belongs_to :student, class_name: "User"
  end

Type 2: When a Student creates an Upvote on an existing Req

  # app/models/user.rb

  class User < ApplicationRecord
    has_many :upvotes, foreign_key: :student_id
    has_many :upvoted_reqs, through: :upvotes, source: :reqs
  end

  # app/models/upvote.rb

  class Upvote < ApplicationRecord
    belongs_to :student, class_name: "User"
    belongs_to :req
  end

  # app/models/req.rb

  class Req < ApplicationRecord
    has_many :upvotes
    has_many :supporting_students, through: :upvotes, source: :student
  end

The Look and Feel

Since this app was targeting a distinct group of people—online self-paced software engineering students at Flation School—I decided to model it after Flatiron's Learn.co curriculum platform, specifically their login functionality, curriculum topics, and study group dashboard.

User Flow

In my mind, the user flow would go something like this:

Login

The student logs into the web app using their Flatiron School credentials or GitHub OAuth and is immediately directed to the study group dashboard. From there, they have the ability to navigate the app to view other students' requests or create their own request.

It's worth noting that creating any type of authentication system was by no means part of the project requirements, but the way my app was designed and modeled made it difficult to picture the app being used without this feature included.

Navigating the App

The study group dashboard has a sidebar which contains a list of Flatiron's software engineering curriculum modules. This is also how the requests are ordered. Instead of being grouped and ordered by date like Flatiron's study group dashboard, they're grouped and ordered by module. The students can either scroll through the dashboard or select an option from the sidebar to jump to that particular module. If they find a request they like, they can click the "Upvote" button, optionally leaving a comment with their upvote. Doing so will add to that request's total number of upvotes and boost its popularity ranking. The upvote will then appear at the top of the dashboard along with the student's other upvotes and any requests they themselves had previously created.

Creating a New Request

Once the student has logged in, they'll see a "Create a New Request" button in the menu bar. Clicking this will open a modal form in which the student can input the request topic, select the appropriate module from a dropdown menu, and provide further information about the request in the description textarea field. Upon clicking "Submit", the modal disappears, the study group dashboard scrolls to the module that was input via the form's dropdown menu, and an alert is triggered asking the student to make sure they're not submitting a duplicate request (the alternative being to upvote and leave a comment on the request they would be duplicating). The student then either opts to cancel their request, edit their request, or submit their request as is. Their request will then appear at the top of the dashboard along with their previously submitted requests and any upvotes they've created on other students' requests.

Logout

Also upon login, a "Logout" button will appear in the menu which the student can click to be logged out of the web app. Again, this is not part of the project requirements but if you have a login... you gotta have a logout too.

In the End

Ultimately, I did not go forward with this particular plan. There were several reasons why, which as I said earlier could be a blog post on its own—and maybe it will be some day. Instead, I created a very similar app with almost identical functions, but instead the resulting study sessions are meant to be a "crowdsourced" activity. Hopefully I'll be able to find or create a community that will really embrace this idea of self-teaching and I can see where it goes. Until then, I plan to redesign my finished project to be more easily expandable and find something slightly more sophisticated than vanilla JavaScript to use when building the frontend.

Slipsum L. Jackson

Meg Gutshall — Wed, 16 Oct 2019 04:19:23 +0000

Author's Note (11/12/20)

My original blog post was flagged by the DEV Team for violating the Code of Conduct.

Here's the email they sent me:

For the record, my name is spelled Meghan

I'm not going to complain about the "free speech police" or anything like that. I could have used a different, less-controversial Lorem Ipsum generator as an example in my post—though it's interesting how even Lorem Ipsum generators cause controversies nowadays—however, I highly admire Samuel L. Jackson and think he's a brilliant actor so I wanted to use this one. The language that violated the DEV Community's Code of Conduct was all produced by the Lorem Ipsum generator and includes iconic dialog from his many films.

I understand the value of creating a safe community and have decided to respect the wishes of the DEV team. That being said, I do think it's a bit ridiculous to flag a post for quoting immensely popular works of cinematography. I've thought for a while about how I can adhere to DEV's CoC while maintaining the integrity of my original post and have decided to take the following steps:

I am going to redact this post, but leave the canonical version unredacted.

I am including citation links on each generated quote which take you directly to the quote's IMDb page. This is to assist readers who would like further information on the movies themselves. I'm a fierce advocate for documentation as I believe that it's an easy and universal way to disseminate knowledge to others.

I have come across a large list of other Lorem Ipsum generators since first writing this post which I've included in this update. This gives the readers a plethora of options to pick from for their own Lorem Ipsum uses.

You can find the original post and others on my personal blog. Please enjoy!

Slipsum L. Jackson (Redacted)

I created this blog post as part of a demonstration in a recent Code Talk session I recorded about the Flatiron student blogs. Feel free to check out the video below and view the session notes here.

I know this post is full of REDACTED words. It's actually a bunch of monologues given by one of my favorite actors, Samuel L. Jackson. I found this awesome tool called Samuel L. Ipsum that will generate "motherREDACTing placeholder text motherREDACTer". If this isn't for you, search "Lorem Ipsum" generators and I'm sure you'll be able to find something to your liking, perhaps Cat Ipsum so you can "litter your copy with more kitty"? :)

Author's Note:

I have since stumbled across an Awesome List of Lorem Ipsum generators. There's something for everyone in here!

If you know of a Lorem Ipsum generator that is not on this list, try your hand at open source contribution by submitting a pull request to add it!

Now take it away Mr. Jackson...

Photo sourced from Samuel L. Ipsum website

Look, just because I don't be givin' no man a foot massage don't make it right for Marsellus to throw Antwone into a glass motherREDACTin' house, REDACTin' up the way the REDACTer talks. MotherREDACTer do that shit to me, he better paralyze my REDACTED, 'cause I'll kill the motherREDACTer, know what I'm sayin'? ^[1]

My money's in that office, right? If she start giving me some REDACTED about it ain't there, and we got to go someplace else and get it, I'm gonna REDACT you in the head then and there. Then I'm gonna REDACT that REDACTED in the kneecaps, find out where my REDACTED money is. She gonna tell me too. Hey, look at me when I'm talking to you, motherREDACTer. You listen: we go in there, and that REDACTED Winston or anybody else is in there, you the first motherREDACTer to get REDACTED. You understand? ^[2]

Now that we know who you are, I know who I am. I'm not a mistake! It all makes sense! In a comic, you know how you can tell who the arch-villain's going to be? He's the exact opposite of the hero. And most times they're friends, like you and me! I should've known way back when... You know why, David? Because of the kids. They called me Mr. Glass. ^[3]

The path of the righteous man is beset on all sides by the iniquities of the selfish and the tyranny of evil men. Blessed is he who, in the name of charity and good will, shepherds the weak through the valley of darkness, for he is truly his brother's keeper and the finder of lost children. And I will strike down upon thee with great vengeance and furious anger those who would attempt to poison and destroy My brothers. And you will know My name is the Lord when I lay My vengeance upon thee. ^[4]

The above is just a sample of some text you can generate with the Samuel L. Ipsum tool.

Creating Rxeactions

Meg Gutshall — Wed, 16 Oct 2019 04:19:10 +0000

Project Idea

When I was in college, I was diagnosed with generalized anxiety disorder. Since then, I have changed psychiatrists several times and have added major depression and PTSD to my list of diagnoses. Over the course of the past decade, between seeking treatment from different doctors (each with their own preferred methods of therapy) and receiving new diagnoses, I've been on a LOT of different medications. Unfortunately, I couldn't tell you what most of them were, let alone the dosage.

This is where the idea for Rxeactions stemmed from. When I would see a new psychiatrist and we would discuss prescription medications, they would ask me for a history which I wouldn't be able to give them. I may be able to track down at least the names, dosages, and when I was taking them, but who wants to call a bunch of doctor's offices to track down their medical records? I don't! Other times, my psychiatrist would suggest a medication they had in mind to try for my treatment and I'd remember taking it before but not when, or for how long, or why I stopped it.

I really wish I would have had the foresight at the time to write down my prescribed medications and associated experiences, but I didn't. With this app, it's no longer something I'll have to worry about and hopefully it will prevent the same regret I feel now for others who find themselves in a similar situation to mine.

Starting the Project

Delay

I had a really difficult time starting this project. I think it was a combination of a few things. The last three labs in Flatiron's Sinatra section of the curriculum—Playlister, NYC Landmarks, and Fwitter—were just ridiculously hard. I got totally burnt out from them so by the time I finished those I was mentally exhausted. Also after I finished Fwitter, I didn't get an email from the project lead for another four days! When I asked him about it, he told me about the process the project leads have to go through to see which students are at the project and it's just really jacked up. Flatiron School's logistics and operations department needs to get their shit together. They're churning out these excellent programmers—why are they not having them build out solutions for their own use as well? It just doesn't make any sense to me why they are using sub-par third-party tools when former students can make them exactly what they need. Okay, rant over.

Design

I designed my app to act as a digital journal that allows users to privately track medications they’ve been prescribed as well as side effects, thoughts, and feelings associated with those medications.

The Setup

The environment.rb file is where we load all of the app's dependencies, from gems to database connections. Some Ruby gems that I decided to use were BCrypt for password hashing and Sinatra Flash to display error messages. The config.ru file details to Rack the environment requirements of the app and then runs the app. The Rakefile is where the app's rake tasks are defined. The only custom task defined in my app's Rakefile is rake console, which starts a new session in Pry.

For more detailed information on the aforementioned files and how they interact, see my blog post What's Up With That!?: SINATRA_ENV.

The Build

Corneal

I used the Corneal gem to build out the skeleton of my project. It was so helpful, and no wonder-it was build by a previous Flatiron student!

The Build - Models

Migrations

I built out my migration tables using the rake db:create_table rake task. I love the autocreate feature for the migration tables because writing those timestamp names by hand is annoying!! I had to go through a lot of iterations of my create_table migrations since I kept changing up my model attributes.

Models

I built out three models: User, Medication, and Reaction. I set up my associations as follows: A user has many medications and has many reactions through medications. A medication belongs to a user and has many reactions. A reaction belongs to a user. Therefore, I added a user_id attribute to the medication table migration and a medication_id attribute to the reaction table migration.

In addition, the Medication model contains two methods: one that defines the medication's slug attribute and one that will find a medication by its slug.

Active Record Validations

I added validations to my models as well using Active Record's built-in validation helper methods. Model-level validations are the best way to ensure that only valid data is persisted because they are database-agnostic, cannot be bypassed by end users, and are convenient to test and maintain. I learned a LOT about Active Record validations and associations by reading through the online documentation. I feel like I have a much better grasp of those concepts now and will be more prepared for the Rails curriculum.

For the User model, I validated the presence of the user's required attributes as well as the length of their password and the uniqueness of their email address to prevent duplicate accounts from being created. I specified to the model to only check for uniqueness on creation because when a user tries to log in I don't want an error message saying that the email is already associated with an account because, duh it's the user's account! For the Medication model, I validated the presence of the medication's required attributes (one of which is boolean so I had to use different options for this validation). For the Reaction model, I validated the presence of the reaction's required attributes.

Seed Data

I created three different seed files (one for each model) and saved them under db/seeds. I named the files 1-users.rb, 2-medications.rb, and 3-reactions.rb so they would execute in numerical order. Then, in seeds.rb I wrote some code to iterate through db/seeds and load the files so that when the rake task rake db:seed is executed, my database is populated in exactly the order I want while at the same time keeping the seed files separated by model, making them easier to read and manipulate later.

In the first line of each seed file, I destroyed any information in the database pertaining to that file's model so I would be sure that my seeds would be persisting into a clean database. Then, I used the .create! method and entered my own invented data for each attribute. For the medications seeds, I repeated the above process and also assigned created_at, updated_at, and user_id attributes so I could associate the medication to a user upon instantiation. For the reactions seeds, I did the same but instead assigned created_at and medication_id attributes so I could associate the reaction to a medication upon instantiation.

The Build - Controllers

The controllers are where the application configurations, routes, and controller actions are implemented. They handle all incoming requests to the app, and send back the appropriate responses to the client through the use of routes and the MVC file structure. I ended up with a total of five controllers for my app. In addition to a controller for each model, I also have a SessionsController and an ApplicationController which all of my app's other controllers use as an inheritance point.

Application Controller

The ApplicationController represents an instance of my app when the server is up and running. The configure block tells the controller where to look to find the views and the public directory. It also enables the use of sessions and sets a session secret. Lastly, it registers the use of the Sinatra Flash gem.

My app's root route is defined in this controller as well as the route for my app's about page. I chose only these two routes to define in the ApplicationController because anyone can access them when they're logged out of the app.

I also defined four of my app's helper methods in the controller. Since my other controllers inherit from the ApplicationController, they have access to the helper methods, which means I won't have to redefine them in each controller to use them. These methods jobs are to: determine the current user, determine whether or not the current user is logged, display an error message if the current user is not logged in, and display an error message if a user is trying to view another user's content.

Sessions Controller

The SessionsController is responsible for maintaining the user's session while they're using the app. The signup route will conditionally redirect the user to the home page where there will be a signup form. The input from this form will go to the UsersController. If the input proves valid, a new user will be created and logged in, then redirected to their dashboard. The login route will conditionally redirect the user to the home page where there will be a login form. If the input proves valid, the user will be logged in and redirected to their dashboard. The logout route clears the current session, effectively logging the current user out of the app, ending in a redirect to the home page.

Users Controller

The UsersController handles all HTTP requests that call on the User model object. The post users route accepts information from the signup form. If the input is valid, a new user is then created based on that input and the user is logged in and redirected to their dashboard. If not, they're returned to the signup form with an error message corresponding to the invalid input. This controller also has routes to render the user dashboard page, edit the user's information, and save those edits if they are valid. In addition, the UsersController has its own helper method that relies on current_user, one of the helper methods in ApplicationController-a great example of the magic of inheritance at work!

Medications Controller

The MedicationsController uses RESTful routes. This means that when the controller receives an HTTP request, it identifies both the HTTP verb and the URL to execute the code in the controller action that has the corresponding method and URL. The MedicationsController also has full CRUD actions, meaning it can create, read, update, or delete a Medication model object. In addition, I added a stop-med route which will change specific medication attributes to reflect that it is no longer current and then redirect the user to create a new reaction.

Reactions Controller

The ReactionsController is much like the MedicationsController except it employs the use of nested URLs.

The Build - Views

For my layout.rb file, I used a navbar in my header and added conditional statements as to which links I want displayed when the user is not logged in. I also used erb interpolation to create a @title instance variable which I set on each view page, enabling the page's title to change dynamically as the user navigates through the app.

I tried something different as well throughout my app by using partials. Sinatra is not as friendly to partials as Rails, but it worked for my purposes. I basically made view pages for my controllers to render that act as sub-layouts. Then, I used erb interpolation to render other view files within the containers I had created in the sub-layouts. This way, I could have users take multiple actions on the same page instead of navigating through the app page-by-page.

Home Page

The home page displays a greeting with a small blurb about my app and some buttons that link to the about page, followed by the signup and login forms. Users who are already logged in will be redirected to their dashboard if they try to access the home page.

About Page

The about page has four sections: "How To Use", "FAQs", "The Idea", and "Contact Me". Each of the first three sections has a button that will return the user either to their dashboard or the home page, depending on if they are logged in. The "How To Use" section explains the actions the user can take on each page of the app (except the forms since they're pretty self-explanatory) and each corresponding page has a question mark icon in the top right corner that will bring them to this view. The "FAQs" section is a list of questions I imagine users may have about the app. I take the opportunity here to clarify that this app is not meant to be used as a resource for medical advice and then direct them towards a few outside resources. In "The Idea" section I talk about how I came up with the idea for my app and in the "Contact Me" section I talk a little bit about myself and post links to my social profiles and email contact.

User Views

User Dashboard

Upon login or successful registration, the user will be redirected to their dashboard. The right-hand column displays the user details as entered in the signup form along with the option to edit these details by clicking the blue "Edit my user details" button. Below this is a list of the user's current medications with a few details about each medication. The user should click on the name of the medication to visit its detail page. In the left-hand column is a form to create a new medication. Upon completing the new medication form, the user will be redirected to that medication's detail page.

Medication Views

Medication Detail Page

On the medication detail page the user can see all the information submitted through the new medication form. If the user left the "Usage Start Date", "Usage End Date", or "Prescribing Doctor" fields blank (as they were not required), they will not appear on the medication's detail page until they add the missing information via the "Edit Medication" button. Keep in mind that deleting a medication is different from stopping a medication. To record that a medication is no longer being taken, the user should click on the "Stop Taking Medication" button. The user should only use the "Delete Medication" button if they wish to completely remove the medication and its associated reactions from their account. Once done, this action is irreversible.

On the right-hand side underneath the medication details is a list of the user's reactions associated with this particular medication along with a few details about each reaction. The user should click on the reaction's title to visit its detail page. On the left-hand side is a form to record a new reaction. Upon completing the new reaction form, the user will be redirected to that reaction's detail page.

Medications List

The medications list page displays a column of the user's current medications on the left and the user's previous medications on the right followed by all of the user's medications listed at the bottom. There is also a button in the upper right-hand corner to create a new medication which when clicked will take the user to a full-page new medication form.

Reaction Views

Reaction Detail Page

On the reaction detail page, the user will see the name of the medication the reaction is associated with followed by the title of the reaction. Below that will be an entry timestamp (as well as update if one was made to the reaction) and the body content of the user's recorded reaction. Following that are the dosage amount and usage instructions of the medication at the time the user recorded their reaction and whether or not the user is currently taking the medication. Further down the user will find "Edit Reaction" and "Delete Reaction" buttons as well as a button to return to the associated medication's detail page.

Styling

If you don't know by now, you gon' learn today... I LOVE HTML AND CSS!!! So I probably spent a little too much time on styling with this project if I'm going to be honest with myself (procrastination in the best way possible). I used Bootstrap 4 for the basic layout as well as a few components like navbar, forms, and buttons. I also used GoogleFonts for my text and FontAwesome for the icons throughout my app.

Troubleshooting

I had a hard time with the dates in the project. I didn't want to use the typical yyyy-mm-dd format for medication start and end dates because most people don't remember a specific day they started or stopped taking a medication so instead I went with yyyy-mm. However, Ruby did not like that at all. HTML5 allows for forms with input type month but Ruby will not persist the yyyy-mm format as a date so I appended "-01" on to the end of the date params to act as -dd and let Ruby persist the data. When I needed to populate the form fields for the edit forms or show the dates on any view pages, I just used the #strftime method to convert them back and it worked like a charm.

I had issues with the session.user_id not persisting as I browsed through different pages of my app. I tried to use some different gems to set a secure session_secret but it seemed that the only thing that would work was a plain old string. I read through the Sinatra documentation (in addition to countless other resources) but I just couldn't get the sysrandom gem to work and I had wasted enough time on it already.

My biggest issue was associating the user's reaction with the correct medication. I didn't want the user to have to pick from a drop down list of their medications whenever they wanted to record a new reaction because I wanted my app to be more intuitive than that (considering the new reaction form is located on the medication's detail page). I came up with a viable solution by creating a session.med_id that would change depending on the last medication detail page the user visited and using the session.med_id to set the new reaction's medication_id attribute. However, another student suggested I use nested routing and that turned out to be a cleaner, much more straightforward solution to my problem. Plus, by implementing nested routes, I was able to get rid of a lot of unnecessary code that was junking up my app.

Expansion Ideas

As I built out my app, I had a ton of ideas, many of which went in a separate file for later if I decide to expand Rxeactions and try to make it available on the market. Here are some of the ideas:

Forms & Views

I would like to be able to add sort functions to the medications and reactions list views. I'd also like to edit the form so the user has less control over the types of input, meaning I would get back data in the exact format I want. Examples of this are requiring the medication dosage_amount to be integer input while using a dropdown list for the dosage_amount units and using a dropdown list for the dosage_form choices. In addition I'd like to make the forms more granular in what information they ask for, especially when it comes to the medication usage instructions.

Additional Models

It would make much more sense to make a Prescription model that holds the details specific to the user and create models that act as attributes to fill in parts of the new medication form, such as medication name, dosage, and dosage form. This could even apply to the prescribing doctor attribute as I also had the idea to make a Doctor model. The doctor would be able to view and edit medications with which they're associated as well as view the associated reactions and user information, but they will not have edit privileges and they also would not be able to view any of the user's other medications unless they were listed as the prescribing doctor for those too. The doctor would also have contact info properties that would be viewable by all users in case any of their patients (or prospective patients) needed to get in touch with them. Another user model idea would be to add a family function in which users could be grouped by families, allowing each other viewing permissions, or a user could track a dependent's medications as a sub-user under their own account.

Medication Information

I would like to add an alarm feature to remind people to take their medication and then have a box for them to check off when they actually take it so they don't forget if they did or not. If the app could track the quantity of the medication the user has compared with the dosage amount and usage instructions, it would be able to send the user a reminder when they need to order a refill-or even send a reminder to the pharmacy or prescribing doctor. It would also be beneficial to the users if they could access verified medical advice about their specific medications right from the medication details page. I'd really like to be able to add the capability for an alert to appear on the user's dashboard when they list two medications as current that have been shown to present negative interactions with each other. Or possibly an alert for common or dangerous side effects when a user adds a new medication.

Overall Reactions

I'm thinking about how I could implement a text analyzer to comb the titles and content of the reactions for each medication and give an overall rating for the medication based on the user's recorded reactions. It would decide if the medication was mostly helpful to the user, mostly harmful to the user, or maybe neither and display this analysis on the medication's details page.

Project Demo Video

Creating BeerSnob

Meg Gutshall — Wed, 16 Oct 2019 04:18:54 +0000

Project Idea

I had a few ideas that I was considering for this project at first. I tossed around the idea of scraping through each year in the '90s and highlighting different trends, fads, pop culture, and new stories. I also considered scraping through popular songs and returning the original songs that the new song took samples from. That came closest to fruition but unfortunately I couldn't find a website conducive to this idea. I added it to my list of future projects. :)

I wanted my first project to be something useful–not just a throw-away program that I’d never touch after submission. I examined my interests and found that I could create an app at the intersection of beer and education. I found craftbeer.com to be a viable website for scraping and thus BeerSnob was born.

Starting the Project

I experienced quite a few delays in starting this project, each one pretty frustrating. I used the Visual Studio Code text editor in place of the Learn IDE and had several issues with setup that I had to solve–either through Google, message boards, or speaking with other developers and students. After fixing the settings to allow me to submit commit messages with titles and description (which is a coding habit I want to ingrain upon myself from the start) and then installing rvm to manage my rubies and gems, I was ready to dive in and begin coding my project.

Setup - Creating a Gem with Bundler

I installed and used bundler to set up my project, taking the following steps:

Open the terminal and cd into the folder in which you want to create your project (mine is called code).
Type in bundle gem then your project name. (Use an underscore instead of a hyphen to make your project name camel case.) Decide whether you want to use RSpec, MiniTest, or neither for development testing, use the MIT license for open sourcing regulation, and a code of conduct for any open source contributors to follow. Bundler then initializes a git repo for your project!

Setup - Connecting Your Project to GitHub

cd into your newly created project folder, then navigate to GitHub. Create a new repository with the same name as the project on your computer. Type git add . into your terminal, then enter the last three lines under the "create a new repository on the command line" option. They should look like:
```
git commit -m "first commit"
git remote add origin git@github.com:[your-username]/[your-project-name].git
git push -u origin master
```
Refresh your GitHub page and you'll see your project and its files now in your GitHub repository.
To make sure you're working out of the correct repo, click on the green "Clone or download" button in your project's repository. Select "Clone with SSH" for a more secure connection. "Clone with HTTPS" will also work, however, you'll be required to supply your GitHub username and password each time you make a connection to your remote repo. Click on the clipboard image to copy the link and return to your terminal. Make sure you're working in the code folder (or whichever folder your project is stored in), then type git clone and paste the link to clone the correct repo for your project.
Your new project's repo folder should appear in your local code folder. Open your text editor of choice and cd into the project folder to start working.

Hint: To test your text editor's connectivity to GitHub, make a change to your README.md file and save. In the terminal, type git add ., git commit -m "Modify README.md", and git push. When you refresh your GitHub page, you should see the updated commit message and two commits.

-OR-

Type git remote -v into your terminal. If you're connected correctly to your remote repo, you should see the following lines:

your-project-name $ origin git@github.com:[your-username]/[your-project-name].git (fetch)
your-project-name $ origin git@github.com:[your-username]/[your-project-name].git (push)

Setup - The Executable File

Add your executable file (the file that makes the app run) in the bin folder. I named mine beer-snob. (Remember to add the shebang line #!/usr/bin/env ruby at the top of your file so your computer knows to use ruby to run the program.)
We want the user to be able to run the app right out of the terminal using bash instead of explicitly calling on a ruby interpreter to run it. This means we have to change the executable file's permissions. We can do this by cding into the bin folder and entering chmod +x followed by the executable file's name.

Program Files

I employed the encapsulation principle in creating and writing my various program files. All components of the app (gems and files) are required in an environment file called beer_snob.rb, which in turn is required in the executable file.

BeerSnob Executable File

The app's executable file employs only one line of code to start the program, however, it does have a few other requirements:

As mentioned earlier, the shebang line (#!/usr/bin/env ruby) tells your computer that the file is written in ruby. Therefore, this needs to be the very first line of your program to ensure that your computer reads and processes the app correctly.
The next line is require bundler/setup which enables the app to load all necessary gems and dependencies from the Gemfile by adding them to the load path.
The third line is the app's environment file. Mine reads require beer_snob. This enables your executable file to access all the gems and program files contained within your environment.
Then of course follows the line that starts the program. Mine reads CLI.new.learn.

CLI File

The purpose of the CLI file is to call methods that act as basic functions of the program. I created a basic run method #learn which first instantiates an instance variable using the Beers and Scraper classes and then uses that variable in the following methods:

#greeting: welcomes the user to the app
#list_style_families: lists the 15 beer style families
#top_menu: handles the user input of which family they wish to explore and executes the appropriate action
#list_beer_styles: lists the beer styles within whichever style family the user chose
#sub_menu: handles the user input of which beer style they wish to explore and returns the appropriate information
#exit: displays a closing message and exits out of the program

I incorporated decorative elements in my puts Strings by using ASCII art in the #exit method and the colorize gem to distinguish headers and categories from general information.

Scraper

I decided to start my project by creating a scraper.rb file. I actually began the file in a practice repo to mess around and see what I could come up with. When it started coming together, I migrated my work into a file in my gem repo.

For each beer I wanted to store the style name, family name, and a brief description of its characteristics. Since some beers have a longer description than others, I at first decided to store only the first paragraph of each beer description. Through helping another Flatiron student with her project, I discovered a method which could return multiple paragraphs of text, depending on the parameters I set. I liked this execution much better as it allowed the app to pull all text for the beer styles with a multi-paragraph description without compromising other, shorter beer style description texts.

Next I wanted to store the listed examples of brewery and beer name for each style. This was a little tricky because my scraper kept returning the list of breweries followed by the list of beer names instead of returning them as key/value pairs. In the end, I created a nested array composed of brewery/beer name hashes by creating an iteration inside of the main beer style iteration. By doing this, I was able to create and store key/value pairs of the commercial examples.

Beers File

I wrote the beers.rb file as abstractly as possible to enable it to create new arrays and object attributes from whichever hash arguments were fed into the method. These methods in turn created the objects that were used in the cli.rb file to display the scraped information.

Art File

The art.rb file houses ASCII art which I incorporated in my CLI#exit method.

Troubleshooting

Scraping

For you to be able to get a sense of the document structure of the website I was scraping from, I'm including the site link here: Beer Styles Study Guide

The site that I decided to scrape is structured differently than I would have done it. Not all the HTML elements are nested properly and a lot of them either don't have classes or they're not descriptive of the actual element. Therefore, when scraping the site, I originally decided to iterate over the <li> tags and use indexes to draw out the information and associate it to the proper key. Unfortunately, some of the beer styles include the "Brewing and Conditioning Process" characteristic while other do not. I discovered this after my CLI displayed info associated with the wrong characteristic for some of the beer styles, shifting them down by one line item. So I went back to the scraper drawing board.

I reviewed earlier scraper labs and got an idea from the Student Scraper Lab. I created a subiteration within my #scrape method to create a key/value pair only if the key existed. I assigned the new key to be created from the param class and its corresponding value from the value class nested within the <li> tags. This process scraped more information than I want to display, but that wasn’t an issue since I could choose which information I wanted to display in the CLI class.

I didn't have to change anything for the “Commercial Examples” characteristic since I also created a subiteration for those, which dug deeper down in the nested levels to retrieve the specific beer and brewery information. However, I did have to treat the “Alcohol” characteristic differently because instead of storing its value in a <span class="value"> element, the website inserted the value text directly inside the <li> element. Thankfully, I was able to keep my indexing method for this characteristic as it's the first line under the "Style A-Z" category and, therefore, is unaffected by the addition of other characteristics.

Simplifying the Program

Even after making the above changes I still ran into issues. When writing the #initialize method in the Beers class, I employed the #send method in order to create the object’s attributes from the key/value pairs. However, since the keys were Strings and not Symbols, I wasn’t able to convert the pairs to attributes using the #send method. I could probably figure out a way to do it if I researched it more but I decided to eliminate these characteristics altogether and readdress the problem at a later date.

Project Demo Video

Knowing When to Quit

Meg Gutshall — Wed, 16 Oct 2019 04:18:22 +0000

My Rails portfolio project took a loooooooong time to finish. Actually, my BorrowBuddy app is version 2.0 of my project which was required to complete the Rails section of Flatiron's online software engineering program. I had an amazing—and completely viable—idea to begin with and I worked really hard on trying to bring to life, but I found myself going in circles and eventually decided to start over. The most difficult part though was determining whether to start fresh or press on.

This project originally started out as BookBuddy. BookBuddy was designed to be a library checkout system for school and classroom libraries. In effect, the app would allow students in a school to view all books catalogued in the school's libraries, ranging from a centrally-located library to teachers' classroom libraries. They can borrow the book through the app, where they'll be told in which library the book is located, and then go physically retrieve the book from the room. The student has the ability to put a book on hold if it's on loan and renew their current borrow if the book does not have a hold against it by another student. I also added admin users because it wouldn't be an effective app without someone maintaining the libraries, now would it? They have the ability to create, edit, and destroy schools, libraries, books, students, borrows, and holds. I wanted to eventually include email notification capabilities so the students would automatically receive reminders for when their books were due and when books they had on hold became available but I wasn't able to get that far; the problems had started up.

The build was actually going really smoothly at first. Flatiron includes virtual study groups as part of the online program (which as an interactive learner, I find to be immensely helpful) and I had attended—and actively participated in—one of the Rails Project Build series hosted by Jenn Hansen, the wonderful and highly knowledgeable Rails section lead (see the corresponding repo here). Needless to say, I felt pretty comfortable with what I was doing. The issues started when I added my Admin model to the app. Since I was using the Devise gem for my user models, I had generated Admin using Devise like so:

rails g devise Admin

After that I checked the model and the migration file to make sure everything was configured the way I wanted it, then ran rails db:migrate, restarted my server, and it was all running pretty smoothly. But when I would navigate throughout my app, I keep running into permission issues. You see, my Admin and Student models had different Active Record associations as well as different permissions so they had to be created as two separate classes (instead of adding admin as a boolean attribute on a User class). I tried so many different fixes. The Devise docs became my best friend. I attended every Rails project office hours that I could, but it seemed like whenever I had the issue nipped in the bud and tried to move on to fulfilling another requirement in my project, my browser would raise another error leading back to Devise. It came to a head the week after I returned from the Ruby for Good conference/hackathon when I felt like I hadn't accomplished anything because I was just coding myself in circles trying to fix these bugs. At this point in time, I had been working on the project for three weeks and was nowhere near finished.

I had one of two choices:

Stick with BookBuddy and somehow dig my way out. I had put so much work into this project already and I knew there had to be a solution to my problem out there—I just hadn't found it yet.
Go scorched earth and start from scratch. At this point, the option was appealing just so I wouldn't feel like slamming my head against a wall anymore. But did I really want to start all over again?

It turns out I landed somewhere in the middle. Like I said before, I had put a ton of hard work and long hours into BookBuddy so that app was not going to go anywhere; but that didn't mean it had to be my Rails portfolio project either. It's still sitting happily in its GitHub repo just waiting for me to obtain a little more knowledge (or patience... or bravery) to pick it up again and continue on. Instead, what I did was abstract the original concept of BookBuddy and create BorrowBuddy, an app that tracks which items you lend out and to whom you lend the items. I was able to use a lot of the code I had already written in my previous project and implement it on a smaller, simpler, more manageable scale.

In many cases, it's important to stick with something once you start it—especially as a programmer (that's pretty much part of the job description). That's a huge reason why I was so hesitant to restart my project. Programmers are naturally drawn to figuring out why something doesn't work, and a healthy dose of perseverance (a.k.a. stubbornness) is certainly a good quality to have, but not when it starts to get in the way of your main objective, your end goal. I'm learning many things through the Flatiron program and this latest project taught me that, at times, there can be value in quitting.

What's Up With That!?: SINATRA_ENV

Meg Gutshall — Tue, 05 Mar 2019 23:07:19 +0000

If you’re in the Sinatra Active Record section of the Flatiron School, you’ve probably seen this error message a few times: “Migrations are pending. Run rake db:migrate SINATRA_ENV=test to resolve the issue.” Well we know we need to run rake db:migrate to create our migration tables, but SINATRA_ENV... what’s up with that!?

First let’s go over a few files line by line so we can follow ENV["SINATRA_ENV"] on its journey through our app. For this, I’m using the Sinatra Complex Forms Associations Lab.

Rakefile

"SINATRA_ENV" is the key to Ruby's ENV hash and defines your deployment environment. This is set in your Rakefile.

1 . ENV["SINATRA_ENV"] ||= "development"

In most of the labs in this section, this will be the first line of your Rakefile. This means that if "SINATRA_ENV" doesn’t already have a value, its value will be set equal to "development".

3 . require_relative './config/environment'

This loads our app’s environment.rb file.

4 . require 'sinatra/activerecord/rake'

This loads Rake tasks from the sinatra-activerecord gem. A custom Rake task is defined on Lines 8-10 which starts a new Pry session.

Environment.rb

Now let’s check out our config/environment.rb file.

1 . ENV["SINATRA_ENV"] ||= "development"

Again, we see our "SINATRA_ENV" being defined. In order to maintain DRY code, I removed Line 1 from the Rakefile and all my tests for the lab still passed without any failures.

3 . require 'bundler/setup'
4 . Bundler.require(:default, ENV['SINATRA_ENV'])

On Lines 3 and 4 we require our gems and dependencies. Line 3 finds our Gemfile and makes all the gems contained within (plus their dependencies) available to Ruby by adding them to the load path. On Line 4, we’re requiring all of our gems (:default represents all gems since we didn’t create gem groups for this app) as well as our deployment environment hash to be used with the Active Record gem.

6 . ActiveRecord::Base.establish_connection(
7 .   adapter: "sqlite3",
8 .   database: "db/#{ENV[‘SINATRA_ENV’]}.sqlite"
9 . )

On Lines 6 through 9, we establish our database connection. Our adapter sets the name of the database management system (typed in all lower-case) that we’re using to hold our data and our database sets the path to our app’s database. This path includes our deployment environment hash, which is an argument of Bundle.require on Line 4 and will change based on our key’s value, pointing to other databases.

11 . require_all 'app'

This loads all other files nested under app to run the program.

Config.ru

Lastly, let’s look at our config.ru file.

1 . require './config/environment'

Again, this loads our app’s environment.rb file. Notice the difference between this line and Line 3 in our Rakefile? Both do the same thing, they just require the environment.rb file in different ways.

3 . if ActiveRecord::Migrator.needs_migration?
4 .   raise 'Migrations are pending. Run `rake db:migrate` to resolve the issue.'
5 . end

Lines 3 through 5 check to make sure our migrations have been run. If not, the error message on Line 4 is raised.

8 . use Rack::MethodOverride

Rack::MethodOverride is a piece of Sinatra Middleware that intercepts every request run by our application. It will interpret any requests with name="_method" by translating the request to whatever is set by the value attribute-normally PATCH or DELETE for purposes in our Sinatra curriculum. This line must be placed in the config.ru file above all controllers in which you want access to the Middleware's functionality.

9 . Dir[File.join(File.dirname(__FILE__), "app/controllers", "*.rb")].collect {|file| File.basename(file).split(".")[0] }.reject {|file| file == "application_controller" }.each do |file|
10 .   string_class_name = file.split('_').collect { |w| w.capitalize }.join
11 .   class_name = Object.const_get(string_class_name)
12 .   use class_name
13 . end

In Lines 9 through 13, we're mounting our controllers nested under app/controllers. These classes will also be loaded as Middleware. In this case, they'll be use OwnersController and use PetsController. Notice how "application_controller" is rejected? That's because it is called on in Line 14 below.

14 . run ApplicationController

This line creates an instance of our ApplicationController class that can respond to requests from a client. We can only run one class and the rest are loaded via use.

Bringing It All Together

So now we know what happens each time the Rakefile, the config/environment.rb file, and the config.ru file is run. We still have to answer the question as to what ENV["SINATRA_ENV"] actually is.

ENV is a hash-like accessor for Ruby environment variables. It will change depending on what information Ruby needs. The ENV accessor holds all types of information for Ruby as well as its corresponding frameworks and gems. In our case, Ruby needs to define a "SINATRA_ENV" so this is added as a key to the ENV.

When we run learn to test our app, this triggers the gem RSpec, which will run our spec_helper.rb file.

1 . ENV["SINATRA_ENV"] = "test"

As we can see on Line 1, our ENV["SINATRA_ENV"] is being set equal to "test" so that when we go to our environment.rb file as directed on Line 3, ENV["SINATRA_ENV"] is already assigned a value and, therefore, does not take on the value of "development". This means that on Line 4 of our environment.rb file, the deployment environment hash dependency has the value of "test" and on Line 8, we are establishing a connection with a different database entirely-db/test.sqlite! This database contains seed data to match the expected test outputs.

Lines 4 through 6 require gems related to testing.

8 . if ActiveRecord::Migrator.needs_migration?
9 .   raise 'Migrations are pending. Run `rake db:migrate SINATRA_ENV=test` to resolve the issue.'
10 . end

Lines 8 through 10 check to make sure our migrations have been run. If not, the error message on Line 9 is raised... and now we've come full circle. The app will not function unless we've run our migrations first because we won't have any information to display or manipulate.

The rest of our spec_helper.rb file configures the app for testing and then runs our config.ru file.

Shotgun

There's one last difference I'd like to point out. In the Sinatra section, we learn about a trusty little gem called shotgun which allows you to start your Rack-based web app with an automatic code reloading feature. It starts up a Rack server and listens for any requests so when you hit the browser's refresh button, you can see changes made to your code that have been saved. All you have to do is type shotgun in your terminal to start up a new session.

Starting a new shotgun session is like starting a new rackup session in that the first thing our app loads is our config.ru file, which on the very first line, requires our environment.rb file. At this point, ENV["SINATRA_ENV"] will be set equal to "development" and the rest of our environment.rb file will execute, bringing us back to config.ru. Again, we have the chance of raising an error message on Line 4 of our config.ru file if we have not already run our migrations. However, this message simply says "Run rake db:migrate to resolve the issue" instead of "Run rake db:migrate SINATRA_ENV=test to resolve the issue" Why is that? It's because of the line of code ENV["SINATRA_ENV"] ||= "development", which sets "development" as our default value for the "SINATRA_ENV" key. Since that's the default, we don't have to specify another "SINATRA_ENV" in our error message.

Conclusion

ENV["SINATRA_ENV"] started out as a mixed-up mess for me but after a lot of research and deep-diving into my code files, I came to understand its purpose throughout my programs. Hopefully this post helped you understand it a little bit better as well.

Git commit aborts before I can create a commit message and I use “--wait”

Meg Gutshall — Mon, 15 Oct 2018 20:34:02 +0000

I use Visual Studio Code on my Mac as my text editor and have it set up to open a new window to type my commit message, however when I type 'git commit' in the terminal, it instantaneously displays 'Aborting commit due to empty commit message.'

I have my git config set up as 'git config --global core.editor "code --wait"' and when I type 'git config --global -e' it shows '[core] editor = code --wait'. I've uninstalled and reinstalled git, I've went through the VS Code as Git Editor setup guide, and have searched online for a solution for at least ten hours. My git and VS Code versions are up to date and my commits work when I type 'git commit -m "message here"' in the command line, but I still don't know why my VS Code editor option isn't working.

Any ideas here? Thank you!

Get to Know Your Self (Refactored)

Meg Gutshall — Thu, 20 Sep 2018 16:38:21 +0000

While Ruby is an incredibly user-friendly language, it’s not without its conundrums—one in particular: self. self is a Ruby reserved word, or a word specifically designed to have a special meaning in the Ruby language. The scope (or program visibility) of self is any class or instance of a class, which we can also refer to as an object. This means that self can enable developers to contextually reference a particular class or instance of a class—depending on what the needs are for their program—without using a specific variable name.

If the method is a message, who is the receiver? The object! Many times the object and self are one in the same, but sometimes they aren't. In the example below, I'll explain how self changes depending on the "message" that's being sent.

class AfroPet
  attr_accessor :species
  @@all = []

  def initialize(species)
    @species = species
    @@all << self
  end

  def self.all
    @@all
  end
end

hipmo = AfroPet.new("Hippopotamouse")
eleham = AfroPet.new("Eleham")
ghound = AfroPet.new("Giraffet Hound")

The code above shows the AfroPet class which has a species attribute as well as an @@all class variable. Two methods have been defined as part of the AfroPet class: #initialize and self.all. In addition, three new species of AfroPet are created, including the pocket-sized Eleham!

`self` Referring to an Instance of a Class

We first see self being shoveled into the @@all class variable on Line 7, in the #initialize method. At this moment in the program, what is self referring to?

Remember that whenever we instantiate a new object (also referred to as creating a new instance of a class), we call #new on the class itself, then immediately call #initialize on the object just created—like a one, two punch. By writing @@all << self into our #initialize method, we enable the new instance to be automatically saved into the @@all class variable at the time of creation instead of having to manually add it later, which saves us time and keeps our code DRY!

To refer back to my message analogy, in this example #new is the sender while the #initialize method is the message. Furthermore, since we find self being utilized inside the #initialize method, it is considered part of what is called the method scope, confirming that self does indeed refer to the newly created object.

`self` Referring to a Class

We next see self on Line 10 in the self.all class method. This is a class method designed to return the value of the @@all class variable, which is an array of instances of the AfroPet class. As you saw above, we created three new instances of the AfroPet class: hipmo, eleham, and ghound. So what happens when we call the self.all class method?

AfroPet.all
#=> [#<AfroPet:0x000055b7db32c9c0 @species="Hippopotamouse">,
     #<AfroPet:0x000055b7db32c970 @species="Eleham">,
     #<AfroPet:0x000055b7db32c920 @species="Giraffet Hound">]

After typing AfroPet.all in our terminal, it returns an array containing our three previously-instantiated AfroPet objects, showing that the program recognizes that in this case, self is referring to the AfroPet class. We know this because the recipient of this particular "message" (or any class method as denoted with the self. prefix before the method name) is the class itself, which means that self is not scoped to any particular instance, but to the class instead.

So how does self know when to change the object it’s referencing? Two ways:

The first being context as we have previous discussed above.
The second being a built-in rule for this reserved word: one and only one self will exist at any given time in the program. There will never be a case in which self will refer to more than one object at a time, therefore leaving it up to context to determine what self actually means at any given point in the program.

I know, that’s a lot of information and your head is probably spinning by now, but let’s do one more example of self. I’ll walk you through it!

class Creamery
  attr_accessor :creamery_name, :ice_cream_flavor, :creamery_flavors
  @@all = []

  def initialize(creamery_name, ice_cream_flavor)
    @creamery_name = creamery_name
    @ice_cream_flavor = ice_cream_flavor
    @creamery_flavors = []
    self.creamery_flavors << @ice_cream_flavor
    @@all << self
  end

  def new_flavor(ice_cream_flavor)
    @ice_cream_flavor = ice_cream_flavor
    self.creamery_flavors << @ice_cream_flavor
  end

  def self.all_creamery_flavors
    @@all.each do |creamery|
      creamery.creamery_flavors.each do |flavor|
        puts "#{creamery.creamery_name} " + flavor
      end
    end
  end
end

bnj = Creamery.new("Ben and Jerry's", "Chunky Monkey")
hersheys = Creamery.new("Hershey's", "Chocolate")
nelsons = Creamery.new("Nelson's", "Graham Slam")

After defining the Creamery class, we create three new creameries: bnj, hersheys, and nelsons.

In this example, the #initialize method creates a new creamery given the creamery_name and ice_cream_flavor attributes. Here we also declare an empty array called @creamery_flavors to store this creamery’s ice cream flavors. The ice_cream_flavor is added to the creamery’s @creamery_flavors instance variable and the creamery itself is added to the @@all class variable. Remember: In the last example, we saw how self refers to the newly created object when used inside the #initialize method.

You can add a new flavor to a creamery by calling #new_flavor on that instance of creamery and declaring the new ice_cream_flavor as a String argument of the method. The new flavor is then added to the creamery’s @creamery_flavors array. Does the context in which self is used here look familiar? (Hint: See the #initialize method!)

hersheys.new_flavor("Vanilla")
#=> ["Chocolate", "Vanilla"]
hersheys.new_flavor("Strawberry")
#=> ["Chocolate", "Vanilla", "Strawberry"]

bnj.new_flavor("Chubby Hubby")
#=> ["Chunky Monkey", "Chubby Hubby"]
bnj.new_flavor("Oat of this Swirled")
#=> ["Chunky Monkey", "Chubby Hubby", "Oat of this Swirled"]

Lastly, the self.all_creamery_flavors class method iterates over the creameries in the @@all class variable and displays all the ice cream flavors contained within the Creamery class. It works like this:

Iterate over the @@all class variable to access each creamery instance.
For each creamery, call #creamery_flavors to access their instance variable array of ice_cream_flavor attributes.
Chain the #each method on that to iterate again over this nested array, this time puts-ing out the flavors to the terminal.

The original @@all class variable will automatically return at the end of this method's execution.

Creamery.all_creamery_flavors

"Ben and Jerry's Chunky Monkey"
"Ben and Jerry's Oat of this Swirled"
"Ben and Jerry's Chubby Hubby"
"Hershey's Chocolate"
"Hershey's Vanilla"
"Hershey's Strawberry"
"Nelson's Graham Slam"

#=> [#<Creamery:0x00005558bceb7e08 @creamery_name="Ben and Jerry's", @ice_cream_flavor="Oat of this Swirled", @creamery_flavors=["Chunky Monkey", "Chubby Hubby", "Oat of this Swirled"]>,
     #<Creamery:0x00005558bceb7d68 @creamery_name="Hershey's", @ice_cream_flavor="Strawberry", @creamery_flavors=["Chocolate", "Vanilla", "Strawberry"]>,
     #<Creamery:0x00005558bceb7cc8 @creamery_name="Nelson's", @ice_cream_flavor="Graham Slam", @creamery_flavors=["Graham Slam"]>]

You just learned self! If you feel you have a good grasp of the concept of self, celebrate with a scoop of your favorite ice cream! If not, check out the following helpful resources:

Ruby self
Self in Ruby: A Comprehensive Overview
Understanding self in Ruby

...And then have a scoop of ice cream. :D

Refactor Bonus Section

Over a year after I originally wrote this blog post, I had occasion to come back and review my old posts. My God this one was not pretty! I tried to clean it up a bit and use better examples/explain them better. If you have any comments to add or see something that's glaringly wrong, please DM me on Twitter at @meg_gutshall or email me at meghan.gutshall@gmail.com.

In my second round of research, I found a remarkably interesting and high-level post on self in Ruby and wanted to share it as bonus content. Warning: This is confusing shit and I am still far away from feeling completely comfortable with it. If you're a beginner, I highly recommend you stick to the three links above and bookmark this one to revisit at a later date: Metaprogramming in Ruby: It's All About the Self.

Also, I rewrote both of my code examples used above for this refactored blog post and wanted to show a method for the second example that could be of general use—it's just not necessarily related to self.

class Creamery

  ...

  def all_flavors
    @creamery_flavors.each {|flavor| puts flavor}
  end

  def self.all_creamery_flavors
    @@all.each {|creamery| creamery.all_flavors}
  end
end

You may have noticed that we had to iterate twice in the blog post's self.all_creamery_flavors method. Here I created an #all_flavors instance method that iterates over the @creamery_flavors array, puts-ing each flavor just like the blog post example. The only difference is, this method is scoped to an individual creamery. Then, I refactored the self.all_creamery_flavors class method to call on the new #all_flavors instance method once it goes through its first iteration in accessing individual creamery instances.

HTML & CSS: The ‘90s Kids of Programming

Meg Gutshall — Thu, 20 Sep 2018 16:34:05 +0000

For brevity’s sake, I am going to use acronyms throughout this post. Full phrases and relevant information will be covered at the end of this post.

After almost two months in the online software engineering program, I finally feel like I’m getting into the thick of the curriculum at Flatiron. I’ve finished Intro to Ruby Development, learned about Git and GitHub, sped through Procedural Ruby, and am now working on the Object Oriented Ruby section. One section I especially enjoyed though was HTML and CSS Introduction.

HTML: The Language of the Web

HTML is the language of the web, however, it is not a programming language, but rather a markup language. HTML documents are comprised of content (text written in plain English) and markup (HTML tags meant to structure the content). These documents are used by web servers and web browsers to display the non-markup version of the document—a web page—in a process called rendering.

Here’s a basic overview of the rendering process: HTML documents are stored at unique locations (IP addresses) on web servers and made available to web browsers via the Internet. A user will type a URL into a web browser’s search bar and the web browser feeds the URL into the DNS, which then translates the URL address to its corresponding IP address. The web browser then uses HTTP to communicate with the server at the returned IP address and requests the sought-after information—the HTML files used to render the web page. Once the web browser receives these files, it translates the HTML code and displays the web page on our screen.

The Semantics of HTML

As a linguistics nerd (in case you missed it, there's a great example of my Spanish linguistics nerdiness coming out in my last post, "The Little Things Matter"), I love HTML due to its semantic capabilities, so bear with me as I geek out for a minute…

An HTML document consists of two sections: a head and a body. The head is not displayed as part of the web page when the browser renders the HTML document. Instead it contains data (such as page title, a favicon, links to the document’s CSS and JavaScript, and metadata) which relays additional information not contained in the body section to the web browser. A web page’s title and favicon appear in the window tab of the web browser. The CSS link provides styling rules for the HTML document and the JavaScript link enables additional, more complex features. Metadata defines the document’s language, character encoding, author, and description. Adding an accurate description that includes applicable keywords is especially important as it affects the site’s SEO and will determine the frequency with which the web page appears in Internet search results.

The meat of the document, the body, is composed of HTML elements. An HTML element contains an opening tag, a section of content, and a closing tag*. The type of tag used in the element determines the meaning and structure (semantics!) of the enclosed content. Common HTML tags denote links, line breaks, headings, images, lists, paragraphs, and tables. Web browsers read the HTML tags and apply their meaning to the enclosed content when rendering a web page. HTML elements can also accept attributes to transfer more detailed information regarding the enclosed content. It is important to assign HTML tags accurately, not only to structure the web page correctly, but also to enable website accessibility for those who use screen readers and other tools to navigate the web.

CSS: The Beauty to HTML’s Beast

CSS styles web pages by assigning a CSS selector to an HTML element and a declaration to the selector. The most commonly used CSS selectors point toward an HTML element, class, or id, but can also call on an element’s attribute or its relationship with the surrounding elements. CSS declarations are made up of properties and their corresponding property values. Multiple CSS declarations can apply to one or more CSS selectors–called a declaration block–and multiple CSS selectors can apply to one or more HTML elements, giving CSS a totally customizable execution.

A general convention among programmers is to completely separate the tasks of writing content (HTML) and styling content (CSS). Although CSS was designed specifically to work with HTML, in most cases a site’s CSS is located in an entirely separate document than the HTML. Instead, the HTML document stores a link to its corresponding CSS document in the head section which the web browser calls on to style the web page at the time of rendering.

Why HTML and CSS Are Important for Programmers

The combination of these two languages make up a huge part of front-end web development. As a software engineer, you’ll need to be able to read and write HTML to code and debug your programs... and you’ll want to be familiar with CSS to make your programs pretty! While on Flatiron’s learning platform, the message that stood out to be the most in the HTML and CSS Introduction section was: All pathways to web programming success rely on strength in HTML. And as I see it, the first step on that pathway is your portfolio website. This cannot be created without HTML and will most likely look awful without CSS. Your website is your prospective employers’ first impression of you as a programmer—so make it a good one!

There is so much information available on HTML and CSS as they are fundamental programming tools and, simply, because they have been around for a very long time. I could write a dozen more blog posts on the topic but, for now, will leave you with a short index of the aforementioned acronyms as well as some of my favorite resources regarding HTML and CSS.

Index

CSS → Cascading Style Sheets
DNS → Domain Name Server
HTML → Hypertext Markup Language
HTTP → Hypertext Transfer Protocol
SEO → Search Engine Optimization
URL → Uniform Resource Locator

Resources

Mozilla Development Network
Learn to Code HTML & CSS
CSS Tricks
W3Schools

*Not all HTML elements require a closing tag (such as img, input, br, hr, meta, and a few others), but that's a topic for another blog post. When in doubt, use a closing tag.

The Little Things Matter

Meg Gutshall — Thu, 20 Sep 2018 16:30:13 +0000

I’m officially one month into the online software engineering program at the Flatiron School! It’s tough (really tough)... but I’m still here! I just finished the ‘Intro to Ruby Development’ section and learned step-by-step how to program a game of Tic Tac Toe in the Ruby language. So far I’ve noticed that once I get through the snags I encounter in the labs, I get a fairly comprehensive understanding of the material. When I’m unravelling those knots though, I find myself repeating over and over in my head, ‘Don’t be so damn hard on yourself!’

You see, this is brand new to me. I never touched Ruby until I started at Flatiron. I’ve found that it’s an incredibly user-friendly language, but inevitably (and more frequently than I’d like), I still manage to get lost. It’s really frustrating, and I have to constantly remind myself that it’s okay to get a little off-track. Confusion is part of learning something new, and as a beginner, it’s important to have patience while getting over that learning curve.

Patience is key—and I’ll explain more later—but first I need to give you a little more background about myself. Let’s get in our time machine and go back ten years…

I had just entered Temple University as a freshman with an undeclared major. Although both of my parents were drawn toward STEM-related fields, I decided to forge my own path through the college of Liberal Arts. Since a language was required, I added Spanish to my schedule and ultimately came to love it, declaring Spanish as my major in my third semester. After four years of study and multiple visits to Spanish-speaking countries, I can now say that I’m a fluent speaker.

So what does this have to do with Ruby and the Flatiron program?

As I go through the lessons, I’m drawing a lot of parallels between learning Ruby and learning Spanish. One that keeps jumping out at me is: the little things matter.

If you’re a programmer, I’m sure you’ve been through this at least once before: You’re writing a program and trying to get it to pass your tests but you keep receiving an error message. You try everything you can think of to fix it and the next thing you, know three hours have gone by and you’re still stuck on that one damn test!! Yeah, that was me last Saturday afternoon and I was getting desperate.

Luckily, Flatiron’s platform Learn.co lets you chat live with a technical coach when you get stuck on something—which I probably should have utilized about 30-40 minutes into my struggle instead of driving myself completely insane. I was connected with technical coach James (shout out to James!) and we got to work. He seemed a bit confused because everything looked okay to him, so we tried a few small tweaks at a time to see if we could get the code to pass. In the end, we discovered that I was returning false at the wrong part of the program. If you return false inside an iteration, the method only accepts the first object in your array and ends before iterating through the rest of the objects. In other words, not good.

Ugh!! After all of that confusion, hard work, and frustration, the end result was switching just two lines to get the program to pass the test. Two lines! That’s it! I laughed at myself, thanked James profusely, and was able to code out the rest of the program on my own to complete the Tic Tac Toe Game Status lab. Again (over a well-deserved beer), I thought to myself: ‘Have patience. You’ll get this down soon.’

This experience reminded me of a common beginner’s mistake with the Spanish language. There are many Spanish-English cognates—which are words that sound very similar because they have the same root origin in Latin (i.e. apartment and apartamento)—and because of this, many beginners will accidentally use the wrong word or make up a new word entirely. For instance, a lot of students mistakenly say “estoy embarazada”, which means “I’m pregnant”, instead of “estoy avergonzada”, which means “I’m embarrassed”. That’s a fun one to explain to a new Spanish speaker. :)

Even changing one letter in one word of a sentence can completely change the meaning of the statement. In a class at Temple, a friend of mine meant to say “No como desayuno si no tengo hambre.” but instead it came out as “No como desayuno si no tengo hombre.” One means “I don’t eat breakfast unless I’m hungry.” the other, “I don’t eat breakfast unless I have a man.” Hmm… we got a good laugh out of that one.

Needless to say, in a learning environment, these little mistakes in Spanish can be a lot funnier than mistakes in Ruby, which tend to be frustrating as all hell. But like I said before, it’s important to have patience with yourself, because if you’re not careful, little mistakes can snowball into bad situations. I’ve gotten lost in both Cuba and Mexico (twice) because of mispronunciation or confusing common words. Those were both frustrating and costly lessons to learn.

Once I reach the more complex labs, I imagine it will be pretty similar, but only on a larger scale so messing up one little bit of code will have greater consequences. Therefore, I’m taking a lesson I learned early on while studying Spanish and applying it here to programming: Be patient. If you pay attention to the little things, you keep them from becoming big problems.

My $witch to $oftware Development

Meg Gutshall — Thu, 20 Sep 2018 13:47:38 +0000

In late 2017 I was working as technical coordinator and marketing lead for a small IT consulting firm outside of Philadelphia, my first ever position in the tech industry. Since I knew absolutely nothing about the industry, I decided to do my own research and immerse myself in the latest news and best practices. I read books and articles on different technologies and programming languages, I attended numerous networking events in the city, and I even enrolled in a computer science class through my local community college. I was never afraid to ask questions and suggest implementing new concepts at the firm, but my boss never seemed to recognize my efforts and in fact discouraged my actions, citing that it wasn’t part of my job description. After over a year and a half of dedication to the company, I began to realize that ideas we had discussed at the interview were never going to come to fruition and, frankly, I was feeling extremely underappreciated in my role. It seemed to me that the position I had so much wanted to become a career was not working out.

As part of my job, I was in charge of onboarding new consultants and running payroll which meant I had intimate knowledge of everyone’s salary details and how many years of work experience it took for them to get there. This insight, combined with networking events in which I met many women who had transitioned into the tech industry, sparked an idea in my brain and got me thinking, ‘Why can’t I do this too?’

Okay, so the title of my blog post may be a little misleading. The wages, benefits, and job perks that I encountered with the consultants at the recruiting firm definitely caught my eye, but after the first time I manipulated HTML code and saw tangible changes reflect on a website… you could say I fell in love.

My journey to my present-day status started in 2012 with a simple project at my first job—a field hockey training facility. After scoring an interview for an administrative position, Googling ‘What is field hockey?’, and sitting through the strangest 2.5-hour interview I’ve experienced to date, I was offered to start the following Monday. One of my tasks was to add content to their website which was developed through WordPress. I began to teach myself how to navigate the platform using the enormous amount of free educational information available online and soon went from updating rosters and posting pictures to creating tournament galleries, adding streamlined registration features (with online payment capabilities), and cracking open files to tweak the HTML and CSS codes. I even created a subdomain to highlight the club’s tour in New Zealand which included blog posts and collaborative galleries.

After two and a half years at my first job, I decided to resign in the summer of 2015 and take some time to travel. Upon arriving home, I followed some LinkedIn connections to my next job at the IT consulting firm. (Networking—it really works!) Even though I had an overwhelming amount of duties (when you work as admin for a small company, you wear many, many hats), I was still able to get my hands on the company website's code. I mainly updated blog posts and tweaked features here and there, but I also had the opportunity to run site testing when my manager decided to hire a professional to completely redo our site. It was my job to try to break things before the site went live and I got pretty good at it!

At the end of 2017 I had to take short term disability leave and my employer couldn’t hold my position open for me so I was let go. I was struggling to pay the bills and on top of that, questioning everything about my life and what had led me to my current situation. After some intensive self-reflection and a few meetings with a career coach, I found myself on the path to starting a career in software engineering.

Through attending networking events and tech talks, I learned the myriad ways in which software engineering can be used to help society as well as improve the lives of others. Philly is a city of passion—which extends to their tech industry and startup culture as well. Whether it be fixing a simple dilemma or creating a solution for a systemic problem, the people in my city are willing to share their thoughts, then collaborate and act on them. I myself have a passion for solving problems and helping others and I think this could be the perfect outlet for me to do so. Plus, there will never be a risk of stagnation in the field since technology is ever increasingly becoming a part of our day-to-day lives.

The tech industry seems to crave innovation and curiosity so this trait that had previously gotten me reprimanded could do the exact opposite in the proper environment. Already, a mentor of mine reached out to me for help at her social media marketing firm, which includes updating her website. Now, I find that when I have nonconventional suggestions or go the extra mile in a project, I’m either met with praise or directional feedback which constructively encourages me down an alternate path. I don’t feel boxed-in or micromanaged anymore. Plus when I told her that I was going back to school for software engineering, she was ecstatic for me!

Thankfully, I have already learned the tools I need to get a foothold in the tech industry (you pick up a LOT working at a recruiting firm), now I just need the developmental knowledge and, with Flatiron School’s online software engineering program, I will attain that expertise.

DEV Community: Meg Gutshall

Everyday Inspiration

The Original Idea

Models

Enum Attributes

Associations

The Look and Feel

User Flow

Login

Navigating the App

Creating a New Request

Logout

In the End

Slipsum L. Jackson

Slipsum L. Jackson (Redacted)

Now take it away Mr. Jackson...

Creating Rxeactions

Project Idea

Starting the Project

Delay

Design

The Setup

The Build

Corneal

The Build - Models

Migrations

Models

Active Record Validations

Seed Data

The Build - Controllers

Application Controller

Sessions Controller

Users Controller

Medications Controller

Reactions Controller

The Build - Views

Home Page

About Page

User Views

User Dashboard

Medication Views

Medication Detail Page

Medications List

Reaction Views

Reaction Detail Page

Styling

Troubleshooting

Expansion Ideas

Forms & Views

Additional Models

Medication Information

Overall Reactions

Project Demo Video

Creating BeerSnob

Project Idea

Starting the Project

Setup - Creating a Gem with Bundler

Setup - Connecting Your Project to GitHub

Setup - The Executable File

Program Files

BeerSnob Executable File

CLI File

Scraper

Beers File

Art File

Troubleshooting

Scraping

Simplifying the Program

Project Demo Video

Knowing When to Quit

What's Up With That!?: SINATRA_ENV

Rakefile

Environment.rb

Config.ru

Bringing It All Together

Shotgun

Conclusion

Git commit aborts before I can create a commit message and I use “--wait”

Get to Know Your Self (Refactored)

self Referring to an Instance of a Class

`self` Referring to an Instance of a Class

`self` Referring to a Class