Forem: Dane Dawson

My experiences at coding bootcamp

Dane Dawson — Thu, 24 Sep 2020 16:45:23 +0000

On January 27, 2020 I started attending FlatIron, a 15 week software engineering program. It was a wild, exhausting, and crazy experience and, on May 8th, 2020, I graduated! I thought I would take a moment to talk a bit about what my experience was like for those interested in maybe attending a boot camp in the future, and at the end I wanted to give some base tips to those wanting to learn to code (formally taught or not).

Bootcamp? What's that?

The school I attended was a 15 week software engineering school with a "full-stack" focus, meaning they taught Ruby and Ruby on Rails for back end server management and JavaScript and React for front end client interfacing. It was broken into the following 5 "Mods" (the taglines are my own)

-Ruby - Introduction to Ruby, object oriented programming and you!
-Ruby on Rails - More Ruby, and learning how to talk to your server through a framework. Make a website like it's the 90s!
-JavaScript - JavaScript, love it or hate it! P.S. You will start by hating it.
-React - Framework using JavaScript to build out and structure web design more modern and customizable.
-Final Project - "3 weeks" to do anything you want with the knowledge you have learned so far. Really 2 with project pitching and presentation prep.

with each of the first 4 mods following the same loose schedule:

-Weeks 1/2 : Introduction, education and practice of coding skills/techniques
-Mid/End Week 2: Coding challenge to test your knowledge of the material
-Week 3: Paired Project week
-Friday week 3: Project Showcase

A day in the life

I did my bootcamp in person (until the quarantine hit) because I know myself to learn best in a community, and one of the more nerve-wracking things about starting bootcamp is not knowing what to expect in the standard day to day schooling. Here is an idea of what a day would be like:

9:00AM : School "starts"
9:15AM : Morning Roll Call
9:30AM : Morning standup - 
    Morning standup is a routine where, before getting started on the day, 
    students stand and talk to their table about what they accomplished the day before, 
    what they plan to accomplish today, what mental or physical blockers may prevent 
    that accomplishment, and how they plan to address those blockers. It's a nice 
    thought exercise to get the day started!
10/11AM: (mandatory) Morning lecture -
     Usually an hour long, it covered the topics we were learning for 
     the day and/pr reviewed the previous days topics.
3:30PM : (optional) Mid-day Madness - 
    Unfortunately with the quarantine these happened less, but they were fun mini-lectures 
    where instructors would have problems for us to work, introduce fun (but un-neccesary) 
    aspects of coding, answers questions or do coding exercises. These were a lot of fun.
5:30PM : End of Day - 
    Students gather and talk about their day, usually highlighting one key thing they 
    learned/were proud of, and any issues they overcame.
6:00PM : Class is done!

You'll notice a lot of the day is empty or unscheduled. While it's true there were intermittent meetings or guest lectures (Career guidance, resume building, in field experience, etc) a vast majority of the day was "free time" that we worked on a series of labs and readmes. At our school it was common to have a few lessons that were informative and basic background, one or two interactive labs that walked you through a concept, and then series of labs to expand your knowledge by giving you more complex tasks and challenges. At Flatiron they have a series of tests that you run your code against regularly that helps guide you in your quest for knowledge, but a vast majority of your learning comes from trial and error and constant internet searches. As a software engineer you can expect at least 50% of your time spent reading documentation or searching forums for ways to address issues, so be prepared to hone your Google-Fu.

Code Challenge

Every Mod had a code challenge, designed to test our knowledge and application of the broad foundational subject material we learned over the preview two weeks (or so). They were timed, usually about and hour and a half, and the entire class did them together in one of the larger conference rooms. Looking back now, they are fairly basic applications of coding for each concept, but I was thankful for Flatiron's policy on allowing 1 retake of each code challenge as I failed all but the one initially. This brings me to one of my biggest takeaways from my experience...

You will probably not remember most of what you learned in bootcamp.

It is extremely easy to get overwhelmed by the extreme amount of knowledge you are presented at a bootcamp, and it is practically impossible to retain all of it...even if you could, technology changes so quickly that you will have to learn something else new in a few more years at most! My recommendations for focusing on learning any coding are the follows:

Learn how you learn

Everyone is geared towards absorbing information differently. I almost have to make or do something with my hands for it to retain mentally, so pure reading or lectures are actually pretty ineffective of a learning tool for me, but my wife is the exact opposite. On top of that, every type of information will probably need it's own nuance and uniqueness to make it fit you best. Figure out what helps make learning programming most effective for you and stick with it! I have gotten used to using draw.io for planning project outlines, and Mind Node for brainstorming, and I do a lot of code along videos when learning new methods.

Focus on the base concepts of coding

If you stick with programming long enough, you will pretty much have to learn more than one language eventually. Every coding language has it's pros and cons, and I am neither educated enough nor brave enough to debate with any software engineer what the "best" language is...but almost every language has a lot of common base elements. As you learn more languages you will actually pick up on the ways that most languages are different more than trying to figure out what they have in common, so don't feel bad about having to look up syntax or rules or what certain functions do. Those will come more familiar with time!

Advice to those learning to code

