fix links

Author: tieubao

README.md

@@ -5,20 +5,18 @@ description: null
 date: 2021-12-30
 authors:
   - tieubao
-hide_title: true
 tags:
   - playbook
+hide_title: true
 ---
 
-# Dwarves Playbook
-
 Dwarves Foundation is an innovation service firm. We have been building an organization with high standard software practices and business growth capabilities, helping tech startups, entrepreneurs and makers deliver their innovative software product since 2013.
 
 We stand for the craftsmanship in software development. More than telling people how to do things, as a team, we take responsibility for collaboratively creating the product of innovation with the client. We value the long-term partnership, and we brought the economic impact through massive product distribution and brought to the market by the clients.
 
 This repo is our playbook which contains our practices in software development and also how we collaborate to make them succeed.
 
-![](engineering/assets/team-images.webp)
+![](assets/team-images.webp)
 
 ## Product Design
 

…56a8496bb80c42b7c2b89d718b1da48_MD5.avif …56a8496bb80c42b7c2b89d718b1da48_MD5.avifdesign/assets/prototype/d56a8496bb80c42b7c2b89d718b1da48_MD5.avif renamed to design/assets/d56a8496bb80c42b7c2b89d718b1da48_MD5.avif design/assets/prototype/d56a8496bb80c42b7c2b89d718b1da48_MD5.avif renamed to design/assets/d56a8496bb80c42b7c2b89d718b1da48_MD5.avif

@@ -63,7 +63,7 @@ Design some demo screens and send to the client to verify style, color palette,
 
 Design systems enable teams to build better products faster by making design reusable, reusability makes scale possible. This is the heart and primary value of design systems. A design system is a collection of reusable components, guided by clear standards, that can be assembled together to build any number of applications.
 
-![](assets/d56a8496bb80c42b7c2b89d718b1da48_MD5.avif|"Design System")
+![](assets/d56a8496bb80c42b7c2b89d718b1da48_MD5.avif)
 
 ### How we build Design System
 

design/prototype.md

@@ -32,7 +32,7 @@ Information architecture (IA) is, like a blueprint, a visual representation of t
 
 - Sitemap
 
-!["Sitemap"](assets/wireframe/203ab5b0117c8ecbeb2cf2db4b549d51_MD5.gif)
+!["Sitemap"](assets/203ab5b0117c8ecbeb2cf2db4b549d51_MD5.gif)
 
 - Card Sorting
 

design/wireframe.md

@@ -14,7 +14,7 @@ You can read more about the philosophy of the 12-factor app <https://12factor.ne
 
 > One codebase tracked in revision control, many deploys
 
-**A twelve-factor app is always tracked in a version control system.** We use [git](playbook/engineering/git.md) to track any changes in the code of a repo.
+**A twelve-factor app is always tracked in a version control system.** We use [git](git.md) to track any changes in the code of a repo.
 
 There is only one codebase per app, but there will be many deploys of the app. We usually have one deploy for the following environment: local, development, staging and production.
 

engineering/12-factor-app.md

@@ -30,7 +30,7 @@ They are not the standard but should capture what we want to deliver.
 
 - [ ] Changelogs are for humans, not machines.
 - [ ] Write all dates in YYYY-MM-DD format.
-- [ ] Follow [Semantic Version](playbook/engineering/versioning).
+- [ ] Follow [Semantic Version](versioning.md).
 - [ ] The same types of changes should be grouped
   - `Added` for new features.
   - `Changed` for changes in existing functionality.

engineering/changelog.md

