Forem: Michael Davis

Intro to Building a Ruby on Rails Back End

Michael Davis — Tue, 31 Jan 2023 19:06:36 +0000

Follow along with my example repo, which has a solution branch.

So, you wanna be a Ruby on Rails back end engineer, huh?? Then you came to the right place. 👊🙂

As of the posting of this article, I am finishing up my fourth phase of Flatiron School's full-stack software engineering boot camp. Phase 4 was focused on the topic of this article: Ruby on Rails. As an abstraction of Ruby, Rails expedites many of the tasks necessary to set up a Ruby database. What's the best way to do this, you ask? Well, let's find out! But first, let me briefly outline the data examples to best illustrate how our back end is built.

I'm a big music fan, and a full album listener at that, so I'd like to use the example of music fans giving ratings to particular albums. Each music fan can rate many different albums, and each album can be rated by many different music fans. It would make sense to have each music fan to only be able to rate each album once, because otherwise it would get confusing. Lastly, each rating will belong to one music fan and one album, so ratings will act as our join table with a foreign key for each of the other tables named music fans & albums.

So, each of our tables will have these attributes/columns:

Music Fans - :name
Albums - :title, :artist, :release_year
Ratings - :score, :music_fan_id, :album_id

Creating our associations will come into play later on, but now that we know what data we're going to be working with, let's review our Rails resources...

Rails Resources

In a Ruby on Rails application, there are a few essential things to keep an eye on at the highest level of our file hierarchy:

Gemfile (list of gems to install)
db/ (database folder)
config/ (configurations folder)
app/ (application folder)

If you are in the habit of paying attention to these files and folders, then you won't be caught off guard by any of the basic issues with building out your Rails back end!

We do have a single terminal command that will build out all of the aforementioned resources for us, in the form of:

rails g resource class_name attribute_name:attribute_type

...BUT, it's really important to understand all of the things that this command is doing, and how to properly write the command based on your particular dataset. So, let's start from the top.

Let's Break it Down by Each Resource...

Gemfile

As mentioned above, this is where we list our gems to be installed - these are our Ruby tools that make our life easier when building this code. For our purposes, we want to make sure our gemfile includes:

gem "active_model_serializers", "~> 0.10.12"

...and then to install these gems for use in development and testing, we enter this in our terminal:

bundle install

NOTE: All of your other needed gems should be included if you properly created your rails application with:

rails my_music_app

After creating our app's file structure and installing our gems, we can move on and start building out our data structure.

Database Folder - db/

Now the fun begins. Our database folder is going to contain FOUR important things:

db/migrate (migrations folder)
schema.rb (database structure file, based on migrations)
seeds.rb (seed data, formatted for schema.rb)
development.sqlite3 (final rendered database file)

Let's break it down...

1. db/migrate - (migrations)

This is the folder is where it all begins. Our migration files set up the data structure for each of our tables, including both the name of the table itself and the labels for each column attribute. Each table will have its own migrations. For our Ratings table (the join table with foreign keys), this is what our initial migration file would look like if we built it manually (but hold off on this for just a minute):

class CreateRatings < ActiveRecord::Migration[6.1]
  def change
    create_table :ratings do |t|
      t.integer :score
      t.integer :music_fan_id
      t.integer :album_id
    end
  end
end

2. schema.rb - (database structure)

Our schema file will act as the data structure resulting from the migrations for all of our tables, acting as a filter for our incoming seed data. This file will look similar to our migrations, but will include all the tables. To create our schema file manually (again, hold off on this too unless you want practice), we need to run this in our terminal:

rails db:migrate

Our resultant file should look something like this, including all three of our table migration structures:

ActiveRecord::Schema.define(version: 2023_01_20_164246) do
  create_table "albums", force: :cascade do |t|
    t.string "title"
    t.string "artist"
    t.integer "release_year"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

  create_table "music_fans", force: :cascade do |t|
    t.string "name"
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end

  create_table "ratings", force: :cascade do |t|
    t.integer "score"
    t.integer "music_fan_id", null: false
    t.integer "album_id", null: false
    t.datetime "created_at", precision: 6, null: false
    t.datetime "updated_at", precision: 6, null: false
  end