Regardless of how you learn, but especially if it's self taught or self guided, you will have a whole gaggle of resources you find online. Start early on getting a decent system of bookmarks to help organize the various sites you see and want to go back to. I have a Ruby folder, a Github folder, and Authentications folder...just anything that makes sense to you so that you can file away resources to find easier next time.

You also need to learn to fail gracefully. Nobody programs perfect code 100% of the time, and the joy (and challenge) of coding is the puzzle that needs to be solved to get it to work. Sometimes it's your own error you can fix, and sometimes it's something in a system or a file you are dependant on for your program to work. An error doesn't mean it's broken or that you are dumb/wrong/can't do this. An error is just the next stop on the path to functional code. Get used to errors. Love them, despise them, dread them...they will be with you forever once you get in tech.

Lastly, find a community! There are huge collections of people who are learning these skills, and a wealth of supportive individuals who will happily help you out. That being said, like every industry there are plenty of "gatekeepers" who will try to shame you or judge you on your lack of knowledge...just remember to keep your own positivity up and that being a good team member and empathetic/passionate person is just as desirable for employment as a skillset like coding, and it's a lot easier to learn to code!

Good luck y'all, and happy coding!

Ruby Newby, Testing with rspec part I

Dane Dawson — Thu, 17 Sep 2020 21:39:24 +0000

Welcome back! Today I am going to talk about testing, and why it's so important.

(As a note, this article is meant for absolute beginners with writing and performing test cases, future articles will go more in depth)

Types of testing

There are as many applications of testing as there are types of programmers, and as you delve deeper into the world of programming you will find that every person and organization has their own structure and approach to how they design and implement tests. For now let's focus on the two main approaches to writing code on a foundational level.

BDD

Behavior Driven Development -> Most likely as you begin your coding experience this is what you are used to. The programmer imagines a behavior they want to code to mimic/create, and attempts to write code that creates the results they want. For example, if I wanted a program that told me a personalized greeting when given a name I would start by trying to code something like this:

    def hello(name)
        return "Hello #{name}!"
    end

...And if it didn't work I would tweak/troubleshoot/debug until I got the response I wanted. The idea is your code is driven by the behavior you want it to perform directly.

TDD

Test Driven Development -> Write a test for the results you want to accomplish and then attempt to write the least amount of code to pass the test. Further refine your code by adding more tests to allow your code to be more precise. The following pseudocode is not syntax accurate, but gives more legible examples of a sequence of tests that one might develop to get to the same function we have as above:

    describe 'hello(name)' do
        #first test is to make sure the function returns a greeting
        it "Method hello(name) includes the word Hello" do
            expect(hello(name)).to include("Hello")
        end
        #second test ensures the greeting is personalized
        it "Method hello(name) includes the given name" do
            expect(hello("Joe")).to include("Joe")
        end
        #third test is for the precise return desired with given name
        it "Method hello(name) says "Hello (given name)!"" do
            expect(hello("Joe")).to eq("Hello Joe!")
        end
    end

In true TDD one would write the first test, then write code to suit that test, then expound further with each additional test.

The benifits of testing to systems are multifaceted, but the most common reason you will utilize tests is for debugging. All code requires maintenence and upkeep, and especially as you gain more experience and contribute to more projects it will be literally impossible to remember the nuance or specificity about why you have code written the way you do...not to mention, each individual project may grow/evolve in a way that it's easy to forget the minutiae that interconnects all your methods and functions.
Adding tests to your project gives you means to verify existing code you modify or new code you add to your project doesn't alter the existing code base in a way that you aren't expecting. Although best code practices help minimize the likelihood of this kind code interference it's impossible to remember the way every single line of your code interacts with every other line of code throughout your whole project. Built in tests give you a way to add a series of checks that can be run as frequently as you want to make sure that your project is growing in the direction you want.

Implementing

I could (and maybe will eventually) write a whole article about the history of tests and the ways they are used by organizations of various sizes, but for now I just want to focus on the very basics of test writing.

I will be using rspec for my examples, and will currently be operating under the assumption you already know how to install and set up rspec within your code. If not, here is an example blog post about setting up your rspect environment.

The basic outline for creating a test in rspec is as follows:

RSpec.describe ClassObject do
    describe '#new' do
        it "Generates a new ClassObject with name Hello World" do
            newObject = ClassObject.create(:name => "Hello World")

            expect(newObject.name).to eq("Hello World")
        end
    end
end

The test is wrapped in RSpec.describe (name of the model/object you are testing) do->end. Within the test you can create describe blocks, which will create an ExampleGroup. This is basically a class in which "it" blocks are passed and evaluated, each block existing within a unique instance of that tested class. Every "it" method within the describe block becomes a test case in which you give the parameters of your test and your expected results. This article is solely to introduce the base form of testing, but feel free to look here at one of the more comprehensive syntax/vocabulary guides I have found regarding rspec's many applications.

I have created a very simple series of tests to show initial implementation and foundation for rspec testing. If you were to create these files in a ruby repository with the rspec gem installed they can be run and shown to pass.

First is the class, which I have classed Thingdoer

