Forem: victorhaynes

My Experience: Completing Flatiron School Software Engineering (Live) Bootcamp

victorhaynes — Wed, 05 Oct 2022 17:06:24 +0000

The Stack (& core concepts)

JavaScript (HTML + CSS, JSON Server, Request/Response Cycle)
React (React Router, Single Page Applications, Dynamic Re-rendering)
Ruby (OOP, ORMs, SQL, RESTful APIs)
Ruby on Rails (RESTful APIs /w framework)

The Cost:

Roughly $17,000

The Timeline:

5 Phases, each 3 weeks long
JavaScript/HTML/CSS -> React as a frontend framework -> Ruby/OOP/SQL essentials -> Rails as a backend framework
Phases 1 - 4 you work on and present group projects
Phase 5 a 3 week long solo project
15 weeks total duration + prework

Phase Structure:

Roughly 1 week of learning a new concept (i.e. React)
Roughly 1 week of preparing for a code challenge (i.e. React exam)
Roughly 1 week of applying concepts to your phase project

Pros:

Challenging. This is not something you can easily skim through. If you want something more lax that you can do at your own pace & learn at more of a dilettante-ish rate this is not that.
Applicable content
Namebrand bootcamp, higher quality than most
Full stack program

Neutral:

A pro or a con but you are 100% responsible for your own strength leaving the bootcamp. The staff is here to help but ultimately it's on you what you get out of this.

Cons:

A little bit of a sink or swim environment. If you set your mind to this you can do it. However it will require a lot of effort and self-reassuring along the way and there is no 2 ways about it. Especially if you are entirely new to technology.
Expensive
Rails is not as popular as it once was
There is some self-guided material provided but CSS content is totally lacking
Data structures & Algorithms (DSA) is treated as an after thought. There is self-guided material but realistically, very little time to do it if you want to complete all the core material with comprehension.

Recommendation?:

Yes. If you can commit to the fulltime (online or in person does not matter) program.

The Outcome:

Pending, stay tuned for more.

Ruby on Rails: Serialization Made Easy

victorhaynes — Sun, 11 Sep 2022 03:00:28 +0000

If you do not want an overview on how to setup a Rails API skip straight to part 2.

Serialization in web development can simply be understood as the process of customizing the response our server sends (i.e. a Rails API) after receiving a request from a client (i.e. Goolge Chrome, Firefox, Safari etc.).

Rails uses a gem/library called 'active_model_serializers' to give you easy, powerful response customization.

For this explanation we will assume that we have a relational database based on SQL setup in our backend and have used some sort of ORM (Object Relationship Mapper) to turn OOP objects into models. Our models each map to a table in our database and each instance of our model is a record in our table.

Part 1: Setting up an API

Skip if you are already comfortable quickly spinning up a Rails API. If you want a walk through we will be creating two resources. Wallets (class Wallet, table wallets) and Bills (class Bill, table bills)

A Wallet has many Bills and a Bill belongs to a Wallet.

1) Create a new Rails app. I named mine lets-learn-serializers used the --api --minimal flags to keep the app light and extraneous features out.

$ rails new lets-learn-serializers --api --minimal

2) In root/Gemfile add gem:

gem "active_model_serializers", "~> 0.10.12"

3) bundle install

$ bundle install

4) Use a Rails generator of your choice. The scaffold generator creates many files for you following good coding practices and REST conventions. The resource generator does a lot of heavy lifting for you but less pre-written code than scaffold. --no-test-framework eliminates test files that Rails will generate for you. We do not need this now

$ rails g scaffold wallet owner brand --no-test-framework

$ rails g scaffold bill value:integer wallet:belongs_to --no-test-framework

5) Add the has_many side of the relationship manually to the Wallet model

# app/models/wallet.rb

class Wallet < ApplicationRecord
    has_many :bills
end

6) Create your instances of Wallets and Bills (i.e. create Mock Data) in your seeds.rb file

example_wallets = [{owner: "Victor", brand: "Gucci"}, {owner: "Kells",brand: "Larry Leather"}, {owner: "Bart", brand: "Vintage Co."}]

