facn3 / ghm Goto Github PK

you have two navbars, what is the purpose for that?

https://github.com/FACN3/GHM/blob/master/index.html#L22-L32

Your code should be easy to read 📖 so its easy to understand for anyone coming to look at your code. Its good practice to decide on a way to write before starting and then stick with this throughout the project 👌 to stop inconsistencies such as in your css where there is a variety of blank lines or no blank lines between classes. Sometimes there are blank lines inside the classes which also makes it hard to read.

When writing code it is good practice to separate your concerns as this makes your code more readable both for yourselves and others coming to look at your project. Separation of concerns is applicable in your project where you are using both classes and id's (here) for styling. It is common practice to use classes for CSS and id's for your Javascript 🍁

it's shoud be mobile first **

AWESOME 🎉

I really like that you've added a section about the updates and the technologies in use 👍. You mention the user stories but it could be a good idea to include the ones mentioned here.

you can use the html tag footer instead of div with the id='footer'

https://github.com/FACN3/GHM/blob/master/index.html#L118

for example: https://www.w3schools.com/tags/tag_footer.asp

It is good practice to use semantic HTML because semantic html elements make it clear to the browser what the meaning of your content is.

It takes a while to get used to working on github however its a fairly important concept so in general we follow these rules:

• create issues for each feature
• create a new branch for one feature 🌳
• do some changes, add and then commit them using the commit message to relate to an issue (relates #1)
• checkout to master branch and git pull
• checkout to the branch you were working on and git merge master
• if you have merge conflicts you should solve them now
• git push and create your PR and assign your fellow team mates as reviewers
• all team members should then review your code and either approve ✅ or request changes ❌
• the final team member to review can merge the PR 🎉 and delete the branch 🗑️
• NEVER merge your own PR 🚫
• if everything to do with the issue is complete you can then close the issue 🙌

By creating issues you know exactly what work you are doing and so do your teammates. It is also worth noting the title and description of your commits and PR should explain what work you have done. I should be able to come to your project and view a coherent story of PR to see how your project has developed over time.

the tag is missing in the raw code on github. However, I can see it in the code under the console. May be browser adds it automatically

It's really good practice to have sensible names for variables, classes, ids etc. This will help you and others understand each part of your codebase better. There are two nav bars and the only difference is the ids navbar and navbar1. You probably know exactly what the difference is, and I could find out by going through the CSS but it would be easier for everyone if there was a descriptive title 👍

I do not have a problem with you using promises however this is a fairly advanced concept and I would be interested to know if everyone on the team understands promises concept. It is really important for everyone on the team to understand everything so please go through form.js together this morning.

A good reminder to switch up working each other's devices even when pair programming 👍 :

https://github.com/FACN3/GHM/graphs/contributors

Blocks of text should be limited to a certain number of characters/words per line. People are used to reading books with a line length of about 45–90 characters, so as line length becomes longer it starts to get harder to scan the content. See this link for some more info. If the below section of the site had a maximum width it would look a lot more professional / readable.

https://github.com/FACN3/GHM/blob/master/index.html#L35

https://github.com/FACN3/GHM/blob/master/index.html#L41

https://github.com/FACN3/GHM/blob/master/index.html#L44

https://github.com/FACN3/GHM/blob/master/index.html#L55

https://github.com/FACN3/GHM/blob/master/index.html#L56

https://github.com/FACN3/GHM/blob/master/index.html#L112

When writing code we all comment out sections of code as this is a really useful way to try out different things. However once you have decided on the code you want its good to delete 🗑️ the commented code otherwise your files can get messy and become hard to read. These are the only lines I could find so its only a minor point 👍

should be in read me 👍

One of the user stories for this week:

As a client with JavaScript disabled in their browser for security reasons
I would like to visit your site and get a similar experience to viewing your site on a modern browser with JavaScript enabled
so that I don't feel like I'm completely in the stone age.

When I disable Javascript the form doesn't submit. Is there another way you could do a form without using Javascript?

For this project it's a really good idea to host the site using github pages and provide a link in the README so people can view your site.

Good indentation is really important as it makes code more readable! You can use an atom package called atom-beautify and that will help you to avoid your code looking like this and this.