#thingdoer.rb
class Thingdoer

    #The first test is set to see if the method equals "Hello". 
    #Simple test just to show framework and how to use expect().to
    def return_hello
        return "Hello"
    end

    #This second function has the same test written and also passes. 
    #This works because Ruby implicitly returns 
    def hello
        "Hello"
    end

    #This test would fail with the the previous testing parameter, 
    #because although it puts "Hello", the method itself does 
    #not return "Hello". The test has been changed to pass by 
    #altering the expect().to into expect().not_to
    def hello_fail
        puts "Hello"
    end

    #One more example to show that the last string in the 
    #function is the one returned, the test for this function 
    #checks for "Goodbye".
    def return_goodbye
        "Hello"
        "and"
        "Goodbye"
    end

    #This test shows a way to use include testing. 
    #Use include to specify that a collection includes 
    #one or more expected objects. Note that even though 
    #there are two entries, include only tests if *any* 
    #object passes the condition
    def say_hello
        message = ["Hello", "and", "Goodbye"]
    end

end

And as is required by rspec, the tests are saved within the spec folder and following naming requirements.

#spec/thingdoer_spec.rb
require 'thingdoer'

RSpec.describe Thingdoer do
    describe '#hello' do
        it 'Method hello should equal Hello' do
            expect(Thingdoer.new.hello).to eq("Hello")
        end
    end


    describe '#return_hello' do
        it "Method return_hello returns value of 'Hello'" do
            expect(Thingdoer.new.return_hello).to eq("Hello")
        end
    end

    describe '#return_goodbye' do
        it 'Method return_goodbye should equal GoodBye' do
            expect(Thingdoer.new.return_goodbye).not_to eq("Hello")
            expect(Thingdoer.new.return_goodbye).not_to eq("and")
            expect(Thingdoer.new.return_goodbye).to eq("Goodbye")

        end
    end

    describe '#hello_fail' do
        it 'Method hello_fail should *not* equal Hello' do
            expect(Thingdoer.new.hello_fail).not_to eq("Hello")
        end
    end

    describe '#say_hello' do
        it 'Method say_hello should include Hello' do
            expect(Thingdoer.new.say_hello).to include("Hello")
            expect(Thingdoer.new.say_hello).not_to include("Welcome")
        end
    end

end

Hopefully this will make it a little easier for someone else trying to get started writing tests, I know my first test was an incredibly overwhelming undertaking. I am in the process of creating a simple rails app with testing at all the various levels for upcoming blog posts, so hopefully I will see you back here again soon!

Happy coding!

Staying focused coding from home part 1!

Dane Dawson — Fri, 11 Sep 2020 02:21:02 +0000

I just graduated from Flatiron as a software engineer, and even though I just spent over 3 months diligently studying and working on projects and lessons and learning so much, one of the things I have found extremely difficult is staying productive and focused now that I don't have that framework. I know I am intelligent and clever, and my logical brain realizes how important it is to stay on top of things and continue to work on developing my skills and networking, but let's be honest...The world is in a weird place right now and even in the best of times it's easy to lean back and let the current take you where it wants to. I decided to share some of the tricks and tips I am using to keep myself motivated, accountable, and driven. If you find them useful, great! If you have extra tips or advice, also great! I will try to keep this updated as I see how I react to things and what resonates with me or not and why.

Habit tracking

There are plenty of sites that can teach all kinds of pros and cons to checklists, but personally I find them a great way to organize my train of thought and begin to break things down into actionable tasks rather than nebulous anxiety sources. You can find all kinds of methods and styles you can use, I'll walk through my starting point when I approach any new project whether it's coding or cleaning the closet:

-Figure out the scope of this "task". I know this seems arbitraty, but for any project it's easy to get distracted or overly enthusiastic at some point and end up re-organizing your bookshelf when you started sweeping your floors. Whether it's deciding that your starting MVP for the project will have only 4 models and bare-bones interfacing or specifying you will be focusing on yardwork in the front yard specifically, giving yourself an end goal (even if there are more steps in the future!) will make it easier to "finish" and feel accomplished.
-Break the task in to as few "large" sub-tasks as you can. For our yardwork metaphor, it could be knowing you have to (Mow, Weed-whack/edge the sidewalk, tend the planting beds, Pick up the disaster area your kids left, Sweep/wash the sidewalk and driveway) or for our coding metaphor it could be (Set up backend models, create routes/database interaction, set up frontend, create simple user interface).
-This is where you can pick what works best for you. Personally, I like to take each large task and break it down into almost as small of an "actionable task" as you can. This lets you take time to actually plan and organize your project and method of approach and, when done correctly, can vastly minimize the amount of double-work or corrections you might have to make. I tend to go into the overkill on this personall, where I will take a large task and break it into smaller tasks, and then break of those tasks into smaller tasks still, until I get things that I can accomplish in 30 minutes to an hour. This makes it easier for the next step:
-Check things off!! You did it! I know it's easy to feel like a small task is meaningless, but it's even easier to not do that task at all. Allow yourself to feel proud and get a nice dopamine release, you earned it! This is the part that helps me the most...It's common tendency to think that it's not worth celebrating an achievement until the "big picture" is finished, but if you do this you are vastly under appreciating your worth. The largest, greatest, and most impactful things in history were build one piece at a time, allow yourself to appreciate every step of the journey for what it is: the results of your hard work and dedication.

//This area talk about benefits of habit tracking maybe?

Accountability (Accountabili-buddies!)

