DEV Community: kymiddleton

Reference Guide: Complete and Merge a Pull Request

kymiddleton — Wed, 26 Dec 2018 21:38:14 +0000

In my previous post, Reference Guide: Conducting a Code Review, detailed steps were outlined for the code review process. Once the code review is completed it’s time to complete the process and make comments, approve the reviewed changes or request changes to be made before it can be approved. This is where any identified issues need to be noted.

To complete the pull request review:

Select green button Review changes to finalize the pull request

A pop-up box will appear with options to Comment, Approve, or Request changes

The code review process is very important. If something needs to be changed or modified simply provide descriptive comments and select Request changes. This will send a notification back to the contributor.

Select the appropriate action: Comment, Approve, or Request changes
Click Submit review

Once submitted, you’ll be taken back to the Pull request page.

Merging a pull request:
Provided everything on this page is green, the changes are ready to be merged.

Select Merge pull request

Select Confirm merge

Once this has been selected the files will be merged and the icon under the pull request will switch from a green icon that states Open to a purple icon that states Merged.

Only a couple more steps!

Return to the terminal and complete the following:

git checkout master
git pull

These additional steps will pull changes from the master and update the local copy. It’s always best to make sure collaborators are working from current files.

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Reference Guide: Conducting a Code Review

kymiddleton — Wed, 26 Dec 2018 21:35:42 +0000

Code review is the process of reviewing and approving code changes for collaborators, someone other than the author of the pushed changes. It's basically code inspections conducted by peers working on the same project with a protected master branch. For more details on the code review process and benefits check out my post here.

When a notification has been received to review changes, go into GitHub and access the project repository.

Select the Pull requests tab.

A number next the Pull requests tab indicates the number of requests pending review.

Select the Pull requests from the listed items.

Once the Pull requests has been selected a new page will display several details:

Number of commits to be merged
Number of files changed
Contributors branch name

Before continuing in GitHub, make note of the contributors branch name and return to the terminal. Once inside the projects root directory:

git fetch origin <branch name>
git checkout <branch name>

From here, run the application to identify any potential issues.

Go back to GitHub to review the code changes in the pull request.

Select the Commits tab or the Files changed tab

Commits tab

This tab displays the history of the commits submitted for the specified pull request
Each commit can be selected to review the progression of changes made

Files changed tab

This tab provides a side by side comparison of the file changes.

New changes are on the right-hand side highlighted in green.
On the left-hand side, old changes are highlighted in red

The next step of the process will be to complete the pull request review. That process will provide the opportunity to make comments, approve the reviewed changes or request changes to be made before it can be approved. Therefore, if any issues were identified when the application was checked out and run locally be sure to make notes of the specific issues identified. If there is something noticeable when looking at the side by side view in the Files changed tab also be sure to mention specifics in the next step of the process Complete and Merge a Pull Request.

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

What is a code review?

kymiddleton — Wed, 26 Dec 2018 21:29:02 +0000

Have you ever worked on a project and became so hyper focused the world around you could fall apart and you wouldn't notice? I love those moments and as a new web developer it's when I feel everything coming together and I make a significant amount of progress on a project or a piece of functionality. The downside is of course when something breaks or just doesn't work the way its intended and despite my best efforts of concentration my eyes can no longer decipher the difference between a comma and a period. That's when code review come into play!

Code review needs to be taken seriously. Don't treated it like it's depicted in this cartoon!

There are tremendous benefits of code reviews. For one, code reviews save time and help to streamline the development process up front. Ultimately the upfront time saved reduces the amount of work for the Quality Assurance teams later. A second set of eyes to review something you've stared at for days can quickly identify simple errors and even catch bugs that might have slipped undetected through testing or production. We all know time is money and time saved is money saved too.

In my opinion the code review process also fosters collaboration. The more I collaborate with others the more I learn too. To me, it's fascinating to watch someone code, troubleshoot and do a code review. It provides an opportunity to witness someone else's approach to coding and their thought process. It's a priceless opportunity for anyone to learn ways to identify common problems or write cleaner code along with useful shortcuts.

For more information checkout the posts in my Reference Guide series: Conducting a Code Review and Complete and Merge a Pull Request.

Reference Guide: Pull Requests