example_bills = [{value: 20,wallet_id: 1},{value: 5, wallet_id: 1},{value: 1, wallet_id: 1},{value: 100,wallet_id: 2},{value: 100,wallet_id: 2},{value: 50,wallet_id: 3},{value: 20,wallet_id: 3}]

Wallet.create(example_wallets)
Bill.create(example_bills)

7) Migrate and seed your database

rails db:migrate db:seed

8) If all goes well you should be left with 2 tables:
wallets:

bills:

9) Check out your wallet and bills controllers, they should look something like this:
/app/controllers/wallets_controller.rb:

Now we are ready to receive requests for CRUD actions on our /wallets and /bills resources. We can send information about our wallets and bills to a client.

Part 2: Serializing our Response

Brief serializer explanation:

When we use the render json: method in a model controller Rails defaults to sending everything about a given model to the client.

A GET request to /wallets will send back all of our Wallet objects and each object will have the attributes: "owner", "brand", "created_at", "updated_at". Similarly, a GET request to /bills will send back all of our Bills and their: "value", "wallet_id", "created_at", and "updated_at attributes". This is what you will get. No more and no less.

If we want to change this default behavior (i.e. perform some sort of server-side calculation before sending a response back or excluding some information or literally anything other than "send everything back the way it is") the cleanest way to do so is to use a Serializer.

Rails, usually for better, is an extremely opinionated framework. If you've gotten this far you've probably figured out that the way we name the building blocks of our MVC architecture in Rails matters, a lot. Rails does try to make it easy on us though as long as we know and follow the rules. By default, Rails will implcitly look for a serializer who's name matches the name of a model before sending back a response.

Put simply, before our WalletsController sends anything anywhere it will look to see if a WalletSerializer exists. If it does, it will use it. You can also specify what serializer you want to use should you have a need to but custom serializers are for another day.

Putting this in practice:
Let's take a look at our Wallets serializer now. The $ rails g scaffold <model_name_here> command created this serializer for us. If you do not want all of the code scaffold gives you you can create a standalone serializer with $ rails g serializer <singular_lowercase_model_name>

Depending on how you created your serializer your attributes will default to either :id or all of the attributes excluding :created_at and :updated_at.

Using the attributes keyword inside a model's serializer we can specify what we want to include in our JSON response to the client

# app/serializers/wallet_serializer.rb

class WalletSerializer < ActiveModel::Serializer
    attributes :id, :owner, :brand
end

As is, a GET request to /wallets returns this JSON response:
And this makes total sense considering how our serializer for Wallets is setup. We got "id", "owner", and "brand" back. But hmmm, our timestamp columns from our wallets table are being excluded. Let's add them back in.

# app/serializers/wallet_serializer.rb

class WalletSerializer < ActiveModel::Serializer
    attributes :id, :owner, :brand, :created_at, :updated_at
end

Our response now looks like this. For the rest of the blog I will keep the timestamps out for clarity:

Advanced uses:

In my view, there are two core tasks that serializers help achieve other than just excluding/including information.

1) Making use of the associations between models

With very little effort, because we have the Wallet - has_many :bills and Bill - belongs_to :wallet associations setup in our model we can include the association in our serializer.

class WalletSerializer < ActiveModel::Serializer
  attributes :id, :owner, :brand

  has_many :bills
end

And thanks to Ruby magic:
We can now see that the wallet with id 1 or Victor's wallet has a $20, $5, and $1 bill. Kells has two $100 bills and etc.

2) Including new, custom, or calculation-based information that is not in our database but needs to be sent to our front end.

What if instead of knowing what kind of bill was inside each wallet we just wanted to know the total amount of money in each wallet? We can easily do that using some vanilla Ruby, ActiveRecord methods, and the functionality our serializer gives us. Let's write a cash_total method to calculate this server-side and include the result in our JSON response

class WalletSerializer < ActiveModel::Serializer
  attributes :id, :owner, :brand, :cash_total

  has_many :bills

  def cash_total
    self.object.bills.pluck(:value).sum
  end

end

And just like that, you can now see that Victor has $26 in his Gucci wallet and Kells has $200 cash in his Larry Leather wallet.