Me and a few friends have started using Habitca as a way to track our tasks. This combines all the wonderful things I have mentioned above with task-lists and habit tracking, but one of my greatest constant motivators is mutual accountability. Find a group of people you trust and respect (even if it's just one person!) and talk to each other about what you are doing. Share your task lists (full details or just highlights), talk about what's going on and what your gameplan is. An idea in our head can be ethereal and lofty, but having someone you can be open and honest with about your progress (or lack there-of) can help you both stay on task and grow. Some tips for people making/forming Accountabili-buddy groups:

-The only criticism is constructive criticism. You are here to support and improve not only yourself but everyone in your group, negativity will only create more negativity.
-Be open and upfront with what you want from the group. If you want someone to message you every day and make sure you are on task, let it be known...but on the flip side, if you want to keep to yourself and have the group there for questions or specific feedback, that is fine too! Take the time early on to set boundaries and expectations, I know it feels clinical and abnormal but it will save you a lot of misunderstanding later on!
-Respect each other. This kind of group activity is opening yourself up to a level of vulnerability that can be easy to underestimate. Allow yourself to be patient and kind in every interaction, the best accountabili-buddy is stern but supportive.

Habitca has (thusfar) been a great resource, it allows us to have private lists of things we are tracking or (in the paid version) group tasks that we can all do/track together.

Compartmenting spaces

Set up a work area! It's that easy! The harder part is making sure it's the only place you work. There are plenty of sites to tell you ways to organize your home work space, tips and tricks about ways to design your space. I could (and may eventually) write a whole post just about setting up an ergonomic and functional workspace, but the key thing I want to focus on is true regardless of what your setup at home is.

-Designate a "work only" space. Your brain is surprisingly good at catching onto habits, both good or bad. If we use the same table/counter/desk to do all of our work at, we train our mind that this location is for working, and will be much easier to stay focused and guided in that direction.
-Honor the "work only" space. Avoid doing anything that isn't work related at your work area. As soon as your start to spend time browsing Reddit or perusing Amazon at your work station your brain is going to get distracted. Is this a place where we focus on work, or a place for recreation?

Its important not to bite off more than you can chew! Trying to change too much at once will only make you feel overwhelmed, focus on one habit/task at a time.

Happy Coding!

Ruby Newby, introduction to Rails associations and their potential

Dane Dawson — Wed, 06 May 2020 12:47:01 +0000

One of the more useful tools that comes with Ruby on Rails is associations. This allows you to set up relationships between models to use built in functions to stream line your code for commonly used interactions. I will be heavily referring to the documentation included with Ruby on Rails, which I would recommend reading through when you have the time. For now I will highlight the most basic relationships that one is likely to use.

Associations make it easier to get models to have a connection that can be instantly referenced, allowing a coder to make a reference to a single model and, with that reference, also get information on all it's associated models.

Here are the relationships that come default with Rails and the ones you will interact with most:

belongs_to
has_one
has_many
has_many :through
has_one :through
has_and_belongs_to_many

To talk about what the differences between each relationship is I'll use a music app metaphor that is pretty common.

Let's start with the has_many and belongs_to: Any song written by that songwriter belongs to them, and couldn't exist if they weren't there to write it, so in the song model we would write:

class Song < ApplicationRecord
belongs_to :singer
end

And, because out singer owns the songs, we will change their model accordingly:

class Singer < ApplicationRecord
has_many :songs
end

This will allow you to, in the console, type out

Singer.first.songs

And it will give you the models of each song associated with the first singer in the database!
The current setup makes the song model dependant and makes it to where a song can't be saved to the database unless you assign it to a singer. This can be useful in database management and also a source of debugging stress if you forget!

Note, because the singer will write more than one song it is a has_many and thus songs needs to be plural.
A good example of a has_one could be the singer's alias. Marshall Bruce Mathers III has_one professional alias, and it's Eminem. The use of has_one is benificial because it's not dependant. Let's add the steps for our alias class and singer class updates:

class Singer < ApplicationRecord
has_many :songs
has_one :alias
end
//
class Alias < ApplicationRecord
belongs_to :singer
end

Notice that the has_one is singular! Now let's talk about through associations...Everyone knows that a well rounded artist doesn't shoehorn themselves into only one genre and style of music, wouldn't it be nice if we could find out what kind of genres a musician has performed with one simple keystroke? Let's set that up!

First, we need to show that songs can have genres. For simplicity sake we are going to say that every song has only one genre, so let's set up that relationship first:

class Song < ApplicationRecord
belongs_to :singer
has_one :genre
end
//
class Genre < ApplicationRecord
belongs_to :song
end

Here's the fun part! We already know the song is associated with the singer, and the genre is associated to the song, all we have to is pass that connection along the chain! Our final set of model associations would look as follows:

class Singer < ApplicationRecord
has_many :songs
has_many :genres, through: :songs
has_one :alias
end
//
class Song < ApplicationRecord
belongs_to :singer
has_one :genre
end
//
class Genre < ApplicationRecord
belongs_to :song
//
class Alias < ApplicationRecord
belongs_to :singer
end

This will allow you to do things like the following which can make backend database management a lot easier and smoother.

 Singer.first.genres
 Singer.first.alias
 Song.first.singer
 Song.first.genre
 Alias.first.singer

Until next time, happy coding!

Checklist for HTTP Rails/React user auth setup - Rails backend setup checklist.

Dane Dawson — Wed, 06 May 2020 12:19:15 +0000

This article is written as a destilling of this video series by Edutechional. If this is your first time creating a user authentication with Rails and React I would highly recommend watching the 10 video series to understand what is going on. I also recommend any of other videos he offers, his way of explaining is straightforward and easy to understand. If, however, this isn't your first time setting up a back end cookie based user auth and you just want a nitty gritty checklist of an auth framework, you've come to the right place! I tried to grab every bit of code needed to get it working with minimal descriptions to streamline flow. Good luck.

-Create new app in Rails with a pstgresql database and create the database

rails new app_name --database=postgresql
rails db:create

-Get latest version of bcrypt in your gemfile as well as rack-cors. At the time of writing this article:

Gemfile

gem 'bcrypt', '~> 3.1', '>= 3.1.13'
gem 'rack-cors', :require => 'rack/cors'

-update gems with console command of preference, I use

bundle

create file app/config/intilizers/cors.rb

Rails.application.config.middleware.insert_before 0, Rack::Cors do
    #first origin is your API host address
    allow do
        origins "http://localhost:3000"
        resource "*", headers: :any, methods: [:get, :post, :put, :patch, :delete, :options, :head], credentials: true
    end
    #second origin is front end host address
    allow do
        origins "http://app_name.herokuapp.com"
        resource "*", headers: :any, methods: [:get, :post, :put, :patch, :delete, :options, :head], credentials: true
    end
end

create file app/config/intilizers/session_store.rb

#key is how you want it to be identified in cookies, domain is same as above in cors file
Rails.application.config.session_store :cookie_store, key: "_appname", domain: "app_name.herokuapp.com"

app/config/routes.rb

root to: "static#home"

create file app/controllers/static_controller.rb

class StaticController < ApplicationController
    def home
        render json: { status: "It's working"}
    end
end

************

Check point

************

You should be able to visit your backend host (My example is http://localhost:3000) and have it show the json string

{"status": "It's working"}

-Create your user model, it must have a password_digest attribute. I am also adding email for validation. Then migrate models.

rails g model User email password_digest
rails db:migrate

app/models/user.rb

class User < ApplicationRecord
    has_secure_password
    #sets email as required attribute for model creation
    validates_presence_of :email
    #validates unique emails
    validates_uniqueness_of :email
end

---Quick check---

If you did this correctly then you should be able to create a user in the Rails console and it should store a user model with an encrypted password_digest. User creation should look like this for encryption:

User.create(email: "email@address.com", password: "password", password_confirmation: "password")

app/config/routes.rb

Rails.application.routes.draw do
  resources :sessions, only: [:create]
  resources :registrations, only: [:create]
  root to: "static#home"
end

Create app/controllers/sessions_controller.rb

class SessionsController < ApplicationController
    def create
        user = User.find_by(email: params["user"]["email"]).try(:authenticate, params["user"]["password"])

        if user
            session[:user_id] = user.id
            render json: {
                status: :created,
                logged_in: true,
                user: user
            } 
        else
            render json: { status: 401 }
        end
    end
end

Create app/controllers/registrations_controller.rb

class RegistrationsController < ApplicationController
    def create
        user = user.create!(
            email: params['user']['email'],
            password: params['user']['password'],
            password_confirmation: params['user']['password_confirmation'],
        )

        if user
            sessions[:user_id] = user.id 
            render json{
                status: created,
                user: user
            }
        else
            render json: {status: 500}
        end
    end
end

app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
    skip_before_action :verify_authenticity_token
end

************

Check point

************

To test the current interactions, start the rails server and in another terminal interface do the following (user info should be the same as the user created at previous checkpoint). Use your hosting address.

curl --header "Content-Type: application/json" \
--request POST \
--data '{"user": {"email": "z@dev.com", "password": "asdf"}}' \
http://localhost:3000/sessions

You should get some message similar to

{"status":"created","logged_in":true,"user":{"id":1,"email":"z@dev.com","password_digest":"$2a$12$m9er4Bkndom7g5I85Ppj0Ob8EoPYkcw/gApT1ofEz2Ld3y4Eopbzy","created_at":"2020-04-26T02:15:57.844Z","updated_at":"2020-04-26T02:15:57.844Z"}}

app/config/routes.rb

Rails.application.routes.draw do
  resources :sessions, only: [:create]
  resources :registrations, only: [:create]
  resources :logout, to: "sessions#logout"
  get :logged_in, to: "sessions#logged_in"
  root to: "static#home"
end

Create app/controllers/concerns/current_user_concern.rb

module CurrentUserConcern 
    extend ActiveSupport::Concern

    included do
        before_action :set_current_user
    end

    def set_current_user
        if sessions[:user_id]
            @current_user = User.find(session[:user_id])
        end
    end
end

app/controllers/sessions_controller.rb

class SessionsController < ApplicationController
    include CurrentUserConcern

    def create
        #unchanged
    end

    def logged_in 
       if @current_user
            render json: {
                logged_in: true,
                user: @current_user
            }
        else
            render json: {
                logged_in: false
            }
       end
    end

    def logout
        reset_session
        render json: { status: 200, logged_out: true}
    end
end

app/config/initializers/session_store.rb

if Rails.env == "production"
    Rails.application.config.session_store :cookie_store, key: "_homesteadtogether", domain: "jdh-homesteadtogether.herokuapp.com"
else
    Rails.application.config.session_store :cookie_store, key: "_homesteadtogether",

Finished!

That should complete the backend of the api. I will try to compress this into more concise single page paragraphs in the future. Working on the front end walkthrough now.

Fetch() in JavaScript pt. II, Revenge of the options

Dane Dawson — Sat, 25 Apr 2020 23:57:01 +0000

Where we last left off at my first post about fetch() we have the ability to use fetch to perform GET requests. For POST, PATCH, and DELETE, we will need to utilize the options I referred to in the last article.

let options = {
      method: "METHOD",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ dataKey1: dataValue1, dataKey2: dataValue2 }),
    };