kymiddleton — Sat, 22 Dec 2018 03:25:15 +0000

The next part of my series addresses 'Pull Request'. A Shared Repository Model allows organizations and teams to collaborate by sharing a single repository with branches used to develop features and isolate changes. A 'pull request' provides a way to notify project maintainers about changes made and initiates the code review process.

For anyone new to code collaboration set yourself up for success and use a reference guide to help walk you through the steps like the ones outlined below.

CREATE A PULL REQUEST TO MASTER BRANCH
Once items are production ready a pull request needs to be completed to merge the changes into the master branch.

Pull Request to unprotected master branch:
Access the repository in GitHub. Recently pushed changes should appear in a highlighted section on the main page of the repository with a green button compare and pull request on the right-hand side of the highlighted section.

Select compare and pull request
Select merge pull request

Pull Request to protected master branch:
In a group environment with collaborators working within a repository with a protected master branch do the following:

Go into GitHub and select the project repository
Locate the highlighted section indicating the most recent pushed changes

Select compare and pull request
Select a Reviewer
- This will be one of the contributors added to the initial project
Select Create pull request
- This step will create the pull request and indicate a review is required and merging is blocked until a review has been completed.
- At this point, GitHub will send an email request to the selected reviewer to notify them of a pending review. To speed up the process it’s best to send a direct message to the selected contributor to notify them the request has been made.

If you missed a previous post you can check them out here:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches

Up next:Conducting a Code Review

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Reference Guide: Merge conflicts

kymiddleton — Sat, 22 Dec 2018 02:49:56 +0000

Welcome back to the Reference Guide series.

Merging is the act of integrating code changes from another branch into a working branch. With 'Git', there are times when competing changes cannot be resolved without intervention. Conflicts can occur when someone edits a file and someone else deletes the same file, or, when changes are made to the same line of the same file.

Merge conflicts can be a bit intimidating at first but rest assured they won't be for long. After a little practice, you'll be a pro in no time.

RESOLVE MERGE CONFLICTS

Once changes have been pushed to the branch name it’s a good practice to follow a few more steps to resolve potential conflicts before making a pull request in GitHub.

git pull origin master
- This command updates the local branch to match the master branch.

Open a code editor of choice to review changes or conflicts. Generally, current changes will be highlighted in one color and incoming changes will be highlighted in a different color. Accept the current or incoming changes. Once completed run the following commands:

git status
git add –A
git status
git commit –m “add comment description of changes made”
git status
git push origin <name of branch>

Up next: Pull Requests

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Reference Guide: Committing Changes with Branches

kymiddleton — Sat, 15 Dec 2018 14:52:31 +0000

When I first started working with branches I could never remember which branch I was on when it came time to commit changes. My go-to command quickly became git branch.

If you missed part of the series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes

COMMITTING CHANGES WITH BRANCHES
It’s best to think of the master branch as production. Therefore, it’s best to never push to the master branch. When using branches remember they run parallel to the master. As soon as a new project is created get into the habit of creating a new branch before making file changes. It’s also best to create a new branch for each design feature.

Branch commands:

git branch
- Displays branches within current project including the master branch.

git checkout <branch name>
- Used to switch to a different branch.

Make a new branch:

git checkout –b <name of new branch>
- Checkout is similar to the homepage of a website by indicating a switch from the homepage or master branch to an alternate page view or branch.
- -b initiates a new branch to be created.

When code is ready to be committed to a branch use the following commands:

git status *Items that appear in red indicate the files and subsequent changes are not being tracked. These files need to be staged and submitted.
git add –A
- This command initiates changes being tracked and the A indicates all files. This also transitions the code to be staged.
git status
- Repeating this command will show the files previously highlighted in red have switched to green indicating changes have been tracked, saved and ready to push to the repository.
git commit –m “add comment description of changes made”
- Staged code is now saved locally with a note to others about the code. Makes commit messages descriptive and meaningful.
git status
- Repeat command to verify all changes have been staged and ready to push to the repository.
git push origin <name of branch>
- Saved changes are pushed to the named branch.

Up next: Handling Merge Conflicts

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Reference Guide: Committing Changes

kymiddleton — Thu, 06 Dec 2018 01:38:07 +0000

Welcome back for part three of my reference guide series.