end

It's always good to double check your schema file after performing rails db:migrate, just to make sure things are looking accurate. So, now our data structure is in place for us to seed our data tables with. BUT, we can't seed our data without...

3. seeds.rb (our seed data)

This is the file in which we set up the actual data values for our table to be populated with. Without our seeds file, we won't be able to utilize our schema, because it won't have anything to work with. Basically, without a functioning seeds file, our resulting database will be comprised of empty tables. We don't want that, so let's look at what we need to do to build our seed data.

There are many Ruby methods we can use in building our seeds file, but we will keep it simple this time. If we were to seed with 3 instances each of music_fan and album, along with 6 unique rating instances, this is what it might look like:

puts "🎵 Seeding music fans..."
MusicFan.create(name: "Vizmund Cygnus")
MusicFan.create(name: "Cassandra Gemini")
MusicFan.create(name: "Cerpin Taxt")

puts "🎵 Seeding albums..."
Album.create(
  title: "DAMN. COLLECTORS EDITION.",
  artist: "Kendrick Lamar",
  release_year: 2017
)
Album.create(
  title: "In Rainbows",
  artist: "Radiohead",
  release_year: 2007
)
Album.create(
  title: "Monsters Are People",
  artist: "Chess at Breakfast",
  release_year: 2021
)

puts "🎵 Seeding ratings..."
Rating.create(score: 10, music_fan_id: 1, album_id: 2)
Rating.create(score: 9, music_fan_id: 3, album_id: 1)
Rating.create(score: 8, music_fan_id: 2, album_id: 3)
Rating.create(score: 7, music_fan_id: 3, album_id: 3)
Rating.create(score: 6, music_fan_id: 2, album_id: 2)
Rating.create(score: 5, music_fan_id: 1, album_id: 1)

puts "Done seeding!"

_PRO TIP: If you want to get practice using the Faker Gem to automate some of the details of your seeds file, _

As you can see, our seed data is built using pretty basic Ruby object format, with keys corresponding to our table attributes and unique values for those keys in each new creation of an instance. And luckily, we don't need to hold off creating this seeds file, since we will always have to create it manually.

NOTE: Each creation of an instance assigns id based on the order in which they're built, so the first MusicFan (Vizmund Cygnus) will have an id of 1, and the second (Cassandra Gemini) will have an id of 2, and so on...

With our fleshed-out seed data now created, we should be in a position to seed and render our database.

4. db.sqlite3 - (rendered database)

Assuming our seed data and migrations are formatted correctly, we can now run this command in our terminal:

rails db:seed

Once we seed, we should now have a development.sqlite3 file in our db/ folder. Right-click on this and select "Open Database". This will open up your SQLite Explorer in the bottom-left corner of your VS Code window. NOTE: Make sure you've installed SQLite as an extension in VS Code, or this won't work!

If you've done everything correctly up to this point, you should have three tables. For example, your albums table should look like this:

If there are ever any weird issues with the database throughout development, you can always try this command:

rails db:reset

...which will drop the database (make sure you actually want to drop it before you do this!) and re-seed.

Now that we have a rendered database, we can finally move on to USING our data!

Configurations Folder - config/

Our config folder luckily only has one file we need to keep a close eye on: routes.rb

This file is where we can determine what CRUD actions to be allowed for our different controllers, as well as setting up custom routes for things like user authentication. We won't take a super close look at this here, but here's what our basic routes file would look like if we have full CRUD on albums and music fans, but only index, show, create, and destroy (excluding update) on our ratings:

Rails.application.routes.draw do
  resources :ratings, only: [:index, :show, :create, :destroy]
  resources :music_fans
  resources :albums
end

Doing this will ensure that we don't have any unused routes on our back end, which will speed up our rendering process.