@@ -8,33 +8,29 @@ date: null
 
 While the vast majority of base code style is enforced by [ESLint](https://eslint.org/) and [Prettier](https://prettier.io/), please also where possible, stick to the contribution guidelines below. These rules should be kept in mind when reviewing Pull Requests:
 
-- Code should be functional in style rather than Object Orientated or Imperative unless there are no clean alternatives.
+Code should be functional in style rather than Object Orientated or Imperative unless there are no clean alternatives.
 
-  - Use pure functions where possible to make them testable and modular.
-  - Avoid mutating variables and the `let` keyword.
-  - Prefer functional & immutable array methods .ie `map`/`filter`/`reduce`/`some`/`every` over any types of mutable `for` loop.
-  - Prefer "return early" coding style, more about it [here](https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88).
-  - Avoid classes and stateful modules where possible.
-  - Don't Repeat Yourself. Make extensive use of the constants and utils files for re-usable strings and methods.
-  - Don't obsess over performance of code, obsess over making it clear.
-  - The above rules can be relaxed for test scripts.
+- Use pure functions where possible to make them testable and modular.
+- Avoid mutating variables and the `let` keyword.
+- Prefer functional & immutable array methods .ie `map`/`filter`/`reduce`/`some`/`every` over any types of mutable `for` loop.
+- Prefer "return early" coding style, more about it [here](https://medium.com/@matryer/line-of-sight-in-code-186dd7cdea88).
+- Avoid classes and stateful modules where possible.
+- Don't Repeat Yourself. Make extensive use of the constants and utils files for re-usable strings and methods.
+- Don't obsess over performance of code, obsess over making it clear.
+- The above rules can be relaxed for test scripts.
 
-- React components should be simple and composable and cater to real life UI design problems:
+React components should be simple and composable and cater to real life UI design problems:
 
-  - **Simplicity**: Strive to keep the component API fairly simple and show real-world scenarios of using the component.
-  - **Representational**: React components should be templates, free of logic, and purely presentational. It aims to make our components shareable and easy to test.
+- **Simplicity**: Strive to keep the component API fairly simple and show real-world scenarios of using the component.
+- **Representational**: React components should be templates, free of logic, and purely presentational. It aims to make our components shareable and easy to test.
+- **Composition**: Break down components into smaller parts with minimal props to keep complexity low, and compose them together. This will ensure that the styles and functionality are flexible and extensible.
+- **Accessibility**: When creating a component, keep accessibility top of mind. This includes keyboard navigation, focus management, color contrast, voice over, and the correct aria-\* attributes.
+- **Naming Props**: We all know naming is the hardest thing in this industry. Generally, ensure a prop name is indicative of what it does. Boolean props should be named using auxiliary verbs such as `does`, `has`, `is` and `should`. For example, Button uses `isDisabled`, `isLoading`, etc.
 
-  - **Composition**: Break down components into smaller parts with minimal props to keep complexity low, and compose them together. This will ensure that the styles and functionality are flexible and extensible.
+When doing styling, strive to use `tailwindcss` classes for consistency and painless maintenance.
 
-  - **Accessibility**: When creating a component, keep accessibility top of mind. This includes keyboard navigation, focus management, color contrast, voice over, and the correct aria-\* attributes.
-
-  - **Naming Props**: We all know naming is the hardest thing in this industry. Generally, ensure a prop name is indicative of what it does. Boolean props should be named using auxiliary verbs such as `does`, `has`, `is` and `should`. For example, Button uses `isDisabled`, `isLoading`, etc.
-
-- When doing styling, strive to use `tailwindcss` classes for consistency and painless maintenance.
-
-  - Avoid hard coding colors. All colors from the design guideline should be pre-defined in [`tailwind.js`](../tailwind.config.js). Please use them with respect.
-
-  - Try to avoid injecting styles via `style` attribute because it's impossible to build responsiveness with inline styles. Strive to only use Tailwind classes for sizing, spacing, and building grid layouts.
+- Avoid hard coding colors. All colors from the design guideline should be pre-defined in `tailwind.js`
+- Try to avoid injecting styles via `style` attribute because it's impossible to build responsiveness with inline styles. Strive to only use Tailwind classes for sizing, spacing, and building grid layouts.
 
     ```jsx
     // Don't
@@ -50,41 +46,42 @@ While the vast majority of base code style is enforced by [ESLint](https://eslin
     </div>
     ```
 
-- Maintain the separation of concerns in the folder, for example:
+Maintain the separation of concerns in the folder, for example:
+
+- `constants/` contains shared variables used across the app.
+- `components/` contains shared ui components used across the app.
+- `utils/` contains shared functions used across the app.
+- `hooks/` contains shared hooks used across the app.
+- `types/` contains common `TypeScript` types or interfaces.
 
-  - `constants/` contains shared variables used across the app.
-  - `components/` contains shared ui components used across the app.
-  - `utils/` contains shared functions used across the app.
-  - `hooks/` contains shared hooks used across the app.
-  - `types/` contains common `TypeScript` types or interfaces.
+When adding third party libraries to the project consider carefully the following;
 
-- When adding third party libraries to the project consider carefully the following;
+- Is this a trivial package we can easily write in-house? If so, take the time to roll your own.
+- Is this library well supported, under active development and widely used in the community? If not, do not use it.
+- Do we use a similar but different library for the same task elsewhere in the company? If so, use this library for developer familiarity and consistency.
+- Will this library impact significantly performance or bundle size eg `Lodash` or `Moment`? If so, consider carefully if it is necessary or if there is a better alternative.
 
-  - Is this a trivial package we can easily write in-house? If so, take the time to roll your own.
-  - Is this library well supported, under active development and widely used in the community? If not, do not use it.
-  - Do we use a similar but different library for the same task elsewhere in the company? If so, use this library for developer familiarity and consistency.
-  - Will this library impact significantly performance or bundle size eg `Lodash` or `Moment`? If so, consider carefully if it is necessary or if there is a better alternative.
+TypeScript helps write code better but should be used with care to not lose its strengths:
 
-- TypeScript helps write code better but should be used with care to not lose its strengths:
+- Avoid using `any` when possible. Using `any` is sometimes valid, but should rearely be used, even if to make quicker progress. Even `Unknown` is better than using `any` if you aren't sure of an input parameter.
+- Pay attention when using the non-null assertion operator `!`. Only use if you know that a variable cannot be null right now rather than blindly using it to pass the validation step.
 
-  - Avoid using `any` when possible. Using `any` is sometimes valid, but should rearely be used, even if to make quicker progress. Even `Unknown` is better than using `any` if you aren't sure of an input parameter.
-  - Pay attention when using the non-null assertion operator `!`. Only use if you know that a variable cannot be null right now rather than blindly using it to pass the validation step.
+File naming should be `PascalCase` for all React components files and `kebab-case` for the rest.
 
-- File naming should be `PascalCase` for all React components files and `kebab-case` for the rest.
+Exports from files can be either as variable or default exports, but please stick to naming the object before using `export default` to avoid anonymous module names in stack traces and React dev tools.
 
-- Exports from files can be either as variable or default exports, but please stick to naming the object before using `export default` to avoid anonymous module names in stack traces and React dev tools.
+Your app should be fast but also remember "Premature optimization is the root of all evil". **If you think it’s slow, prove it with a benchmark.**, the profiler of [React Developer Tools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) (Chrome extension) is your friend! Once you find the root cause, try to follow the suggestions to fix it:
 
-- Your app should be fast but also remember "Premature optimization is the root of all evil". **If you think it’s slow, prove it with a benchmark.**, the profiler of [React Developer Tools](https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi) (Chrome extension) is your friend! Once you find the root cause, try to follow the suggestions to fix it:
-  - Use `useMemo` mostly just for expensive calculations.
-  - Use `React.memo`, `useMemo`, and `useCallback` for reducing re-renders, they shouldn't have many dependencies and the dependencies should be mostly primitive types.
-  - Make sure your `React.memo`, `useCallback` or `useMemo` is doing what you think it's doing (is it really preventing rerendering?).
-  - Stop punching yourself every time you blink (fix slow renders before fixing rerenders).
-  - Putting your state as close as possible to where it's being used will not only make your code so much easier to read but It would also make your app faster (state colocation).
-  - `Context` should be logically separated, do not add to many values in one context provider. If any of the values of your context changes, all components consuming that context also rerenders even if those components don't use the specific value that was actually changed.
-  - You can optimize `context` by separating the `state` and the `dispatch` function.
-  - Know the terms [`lazy loading`](https://nextjs.org/docs/advanced-features/dynamic-import) and [`bundle/code splitting`](https://reactjs.org/docs/code-splitting.html)
-  - Window large lists (with [`tannerlinsley/react-virtual`](https://github.com/tannerlinsley/react-virtual) or similar).
-  - A smaller bundle size usually also means a faster app. You can visualize the code bundles you've generated with [`@next/bundle-analyzer`](https://www.npmjs.com/package/@next/bundle-analyzer).
+- Use `useMemo` mostly just for expensive calculations.
+- Use `React.memo`, `useMemo`, and `useCallback` for reducing re-renders, they shouldn't have many dependencies and the dependencies should be mostly primitive types.
+- Make sure your `React.memo`, `useCallback` or `useMemo` is doing what you think it's doing (is it really preventing rerendering?).
+- Stop punching yourself every time you blink (fix slow renders before fixing rerenders).
+- Putting your state as close as possible to where it's being used will not only make your code so much easier to read but It would also make your app faster (state colocation).
+- `Context` should be logically separated, do not add to many values in one context provider. If any of the values of your context changes, all components consuming that context also rerenders even if those components don't use the specific value that was actually changed.
+- You can optimize `context` by separating the `state` and the `dispatch` function.
+- Know the terms [`lazy loading`](https://nextjs.org/docs/advanced-features/dynamic-import) and [`bundle/code splitting`](https://reactjs.org/docs/code-splitting.html)
+- Window large lists (with [`tannerlinsley/react-virtual`](https://github.com/tannerlinsley/react-virtual) or similar).
+- A smaller bundle size usually also means a faster app. You can visualize the code bundles you've generated with [`@next/bundle-analyzer`](https://www.npmjs.com/package/@next/bundle-analyzer).
 
 ## Read on
 

engineering/frontend/code-style.md

@@ -8,15 +8,15 @@ date: null
 
 It's like a time machine. We can save and reload anytime we want to, like in the old day of Game Boy Advance. We can work in parallel universes of our source code, experimenting without fear of losing work, and rolling back if something goes wrong.
 
-[We use git](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github). Git is one of the most popular distributed source version control. We use [Github](github.com/dwarvesf/) to open source our works, playbook, and practices. We also have a [self-host Gitlab](git.d.foundation) to store all of our source code.
+[We use git](https://egghead.io/courses/how-to-contribute-to-an-open-source-project-on-github). Git is one of the most popular distributed source version control. We use [Github](https://github.com/dwarvesf/) to open source our works, playbook, and practices. We also have a `self-host cgit` to store all of our source code.
 
 ## Commit Message Guidelines
 
 Hour commit conventions are based on [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/#specification)
 
 Commit message should be structured as follows
 
-```
+```bash
 # A - inline command
 git commit -m "<type>(optional scope): <commit message>"
 

engineering/git.md

@@ -17,7 +17,7 @@ Basecamp, for example.
 
 Our path with Basecamp didn't cross by accident. Years ago, we embarked on the Slack community and had it applied for internal communication. And project management on another tool, where documents & files are in G-suite. Every day is a short strip from one place to another. Then get back. Then do it again tomorrow.
 
-![](adjust-the-way-we-work-in-basecamp-style_658f6b0263106796290e37aa78015232_md5.webp)
+![](assets/adjust-the-way-we-work-in-basecamp-style_658f6b0263106796290e37aa78015232_md5.webp)
 
 As much as we enjoyed the fast replies and high-engaging interaction amongst the member, it's challenging to focus on the work. Every smallest message can become a team gossip/ discussion, not to mention the biggest distracting part - memes. That shit is unstoppable.
 
@@ -98,7 +98,7 @@ When you've had enough with the scrolling, a shortcut is a savior. Basecamp take
 
 Basecamp is formal enough to keep people concentrated on what they do, but still it gives them the chance to be creative.
 
-![](adjust-the-way-we-work-in-basecamp-style_f6faf06ec700b2002c00cd15aa3ea707_md5.webp)
+![](assets/adjust-the-way-we-work-in-basecamp-style_f6faf06ec700b2002c00cd15aa3ea707_md5.webp)
 
 Another thing that drives us toward is how Basecamp makes things transparent. The 'Activity' tab reveals everything we need to know, whenever we need it. That somehow helps us focus on what matters, and reduce the risk of FOMO.
 

operations/adjust-the-way-we-work-in-basecamp-style.md

@@ -13,7 +13,7 @@ tags:
 
 Through this process, the employee gradually form their own perspective and their fit with the Dwarves. This is the stage when they decide whether or not to commit to our company.
 
-![](onboarding-checklist_onboard.webp)
+![](assets/onboarding-checklist_onboard.webp)
 
 ## Important Notes