jozue06 / 01-mobile-first

Lab 01: Mobile First

Code of Conduct

Code Wars Challenge

Complete today's Kata and follow the submission instructions below.

Code Wars Challenge Submission Instructions

1. With your assigned partner, pseudocode your solution on the whiteboard. Take a picture of your proposed solution for your repo.
2. Complete the daily Kata(s).
3. Create a new branch for each challenge.
4. Make a new folder in your Code Wars repository on Github. The name of the folder should be the same as the name of the challenge.
5. This folder should contain:
   • A file named "solution.js" which contains the JavaScript solution after confirming that it passes on Code Wars with green passing tests
   • A picture of your pseudocoded solution from the whiteboarding exercise
   • A README.md which includes the problem domain from Code Wars and a link to the challenge
6. Make a pull request from your working branch to your master branch.
7. Submit a link to your PR on Canvas.

Lab 01

Welcome to your first pair programming lab assignment for Code 301!!

Today we'll be kicking off our blog app by applying what we learned in lecture to implement a mobile-first design using responsive web design techniques. You'll also need to spend some time getting familiar with the new Git/GitHub & Pair Programming workflow that we'll utilize throughout this course.

Please take the time to read carefully through each of the READMEs for lab assignments as they have detailed information regarding your assignment, such as: submission instructions, resources, configuration, user stories with feature tasks, and documentation.

Lab 01 Submission Instructions

When you are finished with lab, follow these steps to submit your work. Create one pull request (aka: "PR") from your forked repo to the CF repo with your changes, and you'll each submit that same PR link in Canvas.

1. Be sure to remember to do all of your work on non-master branches.
2. Ensure that all your local changes are committed and pushed to your origin repo.
3. Visit the origin repo on github.com, and ensure that all of your completed work has been merged to master via pull requests within your repo.
4. Create a new PR from your fork to the CF repo and ensure the branches look correct.
5. Fill in the template based on the check box prompts:
   • Write a good descriptive summary of your changes
   • Be sure to include how much time you spent on it and who you worked with.
   • Briefly reflect on and summarize your process.
6. When you create the PR, it will have a unique URL. Copy this link, share with your partner, and paste it into the assignment submission form in Canvas. Both the driver and the navigator will submit the same PR link.

---

Set up your repo

Here is the recommended workflow:

1. Driver: fork the CF lab repository if you haven't done so already.

2. Your forked repo on GitHub is your "origin" repo.

3. Clone your fork to your local development environment. Follow this directory structure:

   ~/codefellows
     301/
       lab-assignments/
         01-mobile-first/ # this is the cloned repository for today's work
   

   1. Immediately git checkout -b <driverName-navigatorName> (ex: git checkout -b allie-sam).
   2. Create a copy of the starter-code directory with the copy's name being the driver-navigator (ex: cp -r starter-code allie-sam) and navigate into that directory (ex: cd allie-sam). Do not work directly in the starter-code directory; only work in your renamed copy of it.

Write code together!

1. Driver: In your terminal, ensure that:

   • You are on the branch named after you and your partner.
   • You are currently within the partner pair directory (01-mobile-first/allie-sam).

2. Open this directory as a project in your editor.

3. Use the "Find in Project" feature to locate all the TODO:, REVIEW:, and COMMENT: items.

4. Before writing code, do a read-through of the existing code and discuss the REVIEW items with your partner.

5. Use live-server in your terminal to render the code in the browser. Note that live-server will automatically update the browser when code is changed and saved.

6. Work through one or two TODO or COMMENT items before switching roles (or one hour, whichever arrives first), testing your code as you go.

7. In your terminal type git status to view the files that you have changed. You should only see the files that you have worked on.

8. Type git diff to see line-item changes with your down arrow key. (Type q to exit this mode)

9. Type git add file1 file2 where file1, file2, etc. are the files that you have changed.

10. Type git status to view the files that have been added to your commit. You should only see the files that you worked on.

11. Type git commit -m "some meaningful message" where some meaningful message is a message that thoroughly explains your commit.