Now that we have limited our routes, to enhance efficiency, we can move on to our final resource...

Application Folder - app/

Similar to how I went over the config folder, I won't go into too much detail on our app folder, but I will give an overview of the important resources to keep an eye on, along with why. Here's a brief list:

models (foundational class models)
controllers (controllers with route actions)
serializers (serializers for preparing data output)

app/models - class models

Our models are the foundation for the rest of our app folder, because it's where we determine our associations and our validations. First and foremost, we need to build out our associations. Here's how they will look, with a score validation between 1-10:

rating.rb

class Rating < ApplicationRecord
  belongs_to :music_fan
  belongs_to :album

  validates :score, inclusion: 1..10
end

music_fan.rb

class MusicFan < ApplicationRecord
  has_many :ratings, dependent: :destroy
  has_many :albums, through: :ratings
end

album.rb

class Album < ApplicationRecord
  has_many :ratings, dependent: :destroy
  has_many :music_fans, through: :ratings
end

NOTE: Our Rating model will already have the belongs_to relationships if we use rails g resource properly. Stick around to the end to see how that's written.

OTHER NOTE: We include dependent: :destroy in order to engage the destroy route of all ratings associated with a particular music fan or album, when they themselves are destroyed. This makes sense because ratings without music fans or albums shouldn't technically exist and will cause issues with rendering in the front end.

Awesome! Now we can move on to our next application resource.

app/controllers - with route actions

Our controllers will contain the methods that our routes.rb file points to. As far as full CRUD, the default actions are as follows:

index (READ all)
show (READ one)
create (CREATE one)
update (UPDATE one)
destroy (DELETE one)

To demonstrate full CRUD here, we need to pick one of the models that has full CRUD. For this purpose, let's go with albums:

class AlbumsController < ApplicationController

  def index
    albums = Album.all
    render json: albums, status: :ok
  end

  def show
    album = Album.find(params[:id])
    render json: album, status: :ok
  end

  def create
    album = Album.create!(album_params)
    render json: album, status: :created
  end

  def update
    album = Album.find(params[:id])
    album.update!(album_params)
    render json: album, status: :accepted
  end

  def delete
    album = Album.find(params[:id])
    album.destroy
    head :no_content
  end

  private

  def album_params
    params.permit(:title, :artist, :release_year)
  end

end

NOTE: we save ourselves a bit of time by defining album_params in our private methods.

We now have all of our CRUD methods built for albums, so all our routes should work properly for it. We can now move on to the final piece in the puzzle...

app/serializers - for preparing data output

We're almost there! With serializers, we are basically telling our routes how to prepare our data. So let's say that when we fetch a particular album, we want to also show all the music fans that have rated that particular album. To do this, we simply need to add one line to our album_serializer.rb. Here's what the file will look like:

class AlbumSerializer < ActiveModel::Serializer
  attributes :id, :title, :artist, :release_year
  has_many :music_fans
end

This will ensure that when we do fetch that album, the JSON response will have a music_fans key and a corresponding value of an array nesting all the music fans that have rated the album.

NOTE: We don't need to include the through: :ratings here because we have already established that association in our model.

One cool element to serializers is that you can create your own custom ones if you need to have more specific data outputs for particular CRUD actions. I won't go into that here, but I recommend doing some research on it!

Now that we've established the importance of all our resources, we can tie it all together.

Tying it All Together

Jeez. Rails has a LOT of resources to keep track of, eh?? If we had to populate our back end with all of these resources one at a time, it would take awhile for sure. Luckily, we don't have to!

Generators to the Rescue

Rails has a generator feature that will create all of these files for us. However, there is room for error here, so it's very important to understand all the resources that are created by the generator, and how to check these resources for errors. Let's take a look at what the generator commands for each class will look like in our terminal, and then break them down. First, here is the basic formula, as mentioned at the beginning of this article:

rails g resource class_name attribute_name:attribute_type --no-test-framework

NOTE: Include --no-test-framework if you already have testing files and want to avoid overwriting them.

