Forem: Justin Saborouh

Slicing

Justin Saborouh — Mon, 12 Dec 2022 02:46:27 +0000

When first developing a website, developers would sit together, think of the idea/purpose of the application, then sit through to discuss database schema, front end styling, back end functionality, etc. Essentially splitting up each big "chunk" of software to design and detail the purposes and minimum viable processes it would require and handle.

The Horizontal Slice

The above references typical software development planning as horizontal slicing. This isn't a bad approach, and seems fairly practical for development work split amongst a dev team. The only concern is that it does not consider the user's experience and interaction with the product, or as it's called the User Stories. In agile development, especially where the end product is meant for millions of users, it is wise to prioritize and pivot the perspective of development towards the User Experience.

Splitting your code up into functional layers, like how the cake presents, is great to cleanly organize what and how certain programming is done, but in the end you can imagine that a horizontally sliced cake does not give a user an even bite of the entire product.

In more practical terms, issues that arise with horizontal slicing include

A stakeholder not being able to see progress/parts of the project until it is completely finished
Feedback from the stakeholder can change the product entirely if one small feature doesn't match (since the entire app was already an Minimum Viable Product (MVP)
Evaluation of smaller user stories is delayed until all parts are completed, which hinders data scientists' ability to evaluate success

The Vertical Slice

The main aspect of vertical slicing is thinking in "slices" of user stories. For example, first develop a login/signup feature that stores the encrypted data in the database and can hash it when needed, while simultaneously routing the frontend to handle unauthorized users to a signup page and redirecting them once authorized.
This approach allows you to work on all aspects of the app and only develop what is needed for that initial vertical slice. The backend is developed enough to handle new and existing user calling, and the frontend can handle routing and redirecting from a home page and signup page, vice versa.
This also yields a better showcase to the stakeholder, only showing the minimal pieces developed in perspective of the user so that when the inevitable rash and absurd changes are asked for, it is slightly tolerable since there is less of the app to "rework"

Other benefits include

Data scientists being able to evaluate a lot earlier
The dev team being more aligned with the stakeholder's ideals and needs without completely forfeiting their own ideals of how the product works behind the scenes.

Conclusion

Both flows of development are great in their own regards. I would even suggest horizontal slicing if you are making a simple app for yourself. But for larger scale, and especially in teams, vertical slicing seems to cover all grounds of management error while still progressing your code

Resources

Data Science Process Alliance https://www.datascience-pm.com/vertical-vs-horizontal-slicing-data-science-deliverables/#:~:text=Traditional%20software%20approaches%20favor%20developing,value%20streams%20(vertical%20slicing).

Visual Paradigm https://www.visual-paradigm.com/scrum/user-story-splitting-vertical-slice-vs-horizontal-slice/

mondayBlog https://monday.com/blog/project-management/vertical-slice/

Rails Restful Routing

Justin Saborouh — Thu, 17 Nov 2022 10:59:41 +0000

When building an interactive full-stack website, there are going to be cases where the user communicates with the server, and the server has to respond with or update the corresponding data. In the simplest of applications, it's the reason why a user can create, read, update, and destroy (CRUD) particular pieces of data.

This is one of the many fundamental properties that Rails simplifies for us in web applications. The User sends a request to the Controller, which manipulates the request to be interpretable by the Model so it can update the View and present it back to the User.

What is REST?

REST is REpresentational State Transfer which references an architectural design flow/pattern when routing your HTTP requests. Often times, requests like GET, POST, etc are used more than once for a certain controller and the definitions for each varying GET or POST request will look and execute messily. To avoid this, the rails backend structures 7 specific route names that translate the HTTP request smoothly once defined in the specific controller.

For example, a lot of GET requests without this convention are written in Sinatra with

class ApplicationController < Sinatra::Base

  get '/games' do
    games = Game.all
    games.to_json data
  end

end

As you can see, to satisfy a simple SELECT * statement, a get request is used and must used over and over again to specific different types of get requests.

Route Setup

