rapid web development

Unit 2,

Class 2

More Git, CLI, Maybe A Little Agile

Quiz

Bring your own hardware


Please. A professional needs tools.

Eventually we will need to install tools that the school's computers disallow.

We don't leave this slide until everyone's on the Class G+ Community

https://plus.google.com/u/0/communities/113771959316964112503

What did we learn from hw01?



Ken Robinson:
If you're not prepared to be wrong, you'll never come up with anything original

That's the goal of this class. To be wrong a lot.

More Git

Let's cover git in more depth today.

We'll do all this together, watching results in GitHub in real time.

Pull up SourceTree's command line:


In class exercise

We're going to clone a new git repo today. All of us will work in this same repo, at the same time (last week we made our own individual forks). We will pull and push and make changes together. We will do all this using the command line.

Git + CLi, Step 1

Navigate to your wdim351 folder we mentioned before. Your command might look like this:
cd /Users/yourloginname/school/wdim351/
Notes:
This command takes you to your "home" directory in both OSX and Windows:
cd ~/
Run this command frequently to see what is in your current folder:
ls

Git + CLI, Step 2

Clone the repo specifically for this exercise:
git clone git@github.com:aipdx-wdim351/wdim351-inclass-week02.git

or

git clone https://github.com/aipdx-wdim351/wdim351-inclass-week02.git


This is what my "wdim351" folder looks like now:


Git + CLI, Step 3

Now let's all navigate into this new repo we just cloned:
cd wdim351-inclass-week02/

(Hint: hit tab to autocomplete after typing out "wdim351-in")

Now run:
ls

You should see a listing of the files within this directory.

Git + Cli, Step 4

Now, we're each going to make our own git branch within this repo so we can make changes without worrying about colliding with others:
git branch <yourlastname>
In my case, it will look like:
git branch bloom

Now, list out all the branches so you can see which you've currently checked out:

git branch -a

You should see your branch listed with "master". Master should have a star next to it.

Git + CLI, Step 5

Now checkout your branch:
git checkout <yourlastname>

Double check that you did that right by running:

git branch -a

You should see a star next to your named branch. Congrats! You've made a branch within a git repo!

Git + Cli, Step 6

Make a folder using the pattern "<yourlastname>-folder", like this:
mkdir bloom-folder

You're going to put some stuff in this folder, but first you have to navigate to the folder:

cd bloom-folder/

Please use your last name and not "bloom".

Git + Cli, Step 7

Let's make a small text file using vi:
vi README.md
You are now looking at a blank text file. This looks scary. It's easy once you know a couple of vi commands. 

Hit "i" to enter "Insert" mode.

Type: "<yourname> was here", then hit Escape, then type
:wq
And hit Enter.