And now our specific class examples:

Rating

rails g resource rating score:integer music_fan:belongs_to

MusicFan

rails g resource music_fan name

Album

rails g resource album title artist

NOTE: The default attribute_type is string, so unless a particular attribute is something else, such as integer, you don't need to actually include the type in your resource generator.

OTHER NOTE: As far as associations, we can only include belongs_to in our resource generator, and need to manually create our has_many associations later on in our individual models.

As you see upon execution in your terminal, this command creates ALL of the resources we have gone over in this article. Pretty cool! If you did this command the right way, you're well on your way to customizing your back end.

I hope this article was helpful, and as always...

Happy Coding!

Beginner's Guide to Ruby Methods

Michael Davis — Mon, 09 Jan 2023 07:34:48 +0000

If you're like me, you've only recently begun your journey into working with back-end coding languages. For you, it might be Python, C#, PHP, or even JavaScript. But for me, it has been Ruby.

As a current Flatiron School student, I just finished up Phase 3 of the full-stack software engineering curriculum, which was built around a comprehensive introduction to Ruby. We learned how to:

Create migrations for back-end data structures
Migrate those data structures to create a data table
Seed the table's data using class models
Create custom methods within those class models, in order to manipulate the data
And use Sinatra to handle CRUD actions

Remember that CRUD stands for (with corresponding Ruby commands):
Create - post
Read - get
Update - patch
Delete - delete

All of these skills are very helpful, both functionally and conceptually, in furthering one's understanding of programming and how to practice it with confidence! I, for one, am pretty excited to now have experience with handling tasks that require these things, BUT...

Ruby has a lot of built-in methods 😐

And it can sometimes take a lot of searching to find the right ones to use...

If your first exposure to data manipulation was in JavaScript, the transition to doing similar things in Ruby can be a bit overwhelming without a guide to the most essential methods that you might use in the process. Therefore, I decided to create one!

So...

Custom Ruby methods can target one of two scopes:

Class Methods, which affect all instances built from a particular class model
Instance Methods, which affect only one particular instance of a class model

The difference between an instance method and a class method involves the simple addition of a "self." to the front of the method name. For example:

def self.class_method_name
   logic_applied_to_array_of_class_instances
end

VS.

def instance_method_name
   logic_applied_to_instance
end

Now that we've distinguished the difference between Class Methods and Instance Methods, let's take a look at Ruby's...

Built-In Methods

By definition, Ruby's Built-In Methods are methods that are already built into the Ruby code, thus allowing the programmer to use them immediately, as elementary tools to build out more complex/specific custom methods.

Built-in methods allow us to do simple tasks like filtering lists, sorting items, finding a particular item, and checking/comparing the values of multiple different items. When we are dealing with data sets that have many items (or instances) containing a variety of key-value pairs, it is important to have these built-in shorthand methods to quickly accomplish the aforementioned simple tasks.

But what ARE these methods? Let's break it down.

To get started, it might help to have some sample data. To accomplish this, I used Active Record to make a table of randomized movie rating data with many movies and many critics. There are three models: Movie, Critic, and Review. Feel free to clone my example repo and try these methods out for yourself!

Don't forget to:

bundle install
rake db:migrate db:seed
use a table explorer like SQLite to verify your database was populated
rake console when you want to test out your methods

Once you've done steps 1-3 above, you should be looking at three simple tables similar to this:

Movies

Critics

Reviews

Alright, that's enough setup. Now that we have data to manipulate, we can try out our methods!

array.map

Let's say we want to take our critics and add a last name to all of them, using the ever-useful Faker gem. The method definition is going to look like this:

  def self.add_last_name
    full_names = self.all.map{|critic|
      critic.update(name: "#{critic.name} #{Faker::Name.last_name}")
    }
  end