And that is enough information to start serializing your responses in reasonable ways. For continued learning experiment with serializing responses for the Bill model/requests to /bills.

I also recommend checking our the Ruby docs for custom serializers now that you have a strong foundation.

Happy Rubying.

ActiveRecord (a Ruby gem): Common Methods

victorhaynes — Sat, 20 Aug 2022 20:35:44 +0000

ActiveRecord is popular Ruby gem (library) that acts as an Object-Relational-Mapper (ORM) for Ruby.

ActiveRecord allows us to combine the object-oriented nature of Ruby with the functionality of relational databases. Using ActiveRecord we can easily define Ruby Classes and map those Classes to columns in a database. We can then instantiate--i.e. create--new instances of those Ruby Classes and map those instances to records (rows) in a database column. We can then finally interact with our newly constructed database with methods from the ActiveRecord gem inside of a Ruby/.rb file.

Before continuing please note that ActiveRecord uses strict naming conventions. This is what allows its default configuration to handle a lot of work for us.

capitol, singular Class name for your model (Food)
lowercase, plural table names (foods)

Suppose we have this table of foods (from a Food Ruby class model that inherits from ActiveRecord::Base if you are keeping track at home) :

Table: foods

id	name	tastiness
1	hotdog	8
2	burger	7
3	ramen	9
4	rice	10
5	cheese	4

We could begin to access or manipulate this table using the Food class in a rake console session for example or in the model's .rb file. Here are some common methods & manipulations:

get first record

Food.first

=> <Object Instance corresponding to id:1 name: "hotdog" tastiness: 8>

returns the first record/Object instance in a column

get record by id

Food.find(3)

=> <Object Instance corresponding to id:3 name: "ramen" tastiness: 9>

returns the first record/Object instance with the id passed as an argument

get record by attribute (first match only)

Food.find_by(name: rice)

=> <Object Instance corresponding to id:4 name: "rice" tastiness: 10>

returns the first record/Object instance with an attribute that matches the .find_by() argument

get all records by criteria (all matches)

Food.where(' tastiness < 8 ')

=> [<Object Instance corresponding to id:2 name: "burger" tastiness: 7>,
<Object Instance corresponding to id:5 name: "cheese" tastiness: 4>]

returns all records/Object instances with an attribute that matches what was passed as an argument
.where returns an ActiveRecord::Collection which is an array-like data structure that can be indexed or iterated through using array methods. Even if there is only 1 match .where will always return the results in a collection.

get all values in a column

Food.pluck(:name)

=> ["hotdog", "burger" , "ramen", "rice", "cheese"]

Food.pluck(:tastiness)

=> [8, 7 , 9, 10, 4]

returns each value in a column as an element in an array

create a new record/instance in a table (with persistence)

Food.create(name: "eggs", tastiness: 5)

id	name	tastiness
1	hotdog	8
2	burger	7
3	ramen	9
4	rice	10
5	cheese	4
6	eggs	5

under the hood this is working similar to using .new & .save together. .new will only create a new instance of a class in Ruby memory. It will not persist until it is written to the database using .save. .create does both of these for you.

count number of records in a column

Food.count(:name)

=> 6

counts the number of records in a column

remove a record/instance in a table (with persistence)

Food.find(2).destroy

id	name	tastiness
1	hotdog	8
3	ramen	9
4	rice	10
5	cheese	4
6	eggs	5

.destroy should be used to destroy a single record/instance
.destroy_all should be used to destroy multiple records such as every instance of a class (i.e. Food.destroy_all) or to destroy every member of an ActiveRecord::Collection (i.e. after a .where to do a targeted removal)

update a record/instance in a table (with persistence)

Food.find(6).update(name: "bread", tastiness: 9)

id	name	tastiness
1	hotdog	8
3	ramen	9
4	rice	10
5	cheese	4
6	bread	9

you can update a single attribute such as only the name or only the tastiness or do both

You are now familiar with basic ActiveRecord ORM methods. If you want to try experimenting with this data at home continue below:

Set this up at home:

Provided you have an Ruby & ActiveRecord environment already configured and you are in that directory, you can try this yourself after creating (and migrating) this migration:

Brief configuration guidance:
Gemfile:

source "https://rubygems.org"

gem "activerecord", "~> 5.2"
gem "sinatra-activerecord"
gem "sqlite3"
gem "pry"
gem "require_all"
gem "rake"

Rakefile:

require_relative 'config/environment'
require 'sinatra/activerecord/rake'

desc 'starts a Pry console'
task :console do
  # Comment out the line below if you don't want to see the SQL logs in your terminal
  ActiveRecord::Base.logger = Logger.new(STDOUT)
  # Start a Pry session
  Pry.start
end

config/database.yml:

development:
  adapter: sqlite3
  database: db/development.sqlite3
  pool: 5
  timeout: 5000

config/environment.rb:

require 'bundler'
Bundler.require

require_all 'app'

Now, on to actually creating this database:

# In a terminal window run:
$ bundle install
$ bundle exec rake db:create_migration NAME=create_foods

# inside of the db/migrate folder
# update your migration to have these attributes
# (the 5.2 should match whatever version of the activerecord gem
# you have installed in your gemfile)

class CreateFoods < ActiveRecord::Migration[5.2]
  def change
    create_table :foods do |t|
      t.string :name
      t.integer :tastiness
    end
  end
end

migrate your newly created migration:

# In a terminal window run:

$ bundle exec rake db:migrate

create this model:

# create a /app folder inside the root of your directory and put a /models folder inside of it.
# create a .rb file with your model name inside of /models 
# singular and lowercase i.e. /app/models/food.rb

class Food < ActiveRecord::Base
end

populate/seed your database with data (create instances of the Food class that will exist inside of your foods table

# create a "seeds.rb" file inside of the /db directory

Food.create(name: "hotdog", tastiness: 8)
Food.create(name: "burger", tastiness: 7)
Food.create(name: "ramen", tastiness: 9)
Food.create(name: "rice", tastiness: 10)
Food.create(name: "cheese", tastiness: 4)

# In a terminal window run:

$ bundle exec rake db:seed

You have now:
1) Defined your table structure
2) Created your table
3) Defined what class belongs your the table
4) Filled your table with instances of your class

You can new view your database using an IDE + an extension (such as Visual Studio Code /w the SQLite extension or using a standalone database viewer app).

Feel free to try access and manipulate your table inside of a rake console session in your terminal or from inside your model's class definition now.

Happy rubying!

React.js: Event Listeners Made Easy

victorhaynes — Sun, 31 Jul 2022 21:39:00 +0000

If you are a beginner webdev contemplating how to use Event Listeners in React, first of all congratulations on getting your foundation in vanilla JavaScript. That baseline JavaScript understanding is going to come in handy. Second of all, you are in the right place.

Event Listeners in React work, for as far as we are concerned, almost identically to how they work in vanilla JavaScript. There are just some syntactic differences and they get attached to HTML elements in our DOM a bit differently.

The "vanilla JavaScript" way of doings things:

In vanilla JavaScript you may be familiar with this sort of process:

// 1) Create a new button HTML element <button></button>
const newButton = document.createElement("button")

// 2) Assign some attributes to the button
newButton.innerText = "Click Me!"
newButton.setAttribute("class","example-button")