Go here for Part One: Reference Guide: Common Commands for Terminal.
Go here for Part two Create a GitHub Repository

COMMITTING CHANGES
When building a new application, a best practice for web development is to code a few lines, test a few lines, then commit changes. The commit process is the equivalent of saving changes to a document by clicking the save icon.

To commit file changes start by entering the following commands in the terminal:

git status
- Items that appear in red indicate the files and subsequent changes are not being tracked. These files need to be staged and submitted.

git add –A
- This command initiates changes being tracked and the A indicates all files. This also transitions the code to be staged.
git status
- Repeating this command will show the files previously highlighted in red have switched to green indicating changes have been tracked, saved and ready to push to the repository.

git commit –m “add comment description of changes made”
- Staged code is now saved locally with a note to others about the code. Makes commit messages descriptive and meaningful.
git status
- Repeat command to verify all changes have been staged and ready to push to the repository.
git push origin master
- Pushing to the master branch is something that should be limited to the first commit of a project repository.
- Repositories with multiple collaborators should always have the master branch protected with changes being pushed to a branch then pulled into the master by creating a pull request.

Up next: Committing changes with branches.

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Reference Guide: Create a GitHub Repository

kymiddleton — Tue, 04 Dec 2018 21:21:34 +0000

Welcome to part two of my reference guide series!
Go here for Part One: Reference Guide: Common Commands for Terminal.

GitHub is a web-based hosting service for version control using Git.

To create a repository go to GitHub:

At the top right corner of the webpage click the + sign and select New Repository.
Enter a name for the repository in the provided field. Use dashes instead of spaces.
Select Initialize This Repository with a README file.
Click the arrow on Add .gitignore
- There are some files that GitHub needs to ignore when files are pushed to the repository. For example: When working with Node.js, select Node from the list.

Select Create repository

How to Protect the Master Branch:
From GitHub:

Select the Settings tab

From the Options menu on the left-hand side select Branches
Select the Add rule box at the right-hand side of Branch protection rules

At the top of the screen there will be a prompt to enter the branch name.

Apply rule to Master or branch name
Select the Require pull request reviews before merging
Select Include administrators
Select Create
Select Save changes

Clone the Repository:
In GitHub:

To clone the repository, select clone to copy the link

In the Terminal:

Go into Terminal and use the command cd to move into the folder where the repository will be stored and accessed.
Once inside the file, or root directory, where the project will be stored enter the following commands.
git clone <paste copied link from GitHub>
- This step creates a link between the local files and the repository files.

Stay tuned for part three: Committing Changes.

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Reference Guide: Common Commands for Terminal

kymiddleton — Tue, 04 Dec 2018 21:14:19 +0000

Have you ever walked out of a room and then couldn't remember what you started to do? Have you ever convinced yourself a trip to the grocery store can be accomplished without a list only to arrive home without the one single item that was most needed? It happens to me, more than I'd like to admit, and I'm fairly certain I'm not alone. Throughout my career, I've developed a strategy to set myself up for success when moments of brain overload strike.

There are certain job responsibilities or steps of a process that are difficult to remember when performed on an infrequent basis or when learning them for the first time. This is where a quick reference list or guide can be a lifesaver. As a newbie to web development there are numerous steps to remember and until they've been committed to memory reference materials are my go-to. In case someone else is in need too I wanted to share the steps I've created for a few common processes needed as a new web developer.

Terminal:
The Terminal program is built-in on Mac computers and uses text commands to operate the computer without using the user interface. Terminal commands for GitHub will all begin with the prefix git followed by the command.

Common Commands:

~ Indicates the home directory
pwd Print working directory (pwd) displays the path name of the current directory
cd Change Directory
mkdir Make a new directory / file folder
touch Make a new file
.. Go up one level / directory
cd ~ Return to home directory
clear Clears information on the display screen to provide a blank slate
ls List provides a list of all files with a directory
ls -l Displays a long list vertically with file permissions, date modified and file name
ls -la Displays all files

Auto Complete File Names:
Enter the first couple of lines of the file name followed by the tab key and it will auto complete the rest of the file path name.

Next up: Part 2 Create a GitHub Repository

For the completed Reference Guide Series:

Part One: Reference Guide: Common Commands for Terminal.
Part two: Create a GitHub Repository
Part three: Committing Changes
Part four: Committing Changes with Branches -Part five: Merge Conflicts
Part six: Pull Requests
Part seven: Conducting a Code Review -Part eight: Complete and Merge a Pull Request

Check your Nodes?

kymiddleton — Fri, 30 Nov 2018 23:18:08 +0000

Node.js is an open-source, cross-platform JavaScript runtime environment designed to let JavaScript run outside of the browser or webpage. It’s a general utility that can be used for a variety of purposes including asset compilation, scripting, monitoring, creating desktop applications, and most notably as the basis for web servers. JavaScript can be used for the server side since Node reuses JavaScript. This means a front-end developer can build an entire server themselves. Other benefits of node:

Numerous plugins are available which easily expands its capabilities.
Creating an entire working server can be accomplished with few lines of code which allows for faster implementations.
The single-threaded asynchronous model allows handling of multiples requests simultaneously without bottlenecks or slowed performance.

SETTING UP A NODE PROJECT
QUICK REFERENCE GUIDE

Open Favorite Code Editor
Open Command Line within Code Editor

`mkdir <projectName>`
`cd <projectName>`

Install the Node Packages in the root directory of the project folder using the following command:

`npm init`

This step will initialize the folder and create the package.json file.

Once the installation has completed the program will prompt a series of questions to gather contextual information about the project such the project name , copyright, version, description, entry point file name, author, etc.
Completion of the fields is not required and can be skipped by using the enter key.
When prompted with Is this okay? (yes) respond by entering yes followed by the enter key.
Look inside the folder for the package.json file.
Open the file to review and familiarize contents.
The syntax of the JSON folder is a JavaScript object.
Next, run the following command in the same directory of the root folder:

`npm install express`

This will create the node_modules subfolder.

The node_modules file holds all the modules for the particular project.
Go back and look inside the package.json file
- A new object will appear, dependencies, which should have Express listed.
- Any new dependencies will be added to the package.json file.

Steps to Take for Existing Projects:
When working on an existing project that already contains a package.json file run the following command:

`npm install`

This will evaluate the contents of the package.json file and install additional packages if needed.

Steps to Take when Receiving an Existing Project:

`npm install`

This will evaluate the contents of the package.json file and install additional packages if needed.

Do NOT Share the Node Modules Folder

This is a critical step to remember especially when collaborating on projects.

Node Module folders must NOT be shared, ever.
When the npm install command runs it compiles files based on the needs of the specific computer.
When collaborating or sharing project files, other contributors will need to install the command npm install in the root directory of the project folder on THEIR computer.
Remember the npm install command without a package name evaluates the existing dependencies within the package.json file and installs needed dependencies.

With so many little steps to remember when building a full stack application I hope this guide becomes a helpful tool for others too.

Change is GREAT. I’ll go first!

kymiddleton — Thu, 29 Nov 2018 14:28:40 +0000

Part 2: A model for Change Management: ADKAR

If you missed part one of this post you can check it out here.

When faced with a challenge, regardless of size, the first step is to devise a plan of action. An often-overlooked component of action planning is assessing five critical factors: Awareness, Desire, Knowledge, Ability and Reinforcement. Together these elements are the Prosci Change Management model, referred to as the ADKAR model.

Awareness is a great starting point since it’s important to be aware of a situation and changes that need to be made or understand the consequences of not making changes. Assessing internal and external factors are also important. Internal factors refer to an inward, emotional, state such as an environment or career field with positive feelings which are energizing or negative feelings such as making someone feel angst. External factors refer to situations such as income needs being met but lacking job satisfaction. Or perhaps the income and job satisfaction is positive but a shorter commute would be a welcomed change. These are all elements of awareness.

The next step is Desire. According to the dictionary desire refers to strong feelings of wishing for something to happen or wanting to have something. Strong feelings of desire for a precise outcome are a driving factor for someone to put forth the effort and energy to learn something new or make significant changes. Ultimately it comes down to personal choice and individual motivation.

