wording: replace "folder" with "directory" (#45)

README.md

@@ -4,7 +4,7 @@ Home to all content in mauss.dev.
 
 ## Writing
 
-Consider each folder its own route, and the `+article.md` file as the contents of the page. There's a couple of rules to follow when writing a post:
+Consider each directory as its own route, and the `+article.md` file as the contents of the page. There's a couple of rules to follow when writing a post:
 
 - Follow [the semantics of Marqua](https://marqua.mauss.dev/#semantics)
 - Follow the [default](https://github.com/markdownlint/markdownlint/blob/main/docs/RULES.md) and [specified](.markdownlint.yaml) `markdownlint` rules
@@ -22,7 +22,9 @@ author:
 ---
 ```
 
-Replace the value of `name:` with your own name (or the post's author if you're opening a PR for someone else). If it's your first time writing, you can add your own avatar image into [`assets/profile`](assets/profile) folder, and reference it in `img:`. Otherwise, just reference the avatar image file again. Finally, replace the link in `link:` with any link you want to point readers when clicking your avatar image.
+- `name:` is the name of the author
+- `img:` is the path to the author's avatar image in the [`assets/profile`](assets/profile) directory
+- `link:` is the link to the author's profile or any other social link
 
 ***
 

sites/dev.mauss/curated/cheat-sheet/bash.md

@@ -47,22 +47,22 @@ du -sh path/to/directory
 du -a path/to/start | sort -nr | head -n 10
 ```
 
-## File and folder manipulation
+## File and directory manipulation
 
-`Copy method`, it creates a hard link for the file or everything in the folder to the desired destination. Hard linking is crucial for media management so that you won't have a lot of wasted space with duplicates or multiple files with similar data and different file names.
+`Copy method`, it creates a hard link for the file or everything in the directory to the desired destination. Hard linking is crucial for media management so that you won't have a lot of wasted space with duplicates or multiple files with similar data and different file names.
 
 ```bash
 #$ file: Copy Method
 # This will create a complete hard linked copy instead of traditional one
 cp -al /path/to/source /path/to/destination
 ```
 
-`Find method`, it quickly finds your desired file or folder with many additional functionalities. It could do many things such as
+`Find method`, it quickly finds your desired file or directory with many additional functionalities. It could do many things such as
 
-- Search for empty files or folders
-- Search files and folders with specific hard link counts
-- Search files and folders that belongs to a specific owner or group
-- Search and destroy files and folders with specific prefix/suffix
+- Search for empty files or directories
+- Search files and directories with specific hard link counts
+- Search files and directories that belongs to a specific owner or group
+- Search and destroy files and directories with specific prefix/suffix
 - and many more...
 
 ```bash
@@ -96,7 +96,7 @@ find . -name .unwanted -exec rm -rf {} \;
 find . -type f -perm 777 -exec chmod -x {} \;
 ```
 
-`Rename method`, it renames multiple files or folders with a specific regex pattern. One of the most useful scripts to have for media management.
+`Rename method`, it renames multiple files or directories with a specific regex pattern. One of the most useful scripts to have for media management.
 
 ```bash
 #$ file: Rename Method
@@ -108,7 +108,7 @@ sudo apt install rename
 rename 's/\[.*\]/\[replacement\]/' **/* -n  # preview changes
 rename 's/\[.*\]/\[replacement\]/' **/*     # execute rename
 
-# This recursively find and rename all folders from the start directory
+# This recursively find and rename all directories from the start directory
 rename 's/unwantedName/changedName/' path/to/start/**/* -n  # preview changes
 rename 's/unwantedName/changedName/' path/to/start/**/*     # execute rename
 

sites/dev.mauss/posts/admin-dashboard-with-svelte-and-firebase/+article.md

@@ -69,7 +69,7 @@ Let's take a look at our previous project structure with Sapper.
 
 ![ssr-structure](./ssr-structure.png)
 
-It's quite bloated in my opinion, with repeated files in `routes` folder, it's required by Sapper to create the defined routes for the client to navigate to. Though Sapper makes it easy for us to create a path using files as routers, it's not really needed for our case here.
+It's quite bloated in my opinion, with repeated files in `routes` directory, it's required by Sapper to create the defined routes for the client to navigate to. Though Sapper makes it easy for us to create a path using files as routers, it's not really needed for our case here.
 
 Our components are no different, but all of those files serve as the foundations of our application structure. It may look like a lot of files, but it allows us to reduce our LOC (especially duplicated ones) significantly. So we'll ignore it from our comparison.
 
@@ -139,9 +139,9 @@ src
 └── store.js
 ```
 
-Our app is fully contained inside `App.svelte`, I've also separated routes that we have before into their own files in pages folder.
+Our app is fully contained inside `App.svelte`, I've also separated routes that we have before into their own files in pages directory.
 
-Because our components are self-contained too, I've literally copy and pasted the entire components folder and it will still works. The rest is migrated manually by moving the necessary code from the `routes` pages to either `App.svelte` or `pages` files. This is thanks to the results of using a component-based approach that I'm able to quickly migrate the app just in time.
+Because our components are self-contained too, I've literally copy and pasted the entire components directory and it will still works. The rest is migrated manually by moving the necessary code from the `routes` pages to either `App.svelte` or `pages` files. This is thanks to the results of using a component-based approach that I'm able to quickly migrate the app just in time.
 
 The only new component I added was `Loader.svelte` to give a more lively app for the user to see while the app is loading. You can see it for yourself or even use this for your own app. Just copy the code below and paste it to the [Svelte REPL](https://svelte.dev/repl)
 

sites/dev.mauss/posts/complete-flutter-development-automation/+article.md

@@ -146,18 +146,18 @@ RUN flutter doctor -v && appcenter
 Here's the said `Dockerfile` I use to create my image. I'll be going through each line of code one by one.
 
 - `1` - Here we're saying to use the latest ubuntu image as our initial image.
-- `3-4` - We're saying we want to create a folder on root called **development** and work .inside that directory. So, all of the files we handle will be contained inside this directory.
+- `3-4` - We're saying we want to create a directory on root called **development** and work .inside that directory. So, all of the files we handle will be contained inside this directory.
 - `5` - There will be a warning when you don't set the argument variable to noninteractive, but it'll still work nonetheless, so this is optional. Using the **ARG** command will create an environment variable just for the current session and will not be carried over to the final image.
 - `6-7` - We'll run an obligatory update and upgrade command using the quiet shorthand to not clutter the terminal while building the image, and install the essential packages needed to work with our next commands.
 - `9-10` - We're setting an environment variable using the **ENV** command for our Flutter home and Dart home. This will set the environment variable and be carried over to the final image.
 - `11-12` - We're downloading the Flutter tarball as a file called **flutter-sdk.tar.xz**, and then extracting and immediately remove the tarball. At the time of making this image, we're using the stable release **v1.12.13+hotfix.8**.
-- `13-14` - We'll be appending the bin folders of Flutter and Dart to the PATH.
+- `13-14` - We'll be appending the bin directory of Flutter and Dart to the PATH.
 - `15` - This is another optional line, but run this so Flutter doesn't collect analytics when the image is used.
 - `17` - We'll be installing lcov to create a summary of our coverage.
 - `19-20` - We're setting an environment variable for our Java home and Android home.
 - `21` - We'll be installing the required packages by Android and we'll be using Java 8 since our Flutter isn't compatible with the higher versions yet.
-- `22-23` - We're downloading the CLI only sdk-tools for Linux, unzipping it to the Android folder, and immediately remove the zip file.
-- `24-27` - Same as before, we're appending the folders needed by Java and Android to our PATH.
+- `22-23` - We're downloading the CLI only sdk-tools for Linux, unzipping it to the Android directory, and immediately remove the zip file.
+- `24-27` - Same as before, we're appending the directories needed by Java and Android to our PATH.
 - `28` - We'll be accepting all the prompts using yes command to install the platform and build-tools needed by Android using sdkmanager. Since we're using the CLI tools only, it doesn't come with this.
 - `29` - There's a warning for this particular file since it doesn't exist, so we'll just create it first.
 - `30` - We'll be accepting all the prompts using yes command to accept all the licenses to prevent warnings when running **flutter doctor**
@@ -214,7 +214,7 @@ test:coverage:
     expire_in: 2 days
 ```
 
-You'll need to pass the results as an artifact for the next stage which they need to create the analysis, we'll save it in the $CI_PROJECT_DIR in the coverage folder. We'll also show the coverage in the terminal at line 5. We're going to use the artifact to create our analysis as well as send it to the server, this is the fourth stage (analysis).
+You'll need to pass the results as an artifact for the next stage which they need to create the analysis, we'll save it in the $CI_PROJECT_DIR in the coverage directory. We'll also show the coverage in the terminal at line 5. We're going to use the artifact to create our analysis as well as send it to the server, this is the fourth stage (analysis).
 
 ```yaml
 #$ file: .gitlab-ci.yml
@@ -298,7 +298,7 @@ deploy:production:
 - `5` - We're saying that this should only run when changes are made to the master branch.
 - `7-8` - Tags are there just to help differentiate each jobs and pipelines.
 - `10-11` - We'll be building our apk on release mode with the name of YOUR_APP_NAME, you should change this to your own app name.
-- `12-14` - We'll distribute the app by releasing it through App Center, the generated file is located at the build/app/outputs/apk/release folder, and the app and group is according to your own App Center configuration.
+- `12-14` - We'll distribute the app by releasing it through App Center, the generated file is located at the build/app/outputs/apk/release directory, and the app and group is according to your own App Center configuration.
 
 That's it! We have now completed our setup to fully automate flutter development using GitLab's devops specifically. All you have to is just start writing some code. Cheers!
 

sites/dev.mauss/posts/django-quick-setup-guide-with-gitlab-and-heroku/+article.md

@@ -26,7 +26,7 @@ It offers multiple plans, but usually the free tier is more than enough for expe
     | HEROKU_APPNAME  | [your_appname] |
     | HEROKU_APP_HOST | [your_webapp]  |
 
-3. initialize git in your project root folder
+3. initialize git in your project root directory
 
     ```bash
     git init
@@ -142,7 +142,7 @@ Another reason to use this is so that other people could recreate the exact envi
     django-admin startproject your_project_name
     ```
 
-2. create new app using command inside your project folder
+2. create new app using command inside your project directory
 
     ```bash
     django-admin startapp your_app_name
@@ -192,7 +192,7 @@ Another reason to use this is so that other people could recreate the exact envi
       - 2 & 8 → for Production in Heroku
       - 12 → registering your app to the project
       - 17 → to use the WhiteNoiseMiddleware
-      - 23 → to set the global template in your root directory as a folder called 'template'
+      - 23 → to set the global template in your root directory
 
       ```python
       #$ file: project/settings.py#92
@@ -223,7 +223,7 @@ Another reason to use this is so that other people could recreate the exact envi
       ```
 
       - 130 → Add the project root directory
-      - 135-137 → Set your static files such as CSS, JS, and Images at the root directory in a folder called `assets`
+      - 135-137 → Set your static files such as CSS, JS, and images inside the `assets` directory
 
 4. Add the path to your app in your project's urls file
 
@@ -264,4 +264,4 @@ Another reason to use this is so that other people could recreate the exact envi
         return render(request, 'your_template.html')
     ```
 
-6. create folder called `templates` inside your app folder and fill it with your html files
+6. create a `templates` directory inside your app directory and fill it with your html files