DEV Community: James Macapagal

Understanding LeetCode Problem #1672: Richest Customer Wealth (JavaScript)

James Macapagal — Mon, 24 Oct 2022 22:51:27 +0000

Hey y'all!

I've been grinding LeetCode lately in preparation for Technical Interviews, and I wanted to walkthrough a solution to an algorithm that I was able to discover.

Algorithm

First off, here's a screen shot of the algorithm, Richest Customer Wealth.

1) Talk To Yourself

First off, in any algorithm, take a step back and ask yourself what this algorithm is actually trying to solve.

Take the time to speak the problem into existence, out loud, and with intent. Yes, even in a live/coding interview!

You want to showcase your ability to verbalize code, talk through it, and also indicate you didn't just memorize this (even if you maybe did ;) )

Start by asking yourself:

How would I phrase this in my own words?
What data or information do I know I have?
What is this problem actually asking me to do?

So, let's break down the prompt:

You are given an m x n integer grid accounts where accounts[i][j] is the amount of money the ith customer has in the jth bank. Return the wealth that the richest customer has.

A customer's wealth is the amount of money they have in all their bank accounts. The richest customer is the customer that has the maximum wealth.

Here's a rough recreation of my own thought process:

> Ok... wait, why do rich people need... ok... focus James... Ok.. Sounds like we have arrays... which could have other arrays in it... array all day amirite...focus james... and these bougie peeps, i mean banks, are asking me to find how much cheese is in their bougie peeps accounts... ahem... what's the total amount of money in each of those accounts which are those arrays... and then find out who got the most cheese... i mean moneys... i mean the maximum value...

(End scene... sorry, we like to have fun here...amirite?)

Speak and it shall be known

Just from speaking it into existence, a whole world of solutions open up for us.

Off the bat, we know:

1. We are dealing with Arrays.

Which is great because maybe now we can use built-in Array methods and/or solutions that Arrays give us by default (at least thanks in Javascript). At the very least, we know we are dealing with arrays.

2. We need to count that paper.

We know we need to find the sum of a numbers in an array. My first thought is a reduce method or some sort of for loop where we are simply taking the sum of all the elements of the array.

3. We need to find who got the most paper

Aka, we need to fine the maximum number of those sums. So, if I can get those sums, I know that there's this Math.max() method that JavaScript gives me that I could use which can be used on numbers... and also... arrays! #ArrayAllDay

And I haven't even touched my keyboard yet. I simply am planning my strategy and solution before I start.

But from taking this quick few minutes to breathe, think, and evaluate, I already know what I probably need to do:

Find a way to get the sum of the baby arrays within the big mama array (arrayception).
Put those totals into another array (papa array).
Find and return the maximum value of those totals (stack that cheese).

Jesse, Let's Code

Ok, so the part we all want to do. The coding.

I'm going to start with my solution and walk through it.

var maximumWealth = function(accounts) {
    let wealthArr = []
    accounts.forEach((account) => {wealthArr.push(account.reduce((a,b)=> a+b,0))})
    return Math.max(...wealthArr)

};

First, I initialize an empty array. I know I'm going to need an array to help me keep track of all the totals I'm going to sum.

Second, I use the forEach method. If you're not familiar with it, I highly recommend reviewing the method (and all Array methods), as I find them extremely helpful.

While I could go on, the TL;DR is it is basically a shortcut for a for loop. In humanspeak, for each element of the array, I want to do something.

Within the context of my algorithm, "for each" account within the "accounts" array, I am going to perform a function. Each account is the individual array of the account.

Which leads me to my function inside my forEach: a push method which is pushing a reduce method.

First, we are going to start "pushing" elements into my empty wealth array (wealthArr) with the push method.

Inside of the push method, I am using a reduce method.

Again, if you're unfamiliar, I highly, highly recommend reviewing the Javascript Array methods first. But, TL;DR, it is essentially another short cut for a loop that calculates the running total of an array.

In this instance, we are reducing all the elements of an array into one single value. We provide to the reduce method a function telling it how we want to reduce. In this instance, a simple function (a,b)=> a+b,0) where a and b are elements of the baby account array and we are adding them together (a + b), starting with value (0). The reduce method is going to perform that on all the elements of the baby account array until there are no more elements to add.

When we get to that singular value, we will push that into my wealthArr array.