Git + CLI, Step 7 (cont'd)

What just happened there?

vi started editing a blank document. We told vi to enter "Insert" mode, which basically just means we can edit our document. Hitting Escape put us back out to "Command" mode where we can run commands inside of vi. You start a vi command with ":" and then text commands. ":wq" means "write this file (save) and then quit vi".

Git + CLI, Step 8

Let's get our changes add to Git. First, let's go up a level in our project folder structure:
cd ..

We should now be in the root of our project; right inside the folder wdim351-inclass-week02.

 

Let's check the status of our files according to Git:

git status

Git should let you know that there are some files that are new/changed.

Git + CLI, Step 9

Let's add this folder and file to Git:
git add .
The "." just means "everything within this folder".
Running git status again will inform you that there are "Changes to be committed". Our files are in a state called "staged"; that is, git knows about them but they haven't been saved hard into the repo yet.

Let's commit these changes, with a message.
git commit -m "my first git commit!"

Git + CLI, Step 10

Look at the history of your branch:
git log
You may need to type ":q" to exit the log. Does that command look familiar?

Now, let's all push our branches up to GitHub:
git push origin <yourlastname>

This is saying "Push y <yourlastname> repo to where I originally cloned this from (GitHub). "

Git + Cli, Step 11

Now, visit this repo in your browser: https://github.com/aipdx-wdim351/wdim351-inclass-week02

Take a look at your branch:

Git + Cli, Step 12

Watch your folder appear and disappear when you switch branches in GitHub.

What is happening? 

Git + Cli, Step 13

Let's merge your changes into the master branch and push this back up to GitHub so everyone can see your awesome work.
Checkout master branch:
git checkout master

Merge <yourlastname> branch into current branch:

git merge <yourlastname>

Always, always, always pull changes before pushing:

git pull origin master

Now push up your changes:

git push origin master

Git + CLI, Step 14

Watch the master branch fill up with folders by periodically git pull ing. Think about that for a second:

Twenty people just contributed to the same project at exactly the same time. No emails, no conflicts, no accidentally overwriting others' work.

Git + CLI, Step 15

Let's kick it up a notch. Everyone will now edit the root README.md and follow the instructions. It will look something like this (from root folder of repo): 
git checkout <yourlastname>
git merge master
vi README.md
(edit file)
git add .
git commit -m "made my changes!"
git checkout master
git merge <yourlastname>
git pull origin master
git push origin master

something totally different


You only need one skill to be successful and get paid boatloads while doing fulfilling work.

And it's not a web language.



(www.pivotaltracker.com)

prep for agile


  1. Sign up for PivotalTracker
  2. Post your PivotalTracker email to G+ post
  3. Split into developer/designer/manager groups
  4. Assigned teams
  5. Members assigned to Pivotal group and team projects

Agile doesn't suck as much


Project management methodologies usually suck.

Agile sucks less.


Agile values

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Agile is about getting things done

Methodologies:

  1. SCRUM*
  2. Extreme Programming
  3. Lean Software Development

Scrum roles


  1. Product owner
  2. ScrumMaster (yes, really)
  3. Team

Scrum Ceremonies

  1. Sprint planning - "This software won't build itself", plan 2-3 sprints worth, all attend
  2. Sprint review - End of one sprint, show off one sprint worth of work to client, all attend
  3. Sprint retrospective - internal: scrummaster & team go over prior sprint
  4. Daily Scrum meeting - internal only, 15 minutes, review yesterday, talk about today.

Sprint planning

  1. Product owner describes highest priority features first, about two full sprints worth.
  2. Should produce a sprint goal ("Implement a basic commenting system for anonymous users.")
  3. Should produce a backlog of tasks (See pivotaltracker, coming up)

Tasks (or "stories"), we'll also cover in the Pivotal demo.

Sprint review

  1. Show and tell between team and product owner
  2. Informal, no PowerPoint because slides are for chumps
  3. Assess against Sprint Goal.
  4. Acquire new features from product owner if not on final sprint.
  5. Adapt to changing requirements

Sprint Retrospective

  1. Scrum master and team only.
  2. "How'd we do?"
  3. "How can we do it better?"
  4. "What did we learn?"
  5. Scrum master: if there are things getting in the way, now's the time to start fixing them

Daily Scrum Meeting

  1. No, I don't know if "scrum" stands for anything
  2. Meet at start of day
  3. Those committed to the project are allowed to talk
  4. 15 minutes max
  5. Not a problem solving meeting, take those offline
  6. "What did we do yesterday?"
  7. "What's happening today?"
  8. "Anything preventing you from getting stuff done?"

Benefits (See tuts article)

  1. Customer satisfaction
  2. Flexible requirements
  3. Deliver frequently
  4. Face time
  5. Internal motivation
  6. Easier to measure progress
  7. Consistent pace
  8. Simplicity
  9. Self-organization
  10. Reflection

Pivotaltracker


Sign in, watch some vids.

Homework

In PivotalTracker in the project for your team, hold a quick sprint planning and create a backlog of stories that describe this simple deliverable:

"An e-commerce website would like to revamp their contact form. It should pop up in a modal window. All fields are required to be filled in. It should autofill in their first and last name if they are signed in. It should send all the information they input in the fields to the proper site admin depending on what the user selected for 'Type of contact' field."

Minimum 10 stories, arrange by priority, assigned to members. Pay attention to Agile rules.

wdim351_week02

By Christopher Bloom

Made with Slides.com

wdim351_week02

  • 2,599

More from Christopher Bloom