There are numerous and nuanced ways to set up fetch requests, and for more detailed information I would recommend looking here, here, or googling around if you need a particular approach. This walkthrough is simply a very basic, functional application of CRUD functionality for fetch requests designed to introduce new programmers and open the door to the possibilities of fetch().

Let me try to break down what each of those aspects can be used for

let options = {
      //This is where you specify what type of request you are sending.
      //This article will cover a basic application of POST, PATCH, and DELETE
      method: "METHOD",
      //I only got the kind of graze the surface of what headers do. 
      //From my understanding they are a way for the backend and front end
      //verify they are sending the same type of information in the same way.
      headers: { "Content-Type": "application/json" },
      //This is the actual content you are sending, you can think of it as either
      //a ruby hash or a JavaScript object (the latter is more accurate). Fetch
      //exchanges JSON strings of data, so we have to convert our data object
      //into a JSON string.
      body: JSON.stringify({ dataKey1: dataValue1, dataKey2: dataValue2 }),
    };

This is the basic outline of what all three of these fetch functions will look like, with some minor alterations depending on what the function is.

POST

The following is an example of one way you could set up a POST request to a simple backend API to create a new user.

//setting global constant for the user database URL
const userURL = "https://localhost:3000/users"

//This is the user object we are adding to the database. 
//This model is fairly simple, but it could contain as many attributes as you would like.
let user = {
  name: 'Mordecai Phineaus III',
  email: 'mordiphi@gmail.com'
};