In your routes.db in your Ruby application, this is where the specifications of the different routes per controller are defined.

Rails.application.routes.draw do
   resources :games
end

Having no particular declarations after the :games attribute has rails interpret all 7 routes to be implemented. If you only wanted to have a CREATE route, then you would add

Rails.application.routes.draw do
   resources :games, only: [:create]
end

Index | Show

Index and Show in a RESTful context both reference the GET HTTP pull method. Index would list the entire index of a certain table, and Show would represent only one row of that table

In routes.db, further clarification is needed

Rails.application.routes.draw do
   resources :games, only: [:index, :show]
end

In the controller for the respective class (in this case, a game_controller.rb file), the implementation is

class GameController < ApplicationController
   def index
      render json: Games.all
   end
end

Here, we tell the database to get all indices of a table and render them back to the Model
You can also tack on a status code if need be

render json: Games.all, status: :ok

Show represents the GET HTTP method as well, but with a parameter (typically an ID of the index you'd like)

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

If you need to cover for the situation in which the ID wasn't found then you can nest it in an if-else scenario

def show
   game = Games.find(params[:id])
   if game
      render json: game, status: :ok
   else
      render json: {error: "Game not found"}, status: :not_found
   end
end

Create | Update | Destroy

Once again we specify our routes.db to include these HTTP requests

Rails.application.routes.draw do
   resources :games, only: [:index, :show, :create, :update, :delete]
end

When creating entries, rails can not automatically assume the contents of a POST request, we need to re-orient the parameters so that the body of the post request can be interpreted to create new entries
Adding this wrap_parameters declaration tells rails to re-format the data into a [] array-like format, so that we can break apart what was sent and see if there are extra, or lacking pieces of data

class GameController < ApplicationController
wrap_parameters format: []

The CREATE request is defined as follows

def create
   game = Games.create(game_params)
   render json: game, status: :created
end

private
def game_params
   params.permit(:name, :publisher, :release_year, :console)
end

The game_params function takes the params and assigns each attribute to be returned as parameters, so it is properly formatted when passed into the create function

Update would replicate the show route but with a small change when rendering

def update
   game = Games.find(params[:id])
   if game
      game.update(game_params)
      render json: game, status: :accepted
   else
      render json: {error: "Game not found"}, status: :not_found
   end
end

Destroy would be similar to above as well, the only niche is that since there isn't necessarily any data to render back to the Model, you would return head :no_content

def destroy
   game = Games.find(params[:id])
   if game
      game.destroy
      head :no_content
   else
      render json: {error: "Game not found"}, status: :not_found
   end
end

Conclusion

Overall, as fundamentally standard CRUD is across all forms of database management/administration, the only extra step needed when adapting to new environments is following the conventions. New and Edit would require a form to be presented and rendered, in which case the Create and Update definitions would be invoked afterwards.
Happy CRUDing!

References

MVC: Model, View, Controller (https://www.codecademy.com/article/mvc)

ThoughtBot: REST Tutorial (https://thoughtbot.com/upcase/videos/rest)

RailsGuides: Rails Routing (https://guides.rubyonrails.org/routing.html)

MakandraCards: wrap_parameters for your API
(https://makandracards.com/makandra/46405-rails-wrap_parameters-for-your-api)

SQL and Table Relationships

Justin Saborouh — Wed, 26 Oct 2022 18:56:26 +0000

SQL, or Structured Query Language, is the standard language most programs use to CRUD data. Common database structures like SQL Server, Oracle, MongoDB, mySQL, etc use a table-like format with rows and columns to organize data, and since there will be multiple tables with differing representations, it is important to understand how to join and relate these tables together to have efficient, smoother data.

Some examples of SQL CRUD code include:

CREATE TABLE Persons (
    PersonID int,
    LastName varchar(255),
    FirstName varchar(255),
    Address varchar(255),
    City varchar(255)
);

SELECT FirstName, LastName
FROM Persons
WHERE city="sacramento"
ORDER BY LastName ASC

UPDATE Persons
SET Address="N/A"
WHERE city="The Moon"

DELETE
FROM Persons
WHERE city="The Moon"

When planning to make multiple tables and numerous relationships in a schema, it is important for your tables to have a primary key when being created. A primary key is typically and ID that is used to keep track for linking entries between other tables. Once that ID is referenced in another table, it becomes a foreign key.

In this schema example, the first table showcases dog names as the primary key along with string inputs for the Dry/Wet and Good-Boy columns. The second table has tag numbers with certain dogs' measurements. When these primary keys merge with the final table at the bottom, they are referenced as foreign keys that reference an entirely different table when followed through.

Depending on how these tables reference each other, you can imagine there would be different types of relationships.
There are two main types of relational databases in SQL

One-To-Many is fairly common in most schemas, and represents that a record in table A can be seen multiple times if joined to another table B. For example, if there is a large list of employees as Table B, and in that table has a foreign key of which supervisor advises a certain employee, you could imagine in a supervisors list as Table B, multiple supervisors would be referenced multiple times, spanning multiple employees.
Many-To-Many is very similar to one-to-many, but using the same example, it would be many-to-many if each employee could have more than one supervisor
One-to-One isn't as commonly seen as one-to-many, as you can simply just join the tables together, but it showcases that a singular record from table A with only relate to a singular record in table B, not duplicates on either pathway of the relation

When simplifying your schema, it is important to understand how to join your tables properly so the correct relationships and information is recorded over. A join clause combines entries from multiple tables, relative to a certain column that is shared between them.

There are 4 main types of joins

The Inner join just returns a new table with matching columns from both tables.
The Left and Right joins will do the same but also include additional columns depending on which table was interpreted.
A Full Outer join just simply returns all the entries where a match is found on either table.

Sources
W3 Tutorials - SQL Joins
(https://www.w3schools.com/sql/sql_join.asp)

101 Computing - Relational Databases
(https://www.101computing.net/relational-databases/)

SQLShack
(https://www.sqlshack.com/sql-definition/)

TheSupportGroup
(https://blog.supportgroup.com/getting-started-with-relational-databases-one-to-one-and-many-to-many-relationships)

Data Fetching for Live React Apps

Justin Saborouh — Thu, 06 Oct 2022 07:52:21 +0000

When starting your adventure of web development and programming, most of the starter apps and concepts are understood through single-page, static applications. This means that these apps are going to be same no matter what machine it's hosted on, and don't typically require an internet connection.

However, as seen with most of our day-to-day applications, there is always a sense of live-updating and client-server interaction to give the user a unique experience when using these apps. This is introduced in React as Data Fetching.

The method of updating and populating data on a webpage is defined as an AJAX call. React applications have a built-in library for these calls called window.fetch. With this fetch command, we can make calls to gather additional data.

fetch('http://example.com/ingredients.json')
  .then((res) => res.json())
  .then((data) => console.log(data));

The first parameter pertaining to the fetch invocation tells React where to gather the information from. Prioritizing the destination to be a json file will return less steps converting the data received. The result isn't technically the json body but a promise that will eventually turn into a response res element that is converted to json format. Then, with the last .then statement, we can finally instruct what to do with the gathered data.

The first time we can appropriately program a fetch command is in conjunction with the useEffect() hook. After the first stage of a page rendering, which is simply loading the DOM elements and basic HTML, another 'reload' is ran where most components are rendered, as well as text content and image sources. Here is where we'd want to call the useEffect hook to gather any outside data we'd need to use.

import React, { useState, useEffect } from "react";
function App() {
  const [recipesList, setRecipesList] = useState([]);

  useEffect(() => {
    fetch("http://api.open-cooking.org/recipes.json")
      .then((res) => res.json())
      .then((data) => {
        setRecipesList(data.recipes);
      });
  }, []);

  return <div>{peopleInSpace.recipes((recipe) => recipe.ingredients)}</div>;
}

export default App;

The example code here let's us call a fetch during the initial 'second' load of a React application, sets the data to a readable json format, and adds the data to our state variable of recipesList.

Another time to call a fetch argument is during an event signal for any DOM element. Let's say you needed to retrieve and load data after a button or an event was clicked.

function handleClick() {
  fetch("http://api.open-notify.org/recipes.json")
    .then((res) => res.json())
    .then((json) => setData(json));
}

return <button onClick={handleClick}>Click to Fetch!</button>;

On click, the button will call a function that accesses data from a URL and assigns it to a state variable.

These are the two primary scenarios to call and fetch data from external sources. With this expanded perspective of react building, we can build slightly more advanced applications that are interactive with the user to alter and retrieve data.

Resources
AJAXs and APIs - React (https://reactjs.org/docs/faq-ajax.html#example-using-ajax-results-to-set-local-state)

Using the Fetch API - mdn web docs (https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch)

Using the Effect Hook - React
(https://reactjs.org/docs/hooks-effect.html)

Scope in JavaScript

Justin Saborouh — Tue, 20 Sep 2022 04:35:12 +0000

Scope in JavaScript, and in programming as a whole, is a cornerstone fundamental to grasp in order to:

Avoid any potential errors and bugs regarding undefined variables and modifications
Produce cleaner code that inadvertently manages and limits memory usage

Scope can be defined as the visibility of values and expressions that can be used in the current context. Most developers when first starting out typically have variables and expressions defined globally so there won't be any issues when just learning the fundamentals. However, over time when your code becomes more and more dense with many layers of pathing, there will be moments where you don't necessarily intend to execute every line of code because of overlapping or interference when accessing and modifying values (in a non-threaded context)

In JavaScript, there are 3 primary areas of scope

Global Scope
Any definition that is not under any function or block (the {} that contains code) is defined to be in the global parameter of scope. Anything declared globally can be used and modified anywhere

const greeting = "Hello World"
function sayHello(){
   console.log(greeting)
}
console.log(greeting)
//The greeting will be logged twice as it was accessed twice; 
//once in the function and another in the global scope

Function Scope
Definitions that are stated inside the block of a function. Only in the context of said function, are the declarations significant. Any variable created in the function scope can only be referenced in that scope. However, any modifications made to a variable above the level of this scope can be considered since the above rule applies for that scope's context.

let greeting = "Hello World"
function sayHello(){
   let newGreeting = "Hello Human"
   console.log(newGreeting)
}
console.log(newGreeting)
//This will result in an error despite a declaration of
//newGreeting, as the function was never called in a global
//scope

let greeting = "Hello World"
function sayHello(){
   newGreeting = "Hello Human"
   console.log(newGreeting)
}
sayHello()
console.log(greeting)
//Now there will be two logs to the function

Block Scope
Block Scope can be treated similarly to function scope, except variable declarations in a block scope can be referenced in children beneath the block. This scope is typically found in conditional statements such as if and switch cases.

function sayHello(name){
   console.log(`Hello ${name}`)
let gender = 'boy'

if (baby === 'boy'){
   let name = 'Mark'
   sayHello(name)
}
else if(baby === 'girl'){
   let name = 'Alice'
   sayHello(name)
}

//This example showcases the 'name' variable being passed down
//through the block scope to the function scope of sayHello

Overall, scopes should be learned through a hierarchical system, where the global scope is above the function scope, which parents the block scope. Variables defined through any scope should be predefined with the let or const tag, as the var tag can allow variables to be referenced in the scope's parents.

References

Scope - MDN Web Docs "https://developer.mozilla.org/en-US/docs/Glossary/Scope"

JavaScript Scope - Steve the Dev "https://www.stevethedev.com/blog/programming/javascript-scope-primer

JavaScript Variable Scopes - JavaScript Tutorial
"https://www.javascripttutorial.net/javascript-variable-scope/#:~:text=JavaScript%20has%20three%20scopes%3A,Block%20scope%20(started%20from%20ES6)"