Here, we are using self. at the beginning of this method name, because this is a Class Method, intended to affect all instances of a particular class. You can certainly use .map on smaller arrays of instances, too but our goal here was to use all the instances in this class. So, this map is stepping (iterating) through the array of instances and applying the change to each and every one. We can test out this method in our console by typing rake console in our terminal (step 4 from above), and then entering this code:

Critic.add_last_name

This should return a bunch of lines and successfully update our database so that all the critics have last names now. Refresh your database viewer to make sure the updates went through!

array.filter

Let's switch over to the reviews table now. If we want to know all the ratings of only a particular movie, we can .filter all our reviews by the movie_id key. Here's what that method definition might look like:

  def self.filter_by_movie(movie_id)
    self.all.filter{|review| review.movie_id == movie_id}
  end

Again, we are using self. upfront because we are filtering down from all instances of this Review class. This filter is stepping through and checking each review instance's value for movie_id and checking it against the one passed in as an argument when the method is called, removing if this returns false. We test by entering rake console again and typing:

Review.filter_by_movie(1)

...and this should return a new array of review instances that have a movie_id of 1!

.order

What if we wanted to sort all the reviews by rating? For that, we use .order, and with it we have a couple options. If we're using integers, it will order numerically from lowest to highest (ascending) by default. In the method, we must specify the key we wish to order the instances by, which will of course by our rating. Let's check it out:

  def self.order_by_rating
    self.all.order(:rating)
  end

Yet again, we are appending self. to the front of the method name to specify that we are looking to sort all instances of this Review class. And we passed in :rating in symbol format to follow the syntax rules for the .order. Open up your rake console again and test with this code:

Review.order_by_rating

This should return a new array with the same number of reviews, but they will be ordered from lowest rated to highest rated! If you wish to order the reviews descending instead, simply replace the content inside the parentheses with rating: :desc!

I have run out of time to finish this article now, but I will be returning to talk about these methods as well:

.max_by / .min_by

.sum

.count

.create

.find / .find_by

.istrue? / .isfalse?

.destroy

Thanks for reading, and happy coding!

React Router for Dummies

Michael Davis — Sun, 11 Dec 2022 03:00:29 +0000

Greetings, Friends & Fellow Devs 👋

I really hope you didn't take the article title for an offense, because if you're pursuing a career (or even a side-hobby) in software engineering, you're most certainly not a dummy, and I have great respect for you. And if you aren't pursuing software engineering, then I highly recommend it, because there are great benefits and we've got jackets.

Not to mention, the original working title was:
<ReactRouterForDummies onRead={changeDummyToSmarty} />

Anyway...

As of the publishing of this article, I am a late-Phase-2 student of Flatiron School's Software Engineering bootcamp, heading into Phase 3. This program is a full-time, intensive, no-nonsense run-through of both front-end and back-end web development technologies. At this point, we have accumulated a comprehensive understanding of the way JavaScript, HTML, and CSS can all work together to render sleek & responsive websites, similar to the one you're seeing at this very moment!

Let's Talk About Frameworks

One way to shape this complex tapestry of web dev languages is through frameworks. A programming framework is:

"...an abstraction in which software [...] can be selectively changed by additional user-written code, thus providing application-specific software. It provides a standard way to build and deploy applications and is a universal, reusable software environment that provides particular functionality as part of a larger software platform to facilitate the development of software applications, products and solutions."¹

Pretty cool, right?

Frameworks provide a TON of additional efficiencies and functionalities that are a distant fantasy for vanilla (plain) code. And truly, frameworks are the logical next step once you have a solid understanding of the underlying languages & logic beneath them. And that brings us to our topic for this post: The React framework, and more specifically...

React Router

React Router is an extremely capable tool, allowing a React web app to accomplish the goal of client-side routing, which manifests a dynamic website hierarchy based on the content and components within that app. Through React Router, a web developer is able to:

Easily create a well-organized domain extension hierarchy
Eliminate the need for a new server request upon navigation between pages within that domain
Generally boost the speed and clarity of the user experience

Time to Break It Down...

Routers