And finally, going back to my 3rd point, I need to return the maximum value. So, I am taking my wealthArr which should have elements populated, and then calling the Math.max() method.

Pass The Talk Test

If you have the time, I highly recommend talking through a test of your solution. So, let's test this!

First, let's set grab one of the test accounts arrays that LeetCode gives us.

accounts = [[1,5],[7,3],[3,5]]

So, first, we are going to create an empty array called wealthArr. Simple enough.

wealthArr = []

And then we are going to call our forEach method on the accounts array, which is going to sum up every single value in one of those baby account arrays.The forEach is then going to start pushing into my empty wealthArr array the sum of each of those accounts, using my reduce method.

Each of those accounts are the individual arrays. The forEach is going to iterate through each of the elements of my accounts array and do stuff to them.

account1 = [1,5] 
account2 = [7,3] 
account3 = [3,5]

So, for instance:

account1 = [1,5] =>  1 + 5 = 6
account2 = [7,3] =>  7 + 3 = 10
account3 = [3,5] =>  3 + 5 = 8

So, at this point, after going through each of those accounts, I should have the following:

wealthArr = [6,10,8]

And then finally, I return the maximum value of the newly populated wealthArr. Be sure to use the spread operator (...)!

return Math.max(...wealthArr)
// return Math.max([6,10,8)
> 10

Voila!

Now, you could do this without array methods, using a regular for loop and creating your own running sum. There might be some interviews where they won't let you use built-in methods (which... is a discussion topic...)

That said, I highly recommend utilizing every tool at your disposal, and I find array methods both easier to understand, faster to implement, and also showcase your abilities in the language.

Enjoy, good luck, and please reach out if there are any questions!

Bonus: Time and Space Complexity (Big O)

The Time Complexity is O(n x m) or O (nm)
The Space Complexity is O(1)

Now, I do want to touch upon this for this algorithm, even though I am admittedly not an expert on Big O notation, since it's always important to know.

I like to think of Time Complexity as asking the question: how many operations am I performing on each input?

In this instance, I know I'm performing the following:

A loop (via my forEach method which is a looping method)
In each element of that loop, I'm performing another looping method via my reduce method.

For 1 and 2, we are performing one operation on one input (n) and then performing another operation on another different input (m).

As n grows, m could grow too. As m grows, this affects n as well.

In plain English, think of it this way:

The more accounts (arrays) we have, the more looping we have to do. The more numbers in each of the individual accounts we have, the more adding we have to do

This makes the Time Complexity O (n x m)

If we were doing another forEach within my original forEach, we'd be doing the same n operation, which would lead us to O(n * n) which is (On^2). Or if we needed to find a specific account/array, that also adds more complexity.

The Space complexity is O(1) which is constant. This means we are not creating more space the more we perform this function. If we were somehow saving the wealthArr into another array of arrays, then that would increase space complexity.

How to Seed Your Rails API with an External API

James Macapagal — Sun, 31 Jul 2022 19:15:00 +0000

As part of Phase 4 of Flatiron School's Software Engineering bootcamp, we are tasked with building a full-stack application, including standing up an API with Rails to communicate with a React client application.

Up until this point, most of our test data has been using either Faker to generate seed data, or by creating our seed file from scratch.

But, as you can imagine, both of those strategies have their drawbacks.

With Faker, your quality of test data is limited by the ability of the stock Faker data, or by customizing your own Faker data.

With scratch-baking your seed data, it can get tedious and your tests are further skewed by the fact that you are creating the test data you are testing.

But what if I told you that you could use an External API to seed your seed data?

There are a few other services, but I used RapidAPI and specifically RAWG API which has a ton of APIs to use.

I promise it's not that hard, and it'll be fun!

Assumptions

1) You have a RapidAPI and RAWG API account
2) You are using Ruby on Rails and are using at least version 2.7.4
3) You are familiar with Ruby on Rails, Ruby Gems,and migrating and seeding a Rails API.
4) You have the HTTP/REST concepts.

Additionally, I used the RAWG API, so I will show the steps I used for that API; however, other APIs may have different instructions and steps. I would highly recommend reading the documentation for the specific API you are using as they may recommend a different process.

Step 1: Get a API key and API Endpoint

First, I registered for a free account with RapidAPI and then RAWG. This allowed me to get an API key, which is necessary for accessing their API.

