@ -23,7 +42,12 @@ Also make it so the user can decode an encoded message.
https://en.wikipedia.org/wiki/Caesar_cipher
https://en.wikipedia.org/wiki/Caesar_cipher
You can put this Caesar Cipher code in a separate js file (before your main `app.js`), and then reference the `caesarShift` function in your angular controller.
You can put this Caesar Cipher code (or the code that you wrote a few weeks ago for the morning exerice) in a separate js file (before your main `app.js`), and then reference the `caesarShift` function in your angular controller.
**Commit 1** <br>
<hr>
"Commit 1: Made an app.js with my Caesar Cipher function."
<hr>
In the example in the above image, the `amount` is set to `12` for encoding, and `-12` for decoding.
In the example in the above image, the `amount` is set to `12` for encoding, and `-12` for decoding.
@ -69,3 +93,134 @@ var caesarShift = function(str, amount) {
};
};
```
```
**Commit 2** <br>
<hr>
"Commit 2: Connected the cipher to decode messages."
<hr>
**Commit 3** <br>
<hr>
"Commit 3: Connected the cipher to encode messages."
<hr>
## Part 2
##SONG LYRICS SHUFFLER
You will make a static page that displays songs with the song title, author, year, and lyrics. For no really good reason other than to practise `ng-click` and execute controller functions, you will be able to shuffle the order of the lyrics by clicking a shuffle button, as well as hide/show the song by clicking on the title.
Ultimately, you can add new songs to the page.
Sample screenshot:
#### The app should:
- Display song titles, authors, years, and lyrics line by line
- Hide / show the song by clicking on the title (the title does not get hidden 'cos you still have to click on it to show the song again)
- Shuffle the lyrics by pressing a shuffle button
- Add a new song
- When entering lyrics, the user should separate the lines of lyrics with a comma. **HINT FOR LATER** when the form is submitted, the app could `split` the lines by comma for use in an array
#### Set up - you will need:
- `index.html`
- `app.js`
- `style.css` if you want to add some style
#####Sample data
```
this.songs = [
{
author: "De La Soul",
title: "Ring Ring Ring",
lyrics: [
"Hey how ya doin'",
"Sorry ya can't get through",
"Why don't you leave your name",
"And your number",
"And I'll get back to you"
],
year: 1991,
hidden: false
}, {
author: "Ini Kamoze",
title: "Here Comes the Hotstepper",
lyrics: [
"Here comes the hot stepper",
"I'm the lyrical gangster",
"Pick up the crew in-a de area",
"Still love you like that"
],
year: 1995,
hidden: false
}, {
author: "Snow",
title: "Informer",
lyrics: [
"Informer",
"You no say daddy me Snow me-a gon' blame",
"I lick he boom boom down",
"'tective man they say, say daddy me Snow me stab someone down the lane",
"I lick he boom boom down."
],
year: 1993,
hidden: false
}
];
```
Server and database will be introduced tomorrow
Overall, you will need data and functions in your controller.
**Commit 4** <br>
<hr>
"Commit 4: Set up my initial files."
<hr>
#####Display songs
- A link to Angular 1.5 from https://angularjs.org/
- module / `ng-app`
- controller / `ng-controller`
- `ng-repeat` ( you might want to include a `track by $index` in the directive params, but if you don't need to, then don't)
- `ng-click` (hint: you can pass in $index as a param)
- `ng-if` or alternatively, `ng-hide` and/or `ng-show`
- curlies `{{ }}`
**Commit 5** <br>
<hr>
"Commit 5: Setup and now displaying the songs."
<hr>
#####Add a song
- a form with an `ng-submit`
- inputs that rout to `ng-model`s which could be inside a formdata object in the controller maybe.
**Commit 6** <br>
<hr>
"Commit 6: Setup and now able to add a song."
<hr>
#####Shuffle function
Pass in an array and the shuffle function will randomize the order of the elements
Make a Caesar Cipher page that takes an input and encodes it with a Caesar Cipher and and displays the encoded input while the user is typing. (no submit button).
Also make it so the user can decode an encoded message.
### ANGULAR DIRECTIVES
- `ng-keyup`
- `ng-model`
### CAESAR CIPHER
https://en.wikipedia.org/wiki/Caesar_cipher
You can put this Caesar Cipher code in a separate js file (before your main `app.js`), and then reference the `caesarShift` function in your angular controller.
In the example in the above image, the `amount` is set to `12` for encoding, and `-12` for decoding.
You will make a static page that displays songs with the song title, author, year, and lyrics. For no really good reason other than to practise `ng-click` and execute controller functions, you will be able to shuffle the order of the lyrics by clicking a shuffle button, as well as hide/show the song by clicking on the title.
Ultimately, you can add new songs to the page.
Sample screenshot:
#### The app should:
- Display song titles, authors, years, and lyrics line by line
- Hide / show the song by clicking on the title (the title does not get hidden 'cos you still have to click on it to show the song again)
- Shuffle the lyrics by pressing a shuffle button
- Add a new song
- When entering lyrics, the user should separate the lines of lyrics with a comma. **HINT FOR LATER** when the form is submitted, the app could `split` the lines by comma for use in an array
#### Set up - you will need:
- `index.html`
- `app.js`
- `style.css` if you want to add some style
Server and database will be introduced tomorrow
#### Angular stuff you will probably want:
#####Display songs
- A link to Angular 1.5 from https://angularjs.org/
- module / `ng-app`
- controller / `ng-controller`
- `ng-repeat` ( you might want to include a `track by $index` in the directive params, but if you don't need to, then don't)
- `ng-click` (hint: you can pass in $index as a param)
- `ng-if` or alternatively, `ng-hide` and/or `ng-show`
- curlies `{{ }}`
#####Add a song
- a form with an `ng-submit`
- inputs that rout to `ng-model`s which could be inside a formdata object in the controller maybe.
Overall, you will need data and functions in your controller.
#####Sample data
```
this.songs = [
{
author: "De La Soul",
title: "Ring Ring Ring",
lyrics: [
"Hey how ya doin'",
"Sorry ya can't get through",
"Why don't you leave your name",
"And your number",
"And I'll get back to you"
],
year: 1991,
hidden: false
}, {
author: "Ini Kamoze",
title: "Here Comes the Hotstepper",
lyrics: [
"Here comes the hot stepper",
"I'm the lyrical gangster",
"Pick up the crew in-a de area",
"Still love you like that"
],
year: 1995,
hidden: false
}, {
author: "Snow",
title: "Informer",
lyrics: [
"Informer",
"You no say daddy me Snow me-a gon' blame",
"I lick he boom boom down",
"'tective man they say, say daddy me Snow me stab someone down the lane",
"I lick he boom boom down."
],
year: 1993,
hidden: false
}
];
```
#####Shuffle function
Pass in an array and the shuffle function will randomize the order of the elements
@ -22,9 +39,8 @@ The concept of branching is that you are creating a replica of your codebase, wh
- Branches exist locally on our git, as well as remotely on GITHUB! This is a HUGE concept to remember!
- Branches exist locally on our git, as well as remotely on GITHUB! This is a HUGE concept to remember!
- Creating a new branch replicates the branch you are currently on.
- Creating a new branch *replicates the branch you are currently on*.
- Changes branches literally changes the OS file structure for that repo.
###### Commands
###### Commands
- `git branch` will return a list of branches for that repo along with an asterisk next to the current branch
- `git branch` will return a list of branches for that repo along with an asterisk next to the current branch
@ -33,22 +49,28 @@ The concept of branching is that you are creating a replica of your codebase, wh
- `git checkout branchname`: this is how you switch branches
- `git checkout branchname`: this is how you switch branches
===== LAPTOPS OPEN ======
• Exercise
## Exercise
- Create a directory
- In your terminal, go inside your `unit_03/section/w08d02/morning_exercise` folder.
- Create a directory called `branch_test`
- CD into it
- CD into it
- touch file1.txt
- touch file1.md
- git init
- git init
- make your init commit
- make your init commit
- create and checkout into test-branch1
- create and checkout into test-branch1
- touch file2.txt
- touch file2.md
- commit
- commit
- check back into master branch
- check back into master branch
- create and checkout test-branch2
- is file2.md there? Why or why not?
- touch file3.txt
- touch file4.txt
- ALWAYS FROM MASTER, create and checkout test-branch2
- touch file3.md
- touch file4.md
- commit
- commit
- check back to master
- Look at your files. Which ones are there?
- checkout back to master
- Which files are there?
#### Branch Conventions
#### Branch Conventions
- Branches should typically be named after features you are working on.
- Branches should typically be named after features you are working on.
@ -74,7 +96,7 @@ We'll run through a good scenario in a bit.
Merging is when you integrate the work from various branches. Git does a pretty good job integrating changes as seamlessly as possible. Merge conflicts naturally occur during the course of group work, it's not always an indicator of bad code or someone doing something wrong.
Merging is when you integrate the work from various branches. Git does a pretty good job integrating changes as seamlessly as possible. Merge conflicts naturally occur during the course of group work, it's not always an indicator of bad code or someone doing something wrong.
##### Local Merging
##### Local Merging
I strongly advise local merging. By that I mean, regardless of who did what on where, I like having branches on my local laptop, and merging them through my terminal.
We strongly advise local merging. By that we mean, regardless of who did what on where (github, local machines), you should have an up-to-date master branch on your local machine and up-to-date branches.
`git merge branchname`
`git merge branchname`
@ -84,33 +106,31 @@ I strongly advise local merging. By that I mean, regardless of who did what on w
- Always keep up to date with commits.
- Always keep up to date with commits.
## EXERCISE
## EXERCISE
- Make master branch have all the files
- Make master branch have all the files by doing the following:
- git checkout test-branch1
- git checkout test-branch1
- verify the files and commit
- verify the files and commit
- check back into master
- check back into master
- git merge test-branch1
- git merge test-branch1
- repeat the process of checking into branches and verifying the files and commits, then check into master and merge them.
- check your file - did it merge?
- repeat the process of checking into branches and verifying the files and commits for the rest of your branches, then check into master and merge them.
- Note: when you are doing this in a development environment, your code would only be merged onto the master after your branch passed inspection by another developer and they merged your code (or if you approved the code from another developer and merged their code).
You can also handle merges from the github remote account using pull requests but I dislike that process for various reasons...
- You can also handle merges from the github remote account using pull requests. We will do this in the next exercise.
1. Local merging allows you to merge using sublime instead of the github website, in other words it's my own comfort level with subl linter, and various search commands that let me run throughout a codebase structure much faster `command` + `shift` + `f` in particular.
2. Local merging involves me directly running other branches on MY local environment allowing me to QA work directly. Code that is tested across other people's environments is definitely considered better code. Do not assume it worked on mine, it must be fine. Finding bugs early means less future branch merges will be corrupted.
### Merge Conflicts
### Merge Conflicts
Merge conflicts don't occur as frequently when using git individually as opposed to when multiple branches exist with various time streams of commits.
Merge conflicts don't occur as frequently when using git on your own as opposed to when multiple branches exist with various time streams of commits.
- mkdir and cd into `conflicts`
- insde your `branch_test` file, mkdir and cd into `conflicts`
- touch scripts.js
- touch `scripts.js`
- Add the following code:
```
```
console.log(1);
console.log(1);
console.log(2);
console.log(2);
console.log(3);
console.log(3);
```
```
- git add, commit
- git add, commit
- git checkout -b add-moar-numbers
- git checkout -b adding-numbers
- add console.log(4) abnd console.log(5)
- add console.log(4) and console.log(5) to your `scripts.js` file
- git add, commit
- git add, commit
- git checkout master
- git checkout master
- git checkout -b adding-names
- git checkout -b adding-names
@ -124,11 +144,8 @@ console.log('c');
```
```
- git add, commit
- git add, commit
- git checkout master
- git checkout master
- Before proceeding, let's diagram where we are at.
- git merge adding-numbers
- git merge adding-letters
- git merge add-numbers
- git merge add-letters
- MERGE CONFLICT
- MERGE CONFLICT
- Resolving them in sublime, open the entire repo in sublime
- Resolving them in sublime, open the entire repo in sublime
@ -167,22 +184,17 @@ console.log('c');
### SUGGESTED TEAM WORKFLOW
### SUGGESTED TEAM WORKFLOW
- Appoint a git overlord/mastermind/tactician/ninja/or other badass title
- Appoint a git master/leader/overlord/mastermind/tactician/or other cool title
- THE TEAM is responsible for VCS, it's not fair or right to dump git issues on the overlord and walk away.
- THE TEAM is responsible for version control; it's not fair or right to dump git issues on the overlord and walk away.
- The overlord is the point of contact to handle the team's various accounts.
- The overlord is the point of contact to handle the team's various accounts.
- The overlord should make the original repo on local
- The overlord should make the remote repo on their github
- The overlord should make the remote repo on their github
- Add their teammates as collaborators on that github remote repo
- Add their teammates as collaborators on that github remote repo
OVERVIEW
OVERVIEW
- All team members will work on new branches off local
- All team members will work on new branches off local
- All team members will push their new branches to new branches on the remote repo
- All team members will push their new branches to new branches on the remote repo
- The overlord will begin a merge process where he/she recreates all the new branches on the remote onto their local
- Overlord merges all the new local branches into master branch one by one off their local
- Overlord push the new master branch to remote
- All team members will constantly pull master whenever they start a new feature branch, go eat a meal, start a day, end of day, etc. The more frequent they pull from master, the easier merging will be.
- All team members will constantly pull master whenever they start a new feature branch, go eat a meal, start a day, end of day, etc. The more frequent they pull from master, the easier merging will be.
DIAGRAM DIAGRAM DIAGRAM
### Final thoughts
### Final thoughts
- ALWAYS KNOW WHAT BRANCH YOU ARE ON
- ALWAYS KNOW WHAT BRANCH YOU ARE ON
@ -194,12 +206,12 @@ DIAGRAM DIAGRAM DIAGRAM
- Pair programming: multiple devs working off 1 computer also minimized merge conflicts
- Pair programming: multiple devs working off 1 computer also minimized merge conflicts
- DON'T DELETE BRANCHES. Better having redundant branches than losing work.
- DON'T DELETE BRANCHES. Better having redundant branches than losing work.
- DON'T TIME TRAVEL. Each team member has a local git and a remote github. Each has multiple branches, both remote and local. Each branch has different commit time streams. When reverting time you are messing with the HEAD.
- DON'T TIME TRAVEL. Each team member has a local git and a remote github. Each has multiple branches, both remote and local. Each branch has different commit time streams. When reverting time you are messing with the HEAD.
- Don't avoid VCS, tackle it head on. Be sure to rep the process with everyone before starting! If a team member can't explain it or whiteboard it, don't assume it will work itself out. Submit a git issue or ask an instructor for help getting the process down.
### LAB
### LAB
Partner up.
Partner up.
Partner A. Create a directory, git init. npm init an express app that just runs app.listen and console logs the port. Git add and commit.
Partner A. Create a directory, git init. Create an index.html file that has an `<h1>` that welcomes you to the page. Git add and commit.
Create a remote repo on github. Sync that remote to your local. Push and update the remote.
Create a remote repo on github. Sync that remote to your local. Push and update the remote.
@ -209,37 +221,44 @@ Partner B, clone the repo from the github remote so you also have it on your loc
Partner A
Partner A
- Check you are on master branch
- Check you are on master branch
- Create a new branch called get-routes-branch
- Create a new branch called style-main-page.
- in that branch, npm install express.
- in that branch, create a .css style sheet.
- Add a get request to '/' that res.send('root');
- add styling that changes the background color of the .html page. Link the pages.;
- make a commit
- make a commit
- add another get request to '/joe' that res.sends('Joe');
- git push origin style-main-page.
- make a commit
- git push origin get-routes-branch
Partner B
Partner B
- Check you are on master branch
- Check you are on master branch
- Create a new branch called big-nasty-thom
- Create a new branch called footer-main-page
- in that branch, npm install express
- in that branch, open up your index.html
- Add a get request to '/thom' that res.send('Thom');
- Add `<footer>` tags to the bottom of your page and add the names of two footer links.
- Make a commit
- Add a get request to '/matt' that res.send('Matt');
- ADD A COMMENT UNDER EACH REQUEST THAT INCLUDES YOUR FAVORITE FOOD
- Make a commit
- Make a commit
- git push origin big-nasty-thom
- git push origin footer-main-page
Check github. You should see 3 branches on the remote, master, big-nasty-thom, and get-routes-branch.
Check github. You should see 3 branches on the remote, master, footer-main-page, and style-main-page.
Partner A
Partner A
- Make sure you are on your local master `git checkout master`
- Make sure you are on your local master `git checkout master`
- Make sure your local master is up to date with remote master `git pull origin master`
- Make sure your local master is up to date with remote master `git pull origin master`
- Replicate the missing branch(es) that are on done and on the remote that you do not have on your local.
- git checkout -b big-nasty-thom
Github:
- Go to your Github repo
- Click "New Pull Request"
- "base" should be `master` and "compare" should be the branch that you want to merge (the one that you worked on).
- Add a comment. Click "Comment".
- Partner A should take a look at Partner B's pull request, merge if okay, or comment back if it's not okay.
- Partner B should take a look at Partner A's pull request, merge if okay, or comment back if it's not okay.
OR
Local:
- Replicate the missing branch(es) that are done and on the remote that you do not have on your local.
- git checkout -b footer-main-page
- You are now in a new local branch with the same name, but it is a carbon copy of master
- You are now in a new local branch with the same name, but it is a carbon copy of master
- git pull origin big-nasty-thom
- git pull origin footer-main-page
- Now you are updating your local big-nasty-thom with the one from remote.
- Now you are updating your local footer-main-page with the one from remote.
- git checkout master. Make sure you go back to master.
- git checkout master. Make sure you go back to master.
- from master, merge big-nasty-thom `git merge big-nasty-thom`
- from master, merge footer-main-page `git merge footer-main-page`
- repeat the process for get-routes-branch (keep in mind your local get- routes branch will be identical to the remote one so there's no real surprise);
- repeat the process for style-main-page (keep in mind your local get- routes branch will be identical to the remote one so there's no real surprise);
- resolve the conflict as you see fit as relevant.
- resolve the conflict as you see fit as relevant.
- Both partners diagram each process off whiteboard or table!
Thom Page
10 years ago
