"Fast Parking" це веб-застосунок, який автоматично може визначати номери автомобільних знаків на зображеннях, відстежити тривалість паркування для кожного унікального транспортного засобу та розраховувати накопичені паркувальні витрати.
- Управління обліковими записами користувачів;
- Приймання зображень від користувача. Детекція номерного знаку. Виявлення та виділення області з номерним знаком;
- Розпізнавання символів для ідентифікації тексту номерного знаку;
- Перевірка номера авто у базі зареєстрованих транспортних засобів;
- Запис часу в'їзду/виїзду кожного разу, коли визначається номерний знак. Відстеження тривалості паркування;
- Розрахунок загальної тривалості паркування;
- Зберігання даних про тривалість паркування в базі даних;
- Розрахунок вартості паркування. Керування тарифами. Чек за QR-кодом;
- Генерація звітів про розрахунки, які можна експортувати у форматі CSV;
- Real Time сповіщення для подій в'їзду/виїзду у Telegram;
- Візуалізація про кількість вільних та зайнятих паркомісць.
Home
Parking plan from the point of view of users with their cars
Youtube: https://youtu.be/BkJmMh1Nvzk
На основі файлу deploy/env-examples створюємо власний deploy/.env з власними змінними
-
git проекту: https://github.com/AlexanderBgit/PlateN , default branch
dev -
кожен створює власні гілки від
devі оновлює їх черезmerge. Іменна гілокusernmae- постійна користувача,usernmae-featureтимчасова, після об'єднання з іншими гілками знищується. -
merge to
devтільки черезpull-requestі запит користувачам на підтвердження, мінімум один має підтвердити, і тоді розблокується кнопкаMerge, і можна об'єднати уdev. -
Python >=3.10,<3.12
-
poetry
-
Django 5
-
Скрипти
.cmdдля виконання у операційній системі Windows тільки. -
Скрипти
.shдля виконання у операційній системі Linux, Mac. -
Корінь git проекту має декілька незалежних підпроєктів:
- BACKEND
- FRONTEND
- Database
- DS
-
Кожен підпроєкт - незалежний продукт, і відповідно має свій незалежний Docker.
-
Спілкуються через спільну базу даних, при розробці це може бути локальна з Docker або віддалена у elephantsql.
-
Налаштування змінних середовища - спільні у файлі /deploy/.env. Локальна розробка використовує тільки відносний шлях до цього файлу. Наприклад код з
fastparking\fastparking\settings.py:
BASE_DIR = Path(__file__).resolve().parent.parent
env_file = BASE_DIR.parent.parent.joinpath("deploy").joinpath(".env")
if env_file.exists():
load_dotenv(env_file)
else:
print("ENV file not found:", env_file)
-
Security. Кожен докер при старті бере налаштування з .env котрі йому тільки потрібні, а не весь файл. Розміщується .env файл тільки за межами докер контейнера.
-
FRONTEND має власне віртуальне оточення poetry.
-
BACKEND має власне віртуальне оточення poetry
-
DS - робочі файли для Data Science
-
Для роботи з FRONTEND:
- переходимо у теку FRONTEND, активуємо віртуальне сердобине
poetry shell - Далі
poetry updateвстановить або оновить пакунки субпроєкту.
- переходимо у теку FRONTEND, активуємо віртуальне сердобине
-
Для роботи з BACKEND:
- переходимо у теку BACKEND, активуємо віртуальне сердобине
poetry shell - Далі
poetry updateвстановить або оновить пакунки субпроєкту.
- переходимо у теку BACKEND, активуємо віртуальне сердобине
-
Якщо у VC Code створити Workspace, додати до нього підпроєкти як (File->Add folder to WorkSpace), то при запуску терміналу буде запити з якої теки ви це хочете зробити.
-
Для роботи з локальною базою даних використовуємо настуні кроки (Local Database postgres). Для роботи з віддаленою базою даних пропускаємо ці кроки.
scripts/docker_db.cmd
Данні бази будуть створенні у теці Database\postgres-data\
Тека додана у виключення git - не викладати у git, у кожного вона своя!
scripts\docker_db_stop.cmd
Запускати з віртуального оточення poetry
cd FRONTEND/fastparking
python manage.py runserver 0.0.0.0:8000
scripts\run_dev_app.cmd
Запускати з віртуального оточення poetry
cd FRONTEND
poetry export --without-hashes > requirements.txt
scripts\gen_req_txt.cmd
cd FRONTEND/fastparking
python manage.py migrate
scripts\create_django_auto_admin.cmd
Данні бази будуть створенні у теці Database\postgres-data\
scripts\docker_app_run.cmd
Режим DEBUG - консолі
scripts\docker_app_build.cmd
- git checkout dev
- git pull
- cd FRONTEND
- poetry shell
- poetry update
- cd ..
- cd scripts
- docker_db.cmd - run DB local docker, skip if remote used postgres
- create_django_auto_admin.cmd - create admin aromatically from .env
- run_dev_app.cmd - run app
- open browser: http://127.0.0.1:8000
Перевірка коду проєкту на збирання проходить автоматично у кожному "GitHub pull request" безпосередньо перед об'єднанням з гілкою dev функцію Action GitHub.
Але без повірки міграції.
Action GitHub використовує налаштуванням з файлу .github\workflows\django.yml де проходить перевірка на збирання середовища виконання для трьох версії python: python-version: ["3.10", "3.11"].
Безпосереднє тестування проєкту Django автоматично виконується командую python manage.py test.
Сервер: Linux (Debian).
Локальний користувач для виконання задач без прав адміністратора.
На сервері проект виконуються у декількох docker контейнерах, котрі об'єднані файлом налаштувань: deploy\docker-compose-project.yml.
Для визначення події з необхідності виконати операцію повторного deploy - періодично виконується скрипт: scripts\detect_changes_git.sh.
Цей скрипт визначає чи не змінилася віддалена гілка проекту dev.
Якщо зміни виявленні то виконується скрипт - scripts\re_deploy_docker.sh.
Для налаштувань під конкретні умови середовища виконання файл detect_changes_git копіюємо за межі теки проєкту.
У нас це рівень вище ~/PlateN/, та змінюємо локальний шлях до теки проєкту у змінній SOURCE.
SOURCE=${HOME}/PlateN/PlateN
Для налаштування системного планувальника завдань використано команду crontab -e.
Де додано наступний рядок:
*/15 * * * * ~/PlateN/detect_changes_git.sh > /dev/null 2>&1
Що дозволяє запускати скрипт detect_changes_git.sh кожні 15 хвилин.
- Team Lead @artem-dorofeev
- Scrum Master @RostislavB74
- Django expert @lumi-ua and @diixo
- Full stack devops @lexxai
- Art director @plaha303
- Tester @AlexanderBgit
