###### tags: `Bear Den` `Unit 1`
Back to [Bear Den - Web Reset Hour](/6MdxX2y0TVuVMR331tJS9w)
# March Edition - Unit 1 Monday
###### Branch march - [Repo Link](https://github.com/SHL-Melissa/web-reset-hour-unit-1)
###### [Recording](https://www.youtube.com/watch?v=WHs6p5Os0EM)
## Step 1
When creating any web page always know what the basic end result is going to be. Maybe not a picture but what is the idea behind it
Think of it like this:
As a User I can ___________
So for our site we are building a landing page for a Looney Tunes site that will educate those who don't know who the Looney Tunes are.
### So what do we need?
* We will need the following types of documents
* HTML file
* Your landing page will always be called index.html
* CSS file
* As long as you link it the name of this file can be anything most folks use styles.css
* For organizational purposes it is recommended to have these types of files in a CSS folder
* JS file (optional)
* This file is optional but can be quite helpful
* Naming for this file can be anything agian as long as it is linked correctly in the html doc, typically folks use scripts.js
* Like your CSS it is recommended to keep these in a JS folder
* CSS, JS, images folders
* Organization may not seem important with 1 or 2 images or 1 html file but as websites get larger the main folder should contain html docs and css, js, images folders. How you name your folders is up to you just be consistant
* We will need a outline of sorts for our page
* A good organized html doc helps not just you but developers that may come after you.
* For you using the same pattern of outline or organization means you are less likely to miss something.
* Here is a good outline:
```
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<link rel='stylesheet' href='./css/styles.css'>
<title></title>
</head>
<body>
<header>
<h1></h1>
<nav>
<a href='#'></a>
</nav>
</header>
<div class='main'>
</div>
<footer>
</footer>
</body>
</html>
```
* Images
* Most likely we are going to add at least 1 image so it's really smart to have those ahead of time.
## Step 2
Time to get down to coding.
* Focus on your html 1st
* It's going to be hard but the the content written 1st
* Dont' style anything till you have this done.
* Do you have a call to action?
* What do you have on your page that (although not styled) is going to get the users attention? Get them interested in what your site is about.
* Do you have a navigation?
* Good tip - add target="_blank" at the end of your links (most of them) so that your site stays in their browser.
* If it is a internal link don't use this.
* Indentation, indentation, indentation
* You'll thank me for this later, poorly indented code is horible to read and figure out.
* If you have a bug in your code trying to find it can be nearly impossible with out proper indentation.
* Make sure all files that you are linking too are in the project folder
* Every website should have it's own folder, and even it's own repository.
* Why? Well you don't want a webiste about Marvel to have html pages for a website about DC, thats just bad news.
* So keep them seperate.
* Inside each project/website folder is where any linked pages, images, or other documents should be, expecially when working locally.
* Be careful how you link things.
* Make sure to use the correct path, don't include c://Documents or things like that because when you go live my computer won't have the same information in Documents that yours does
## Step 3
* Test and Test often
* Don't just go make a whole lot of changes and then test because it might be harder to know what broke the site (if it broke of course).
* I'm not saying every little change you have to look, but using something like live server you can do a quick save and check say every section you complete.
* Commit and Commit often
* Just like testing you want to make sure you save your work.
* For this I would say every major change or every bug fix you should make a commit. You don't have to push to github every commit just make those save points
* At the end of the day you can push those commits up
## Tips for the road
Now on to my favorite part Tips
1. Commit messages: These should be short but relevent.
1. During the day my commit messages are ususally about what I just changed
2. At the end of the day when I push up my last commit might be saving for the night.
3. But keeking these relevent will help you if you ever need to find an old commit to maybe grab a peice of code that got deleted that shouldn't have.
2. Make a repo: Doesn't matter where you will push them too be it bitbucket, gitlab, amazon, or github.
1. Your computer will crash one day and you will thank me when it does because you didn't loose all your work
2. Employers love looking at things like your github, they want to see what you are up to.
1. Bonus: You can look back at old repos and remember the good old days or just see how far you have really come.
3. Branching: Do you really need it?
1. Yup, for the most part you should branch. Why?
1. If your working in a group this will help keep changes in order. So when Jane makes a change that happends to not work, and John makes a change all to the same file neither changes when pushed to their respective branches will effect the main/master branch so if that is live it is still working.
2. Even if you are the only one working on the project this can allow you to work on different parts or new features but again not break the main/master branch
2. Name your branches smartly.
1. Sometimes using your name is cool, like in a group project, but that seems kinda silly for a project where you are the only one, so here are some ideas for both cases
1. Group Project
1. melissa-landingPage ---- so this tells the whole group that melissa is working on the landing page in that branch
2. john-styling ---- again descriptive and tells everyone that john is working on the styling, this can be an important branch as john will be working on all files, where melissa is just working on one or 2 so keep this in mind
2. Personal Projects
1. styling ---- like above this tells me that in this branch all I am concerned with is the styling of the whole website
2. aboutPage ---- this states I will be working on the about page
4. Always, always, always git pull origin master:
1. This is most important when you are working on a group project. Changes get made all the time and when they are good to go they will get pushed into the main/master branch.
2. If I am working on my branch (melissa-aboutPage)but don't do a git pull origin master before I start making any changes all that styling that John did won't be on my page and when I push mine up, well lets just say my changes will make a whole lot of folks mad because there will be so many merge conflicts.
## More Wednesday
Sign in with Wallet
Connect another wallet