Having awareness and desire seems simple enough, right? Have you ever been nagged? Or have you nagged someone to complete a task that could have been completed in two minutes yet it took two days of reminders before any action was taken? Nagging is simply reminding someone to do something that’s already aware of what needs to be done. In other words, nagging isn’t going to make someone more aware. Unless someone has a desire to do something, all the awareness in the world won’t make a difference. It basically boils down to motivation and having a desire to do what’s necessary to complete a task or make a goal a reality.

Knowledge, the third piece of this model, is the information, facts and skills acquired to understand a subject. Let’s say a web developer is proposing the need for a new position within their team. Part of their action plan includes detailed tasks for the new position along with a list of desired qualifications. After discussing the role with a peer a gap in skills is identified and added to the initial proposal. Regardless of a position or task at hand it’s important to assess the tools or systems needed along with the necessary knowledge needed for someone to be successful.

The next step is Ability which comes down to taking acquired knowledge or skills and applying them to a given situation. A great way to think of this is the difference between theory and practical application. Just because someone has the knowledge of a brain surgeon doesn’t mean they actually know how to perform a surgery. Knowing how to utilize acquired knowledge depends on someone’s ability to turn their knowledge into action.

The final step is Reinforcement. As with any situation in life that involves making changes, from simple behavior changes, healthy eating habits, resolutions to exercise more, or learning how to code is all wasted without reinforcement to sustain the change. Having the awareness to learn a new job skill for career growth is great. Having the desire to learn the new skill and motivation to take classes is awesome. Taking the training course to have a solid foundation of knowledge and the ability to take the knowledge and apply it by completing coding challenges or building web applications is stellar. Once a coding course is completed what steps will be taken to keep those skills fresh? To keep the change going it comes back to the internal and external factors that provided the initial motivation to make the change. Reinforcement is critical for tying these pieces together when it comes to making changes.

Just remember, nagging someone to do something isn’t going to make them more aware unless there’s a personal desire to change. Knowing someone has experience with computer programming in JavaScript and expecting them to fill a vacancy in C# without conducting a gap assessment of skills and ability or providing a training plan is setting someone up for failure. Just as training someone to learn a new programming language is wasted if there’s no plan to reinforce the newly acquired skills. Skills are like muscles that need to be used regularly or they get weak.

Regardless of the type of change being made, continue to evaluate each of these components on a regular basis. Everyone learns at a different pace, has a different learning style, and that’s okay. Everyone processes and handles change differently and that’s also okay. It’s natural as humans to resist change - but change is possible with an action plan.

Change is good. You go first.

kymiddleton — Thu, 29 Nov 2018 06:37:01 +0000

As a boot camp student, it’s been a bit surreal to sit in a classroom again. From what I’ve learned so far, if someone is contemplating a career in web development but doesn’t enjoy the intricacies of problem solving, or sorting through copious lines of code to discover that the malfunction is related to a typo, then web development is probably not the best career choice. In some ways web development is like untangling and enormous pile of jumbled-knotted rope. For some people, they’d take one look at the gigantic mess and either panic or walk away. For others, the appeal of a puzzle is exciting and the act of chasing down individual strands of rope to find the first end is satisfying.

In a traditional learning environment, a specific subject builds mastery over a defined period. A boot camp environment builds a broad knowledge base in a fast-paced learning environment. Simply saying the word ‘boot camp’ evokes images of military themed movies with a drill sergeant and new recruits where the intensity of the training is visible. The environment for a web development boot camp is similar in the level of immersion into a fast-paced learning environment that’s hands on, engaging, requires significant attention, time and energy. Learning anything new can conjure feelings of frustration, self-doubt or discomfort and it can catch some people off guard.

Learning is CHANGE. You may be familiar with the traditional “Change Curve.”

According to William Bridges, Managing Transitions, change is situational however transitions are psychological. Transitions have an ending phase, the letting go of old ways and old identities. The neutral phase is exploration and learning. The “old” is gone however the “new” hasn’t arrived yet. Last is new beginnings, a phase of new identities, new energy and discovering a new purpose. Every person experiences this differently with different reactions and at different paces. Let’s face it change, of any type, is difficult but it can be easier with the right tools.

Part of my non-technical background was spent as a certified practitioner of change management through Prosci Change Management. Their model for change, ADKAR, is simply fantastic and can be applied to any professional or personal situation, even web development!

Check out part two to learn more about this model and how it can help you.