//by creating the postOption as an object, it makes it easier to call within the fetch
let postOptions = {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json;charset=utf-8'
  },
  body: JSON.stringify(user)
});

fetch(userURL, postOptions)
//Note: the following code is functionally identical to the fetch above
fetch("https://localhost:3000/users", {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json;charset=utf-8'
  },
  body: JSON.stringify({
  name: 'Mordecai Phineaus III',
  email: 'mordiphi@gmail.com'
  })
})
//You can see how it can be easier to follow if you use variables

PATCH

Recent updates to Rails and JavaScript have made a PATCH request much simpler. If the back end is properly set up all you have to do is target the object you want to alter and send a similar options object as the POST. See the differences below.

const userURL = "https://localhost:3000/users"

//For this example, let's imagine this is the model for the user object we are updating.
//For simplicity it only has an id, a name, and an email
user = {
  id: 1
  name: 'Mordecai Phineaus III',
  email: 'mordiphi@gmail.com'
};

//Our user wants to update their email
newEmail = {
  email: 'MightyMordiPhineas@gmail.com'
}
//As we are only updating the email, we don't need to include any other attributes

//New PATCH request with the updated email as the body
let patchOptions = {
  method: 'PATCH',
  headers: {
    'Content-Type': 'application/json;charset=utf-8'
  },
  body: JSON.stringify(newEmail)
};
//We will need to find the user in the database to update them
let userId = user.id
//Now we fetch to the specific id of the model we are trying to update

fetch(userURL+'/'+userId, patchOptions)

//Note the above single line of code is functionally identical to the following
fetch("http://localhost:3000/1", {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json;charset=utf-8'
    },
  body: JSON.stringify({
      email: 'MightyMordiPhineas@gmail.com'
        })
  };
);

DELETE is even easier. This is by far the most dirty and straightforward way to do a delete, but especially for your first delete interactions it will work great!

let patchOptions = {
const userURL = "https://localhost:3000/users"

//Let's take a look at that user we had before
//note the updated email address as our PATCH was so successful
user = {
  id: 1
  name: 'Mordecai Phineaus III',
  email: 'MightyMordiPhineas@gmail.com'
};

//Now we just want to delete the file entirely. 

//Since no specific information is needed to delete the file other than the user id
  let userId = user.id

//Our DELETE option is far cleaner
let deleteOptions = {
  method: 'DELETE',
};
//Again, we just target the user by their id we captured above
fetch(userURL+'/'+userId, deleteOptions)

Hopefully armed with these base outlines you can get your API and client side connected and start to really explore the potential programming has to offer.

Until next time, happy coding!

Introduction to fetch() in JavaScript

Dane Dawson — Sat, 25 Apr 2020 20:07:35 +0000

This article series will use Ruby on Rails as a backend and JavaScript as the front end.

As I was learning JavaScript, one of the most confusing aspects of database interactions was the fetch() function. It is one of the most commonly used ways to interact with APIs, and while it has an amazing amount of functionality we will focus on it's most basic application, using the following format:

//Setting our host URL as a constant for easy reference
const URL = "http://localhost:3000"
//We will probably not talk much about options this article, but here is an example one
options = {
      method: "METHOD",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ dataKey1: dataValue1, dataKey2: dataValue2 }),
    };

