initial commit

.editorconfig

@@ -0,0 +1,29 @@
+# EditorConfig is awesome: https://EditorConfig.org
+
+# top-most EditorConfig file
+root = true
+
+# Default formatting Unix-style newlines with a newline ending every file
+[*]
+charset = utf-8
+end_of_line = lf
+insert_final_newline = true
+trim_trailing_whitespace = true
+indent_style = space
+indent_size = 4
+
+# do not trim trailing whitespace in markdown files
+[*.md]
+trim_trailing_whitespace = false
+
+# explicit 4 space indentation
+[*.py]
+indent_size = 4
+
+# explicit 2 space indentation
+[*.{json,yml,yaml,xml,ddl,sql}]
+indent_size = 2
+
+# windows specific files
+[*.{bat,cmd}]
+end_of_line = crlf

.gitattributes

@@ -0,0 +1,9 @@
+#
+# https://help.github.com/articles/dealing-with-line-endings/
+#
+# Linux start script should use lf
+/gradlew        text eol=lf
+
+# These are Windows script files and should use crlf
+*.bat           text eol=crlf
+

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,28 @@
+---
+name: Bug report
+about: Create a bug report
+title: ''
+labels: 'fix'
+assignees: ''
+
+---
+
+**Describe the bug**
+A clear and concise description of what the bug is.
+
+**To Reproduce**
+Steps to reproduce the behavior:
+
+1. Go to '...'
+2. Click on '....'
+3. Scroll down to '....'
+4. See error
+
+**Expected behavior**
+A clear and concise description of what you expected to happen.
+
+**Screenshots**
+If applicable, add screenshots to help explain your problem.
+
+**Additional context**
+Add any other context about the problem here.

.github/ISSUE_TEMPLATE/custom.md

@@ -0,0 +1,8 @@
+---
+name: Blank
+about: Create a blank issue
+title: ''
+labels: ''
+assignees: ''
+
+---

.github/ISSUE_TEMPLATE/feature_request.md

@@ -0,0 +1,20 @@
+---
+name: Feature request
+about: Create a feature request
+title: ''
+labels: 'feat'
+assignees: ''
+
+---
+
+**Is your feature request related to a problem? Please describe.**
+A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
+
+**Describe the solution you'd like**
+A clear and concise description of what you want to happen.
+
+**Describe alternatives you've considered**
+A clear and concise description of any alternative solutions or features you've considered.
+
+**Additional context**
+Add any other context or screenshots about the feature request here.

.github/pull_request_template.md

@@ -0,0 +1,14 @@
+# Resolves #000
+
+## Description
+
+Please provide a brief description of the changes you've made in this pull request.
+
+## Checklist
+
+Please make sure that the following items have been completed before submitting this pull request:
+
+- [ ] All code has been properly tested
+- [ ] All tests pass successfully
+- [ ] Code has been reviewed for clarity, readability, and maintainability
+- [ ] Code has been properly documented with JavaDoc comments

.gitignore

@@ -0,0 +1,77 @@
+# InelliJ IDEA files
+*.iml
+*.ipr
+*.ids
+*.iws
+.idea/
+
+# Eclipse files
+.project
+.metadata
+.classpath
+.settings/
+.loadpath
+bin/
+
+# Netbeans
+nbactions.xml
+
+# Visual Studio Code
+.vscode
+
+# Maven
+target/
+
+# gradle files
+.gradle
+build/
+
+# ignore logfiles
+*.log*
+
+# OS dependant files
+.DS_Store
+.Spotlight-V100
+.Trashes
+Thumbs.db
+Desktop.ini
+*~
+# Thumbnails
+._*
+
+# compiled files
+*.com
+*.class
+*.dll
+*.exe
+*.o
+*.so
+
+# packages
+*.7z
+#*.jar
+*.rar
+*.zip
+*.gz
+*.bzip
+*.xz
+*.lzma
+*~$*
+
+# package managment formats
+*.dmg
+*.xpi
+*.gem
+*.egg
+*.deb
+*.rpm
+
+# databases
+*.sqlite
+
+# Ignore Gradle build output directory
+build
+
+# Ignore Java Utils Properties Files
+settings.properties
+statistics.properties

CODE_OF_CONDUCT.md

