DEV Community: gabbinguyen

Let's Git It

gabbinguyen — Fri, 29 Jan 2021 17:08:26 +0000

At one point a codenewbie, I found myself thoroughly confused by git commands, how to use them, when to use them, and so on. While there's many online resources outlining the commands, most of what I found wasn't 'beginner-friendly' or robust enough for my liking. In short, the documentation confused me even more. It seemed to me as if the people who wrote the docs were simply trying to help themselves remember the commands, as opposed to teaching a newbie what the commands meant.

For any code beginner stumbling across my blog, this post is for you! This is git, simplified.

Git Clone

git clone is used to target an existing Git repository and make a clone of that to exist on your local machine. You are able to sync the local clone to the remote with a few commands (which I will go over later in the post). After cloning it, you can cd into the directory to begin coding.

Git Checkout

Speaking of new branches, git checkout is used to create a new branch. The command for that is git checkout -b "your-branch-name-here"

Git Branch

git branch is a command used to check which branch you are currently working out of. A use case for this is when you're working on multiple features with other collaborators, you don't necessarily want to be working off the same branch. To keep things from getting mixed up or from breaking, you want to checkout a new branch to code your portion of the project. In this case, it's good practice to check what branch you're in just in case before pushing any changes.

Git Add

git add isn't quite the same as a traditional 'save' command. git add sends all the changes made to the staging area, which then is able to be saved with a different command. There are different types of add commands that stage certain pieces of information:

Git Commit

git commit is the command used to save your local copy of the project. The most commonly used command is git commit -m "your-message-here" where you include a message of any changes your made.

Git Push

git push is the command used to upload the local saved changes to the remote repository. After you push, it allows other collaborators to pull your branch, merge your changes with theirs, and work with the modifications you made.

Git Pull

git pull fetches any commits from the remote branch and allows you to merge it with your branch. When you're collaborating with others, the command you'll be using frequently will be git pull origin "name-of-branch-you-are-wanting-to-pull-from

In this example, my project partner's branch is called 'testbranch.' I want to merge what they have with my portion of the project in my own working branch, so I call testbranch at the end of the pull command.

This pull command only merges the work on your local copy. To share the merged work with the rest of your team, you will then add, commit, and push this newly merged branch for others to pull from.

These are just the basics git commands; while there's many more that you can utilize, having a good understanding of the basics will help any beginner get a jump start into collaboration. Happy coding!

References:
-https://stackoverflow.com/questions/572549/difference-between-git-add-a-and-git-add?rq=1
-https://www.atlassian.com/git/tutorials/saving-changes

Great Expectations: Flatiron Software Engineering Program

gabbinguyen — Fri, 29 Jan 2021 04:17:26 +0000

It's the day before my graduation from Flatiron School's software engineering program, and as I approach the end of this grueling 3.5ish month journey, I can't help but to reflect on the progress I've made: from playing around on freecodecamp.com in my spare time, to now being able to build a fully functioning website, involving solo coding a backend and frontend, in less than 3 weeks.

I just made it sound effortless and easy, but in reality, what got me to where I am today was 40-50 hours a week (at least) of watching code lectures, practicing coding, and coding with other newbies. That's a whole lot of coding, and it's practically a full time job! And like most full time jobs, this experience came with its highs and lows.

To give the reader some perspective, I started out with practically zero coding knowledge; I changed the font once on my Myspace layout and that's about as far as I ever ventured into the coding realm until the summer of 2020, also known as the year when Covid-19 decided to rear its ugly head and wiped out any prospects of in-person anything.

In simpler terms, social distancing took effect and remote learning became ubiquitous, so in turn, we had to adapt to the shortcomings that came along with it. Learning how to code is already tough as it is, but losing the class dynamic only made it that much harder.

There was a sharp learning curve in the beginning, and now that it's all said and done, there's a few things I wish I understood about the bootcamp before going into it, so for anyone toying with the idea of applying to Flatiron, this post is for you. If you just recently got accepted - congrats! Hopefully this post can be of help to you too.

1. Curriculum breakdown
The 15-week program is broken into five 3-week phases where you learn the following fundamentals:

Ruby
Ruby on Rails
Javascript
React
Final capstone project (technically not a fundamental but will take 3 weeks)

Ok, rewind - what was all that gibberish? Ruby and Javascript are programming languages, the foundation of what we build our web applications off of, whereas Ruby on Rails (or Rails for short) and React are web application frameworks that help provide structure to the backend and frontend code, respectively.

In short, the curriculum includes two programming languages: Ruby and Javascript, as well as two frameworks: Rails and React.

2. Program split
Each 3-week learning phase consists of:

Lecture week
Code challenge week
Project week

During lecture week, it consists of exactly what it sounds like - sitting through code lectures over specific principles within that fundamental, as well as daily partner exercises where you are paired up with another student to work through a problem code. This week is when a lot of heavy lifting takes place in terms of learning, coding, and practicing the same principles over and over again.