12. Type git status to ensure there is nothing left to commit.

13. Type git push origin <driverName-navigatorName> to push this branch to your forked repo on GitHub.

14. On GitHub, Add your navigator as a collaborator (go to Settings -> Collaborators & teams).

15. Once they have been added, Slack to your partner your forked repo link for them to clone down.

Switch roles

The navigator (who will become the new driver):

• Clone the repo from the link your partner Slacked you into your working directory.
• See the above directory structure for what you should have on your file system and navigate into the subdirectory named after you and your partner.
• Fetch the branch you were just working on (git fetch origin <driverName-navigatorName>)
• Switch to that branch (git checkout -b <driverName-navigatorName>).
• Open the code in your editor and resume editing the code.
• Add, commit, push as you have done before.

---

Resources

• [Video: Mobile Testing Tip for Your Phone] (https://www.youtube.com/watch?v=2t4E_tc8TKM)

---

Configuration

Your repository must include:

• README.md - with documentation regarding your lab and its current state of development. Check the "documentation" section below for more details on how that should look AT MINIMUM
• .gitignore - with standard NodeJS configurations
• .eslintrc.json - with Code 301 course standards for the linter

01-mobile-first
└── starter-code
└── driver-navigator
	├── .eslintrc.json
	├── .gitignore
	├── LICENSE
	├── README.md
	├── index.html
	├── styles
	│   ├── base.css
	│   ├── layout.css
	│   └── modules.css
	└── vendor
	    └── styles
			    ├── fonts
			    │   ├── icomoon.eot
			    │   ├── icomoon.svg
			    │   ├── icomoon.ttf
			    │   └── icomoon.woff
			    ├── icons.css
	        └── normalize.css
	└── PULL_REQUEST_TEMPLATE.md
	└── README.md

---

User Stories and Feature Tasks

As a user, I want to have an application that looks good, is easy to use, and is updated often, so that I want to come back and use it frequently.

• Working from the provided comp images, write CSS such that the browser rendering matches the images as closely as possible.
• Utilize the icon fonts located in styles/icons.css for navigation features as shown in the comp images.

As a developer, I want to use standard industry practices for setting up and organizing the code that handles the styling of my application so that my code is easy to edit and maintain.

• Utilize a normalize.css file, which should be placed in a vendor/styles/ directory, to override default browser settings that affect the way documents render.
• Utilize SMACSS practices to organize CSS into separate files and appropriately order the loading of those files in the <head> of the HTML document.

As a user, I want a familiar experience of the application so that I know how to use it on my smartphone and occasionally my laptop.

• Initially design the application to render per the comp images on mobile devices.
• Set up the viewport and fluid media rules so content renders per the comp images in both mobile and desktop views. Use a breakpoint of 640 pixels.
• Add a "Hamburger" menu button that reveals the nav links when hovered over.
• Ensure that images are responsive and do not exceed the size of the viewport.

Stretch Goal

As a user, I want a familiar experience when accessing the application on my tablet so that I can get the most out of the screen size.

• Set up an intermediate media query for tablet devices (choose the maximum width at your own discretion).

---

Documentation

Your README.md must include:

# Project Name

**Author**: Your Name Goes Here
**Version**: 1.0.0 (increment the patch/fix version number up if you make more commits past your first submission)

## Overview
<!-- Provide a high level overview of what this application is and why you are building it, beyond the fact that it's an assignment for a Code Fellows 301 class. (i.e. What's your problem domain?) -->

## Getting Started
<!-- What are the steps that a user must take in order to build this app on their own machine and get it running? -->

## Architecture
<!-- Provide a detailed description of the application design. What technologies (languages, libraries, etc) you're using, and any other relevant design information. -->

## Change Log
<!-- Use this are to document the iterative changes made to your application as each feature is successfully implemented. Use time stamps. Here's an examples:

01-01-2001 4:59pm - Application now has a fully-functional express server, with GET and POST routes for the book resource.

## Credits and Collaborations
<!-- Give credit (and a link) to other people or resources that helped you build this application. -->
-->