(If you don't know what an API key, I would recommend reading this article for a brief overview)

On RAWG, I was directed to their API homepage, which presented a big fat "GET API KEY" button.

You might need to enter in some basic information about why you are using the API and provide a URL (I provided our GitHub repo).

After you finishing any of these admin tasks, you should be presented with the following page (I blacked out my personal key and info for obvious reasons):

Copy the value in the "API Key" field save that somewhere safe. Do not share this with anyone. This is the key your application will use to request data from your external API.

Step 2: Get your API Endpoint

Next, you'll need to get your API endpoint. This is where your mileage may vary from RAWG, but RAWG gives you their endpoint straight up on the RAWGAPI homepage:

Save that endpoint as you'll be making a GET request to that URL.

Step 3: Install Gems

You'll need to install the following gems:

1) gem rest-client
2) gem dotenv-rails

Step 4: Create ENV and Update .gitignore file

There's some quick steps we need to take in order to let our code tap into the API.

1) Create an ENV file

You'll need to create a .env file and create a variable and assign your API key to this variable:

//.env file
API_KEY = <paste your api key here>

2) Update your .gitignore file

You'll need to add the following code to your .gitignore file. This file tells GitHub which files to "ignore" when tracking and pushing files to a repo. As you can imagine, we don't want to broadcast our API key to the interwebs, so this will give us a little security when we push our code.

//.gitignore file
.env

Once you've done these two steps, we are now ready to update our seeds file!

Step 5: Create your Seed File!

In your seeds file, drop the following code into your file:

1 require 'rest-client'
2
3 puts "Getting Games Data"
4   def api_key
5        ENV["API_KEY"]
6    end
7
8    def games_dataset
9        api_data = { key: api_key }
10        games = RestClient.get("https://api.rawg.io/api/games?key=#{api_data[:key]}")
11        games_array = JSON.parse(games)["results"]
12        games_array.each do |g|
13            Game.create(
14                title: g["name"],
15                genre: g["genres"][0]["name"],
16                platform: g["platforms"][0]["platform"]["name"],
17                image: g["background_image"]
18            )
19        end
20
21
22    end
23 games_dataset() 
24 puts "Seeding Games Data"

Let me break this code down line by line.

- LINE 1: I am requiring the rest-client gem. In a nutshell, this gem gives us access to simple HTTP/REST actions, such as GET, which let's us grab data from the RAWG API.

- LINE 3: Next, I've added a simple puts to the console to tell us what's going on (always a good practice to have!).

- LINE 4-6: Next, I have a method (api_key) that is grabbing my API_KEY variable from my ENV file.

- LINE 8: Then, the big one, my games_dataset method .... Here's what is going on top down:

- LINE 9: I am creating a variable and setting it to an object with key as a key and my api key as it's value.

- LINE 10: I am setting a variable and setting it equal to a method, RestClient.get, which is a method given to me by the rest-client gem that is a get to the API endpoint.

- LINE 11: I am making another variable and using the method JSON.parse(). This Ruby method turns a JSON array into a Ruby array.

- LINE 12 - 19: I am then using a .each method to iterate through the data and using the .create method to seed my data into the appropriate attributes that I need into my Games model.

- LINE 23: I am then calling my method, games_dataset(), so that this method runs when I run rails db:seed, and then also puts-ing to the console so I know when my data is finished seeding.

I would highly recommend throwing in byebugs everywhere during this process, especially to make sure you are pinging the API and getting data successfully in return as well when iterating through the JSON data for seeding your model.

Keep testing by running rails db:seed to ensure you data is seeding your db.

Step 6: Throw Your Hands Up and Yell "I am Invincible!"

...Because you've just seeded a database with another API!

No more Lorem Ipsum's and stock cat pictures from Faker, and no more copy-pasta seeding data.

Bonus Step: When You Deploy To Heroku

When I was deploying to Heroku, I ran into an issue when trying to seed my data in Heroku (heroku run rails db:seed)

I was getting the error RestClient::Unauthorized: 401 Unauthorized.

After some troubleshooting (and help from one of our awesome FI instructors), the issue was that Heroku was trying to seed data from RAWG but wasn't using my API_KEY.

My API_KEY was stored in my .env file which was being ignore in my .gitignore file.

This caused an issue because Heroku takes your latest push to your main branch in GitHub.

