video server

.gitignore

@@ -2,6 +2,7 @@
 # will have compiled files and executables
 debug/
 target/
+.direnv
 
 # Remove Cargo.lock from gitignore if creating an executable, leave it for libraries
 # More information here https://doc.rust-lang.org/cargo/guide/cargo-toml-vs-cargo-lock.html

.pre-commit-config.yaml

@@ -0,0 +1,16 @@
+repos:
+-   repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v3.1.0
+    hooks:
+    -   id: check-byte-order-marker
+    -   id: check-case-conflict
+    -   id: check-merge-conflict
+    -   id: check-symlinks
+    -   id: check-yaml
+    -   id: end-of-file-fixer
+    -   id: mixed-line-ending
+    -   id: trailing-whitespace
+-   repo: https://github.com/pre-commit/pre-commit
+    rev: v2.5.1
+    hooks:
+    -   id: validate_manifest

CHANGELOG.md

@@ -4,8 +4,15 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+
+## [Unreleased]
+### upcoming changes.
+
 ## [efected-cotoemory]
+
+## v1.0.0 
 added nix module <br>
 added Actix Web Framework <br>
 changed the app: used cargo-generate to create boilerplate.
+add fission-codes/rust-template.
 

CODE_OF_CONDUCT.md

@@ -1,3 +1,108 @@
 # Code of Conduct
 
