UKM-Heroes Wiki

For Ilman, Vadim, Wahyu , Ira and Rizal

What is this wiki all about?

The documentation below is aimed towards the people above, with the hopes of giving an understanding about the project structure of UKM-heroes and guidelines on how to work on this project. Hence, we can maintain the workflow and code within our time during software engineering project (and hopefully our sanity when refactoring, debugging our own or others code).

Getting Started

1. Clone the ukm-heroes repository (on which I believe everyone has already access to).
2. Make sure you already have npm and the angular cli.
3. then “ ng serve “ without quotes on the ukm root directory.

Setting Up Your Workspace

1. Hopefully you’re using WebStorm because it would ease your life.
2. Make sure that your Linting is using TSLint (A TypeScript Linter) because Angular uses TypeScript, a subset of JavaScript.
3. And You’re ready to go ! (If supposedly you’re using another editor feel free to ask me or Ilman to set your code editor up 😃)

Project Structure & Naming conventions

“ When you’re refactoring and the codes are a mess “

Project Structure because it matters

1. For project structure, please checkout this link.
2. Also a great read by Tom Cowley, click here
3. Try to be descriptive in naming all of your components, functions, and variables. Always use English words.
4. Name all functions with camel case that starts with lowercase letter e.ggetAllPosts.
5. Use singular form in variable that contains only one thing. Use plural form when naming arrays. The same goes for naming functions ex: getAllPosts, not getAllPost

HTML classes should be straight-forward

1. Naming conventions for CSS classes should be started with the Component name, followed the BEM naming convention, which basically B (Block)= The root of the component, E (Element) = A component part of the block and M (Modifier) = An extension of the block.
2. Elements are delimited with two (2) underscores (__), and Modifiers are delimited by two (2) hyphens (--).
3. Also give space for other block components to maintain readability.

CSS can be painful to read 😥

1. All colors, common box shadows, and borders are placed inside shared.style.scss
2. NEVER use id (#SomePage__container). Use classes instead.
3. NEVER use “ !important “. Because this makes debugging very hard in large projects.
4. Do not use inline styling. Simply because its disgusting 🤮.
5. Let classes breathe between each other.
6. Do note that we would be using flex-box for our lay-outing purposes. Please check this link about flex-box, if you’re not familiar with it.
7. Since we are using SCSS, when using colors, define the color it into a variable.
8. Maintain your CSS order (group relevant properties together). see below

Workflow Guidelines

Work in a feature branch, for example if you’re working on navigation, make a navigation branch.

How to make a branch

1. make sure you’re branching from latest updated master branch
2. use command git checkout -b <your-branch-name>

*You can contact me or Ilman for git related problems

How to generate a component in Angular

1. Use command ng generate component <your-component-name> or ng g c <your-component-name> , g and c is only a shorthand for generate and component.
2. Supposedly you want to create your new component inside a specific folder, use command ng g c <your-folder-name>/<your-component-name>

*contact me if you have any generator related bug 🐜

GIT Rules

1. Make sure you don’t directly push to master.
2. “ Low churn High Impact “ commits, which means don’t commit push small changes unless necessary.
3. Use clear, short and concise commit messages.
4. --no-verify is a sin.
5. Before pushing make sure all tests has passed.

When you’re done with your branch…

1. For front-end features submit a Merge request and assign me as the assignee. I’ll try to review your codes ASAP. As for Back-end related features (if any) assign Ilman as the assignee.
2. When you make a Merge request message us on LINE.
3. After me or Ilman has reviewed your code, Ira would go to your branch and check for its usability and test if it fulfills the requirement from our backlog.
4. Once your work has been reviewed and accepted, merge your branch into master yourself. Make sure there are no conflicts and push your changes directly into the master branch.
5. Tell everyone that you have pushed your changes into master so that everyone can pull your changes immediately.
6. Tick your Trello task board.

*Communicate effectively, if you’re facing problem do not hesitate to ask in the Group Chat or any member of the team.

Merge Request Rules

1. Use descriptive title (make sure when everyone reads the title, at least they have an idea on it).
2. Clear descriptions ( when giving a merge request, clear descriptions give us an idea on what changes you make)
3. Supposedly your code is indicated as bad, please clarify or revise your code.
4. No conflicts.

“ Well that’s all folks! “