Since the .gitignore file is ignored when pushing to GitHub, Heroku was not picking up my API_KEY to use when pinging RAWG.

FIX:

When you first deploy to Heroku, you'll need to configure Heroku to set an environment variable for your API_KEY, similar to what the .env file was doing.

The steps in this wonderful guide on Heroku should help you out!

Conclusion

While this is obviously specific to RapidAPI and specifically RAWG API, the overall concept of this should remain the same for any external API you might use.

To recap, we are doing the following:

Using an API key and Endpoint to fetch data from an external API
Iterating over that data and throwing those values into the attributes of our model.

While the endpoint and key may differ by the different API you might use, this is the basic idea of what we are doing.

There are obviously other ways to do this depending on the languages you are using, but the core concept of "hey, get me data!" remains the same.

I hope this tutorial was helpful, and, from these seeds, may you grow a strong ~~tree~~ database.

You Down with O-O-P?

James Macapagal — Mon, 11 Jul 2022 23:49:28 +0000

Object-oriented Programming.

Sounds so fancy, huh?

It sounds like something out of Star Trek:

DATA: My neural network is fluid, whereby thoughts are attributes of a certain class and subroutines stored like methods.
LA FORGE: Not unlike object-oriented programming?
DATA: Precisely.

(I'm a huge TNG fan, so come at me with the Trek)

It's a term that gets thrown around a lot, and it sounds like something super technical.

(Anecdotally, my wife (who is not a programmer), listens to a Sleep Podcast which is just some dude reading Wikipedia articles. Object-oriented programming was one of them.)

But, as I wrap up Phase 3 (of 5) in Flatiron School Bootcamp, I want to attempt to explain object oriented programming to both my wife and to the five people who will invariably read this 9 years from now.

An ELI5 (explain like I'm five) if you will!

So, come along, stay for the memes and gifs, and really, maybe OOP was just the friends and lessons we learned along the way...

What the heck even is Object-oriented programming?

At its most basic, Object-oriented program is a paradigm- a way of programming. It's a way of specifically programming objects. So, quite literally, programming that is oriented toward the programming of objects.

That's it.
Blog over.
Pay me $150,000, Mark Zuckerberg!

(Just kidding!)

While this definition sounds simple, the concept of it is what is more important (and consequently harder to grasp).

In layman's terms, we want to build things to build other things for us. This is better than building something from scratch every single time we need them.

Because, while we can program objects, it is what we do with those objects is ultimately what's most important.

Before I get deeper into the technical aspects, like my hypothesis states, I want to give ELI5 example of OOP.

So... let's begin...

Legos... My Favorite Toy!

When I was a little kid (and arguably, still am...), my favorite toys were Legos (and video games, which, I'll get to!).

Now, if you've never built a Lego, it's literally pieces of plastic bricks and a set of instructions in a box. You take out the pieces and they're in no order particular order. You read the instructions, and the instructions are neatly laid out in the following format:

An artist rendering of the final product.
A page showing all the pieces included in the box.
A step-by-step guide showing you literally where to place each and every piece.

Patiently follow the instructions (and trust that they are right!), you'll eventually build the Lego!

Let's break everything down again, because I promise I will tie this back to Object-oriented programming.

In every box of Legos, there are:

An idea/picture of what this particular lego model is
Lego pieces.
A step-by-step instruction manual on how to build the Lego.

This makes it easy for any kid (or adult) to pick up a box of Legos and build it without any additional instructions.

The Opposite of Legos

Now, let's think of the reverse of what this process might be.

How annoying would it be for Lego if they didn't include that guide?

Every customer would either need to figure it out on their own just using the picture (cough K-NEX cough), or, perhaps even more annoyingly, ask Lego for instructions every single time.

OOP: Built To Last

So, let's regroup.

Object-oriented programming is a philosophy/paradigm of programming oriented toward the coding of objects, and we can use those objects to, well, build things!

Furthermore, we can create that code to create more code.

This is better than the reverse of that, which is quite literally, building things from scratch, every single time.

In (most) Object-oriented programming languages, programmers begin by writing classes, which act like blueprints for the creation of objects. Every time that blueprint runs, a new instance of that object gets created!

To tie back to my Lego example, think of a particular type of Lego model as a class, and every Lego box that gets created is an instance of that object.

For instance (no pun intended), I always loved the Lego trains. There was one particular model that I got for a birthday. It was a black and yellow one fit with a dining car, sleeper car, and, of course, a working engine car that propelled the train!

I was so excited. I had the bestest, most amazingest Lego train ever!

But... I got a rude awakening the next day at school. It turns out another kid in my school got the same Lego train model for their birthday!

Now... as much as I want to believe I was a unicorn-child that got the onlyest Lego toy in the whole wide world, I'm not idiot (probably).

My Mom probably went to the toy store, went to the Lego section, and picked a Lego train models off the shelf. My classmates parents probably did the exact same thing with the exact same Lego train model.

That lego Train model is a class - quite literally a model of this particular line of Lego trains. Each box of that model is an instance. Assuming every kid builds the train properly, the train will look identical to other kids who have the exact same one because of the instructions inherent to that toy.

Lego Island

Well, let's talk about one of my other favorite toys: video games.

And one of my favorite video games was Lego Island.

It's an old PC game that, you guessed it, is about being on an Island of Legos!

So, applying our new understanding of Object-oriented programming, Lego Island was probably built using Object-oriented principles.

Quite literally, the Legos in that game are their own classes. Each of those instances are the renderings of those classes.

The water. The Lego people. The buildings.

And each of these objects can interact with one another to provide for the interactive gaming experience that makes video games, well, fun!

Conclusion

So, why does this matter?

Object-oriented programming, while a bit harder to grasp initially, actually makes programming much more elegant and sustainable.

Moreover, it is the foundation for many of the most useful programming languages, such as Ruby, C++, Python and more.

While each language will have it's own syntax, Object-orientated programming sets the foundation for many programming languages, which ultimately makes it easier to learn and use them.

Sources:
https://en.wikipedia.org/wiki/Object-oriented_programming

The Gitfather, Part 2: The Prequel

James Macapagal — Wed, 22 Jun 2022 14:08:23 +0000

A long time ago, in a galaxy far, far away...

...Wait, wrong movie reference.

This is another post from the Gitfather, your all knowing and loving code zaddy.

I wasn't always the Gitfather though...

Before my current iteration as a Gitdad, I was a Business Analyst.

A strange role at the unholy intersection of code and clients.

Sometimes also called a "Product Owner" (and hopefully rarely also a Project Manager), the Business Analyst lives at the complicated marriage of business and technology, marrying the technical with the non-technical.

(They also get confused with Business Intelligence Analyst who actually analyze data sets, but that's a topic for another time...)

To be more blunt, I basically took an idea from non-technical ask ("we want this button to turn blue!") and broke it down into technical requirements that Developers could use.

Story Mode

While BAs do a variety of different jobs, one of the most important jobs was writing User Stories, which is essentially an update request to Developers.

If you're not familiar with what User Stories are, they basically are a summary of what a development update should do.

For instance, a ticket with user stories would probably look like this:

As a user, when I click on a button, it should change color from red to blue.

A search feature allows a user to hunt among various invoices if they want to credit an issued invoice.

The system sends a confirmation email when a new user account is created.

In essence, a user story should have a: beginning and an end. When something happens, this should happen.

Turn Up the AC

User stories are also usually accompanied by acceptance criteria which is a fancy term for "what completes a user story?"

Acceptance criteria are the lowest-level functional requirements.

So, in the above examples, the acceptance criteria for the user story might be:

GIVEN I am on the Home Page with a Button, WHEN I click on the "Return Home" button, THEN the "Return Home" button background color renders from red to blue.

GIVEN I am on Google, WHEN I enter an input into the Search bar, THEN I am able to view and browse results based on my search input

GIVEN I am not a registered/authenticated user, WHEN I register with a new account, THEN I am sent a confirmation email confirming my successful registration.

You'll notice that the acceptance criteria are structured using a "GIVEN... WHEN... THEN" statement. It sounds more "code-y", more developer focused.

It also sounds kind of like what the user story said, but in much more specific terms. This lays out a clear roadmap for what the Developer must complete in order for the update to be done.

Acceptance criteria and user stories all "ladder up" to one big project, usually called an Epic, which is the over-arching, bigger software update that is driving everything.

One Ticket To Rule Them All

Epics, User Stories, and Acceptance Criteria are major points of the Agile Methodology of Software Development.

The project lifecycle

While there have been literal textbooks written about Agile, the TL;DR is a project framework of completing software updates into manageable chunks.

There are many other methodologies, but, in my humble opinion, Agile is the most commonly used (and ripped off...looking at you Waterfall...).

Basically, breaking big updates into medium ones and those in to smaller ones, and so on, until you get to what would complete the update. And then working on those updates in 2-3 week "sprints" until the whole thing is finished.

Sometimes, The Requirements Ain't The Requirements

As Developers, we are unfortunately at the business end (pun intended) of all of this. We only get a neat list of to-dos and then we clock out and go play Apex Legends.

As a former Business Analyst, however, I feel like I need to let Developers in on a dirty secret: they really need to be at the business beginning of software updates.

Because, as my former Boss once told me:

Sometimes, the requirements aren't the requirements...

Sometimes, you'll be coding something that makes zero sense. Or might be totally unfulfilling or unworthy of your time.

And it's true.

That user story to "turn the button blue" probably came from the client who probably actually just wanted to update the button styling.

And then it telephone-d into this update where it's now a conditional rendering exercise versus maybe an exercise in updating the CSS.

Or sometimes, you'll deliver an update exactly as promised, and the client still won't be happy.

For instance, I had a client who wanted to make all their images have rounded corners. They were adamant about it.

Sounds easy enough, right?

Well, we did it, and, guess what, after we did, someone else at the client asked why we agreed to do it.

Because we basically spent valuable Developer hours doing this when there was a juicier project sitting there on the shelf.

Conclusion

Needless to say, you can see why I put my life as Business Analyst behind me.

But, while I love being a Developer, there are other things out there behind the scenes which can make our jobs good and bad.

While it should be our job as Developers to build the darn things, it's also our job, unfortunately, to question why we are even doing the darn thing in the first place.

Food for thought the next time you get a request for rounded corners on images.

Sources:
What is Agile?
Acceptance Criteria and User Stories

useState: The Hook Brings You Back

James Macapagal — Thu, 09 Jun 2022 16:56:53 +0000

I have a new found appreciation for The Facebook.

Whoops, I meant, Facebook- I mean Meta.

While I've been a Facebook user so long I can remember the "The", nowadays, I'm fascinated by React, the amazing JavaScript based framework developed and maintained by Meta.

Specifically, I am truly amazed by the wonderful tool developed in React called useState

useState is a Hook, a special type of function with the specific purpose of helping developers maintain state changes in applications.

The purpose of this blog is to identify:

Why State as a concept is important
How useState works
When useState is useful

useState of the Union

Before we jump right in, let's get philosophical and define what we mean by state.

What do we mean by, just the word, state, in real life?

If you said, Illinois, I would say: damn, I thought I turned off location services on my Facebook privacy...

Beyond a politically organized groups of peoples, when we say state, Webster's dictionary says:

mode or condition of being

It is what something is right now. It is also what something will be in the future. It's also what something was in the past.

For instance, right now in my iced coffee, I have ice. In the future, the ice will melt and become water.

In other words, the water is changing state. It's changing from one state (of matter) into another state.

Though basic, this is an important concept to understand, both in life and web development (which is obviously more important of the two).

When it comes to the technology, we want things to change.

We want things to change state.

We want to change the states of things.

Without changing state, technology (and life) would really be boring.

No likes.
No Candy Crush.
Nothing.

A cold, dark, and boring Internet with static applications.

Thankfully, we have handy hooks like useState to make things easier for us.

Well, what even is `useState` and why should I care?

Well, first off, rude.

Secondly, fundamentally, useState is just another function.

A special type of function called a Hook, created by React.

According to React, Hooks are:

functions that let you “hook into” React state and lifecycle features from function components

useState basically lets developers use special logic and features, already written for us!

Let's think about how we might change the value of a variable in vanilla JavaScript:

let x = 0;
console.log(x)
>> 0

function setX(){
 x = x + 1
}

setX()
console.log(x)
>> 1

Pretty straight forward.

We declared an initial value for variable (x = 0).
We performed an operation on that variable (x + 1).

We checked the value of that variable afterwards (x = 1).

But, what if I told you you can do those 3 lines of code in 1 line of code?

Enter useState

While there is some special magic that goes on under the hood, the basis of useState is still rooted within the same idea of maintaining a variable.

Like with many things in React, we need to import this tool before using:

import React from 'react';
import { useState } from 'react;

However, the magic of useState is in its simplicity.

Again, useState is just a function, but it is a special function that returns an array of just two elements: a State Variable and a Setter Function which we can define via array destructuring.

For instance:

const [ count, setCount ] = useState(0);

The State Variable's purpose is in its name: its the variable that we want to maintain our state within. So, count in the previous line of code would be analogous to x in our previous OG JS code.

The Setter Function is also exactly what it sounds like: it sets the State Variable. Again, analogous to setX in our previous example.

Finally, the useState() keyword invokes the Hook from React's vast library and then sets an initial value for our State Variable passed as a parameter to the function (in this case 0).

The difference in useState versus that of our OG JavaScript function is syntax.

We can use array destructuring to easily set these two items, State Variable and Setter Function, without needing to declare and redeclare the variables.

After declaring our two variables, we can then use them how we'd like in the rest of our code.

First off, we still need to define the Setter Function's purpose. In my above example, I created another function that I can call that will call my setter function.

   function increment (){
      setCount(()=> count + 1)
    }

So now, every time I invoke increment, it will call setCount which will update count which will now be set to the new value!

No re-calling the variable or redeclaring needed.

And now we can use both the State Variable and the Setter Function (via that helper function!)

But wait there's more!

useState will not only set our variables (and "func" on them too), it will also re-render any components (and any JSX/DOM elements) within those components.

Think about that. Just one component- not the entire page.

While this is in part thanks to React's virtual DOM, it makes for a more modular, cleaner, and prettier website.

Think about what you might need to do in OG JS to re-render a component with count.

Write some verbose function to keep setting your variables
Set and append ad nauseam all the HTML element with your new variables
Oh yeah, refresh the whole page

That already sounds like hundreds of lines of code for one element, not to mention if this needs to happen within other elements on a page or other pages.

The Hook Brings You Back

In conclusion, useState is revolutionary in its simplicity, efficiency, and application.

What probably would have been done with hundreds of lines of JavaScript (with a healthy dose of unnecessary HTML) can now be done with useState.

The useState hook, via some internal magic, a State Variable, and Setter Function, brings a component back to re-render whenever we need it to- all within an efficient, clean line of code.

In the words of the immortal song "Hook" by Blues Traveler, the Hook brings you back.

Sources:
Hooks Overview
Hooks System
React's virtual DOM

Bonus: If you really want to dive into the rabbit hole, this blog builds it's own React library and dives into how to write your own Hooks.

Advice From A Gitfather: Lessons on Version Control

James Macapagal — Fri, 03 Jun 2022 16:56:33 +0000

Hello, World!

This is my first blogpost as a future programmer! Woo!

I'm a baby-dev. A hatchling. A student.

An init() function of a programmer (sorry, I'm new and I'm still loving the ability to make try-too-hard Programming Jokes).

I'm a student enrolled in the Flatiron's Full-Time Software Engineering Program (Cohort 051622 represent!).

I'll be using DEV to document my learnings, share my bad dad jokes, and hopefully reflect on the lessons and friends I learned along the way.

And for my ubiquitous first post, I won't be waxing about an event listener I coded in JavaScript or how I centered a Div in CSS or anything related to actual code. There are a million angry StackOverflow replies out there for people to read, mess up, and copy-pasta.

No, for this post, I want to discuss this amazing new power I learned: version control!

You see, I was in a group project, and I volunteered as tribute to handle version control and Github.

Little did I know, it would push me down a path toward becoming...

I won't lie- I was scared.

I had never used Github before, and I had only heard about it in tellings as the bane of Programmers, Scrum Masters, and Product Owners alike.

What if I screwed up?
What if I ruined someone else code?
What if I broke the Internet?

And then I read Matt Eva's wonderful guide to Github. and it all became much easier.

While I won't copy Matt's wonderful work, who goes into incredible detail for the exact commands needed, I will share my learnings in my first foray as Gitfather of our project.

While Github is an amazing tool for version control, ultimately, I was responsible for using Github to, well, control the versions.

function versionCtrl(){
   controlVersion()
}

I like to think of version control in terms of a restaurant (I'm a huge foodie, so I always try to relate everything to food).

The way food gets created is incredibly analogous to how code gets deployed.

Let's think about how a restaurant cooks food:

The kitchen receives an order (also called a ticket).
The kitchen divides work amongst different stations.
The dish is worked and passed on at each station.
All stations finish and food is taken out to the customer.

In between each of these steps is a vital team member to a kitchen: The Expo.

In any (good) restaurant, the Expo is arguably the most crucial staff member to success. The Expo monitors each of the above steps and makes sure that each step of the dish gets completed so that no other stations get held (aka "in the weeds").

Much like food, code undergoes the same process:

An update request (sometimes also called a ticket) with deliverables gets created.
Programmers break down the deliverables and code.
Code gets merged so the next code session has updated code.
Once finished, the code is all packaged up and deployed as one complete package.

And, like an Expo, between each of these steps was me- the Gitfather.

I was responsible for making sure that each successful code update got merged to main and that our team was "handing off their dish" correctly.

Like an Expo, I was responsible for reminding team members to cook our food (code) using good version control practices:

Pull from main (git pull or git pull origin main)
Create New Branches (git branch <new branch name>)
Track and Commit Their Work (git add <file> or git add . andgit commit -m "comments")
Push Work (git push)

And like any good kitchen (or any good team), I had to make sure our team was communicating.

If you've ever watched a (good) kitchen at work, the Expo knows everything going on in the kitchen and is barking orders:

Let's get those steaks working (start cooking the steak)!
I got a steak dying over here (my steak is sitting too long)!
Where's my salad?!1? (Where's the damn salad?!)

(Spoiler: I've never actually work in a pro kitchen/restaurant, so take everything I say with a huge grain of Maldon Sea Salt- I just watch a lot of cooking shows!)

As the Gitfather, I had to do the same (although less barking more gentle reminders):

Remember to create a new branch!
Constantly track, commit, and push!
Make sure you pull from main before you work!
Main is merged!
Where's my salad??!1?

Basically, any good Gitfather needs to be on top of what everyone is working on.

For instance, I knew one team member was working on JS updates and another was working on HTML updates. I had to make sure the HTML updates wouldn't conflict with the JS updates. Or, I needed to make sure all JS and HTML was done before we could start hunkering down on CSS. And, in all of this, making sure comments were clear and organized so we all know what we did and where in the code.

Ultimately, while Github is amazing for version control, the best version control is you.

Like a good expo, you need to know what is going on at all times in your kitchen.

Who's working on what?
What is being worked on?
Who is crying in the walk-in?
Who asked for ranch with their steak frites?

And while intimidating as that seems, it ultimately empowers you to be at the center of it all. And you get to see and learn so much.

You get to see the your team create literally something out of nothing. You get to see how people approach problems. You get to see the brilliance of your team members and their programming skills.

And most importantly, you get to take credit for all their work because you merged all their updates to main.

Good luck future Gitfathers, Gitmothers, and Gitzaddy!

DEV Community: James Macapagal

Understanding LeetCode Problem #1672: Richest Customer Wealth (JavaScript)

Algorithm

1) Talk To Yourself

Speak and it shall be known

Jesse, Let's Code

Pass The Talk Test

Bonus: Time and Space Complexity (Big O)

How to Seed Your Rails API with an External API

Assumptions

Step 1: Get a API key and API Endpoint

Step 2: Get your API Endpoint

Step 3: Install Gems

Step 4: Create ENV and Update .gitignore file

1) Create an ENV file

2) Update your .gitignore file

Step 5: Create your Seed File!

Step 6: Throw Your Hands Up and Yell "I am Invincible!"

Bonus Step: When You Deploy To Heroku

Conclusion

You Down with O-O-P?

What the heck even is Object-oriented programming?

Legos... My Favorite Toy!

The Opposite of Legos

OOP: Built To Last

Lego Island

Conclusion

The Gitfather, Part 2: The Prequel

A long time ago, in a galaxy far, far away...

Story Mode

Turn Up the AC

One Ticket To Rule Them All

Sometimes, The Requirements Ain't The Requirements

Conclusion

useState: The Hook Brings You Back

useState of the Union

Well, what even is useState and why should I care?

Enter useState

*But wait there's more! *

The Hook Brings You Back

Advice From A Gitfather: Lessons on Version Control

Well, what even is `useState` and why should I care?

But wait there's more!