-This project adheres to the Rust Code of Conduct, which can be found [here](https://www.rust-lang.org/conduct.html).
+**TL;DR Be kind, inclusive, and considerate.**
+
+In the interest of fostering an open, inclusive, and welcoming environment, all
+members, contributors, and maintainers interacting within our online community
+(including Discord, Discourse, etc.), on affiliated projects and repositories
+(including issues, pull requests, and discussions on Github), and/or involved
+with associated events pledge to accept and observe the following Code of
+Conduct.
+
+As members, contributors, and maintainers, we pledge to make participation in
+our projects and community a harassment-free experience, ensuring a safe
+environment for all, regardless of background, gender, gender identity and
+expression, age, sexual orientation, disability, physical appearance, body size,
+race, ethnicity, religion (or lack thereof), or any other dimension of
+diversity.
+
+Sexual language and imagery will not be accepted in any way. Be kind to others.
+Do not insult or put down people within the community. Behave professionally.
+Remember that harassment and sexist, racist, or exclusionary jokes are not
+appropriate in any form. Participants violating these rules may be sanctioned or
+expelled from the community and related projects.
+
+## Spelling it out.
+
+Harassment includes offensive verbal comments or actions related to or involving
+
+- background
+- gender
+- gender identity and expression
+- age
+- sexual orientation
+- disability
+- physical appearance
+- body size
+- race
+- ethnicity
+- religion (or lack thereof)
+- economic status
+- geographic location
+- technology choices
+- sexual imagery
+- deliberate intimidation
+- violence and threats of violence
+- stalking
+- doxing
+- inappropriate or unwelcome physical contact in public spaces
+- unwelcomed sexual attention
+- influencing unacceptable behavior
+- any other dimension of diversity
+
+## Our Responsibilities
+
+Maintainers of the community and associated projects are not only subject to the
+anti-harassment policy, but also responsible for executing the policy,
+moderating related forums, and for taking appropriate and fair corrective action
+in response to any instances of unacceptable behavior that breach the policy.
+
+Maintainers have the right to remove and reject comments, threads, commits,
+code, documentation, pull requests, issues, and contributions not aligned with
+this Code of Conduct.
+
+## Scope
+
+This Code of Conduct applies within all project and community spaces, as well as
+in any public spaces where an individual representing the community is involved.
+This covers
+
+- Interactions on the Github repository, including discussions, issues, pull
+  requests, commits, and wikis
+- Interactions on any affiliated Discord, Slack, IRC, or related online
+  communities and forums like Discourse, etc.
+- Any official project emails and social media posts
+- Individuals representing the community at public events like meetups, talks,
+  and presentations
+
+## Enforcement
+
+All instances of abusive, harassing, or otherwise unacceptable behavior should
+be reported by contacting the project and community maintainers at
+[[email protected]][support-email]. All complaints will be reviewed and
+investigated and will result in a response that is deemed necessary and
+appropriate to the circumstances.
+
+Maintainers of the community and associated projects are obligated to maintain
+confidentiality with regard to the reporter of an incident. Further details of
+specific enforcement policies may be posted separately.
+
+Anyone asked to stop abusive, harassing, or otherwise unacceptable behavior are
+expected to comply immediately and accept the response decided on by the
+maintainers of the community and associated projects.
+
+## Need help?
+
+If you are experiencing harassment, witness an incident or have concerns about
+content please contact us at [[email protected]][support-email].
+
+## Attribution
+
+This Code of Conduct is adapted from the [Contributor Covenant, v2.1][contributor-cov],
+among other sources like [!!con’s Code of Conduct][!!con] and
+[Mozilla’s Community Participation Guidelines][mozilla].
+
+[!!con]: https://bangbangcon.com/conduct.html
+[contributor-cov]: https://www.contributor-covenant.org/version/2/1/code_of_conduct/
+[mozilla]: https://www.mozilla.org/en-US/about/governance/policies/participation/
+[support-email]: mailto:[email protected]

CONTRIBUTING.md

@@ -1,80 +1,152 @@
-# Contribution guidelines
-
-First off, thank you for considering contributing to efected-cotoemory.
-
-If your contribution is not straightforward, please first discuss the change you
-wish to make by creating a new issue before making the change.
-
-## Reporting issues
-
-Before reporting an issue on the
-[issue tracker](https://github.com/aleeusgr/efected-cotoemory/issues),
-please check that it has not already been reported by searching for some related
-keywords.
-
-## Pull requests
-
-Try to do one pull request per change.
-
-### Updating the changelog
-
-Update the changes you have made in
-[CHANGELOG](https://github.com/aleeusgr/efected-cotoemory/blob/main/CHANGELOG.md)
-file under the **Unreleased** section.
-
-Add the changes of your pull request to one of the following subsections,
-depending on the types of changes defined by
-[Keep a changelog](https://keepachangelog.com/en/1.0.0/):
-
-- `Added` for new features.
-- `Changed` for changes in existing functionality.
-- `Deprecated` for soon-to-be removed features.
-- `Removed` for now removed features.
-- `Fixed` for any bug fixes.
-- `Security` in case of vulnerabilities.
-
-If the required subsection does not exist yet under **Unreleased**, create it!
-
-## Developing
-
-### Set up
-
-This is no different than other Rust projects.
-
-```shell
-git clone https://github.com/aleeusgr/efected-cotoemory
-cd efected-cotoemory
-cargo test
-```
-
-### Useful Commands
-
-- Build and run release version:
-
-  ```shell
-  cargo build --release && cargo run --release
-  ```
-
-- Run Clippy:
-
-  ```shell
-  cargo clippy --all-targets --all-features --workspace
-  ```
-
-- Run all tests:
-
-  ```shell
-  cargo test --all-features --workspace
-  ```
-
-- Check to see if there are code formatting issues
-
-  ```shell
-  cargo fmt --all -- --check
-  ```
-
-- Format the code in the project
-
-  ```shell
-  cargo fmt --all
-  ```
+# Contributing to efected-coto-emmory
+
+We welcome everyone to contribute what and where they can. Whether you are brand
+new, just want to contribute a little bit, or want to contribute a lot there is
+probably something you can help out with. Check out our
+[good first issues][good-first-issues] label for in the issues tab to see a list
+of issue that good for those new to the project.
+
+## Where to Get Help
+
+The main way to get help is by sending an email to [[email protected]][support-email].
+Though, this guide should help you get started. It may be slightly lengthy, but it's
+designed for those who are new so please don't let length intimidate you.
+
+## Code of Conduct
+
+Please be kind, inclusive, and considerate when interacting when interacting
+with others and follow our [code of conduct](./CODE_OF_CONDUCT.md).
+
+## How to Contribute
+
+If the code adds a feature that is not already present in an issue, you can
+create a new issue for the feature and add the pull request to it. If the code
+adds a feature that is not already present in an issue, you can create a new
+issue for the feature and add the pull request to it.
+
+### Contributing by Adding a Topic for Discussion
+
+#### Issues
+
+If you have found a bug and would like to report it or if you have a feature
+that you feel we should add, then we'd love it if you opened an issue! ❤️
+Before you do, please search the other issues to avoid creating a duplicate
+issue.
+
+To submit a new issue just hit the issue button and a choice between two
+templates should appear. Then, follow along with the template you chose. If you
+don't know how to fill in all parts of the template go ahead and skip those
+parts. You can edit the issue later.
+
+#### Discussion
+
+If you have a new discussion you want to start but it isn't a bug or feature
+add, then you can start a [GitHub discussion][gh-discussions]. Some examples of
+what kinds of things that are good discussion topics can include, but are not
+limited to the following:
+
+-   Community announcements and/or asking the community for feedback
+-   Discussing a new release
+-   Asking questions, Q&A that isn't for sure a bug report
+
+### Contributing through Code
+
+In order to contribute through code follow the steps below. Note that you don't
+need to be the best programmer to contribute.
+
+ 1. **Pick a feature** you would like to add or a bug you would like to fix
+    - If you wish to contribute but what you want to fix/add is not already
+      covered in an existing issue, please open a new issue.
+
+ 2. **Discuss** the issue with the rest of the community
+    - Before you write any code, it is recommended that you discuss your
+      intention to write the code on the issue you are attempting to edit.
+    - This helps to stop you from wasting your time duplicating the work of
+      others that maybe working on the same issue; at the same time.
+    - This step also allows you to get helpful pointers on the community on some
+      problems they may have encountered on similar issues.
+
+ 3. **Fork** the repository
+    - A fork creates a copy of the code on your Github, so you can work on it
+      separately from everyone else.
+    - You can learn more about forking [here][forking].
+
+ 4. Ensure that you have **commit signing** enabled
+    - This ensures that the code you submit was committed by you and not someone
+      else who claims to be you.
+    - You can learn more about how to setup commit signing [here][commit-signing].
+	- If you have already made some commits that you wish to put in a pull
+      request without signing them, then you can follow [this guide][post-signing]
+      on how to fix that.
+
+ 5. **Clone** the repository to your local computer
+    - This puts a copy of your fork on your computer so you can edit it
+	- You can learn more about cloning repositories [here][git-clone].
+
+ 6. **Build** the project
+    - For a detailed look on how to build efected-coto-emmory look at our
+      [README file](./README.md).
+
+ 7. **Start writing** your code
+    - Open up your favorite code editor and make the changes that you wanted to
+      make to the repository.
+    - Make sure to test your code with the test command(s) found in our
+      [README file](./README.md).
+
+ 8. **Write tests** for your code
+    - If you are adding a new feature, you should write tests that ensure that
+      if someone make changes to the code it cannot break your new feature
+      without breaking the test.
+    - If your code adds a new feature, you should also write at least one
+      documentation test. The documentation test's purpose is to demonstrate and
+      document how to use the API feature.
+    - If your code fixes a bug, you should write tests that ensure that if
+      someone makes code changes in the future the bug does not re-emerge
+      without breaking test.
+    - Please create integration tests, if the addition is large enough to
+      warrant them, and unit tests.
+		  * Unit tests are tests that ensure the functionality of a single
+      function or small section of code.
+		  * Integration tests test large large sections of code.
+		  * Read more about the differences [here][unit-and-integration].
+    - For more information on test organization, take a look [here][test-org].
+
+ 9. Ensure that the code that you made follows our Rust **coding guidelines**
+    - You can find a list of some Rust guidelines [here][rust-style-guide]. This
+      is a courtesy to the programmers that come after you. The easier your code
+      is to read, the easier it will be for the next person to make modifications.
+    - If you find it difficult to follow the guidelines or if the guidelines or
+      unclear, please reach out to us through our email linked above, or you
+      can just continue and leave a comment at the pull request stage.
+
+ 10. **Commit and Push** your code
+     - This sends your changes to your repository branch.
+     - You can learn more about committing code [here][commiting-code] and
+       pushing it to a remote repository [here][push-remote].
+     - We use conventional commits for the names and description of commits.
+       You can find out more about them [here][conventional-commits].
+
+ 11. The final step is to create **pull request** to our main branch 🎉
+     - A pull request is how you merge the code you just worked so hard on with
+       the code everyone else has access to.
+	 - Once you have submitted your pull request, we will review your code and
+       check to make sure the code implements the feature or fixes the bug. We
+       may leave some feedback and suggest edits. You can make the changes we
+       suggest by committing more code to your fork.
+     - You can learn more about pull requests [here][prs].
+
+
+[conventional-commits]: https://www.conventionalcommits.org/en/v1.0.0/
+[commiting-code]: https://docs.github.com/en/desktop/contributing-and-collaborating-using-github-desktop/making-changes-in-a-branch/committing-and-reviewing-changes-to-your-project
+[commit-signing]: https://www.freecodecamp.org/news/what-is-commit-signing-in-git/
+[forking]: https://docs.github.com/en/get-started/quickstart/fork-a-repo
+[gh-discussions]: https://docs.github.com/en/discussions
+[git-clone]: https://docs.github.com/en/repositories/creating-and-managing-repositories/cloning-a-repository
+[good-first-issues]: [https://build.prestashop-project.org/news/a-definition-of-the-good-first-issue-label/]
+[post-signing]: https://dev.to/jmarhee/signing-existing-commits-with-gpg-5b58
+[prs]: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests
+[push-remote]: https://docs.github.com/en/get-started/using-git/pushing-commits-to-a-remote-repository
+[rust-style-guide]: https://rust-lang.github.io/api-guidelines/about.html
+[test-org]: https://doc.rust-lang.org/book/ch11-03-test-organization.html
+[support-email]: mailto:[email protected]
+[unit-and-integration]: https://www.geeksforgeeks.org/difference-between-unit-testing-and-integration-testing/