// 3) Assign an Event Listener to the button
newButton.addEventListener("click", () => console.log("You clicked me!")

// 4) Append this new button to the body of our HTML document (or anywhere else we want the button) in the DOM
document.body.append(newButton)

// 5) Your button is now visible on your example HTML page in browser and when clicked 
// it will print "You clicked me" in your console
// FYI: your new HTML button looks like this:
// <button class="example-button">Click Me!</button>

We call this style of programming imperative programming. This means we are being extremely literal and precise. We are specifying every little step and providing clear instructions on how to achieve them. This is not a very React way of doings things. React introduces the concept of declarative programming where we can "declare" what we want to happen and React will handle making it happen.

This same example in React would look like this (assuming you have a React app already initialized). Let's start with a pretty clean slate:

Intro: The React way of doings things

// This file is called App.js
// Here is our baseline React application, right now it only has a
// single Component called "App" and "App" just consists of a <div> node

import React from "react";


function App() {
  return (
    <div className="App">
    </div>
  );
}

export default App;

Notice how inside the return statement of App it looks like we are writing HTML syntax. That is because we are essentially are with some minor differences (ex. class is used in HTML where in React we use className). React Components render JSX. JSX is a JavaScript extension that allows us to use HTML-like syntax directly inside of a .js file. This is useful because now we can use vanilla JavaScript, HTML, and React-specific features all in the same single .js file. Lets try to build out our vanilla example in React.

Example (pt. 1) - make a button node

// Here we added a button inside of our <div></div>

import React from "react";


function App() {
  return (
    <div className="App">
      <button className="example-button">Click Me!</button>
    </div>
  );
}

export default App;

Wait. What happened to document.createElement("button") and .setAttribute("class", "some-example-class")? In React we no longer need these methods. We can straight up type the HTML we want to render along with any ids or classes directly. We also do not need to .append() anything to our DOM.

If you care to know how exactly these React Components and JSX are getting rendered, the index.js file that is auto generated upon initializing a React app is how. But there are a host of other concepts that make it all happen which are a topic for a different day.

Let's just get an Event Listener working in React. Instead of using .addEventListener() on an HTML node using vanilla JavaScript we can directly add an Event Listener to the JSX node inside the same, single file!

Vanilla JavaScript	React
.addEventListener("click", ...	onClick=`{someFunction}`
.addEventListener("submit", ...	onSubmit=`{someFunction}`
.addEventListener("hover", ...	onHover=`{someFunction}`
.addEventListener("change", ...	onChange=`{someFunction}`
etc.	etc.

Just like how we straight-up-typed the div, the button, the button's innerText, and assigned a class all inside the JSX we can straight-up-type the event listener we want on the JSX also.

Example (pt. 2) - add an onClick to our button & a function to handle the click event

// 1) We defined a function to handle the click event
// 2) We added an onClick event inside the <button> tag

import React from "react";


function App() {

  function handleClick(){
    console.log("You clicked me!")
  }

  return (
    <div className="App">
      <button className="example-button" onClick={handleClick}>
        Click Me!
      </button>
    </div>
  );
}

export default App;

React Event Listeners must be set equal to something. You want the event listener to be set equal to the function you want to run when the event happens. Specifically, you want to use a function definition and not a function invocation. When our button is clicked on the React application/webpage in our example, "You clicked me!" will be fired off in our console just like in our vanilla JavaScript example.

If you wanted to refactor this a bit you could also the define the post-event-instructions directly inside the onClick and this will achieve the same thing:

Example (pt. 2a) - refactor, define the handler function inline

import React from "react";

function App() {

  return (
    <div className="App">
      <button className="example-button" onClick={() => console.log("You clicked me!")}>
        Click Me!
      </button>
    </div>
  );
}

export default App;

But back to our Example part 2. There are a few other things going on here. Inside of the same App.js file we are able to 1) write vanilla javascript where we defined our function handleClick and 2) make use of JSX inside of our React Component (inside of App's return statement). Another thing to call out is our use of curly braces {}. Inside the return statement of a React Component the default expectation is everything you type will be JSX. If you need to interpolate vanilla JavaScript inside the return statement of a Component you must wrap the JavaScript inside curly braces {like So}.

And..... Done!

Congratulations on getting this far in your journey towards web development. You are now equipped with the fundamentals on how to use Event Listeners in React.

JavaScript: Event Listeners made easy

victorhaynes — Wed, 13 Jul 2022 02:14:53 +0000

Looking for a beginner-friendly example? Skip to the end.

Why am I writing this?

If you are not already an expert programmer, digesting a new concept is often daunting. There is no way around the fact that it takes time and effort for the next topic in your learning journey to sink in. This is further compounded by the fact there are many places to search for help and they are all wrapped in their own assumptions, intentions, and shorthands. It is often said that Googling is an important skill to develop--and it absolutely is!

Equally important however, is at this stage we must realize some sources are more helpful than others. If you have been programing for weeks or months, the Mozilla Developer Network (MDN) is not the best place to go to initially understand a foundational concept. A colleague of mine put it best. MDN is a great place to go when you want to have "beard-stroking, programming philosophizing time." It is a great place to get exhaustive, 100% technically correct answers but the target audience is not beginners. If you are new to event listeners this explanation may not help you.

If you are a true beginner looking for help on an assignment or if want to see a basic example of a concept, you likely do not care about all of the optional parameters of a method or function. Nor do you particularly care about the technical constraints of this particular built-in JavaScript method versus a similar looking built-in method. So let me be clear about the intentions of my blog post. If you want to start making richer webpages now...I give you: Event Listeners Made Easy.

Let's begin: what is an Event Listener?

The cool thing about programming is that you can often think through tasks verbally and literally. It is important to remember that we humans are the smart ones and the computers are the dumb ones. The syntax to create an event listener is .addEventListener().

This is a method built into JavaScript by our programming predecessors, very kind of them. They were even kind enough to give .addEventListener() a very meaningful name and syntax. If we stop and think through this literally:

We are adding an "Event Listener" to something.
We are indicating that we are listening or waiting for a certain event to happen to our something.

Typically, we are adding this "Event Listener" onto a HTML element inside the document in the DOM. Let's talk through a basic example:

We target a specific HTML element in the DOM
We apply the method .addEventListener() to our HTML element
We then want to pass 2 arguments into .addEventListener()
The first argument is the type of event we are looking for (i.e. "click" to listen for a mouse click, "submit" to listen for a form submission etc.)
The second argument is the function or the work we want to kick off once our specified event happens to our HTML Element.

In general, a basic .addEventListener() setup has two parameters (yes there are additional optional parameters if you check MDN). A high level example looks something like this:
some HTML Element .addEventListener("name of event" ,some function)

Example recognized events are: "click", "keydown", "keyup", "keypress", "submit", "mouseover" etc. Again, we owe a debt to our programming predecessors. They already equipped JavaScript with the ability to recognize when common mouse and keyboard actions occur.
Let's look at a real example now.

Example code

Suppose you have the following HTML code in your DOM:

<div id ="info">
     <button id="example-button">Click Me!</button>
</div>

<--! This is merely a <button> HTML element that will --> 
<--! read "Click Me!" when rendered in a web browser -->
<--! and the button is nested inside a <div> element -->

This button is not very useful right now. Sure it appears on our webpage but it is missing behavior. When you click this button it will not do anything. To add behavior to an HTML element we apply the .addEventListener() method to our HTML element using JavaScript.

Let's write some JavaScript code to achieve this. For a quick review, we first need to target the HTML element in our DOM that contains our button using .querySelector() or .getElementById(). I will use .querySelector() just to demonstrate how specific you can be with your query. Yes we can use .getElementById() with less code in this example.

let buttonElement = document.querySelector("div#info button")

// This line of code targets our <button> HTML element
// that is nested inside that parent <div>
// and stores it in variable buttonElement.

buttonElement.addEventListener("click", () => {
   console.log("You Clicked The Button!")
   console.log("If you see this, your Event Listener works!")
})

// Here, we added an Event Listener onto our HTML button
// and specified the "click" event as the 1st argument.
// As the 2nd argument we passed in an anonymous function
// using arrow syntax. The function we passed in this case
// has no name or parameters. They are not explicitly necessary

We have just done something very powerful. We took some static HTML and made it dynamic. Now when we click that "Click Me!" on our webpage i.e. when we click on this button:

<div id ="info">
     <button id="example-button">Click Me!</button>
</div>

we can specify to make some code to run. Inside the .addEventListener() we wrote, we specified instructions that will run after our button is clicked. The anonymous function passed inside as the 2nd argument will trigger and simply print to the console "You Clicked The Button!" and "If you see this, your Event Listener works!" but that is already a beautiful start. We could make that function much more robust. We could name and define a more complex function in the global scope and pass it into our .addEventListener() as the second argument. We could have that more robust function specify instructions to append some new information into our DOM once our webpage user clicks our button. We could even specify instructions to send data to a server and have that data persist in the server once our button is clicked even after we close our webpage. But for now, we have event listeners working and that is a victory.

You now understand the syntax and the basic parameters of .addEventListener() and can start to add "click" events to your HTML Elements in the DOM.