If you're setting up React Router for use in your web app, you'll need to start by importing your router component itself, in the form of <BrowserRouter> or <HashRouter>. More information on the differences between those here.

Next, you'll need to "wrap your top-level <App/> component" in this router component "at the root of your element hierachy"². This should happen in your index.js file, which should look something like this:

import React from 'react'
import ReactDOM from 'react-dom/client'
import { BrowserRouter } from "react-router-dom"
import './index.css'
import App from './App'

const root = ReactDOM.createRoot(document.getElementById('root'));
root.render(
  <React.StrictMode>
    <BrowserRouter>
      <App />
    </BrowserRouter>
  </React.StrictMode>
);

NOTE: You can apply a short name to longer-named imported modules using as, which will clean up your code a bit. You can use whatever short name you want, but it's obviously best to make it relevant. The code above can be made a bit simpler with this tool, importing like so:

import { BrowserRouter as Router } from "react-router-dom";

...and replacing the component labels with that short name.

<Router>
  <App />
</Router>

Once you have properly incorporated your Router into your root component, you are then ready to move down a level in your element hierarchy and start building out the Router's functionality in your <App/> component!

Route Matchers

To efficiently create the website's URL hierarchy within the Router, you employ the use of Route Matchers, of which there are two required components: <Switch> and <Route>.

Remember: We have to start by importing both of these components at the beginning of App.js before we can start building them out.

import { Switch, Route } from "react-router-dom"

<Switch> is the parent container component here. It tells our app to read the information within it as Route Matching information. As you might have predicted, that information is comprised of child components: these are the <Route> components.

Just like <Switch>, <Route> is also a container component, inside which you will place the components you want to be rendered upon the activation of that particular Route. Additionally, you will need to include a path prop in the opening tag for each <Route>. The path prop will instruct the browser on what URL extension will be added to the domain name when that particular route is activated.

You can now fully build your Route Matching in the <App/> component, like so:

import React from "react"
import { Switch, Route } from "react-router-dom"
import Header from "./Header.js"
import Home from "./Home.js"
import About from "./About.js"
import ContactInfo from "./ContactInfo.js"
import ContactForm from "./ContactForm.js"
import Footer from "./Footer.js"

export default function App() {
  return (
    <div>
      <Header />
      <Switch>
        <Route path="/about">
          <About />
        </Route>

        <Route path="/contact/form">
          <ContactForm />
        </Route>

        <Route path="/contact">
          <ContactInfo />
        </Route>

        <Route path="/">
          <Home />
        </Route>
      <Switch>
      <Footer />
    </div>
  )
}

Make sure to place the components with the least specific pathways last, so that the browser can properly select which pathway you're actually trying to reach. For example, <Home/> is listed last because the pathway of "/" happens to be the starting character to each route path. So if you're routing to <Home/>, the <Switch> recognizes that there is nothing else after the "/", it skips over every other <Route> component until the one that only has "/", which will then render <Home/>. This same logic is why the route with <ContactForm/> (a component you want to be interpreted as a sub-branch of "/contact") is listed BEFORE the route with <ContactInfo/>.

NOTE: If you'd prefer to order things differently, perhaps for readability's sake, you can pass the exact prop to the particular <Route> component. This instructs the app to look for the route with that exact pathway, no matter where in the <Switch> it is placed.

Okay... You are almost there. You just need one more tool to complete the React Routing puzzle.

Route Changers (aka Navigation)

Now that you have set up your route pathways via <Switch> and <Route>, you can now place your Route Changers. These components show up in the form of <Link>, <NavLink>, or <Redirect>. All of these components have the power to change currently rendered components, based on the routes you've created in the <Switch> component.

Route Changers can be placed anywhere in the app, and they all require a to prop, which needs to have a corresponding value that matches the path given to the route you're trying to switch to. If this is done successfully, the route will change and the desired components will render on the page.

<Link> is the route changer with the broadest functionality. It simply creates an <a> element on the page that has an href attribute equal to the value of the to prop. This tag changes the route to the one with that matching path. You could create <Link> components for all our routes like this:

import { Link } from "react-router-dom"

export default LinkExamples() {
  return (
    <div>
      <Link to="/">Home</Link>
      <Link to="/about">About</Link>
      <Link to="/contact">Contact Information</Link>
      <Link to="/contact/form">Contact Form</Link>
    </div>
  )
}

...Pretty straightforward!

On the other hand, <NavLink> is a route changer with a more specific purpose. As the name implies, this component is meant to be included in a navigation bar. In addition to changing the current route the same way <Link> does, it also has the ability to change its appearance based on its status of being the currently active route. That's why this component needs both the props to and activeClassName. When the corresponding route is active, the <NavLink> will adopt the class name equal to the value of that activeClassName prop. It is best practice to just nest these components in a navigation bar component, perhaps called <NavBar>. This is what that component might look like:

import { NavLink } from "react-router-dom"

export default NavBar() {
  return (
    <nav>
      <NavLink to="/">Home</Link>
      <NavLink to="/about">About</Link>
      <NavLink to="/contact">Contact Information</Link>
      <NavLink to="/contact/form">Contact Form</Link>
    </nav>
  )
}

<Redirect> is the last route changer, designed to force navigation based on certain client conditions, such as whether the user is logged in and should be able to access only certain paths. I will not demonstrate this one here - perhaps another time!

Lastly, links can be used to render a route dynamically, using an id prop and fetching a specific data object based on that, to be used in the rendering of this route. The id is formatted into the <Link> like so:

<Link to={`/contacts/${id}`}>Contact Information</Link>

In Summary...

React Routing is an efficient way to create a dynamic web app for your users. If you haven't started using this powerful tool, I highly recommend it. I hope this article has helped React Router seem more straightforward.

Happy Coding!

Sources

¹Wikipedia
²Primary Components

The Case for Function Trees

Michael Davis — Fri, 18 Nov 2022 21:21:57 +0000

A little intro...

I am currently enrolled in Flatiron School's Software Engineering bootcamp. At the time of posting this, my cohort is finishing up Phase 1 of the program (JS Basics) and preparing to enter Phase 2 (React Framework). In light of this, I think it's a great time to review some productivity tools!

Whether you are a beginner, jr., or sr. dev...

You've likely been involved in countless projects (software or otherwise) where there is a clear set of expected deliverables at the end of the project. You've also likely come across a myriad of different productivity tools to help build a roadmap for executing these deliverables. These tools might include:

Flow charts
Layout diagrams
Outlines
Word webs

In software engineering...

Visual and conceptual productivity tools come in handy at different times for different goals, tasks, and audiences. Therefore, it's very important to understand what tools are useful to you and your teammates, dependent on the circumstances. Knowledge of the strengths of each tool can yield huge improvements in operating efficiency by reducing the need for clarification.

As I mentioned in my intro...

I am entering Phase 2 of my coding bootcamp, which will cover the React Framework. From what I've been told, React engages a more conceptual approach to development, as opposed to the syntax- and fundamentals-heavy stages of learning the web development basics.
Though I'd never rule out the use of any of the aforementioned productivity tools, I have a feeling that I'll be using one other tool more often: THE FUNCTION TREE

According to Wikipedia...

"A function tree is a diagram showing the dependencies between the functions of a system. It breaks a problem (or its solution) down into simpler parts. When used in computer programming, a function tree visualizes which function calls another."

So, I could see this being a very useful tool for taking the list of deliverables, and:

Conceptualizing the functions
Figuring out the order of function declaration
Mapping out the functions based on priority, scope, nesting, variable reassignment, etc.
Be able to refer back to this and possibly rearrange the function tree or create multiple function trees to cover different branches of the project

...and do all of this in a way that is easily communicable across an entire project team. 10/10

In conclusion...

I'm looking forward to using this function tree visual tool as I learn React and beyond!

Sources(LOL):
https://en.wikipedia.org/wiki/Function_tree