During code challenge week, there is an 'exam' (known as the code challenge) that takes place in the middle of the week that tests you over the principles learned from the previous week. While the program doesn't give out grades, it does operate off a pass/fail system, and if you aren't able to pass the code challenge, the opportunity to retake the exam or redo the phase is then up for discussion.

During project week, you have the opportunity to collaborate with other students on a project where you implement the fundamentals you learned from week 1. This week is probably the hardest, yet most rewarding week in each phase because you are literally creating something from scratch and seeing ideas that you might have had finally materialize. At the end of project week, the cohort comes together to present their project and seeing the progress that other students have made is just as rewarding.

3. Take a break every once in a while
The last thing I wish I knew beforehand was the very important lesson of taking a step back from your computer and decompressing. Going into the program, I thought I had to be non-stop coding to keep up with all the other software devs in the industry. I felt lightyears behind them since I was just beginning to embark on this journey while others had been coding for years, and at a much younger age.

Taking a break won't hurt your coding progress; if anything it can help it. The amount of times I've spent chasing a problem all afternoon only to solve it the next day after being well rested has been far too many times, and it makes sense - your brain is a muscle and like every other muscle in your body, after strenuous exertion it needs rest. 15 straight weeks of coding is mentally draining and the only way to prevent burnout is to take the time to recharge when you can.

So there you have it - things you can expect from the program and how to set yourself up for success. Good luck to any newbies out there, the journey is hard but it sure is fun! Happy coding, y'all.

MVC and REST, Simplified

gabbinguyen — Mon, 11 Jan 2021 03:00:34 +0000

So, you're learning about Models, Views, and Controllers. What's the difference, how do they work with each other, and what does this have to do with your application? Let's break it down and simplify the MVC framework.

Models
The Model is responsible for holding all the logic that applies to a specific Class in the application. The Model also accesses information from the database and sends it to the Controller to route.

Controllers
The Controller is responsible for routing information from the Model to the View, then from the View to the browser to display the contents for the end user. The Controller will have all the methods on any actions (Create, Read, Update, Delete, or other) that apply to the Class.

Views
The View is responsible for taking the data from the Controller and defines what is displayed on the client side. All frontend code will be housed in Views for all the actions in a specific Class.

When we apply all this information to the above scenario, the flow within the framework would proceed as:

The browser requests for the "/users" URL
The application routes the "/users" URL to the action that is housed in the Controller
The specified action asks the User Model to pull information on that class from the Database
The User Model pulls the information from the Database
The User Model returns the information to the Controller
the Controller sends a request to the View based on the original action
The View renders the action's webpage as HTML
The Controller passes the HTML to the browser

Ok great, now we understand the MVC framework! But how do we make it work and do things for your application?

In the Controller subsection, we talked about how it holds all the methods for any actions that apply to that class. When we have a Class in our application, let's say, a User Class, we want to be able to obtain or manipulate the data in the database in ways such as creating a new user, viewing a specific user, deleting a user, and so forth. When a request is made to perform that kind of functionality, the Controller uses RESTful conventions and looks to the Routes file to help map to the method that matches what the browser is requesting.

So REST, simplified, is commands performed, such as our aforementioned CRUD actions.

In the diagram above, we see the HTTP verb hitting a specific URL path and being routed to a specific method, or action, within the Controller to render and display the information within the View.

Simplifying our HTTP verbs:

GET: simply retrieves information, does not manipulate any data within the database
POST: creates new data based on the information enclosed in the request
PATCH: updates existing data with the information enclosed in the request
DELETE: deletes the data enclosed in the request

Now that we have a better understanding and high-level overview of MVC and REST, we can use the MVC framework and the RESTful design pattern in conjunction to create a badass application! Happy coding!

Rails Command Line Shortcuts // Re: Generate

gabbinguyen — Sun, 29 Nov 2020 06:01:20 +0000

Learning Ruby on Rails can be overwhelming, so this article provides some examples on frequently used command line shortcuts to help get you started. We're going to focus on the rails generate shortcuts.

Using rails generate (or rails g) can help cut down the amount of time typing out code needed to build out your application, but what should we use, and when? Let's break down each shortcut and see what is created when we invoke it.

The shortcuts that we will be reviewing are:

Model
Controller
Resource
Migration

1. Model

Entering rails generate model will create:

Model file in the app/models directory
Migration file in the db/migrate directory

2. Controller

Entering rails generate controller will create:

Controller file in app/controller directory with actions included (new, create, and show in this example)
Routes for each action in the config/routes file
HTML view files for each action in the app/views directory

3. Resource

Entering rails generate resource will create:

Model file in the app/models directory
Migration file in the db/migrate directory
Controller file in the app/controllers directory
Resources in the config/routes file

4. Migration

Entering rails generate migration can create a variety of different outcomes such as adding a column to an existing table, renaming a table, destroying a column, and so on.

Resources:

https://guides.rubyonrails.org/command_line.html#rails-generate