@@ -0,0 +1,75 @@
+# Code of Conduct
+
+## Conventional Commits
+Developers should use the Conventional Commits standard when committing changes to the codebase.
+
+| Type     | Description                                                           |
+| -------- | --------------------------------------------------------------------- |
+| feat     | Declares a new feature has been added                                 |
+| fix      | Declares a bug have been fixed                                        |
+| chore    | Declares changes which don’t modify source or test files (eg. assets) |
+| ci       | Declares a change on the CI or CD process                             |
+| build    | Declares changes on the build setup                                   |
+| docs     | Declares changes on documentation                                     |
+| refactor | Declares a change of code without an effective change on the program  |
+| revert   | Declares that a previous commit has been reverted                     |
+| test     | Declares changes on tests                                             |
+
+### Examples 
+
+#### Commit Message
+```
+refactor: adjust vehicle texture size [#ISSUENUMBER]
+refactor: adjust vehicle texture size [NOISSUE]
+```
+
+#### Branch Name
+```
+refactor/#ISSUENUMBER_adjust-vehicle-texture-size
+refactor/NOISSUE_adjust-vehicle-texture-size
+```
+
+## Contributing
+Developers should follow the following guidelines when contributing to the project:
+
+### 1. Create a new branch
+When starting work on a new feature or bug fix, create a new branch from the `main` branch. The name of the branch should be descriptive and should include the issue number and a short description of the feature or bug fix. For example, if you are working on issue #123, the branch name should be `feat/#123_add-new-feature`.
+
+### 2. Commit changes
+When committing changes to the codebase, developers should follow the [Conventional Commits](#conventional-commits) standard. This will ensure that the commit messages are consistent and descriptive, and will allow the commit history to be automatically parsed to generate release notes.
+
+### 3. Create a draft pull request
+After committing changes to the codebase, create a draft pull request to inform other developers that you are working on a new feature or bug fix. The pull request should be kept in draft mode until the feature or bug fix is complete.
+
+### 4. Create a pull request
+When the feature or bug fix is complete, mark the pull request as ready to review to merge the changes into the `main` branch. The pull request should be reviewed by at least one other developer before it can be merged.
+
+### 5. Review pull request
+When a pull request is marked as ready for review, it should be reviewed by at least one other developer. The reviewer should verify that the code meets the [Definition of Done](#definition-of-done).
+
+### 6. Merge pull request
+Once the pull request has been reviewed and approved, it can be merged into the `main` branch. The pull request should be merged using the "Rebase and merge" option to ensure that the commit history remains clean and concise.
+
+## Definition of Done
+
+### 1. Code meets coding standards
+All code must adhere to the rules defined in the Clean Code handbook for at least level L1. Level L2 rules should also be taken into consideration. Specifically, emphasis should be placed on:
+
+1. Correct abstraction level: The code should have a clear and appropriate level of abstraction, with well-defined interfaces and separation of concerns.
+2. Class diagram: The class diagram should be clear and well-organized, with high cohesion and low coupling between classes.
+3. Correct error handling: The code should handle errors correctly, including validating arguments and handling exceptions in a consistent and appropriate manner.
+
+### 2. Unit tests pass
+All code changes must be accompanied by unit tests that verify the expected behavior of the code. These tests must pass without any errors or failures before the code can be considered complete.
+
+### 3. Code is reviewed
+All code must be reviewed by at least one other developer to ensure quality and compliance with coding standards. The code review should focus on identifying any bugs, security vulnerabilities, or design flaws that could impact the quality or maintainability of the code.
+
+### 4. Documentation is complete
+All code must be fully documented, including comments within the code and external documentation such as user manuals. The documentation should be comprehensive and accurate, and should provide enough detail for other developers and stakeholders to understand the code.
+
+### 5. Acceptance criteria are met
+The code must meet all of the acceptance criteria as defined by the stakeholders. These acceptance criteria are used as a basis for verifying that the code meets the intended requirements
+
+### 6. Security is considered
+The code must be reviewed for security vulnerabilities and any identified issues must be addressed. The code should be designed with security in mind, and should be subject to regular security testing to identify any new vulnerabilities.

LICENSE.md

@@ -0,0 +1 @@
+Copyright © 2023 Boostvolt (Jan). All rights reserved.

README.md

@@ -0,0 +1,72 @@
+# AmongDigits
+
+## Overview
+
+AmongDigits is a JavaFX based Sudoku Game where users can play and create their own Sudokus. It is multi-language,
+intuitive, has different themes and even statistics.
+
+## Design & class diagram
+
+Check out the [design & class diagram](./docs/design-class-diagram.md) to learn more about the
+design and technical details including the class diagram.
+
+## Installation & Running
+
+1. Install prerequisites:
+    - OpenJDK version 17 or higher
+    - Optional: Gradle
+      => [Installation Manual](https://docs.gradle.org/current/userguide/installation.html)
+
+2. Clone the repository
+
+3. Configure your IDE to use Gradle
+    - IntelliJ: Gradle Plugin is installed and enabled by default.
+
+4. Run the game from the IDE or the terminal:
+    - ``gradle run``
+
+
+## GitHub Workflow
+
+### Code of Conduct
+
+Our [Code of Conduct](CODE_OF_CONDUCT.md) describes the rules and guidelines for contributing to our
+project.
+
+### Branching Model
+
+We used the feature branching workflow for several reasons:
+
+- Firstly, it promotes better organization and management of code changes, especially those
+  involving multiple team members working on different features or tasks simultaneously. By creating
+  separate branches for each feature or task, developers can work on their code changes
+  independently without interfering with the work of others. This reduces the likelihood of
+  conflicts arising between different changes, which can be time-consuming to resolve.
+
+- Secondly, the feature branching workflow also enables better tracking of code changes and easier
+  identification of issues or bugs. Since each feature branch contains changes related to a specific
+  feature or task, it is easier to pinpoint issues and resolve them quickly.
+
+- Finally, the feature branching workflow also facilitates better quality control and helps ensure
+  that the project's overall codebase remains stable and functional. Changes are tested and reviewed
+  before they are merged back into the main branch, reducing the risk of introducing bugs or errors
+  into the production code. This ensures that the final product is of high quality and meets the
+  requirements of the stakeholders.
+
+## Time planning (Weekly summed up efforts)
+
+### Week 1 (14.04.23 - 21.04.23)
+
+- 10h total effort
+
+### Week 2 (21.04.23 - 28.04.23)
+
+- 15h total effort
+
+### Week 3 (28.04.23 - 05.05.23)
+
+- 45h total effort
+
+### Week 4 (05.05.23 - 12.05.23)
+
+- 75h total effort

SECURITY.md

@@ -0,0 +1,6 @@
+# Reporting Security Issues
+
+If you believe you have found a security vulnerability in the codebase, we encourage you to let us
+know right away.
+
+We will investigate all legitimate reports and do our best to quickly fix the problem.