PRISMO Hackaton topics for discussion

[leechwort]

Here I want to place small topics needed to be discussed offline and maybe fixed on hackathon. Here it is!

🐧 Features and impovements:

1. "Add device" page: fix layout, design
2. "Add device" page: generate random UUID, fix names of controls
3. "Event Log" page: sorting, filtering by users, by time, select time range, set limito of log entry. Maybe we better use restAPI for this page instead of templates.

🦅 Code organization:

1. Why did we changed directory structure again? Can we place, ok, "routes" in one place?
2. Why readers are in "features"? I think name is very misleading.
3. In general, we need to clarify project directory stuctures.
4. Naming convension? "routers"? or "routes"? -> According to [2] should be routes. Or "views"?
5. Code style convension?
6. Get rid from operation DTO?
7. What dto is at all? Is it common convention name? Examples?
8. Naming convention "repository"? It it right word for this?
9. Dataclass do not need init constructor.

🦉 UX:

1. Show key in logs?
2. Get back "Last enter"? IMHO we stiil need it to filter people, who did not visit to hackerspace for a long time.

🦇 Reader API:

1. Slashes in device API ends?

🦋 Development process:

1. Check everything through autopep8 before commit
2. Use git rebase instead of merge.
3. Just for discussion: minimal code review?
4. Tests?

Examples for reference, about project structure:
[1] https://stackoverflow.com/questions/14415500/common-folder-file-structure-in-flask-app
[2] https://www.digitalocean.com/community/tutorials/how-to-structure-a-large-flask-application-with-flask-blueprints-and-flask-sqlalchemy

[VovaStelmashchuk]

"Add device" page: generate random UUID, fix names of controls, agree, but I think we need to implement the auto-generate UUID after implementation of the initial reader firmware from admin panel, before this use the UUID its not a human friendly

[VovaStelmashchuk]

DTO is a data transfer object, https://en.wikipedia.org/wiki/Data_transfer_object

[VovaStelmashchuk]

The repository pattern is a design pattern that isolates the data layer from the rest of the app. The data layer refers to the part of your app, separate from the UI, business logic, etc, not sure about the repository right naming, may be it needs to be some thinks like source, etc.

[VovaStelmashchuk]

One more, topic for discuss its a common problem with the project glossary, we have the reader and device that look the same, I think we need to rename all variables and files in the projects to one name and add some glossary to the project docs.

[VovaStelmashchuk]

Thx, for suggesting autopep8, I am thinking about adding some code style too. I will review some continuous integration for implementing the check as part of our SDLC.
I think the point needs to be discussed with other point code reviews, my suggestion is after publishing a version v0.1 close the dev for push and accept all changes into the branch by a pull request.

[leechwort]

Interesting project structure was proposed by Bard:) What do we think about it?

flask_door_access/
├── api/
│   ├── __init__.py
│   ├── reader_api.py  # Routes and logic for reader API
│   └── web_api.py     # Routes and logic for REST API used by web application
├── app/
│   ├── __init__.py
│   ├── flasher.py     # Utilities for flashing readers
│   ├── models/        # Database models for users, devices, and access logs
│   │   ├── __init__.py
│   │   ├── user.py
│   │   ├── device.py
│   │   └── access_log.py
│   ├── routes.py      # Application routes for web interface
│   └── templates/     # HTML templates for web interface
│       ├── __init__.py
│       ├── base.html    # Base template for all pages
│       ├── index.html   # Home page
│       ├── users.html   # User management page
│       └── devices.html  # Device management page
│   └── __init__.py    # Main application entry point
├── config.py         # Configuration settings for database, API, etc.
├── requirements.txt  # Python package dependencies
├── static/           # Static files for web interface (CSS, JavaScript, images)
│   ├── css/
│   │   └── style.css
│   ├── js/
│   │   └── script.js
│   └── images/
├── tests/            # Unit tests for application modules
│   ├── __init__.py
│   ├── test_api.py
│   ├── test_flasher.py  # Tests for reader flashing utilities
│   ├── test_models.py
│   └── test_routes.py
└── utils.py           # Additional utilities for the application

[VovaStelmashchuk]

I see you suggest the layer-based project structure for Flask Door Access. I want to stay with domain-driven design (DDD). In DDD, we organize our code around specific business domains, creating a modular and cohesive structure. Each domain contains its own models, services, and components, making it easier to understand and maintain the application's functionality.

In case we need you to want to work with some domain entity like a device, etc, you just work with one folder. Also in case you modify some feature you have all feature files in one place. A lot of things can be featured a Slack integration, admin functions or readers.

[leechwort]

We defenitely need some help from experienced developers in this field... From my point of view we just overcomplicate such simple Flask app. I may be wrong and we are on our way to finally clean architectural pattern.