//This is the actual series of functions for a fetch request. 
//However, the above options and URL are just examples of possible text
//This series of code would actually be inneffective in practice 
//so we are focusing on the structure rather than specific content.
fetch( URL, options)
.then(response=>(response.json()))
then(json=>(console.log(json)))

First, let me break down what this series of lines will do at a base level. The first line:

fetch( URL, options)

This will send a request (included in the options) to the specified URL (which we are saying is a local server we are hosting at http://localhost:3000). There is a lot to unpack in the options, but the first fetch request almost any app will make is a GET request, pinging the database for some information from the API. One of the wonderful things about fetch is that if you are only doing a GET request you can actually leave the options variable blank and it will assume you are fetching information. Example:

//Global constant for database URL
const URL = "http://localhost:3000"
//Calling fetch on that url
fetch( URL )

Will send a GET request to whatever URL you send it. What will happen is fetch will send out a request to that URL, and if the URL is valid, it will return a promise. Most errors you will get at this point are because either the url is entered incorrectly or the database doesn't have the routes connected for request you are making at that URL. It is worth looking into what a promise fully entails, but a good foundational understanding is that the database was reached, the route connected, and it returned a notification saying "I got your request, I will send information as soon as I can". Once the information is retrieved and packaged at the server, it will send a response that is normally a JSON string.

Some quick words about asynchronous functions

For me, fetch was the first asynchronous function I had contact with, and it's the asynchronous nature of this function that requires the subsequent .then() functions. Normally, when JavaScript runs, it will read through the entire document once, and then run the code line by line. By nature, most code is synchronous so as soon as one line finishes being read it is computed immediately and the next line is executed. Fetch(), however, knows that it may take time to get the response back from the server, so after running the fetch request it will immediately move on to the next line of code...but our fetch won't have returned anything except a promise!

This brings us to the next lines of the fetch chain:

//Global constant for database URL
const URL = "http://localhost:3000"
//Calling fetch on that URL. This will instantly return a promise (if URL is valid databse).
fetch( URL )
//Then, once the response has been returned, convert the JSON string to an object
.then(response=>response.json())

As we now covered, the fetch will first return a promise followed (usually very quickly) by a response. This response will hold all the information pulled from your GET request, but it will hold it in a JSON string. While a JSON string is very useful for data sending (it is one long, easily digestible string with all negative space removed), it is difficult for most humans to interact with a JSON string comfortably. Our first action is to take this string and turn it into something we can actually manipulate, a JSON object. Thankfully, JavaScript has a built in function .json() to turn a JSON string into a JSON object. This, however, is yet another asynchronous function as the system won't know how long it will take to fully convert this string. All this means is we tack on one more .then to take that JSON object and do whatever we want to with it. This example is simply logging the object in the console, which is a good first step with a fetch to make sure you have the data you want in the format you want it.

//Global constant for database URL
const URL = "http://localhost:3000"
//Calling fetch on that URL. This will instantly return a promise (if URL is valid databse).
fetch( URL )
//Then, once the response has been returned, convert the JSON string to an object
.then(response=>response.json())
//Then, once the string has been converted into an object, console.log the object
.then(json=>console.log(json))

In this current setup we have created a URL variable that just hits a server at it's root folder. A practice I have found useful is setting the server locations you will be targeting as global constants. Note, all these names used so far are simply placeholders for legibility in this walkthrough, you can use anything you want to reference the variables. If you were fetching an API to get a collection of users, you may do like the following:

//Global constant for user database URL
const userURL = "http://localhost:3000/users"
fetch( userURL )
.then(response=>response.json())
.then(users=>console.log(users))

If this works correctly, we should have in our console a list of every user object in our database. You could easily return the users, or embed another function that renders components, divs, or any other application of those objects you want.

If you wanted to target a specific user by id, you could do a targeted fetch like the following:

//Global constant for user database URL
const userURL = "http://localhost:3000/users"
//You can define this userId through an input value or any other way you'd like
let userId = 1
//This is the same as typing "http://localhost:3000/users/1" but open to dynamic change
fetch( userURL+"/"+userId )
.then(response=>response.json())
//this will now only return the user found at the id given
.then(user=>console.log(user))

Now that we have the basic foundations of GET requests, all the other requests work very similarly except the presence of the options.

Click HERE to see a basic introduction to full CRUD fetch requests!

My First Large Programming Project - Lessons Learned

Dane Dawson — Fri, 14 Feb 2020 18:18:08 +0000

I am writing this post now after completing the alpha of my very first project, Ruby Wizard, an interactive text-based game framed to lay foundation for a game introducing new programmers to Ruby. It was a humbling and gratifying experience trying to storyboard and plan a project with a deadline for the first time, but I wanted to take a moment to point out things I picked up along the way I learned during my first real project.

--You can never plan too much--

Seems straightforward but the more you can storyboard, whiteboard, brainstorm and draw out before you actually even touch a computer the easier you will find getting everything to connect in the end. It's easier to take an extra day to plan than an extra 2 days to debug! We started basic brainstorming on a combination of GoogleDocs for content and Draw.io to whiteboard our object interactions and map our software layout, and probably spent at least 2 days planning as much as we could before we typed a single word of code.
--Make small changes with each test, and isolate as much testing as you can--

My first alters to code were vast and sweeping, adjusting multiple values and methods across several pages all at the same time. It shouldn't be hard to see why this was a terrible idea. I would often spend longer debugging the mess I created than I would have if I just tested along the way. My rule of thumb has become "Every time you make an edit that breaks your code, as soon as it should be fixed check it". If all you do is change one value or variable, save and test immediately. Run things early and often and it saved me a lot of trouble in the later stages of our project debug.
--Break problems down as small as possible--

There were many aspects of making a game that were completely overwhelming, especially some of the stretch goals we still have in mind as we continue to tinker with this project in the future. Any task you have ahead will be exponentially easier if you break it into it's smallest compartments.
--Always check for gems--

We were doing a game operating entirely through the console, so we already knew that graphical interface was going to be minimal...but we still wanted things to look good! Thankfully, other developers have had the same issue and were kind enough to openly source their solutions. We ended up utilizing TTY-prompt, TTY-box, and TTY-font as our primary display functions...which leads me to my next tip...
--Take the time to view the readme on any gem you use!--

If you find a gem that looks like it may help you out, definitely take the time to go through the whole readme/documentation if possible. During out project we were using boxes to frame data pulled from a database with one method we found in the gem TTY-box. We found the gem for exactly this one purpose we had in mind, and, having accomplished that task, promptly forgot we had the TTY-box gem installed. Later we came across issues with our display output in a context that we spent hours working on ways to re-configure the text and data to make it more presentable, and finally after 30 minutes reading the TTY-box gem readme I found it had a function that did exactly what we just wasted an afternoon trying to work around. You already installed the gem and required it, might as well take advantage of that! Be careful though, the more you utilize a gem the more you depend on someone else upkeeping their code.

My project is available to view on my github here, feel free to check it out and give some constructive feedback!

Ruby Newby, Classes introduction Part 1

Dane Dawson — Fri, 14 Feb 2020 18:15:55 +0000

The object Class is a useful and expansive tool in Ruby programming, but because of the multitude of applications and uses it has in more advanced programming techniques it can be difficult to find a basic and fluid introduction to what they are and how to use them. This will be my attempt at a (hopefully) concise and useful introduction to Classes and their components.

First let's define what a Class is. In broad terms Class is used as an Object one can use to create objects with defined attributes and methods to interact with those objects. For this article we will think of a Class as a miniature MakerBot full of very basic (and tiny) worker robots. The MakerBot Class can be used to create MakerBot Objects and within the MakerBot class is a place to keep the blueprint for what it makes (these are called attributes and will be covered in more detail in future posts). Unfortunately the workers don't know how to do anything you don't tell them how to do exactly, so there is also a place full of instruction manuals for the workers to follow (these will be the methods we write within the Class itself). Sounds simple enough, right? Let's break it down!

First, we build our MakerBot (the class):

class MakerBot
end

That's it! We now have a Class called MakerBot. We have to notate that we are making a class, and then name our class. With Ruby you write Class name in CamelCase, combining all words into one line and capitalizing each letter. If our MakerBot was just a factory, for instance, we may name our class Factory. The only downside to our MakerBot as is...it doesn't do anything! Let's give this Class something that happens when you call on it.

class MakerBot
    def initialize
        print "It works!"
    end
end

Initialize is part of an inhereted method for the Class. Inhereted methods are methods that come with an object inherently, without you having to type any code. An example would be array.length, where length is the inherited method that arrays carry, allowing programmers to discover the length of an array simply by calling length against it. Using initialize and typing (ClassName).new creates an Object (in our case, a MakerBot). The object it makes is defined by whats in the initialize method within the Class, and is where we will be adding in attributes and some specific methods in the future. Right now let's try calling our Class to create a new MakerBot Object.
We can now call our MakerBot by typing:

MakerBot.new

and it should return

It works!

Hey look! Our code did something! But having some words on a screen is not really having our own MakerBot...Let me add some lines of code to give it some attributes and really give our MakerBot some substance! Well...digital substance.

class MakerBot
    def initialize(name, product, owner)
    end
end

You can see we added arguments to the initialize method, this will allow us to input values to give our MakerBot some details to make it more like an actual object! Let's try running it now and see what happens...

MakerBot.new("Steve", "Waffle-fries", "The Master Programmer")

Huh...that's strange...Nothing happened? The good news is, you didn't type anything wrong! The problem here is that although we are making a new MakerBot and giving it all these cool attributes, we aren't actually saving anything...anywhere...ever! On the next post I will continue exploring attributes, and how to save data points in temporary memory. As a teaser, by the end of next lesson the following code will make sense!

class MakerBot
    attr_accesor: :name, :product
    attr_reader: :owner

    @@all = []

    def initialize(name, product, owner)
        @name = name
        @product = product
        @owner = owner
        @@all << self
    end
end

Until next time, happy coding!