Оскільки я розробник, це треба було зробити.
У цій статті ви дізнаєтеся, як реалізувати систему в Django (фреймворк на Python).
Історія UX-дизайну
Це корисно починати з бажаної мети, опису: сім'я хоче покращити рівень участі дітей у виконанні домашніх завдань (мета 1). Спосіб досягти цього — через простий додаток. Усі користувачі в родині повинні мати легкий доступ до цього додатку. Батьки можуть призначати домашні завдання через додаток. Завдання виконуються дітьми. Коли завдання виконано, квиток на завдання перетворюється на час для ігор: додається час для ігор на сьогодні або на майбутні дні. Коли діти використовують PlayStation або інші ігрові пристрої в будинку, отриманий час для ігор використовується.
Механізм здійснюється через "квитки". Квиток — це просто код або повністю реалізовано в додатку. Чи потрібне текстове представлення квитка, — хороше питання!
Зведемо до основ:
- 1 вигляд для банку часу — для кожної дитини
- 1 вигляд для пропозицій домашніх завдань від батьків
- механізм обміну виконаного завдання на час для ігор
Розділимо початковий заголовок трохи:
- Django-based = використання чистого MVC-фреймворка на Python
- Time bank = видача квитків за виконане домашнє завдання, дозволяючи дітям обміняти їх на час для ігор
- homework-based = має корисність і вчить, що в цьому світі нічого не дається дарма, хоч інколи так здається
Передісторія досить проста. Я хотів протестувати створення корисного fullstack-додатку на Python. Оскільки ми говоримо про сімейне життя, чому б не скористатися старим добрим принципом "годування собаки" і не використовувати систему в реальному житті. Годування собаки символізує, що я використовую систему, щоб отримати миттєвий зворотний зв'язок хоча б від одного користувача, якого я дуже добре знаю.
Програмування найкраще, коли ви можете відразу використовувати продукт у своєму житті. Для мене це завжди так. Для історичних міркувань перегляньте це: Ранні проекти, які я програмував на ПК | автор: Jukka Paulin | грудень 2024 | Medium
Можливо, є інші проекти,
можливо, вже є проекти, які досягли досконалості в цій сфері.
Але...
Завжди є місце для ще одного завдання на Django!
Використання Django
Я практично слідую за ChatGPT, щоб створити скелет, каркас для додатку. Django — це фреймворк для веб-розробки на Python, який приносить певні переваги: це так звана система з "батареями в комплекті", яка включає як бекенд, так і фронтенд.
Модель на веб-сторінку
Генератор Views у Django виводить HTML у ваш браузер — це створює веб-сторінки для ваших виглядів.
Views — це не що інше, як HTML, де вміст залежить від того, які дані у вас є на момент виробництва. Ви можете декорувати їх за допомогою CSS, щоб отримати повний контроль над виглядом фронтенду, і налаштувати вигляди, щоб вони були красивими та елегантними.
Моделі, дані, просто існують як програма Python. Тому в дусі об'єктно-орієнтованої розробки, Django створює Моделі як класи. Ви інстанціюєте їх як живі об'єкти, а потім Views (фронтенд) відображає вміст на основі значень моделі. Ви можете симулювати майже все, на що вистачить вашої уяви, і Django пропонує чудовий метод для цього. Вам не обов'язково потрібно знати багато про об'єктно-орієнтоване програмування. Інструменти керування Django допомагають створювати основний код для ваших моделей. Звісно, ви можете редагувати згенерований вихідний код для тонкої налаштування логіки, якщо контролюєте ці зміни.
Views мають бути написані так, щоб зміни в Логіці (M шарі) не включалися в код на рівні views. Views лише маршрутизують зміни в Model через Controllers (C).
Отже, давайте підсумуємо:
- Моделі (M) утримують дані — вони є рівнем, який створює "безголовий" бекенд. Насправді, моделі — це архітектурні моделі ваших даних додатку. Моделі потім інстанціюються як об'єкти Python і стають корисними.
Django дозволяє створювати попередню архітектуру програмного забезпечення, що зазвичай виправдовує себе, коли ви переходите до етапу підтримки та обслуговування вашого додатку. - Лише з моделями ви теоретично могли б запустити та використовувати ваш додаток. Це просто не виглядало б красиво, насправді воно взагалі не "відображалось би" у браузері користувача, але внутрішньо працювало б, виконуючи облік вашого веб-додатку.
- Код контролера передає дії користувача на веб-сторінках до бекенд-логіки. Контролери прикріплюються до будь-яких видимих елементів на веб-сторінці вашого додатку: кнопки, пункти меню, клікабельні іконки, зображення.
- Обробники в коді Python приймають ці прості команди з views, як HTTP-запити, а потім вносять зміни в дані = моделі. Django викликає диспетчер маршруту для того, щоб надіслати запит до правильного фрагмента коду. Зверніть увагу, що через виконання обробника ми вносимо зміни в живі моделі, тобто об'єкти. (Моделі абстраговані як класи Python. Класи — це шаблони коду. Коли ви інстанціюєте Модель на вашому сервері, ви створюєте новий живий об'єкт, який може активно зберігати дані та дозволяти маніпулювати ними.) Якщо б ми програмували бекенд для гри, інші об'єкти могли б бути присутні: можливо, позиції гравців, кулі, що летять у світі, тощо. Або просто кошенята, що літають навколо!
- Об'єкти на основі моделей можуть і повинні бути "персистентними" (збереженими) в будь-якому вибраному вами реальному бекенді (= "база даних") — Django навіть пропонує простий реальний шар збереження для вашого "batteries-included", за замовчуванням бекенду. У найпростішому випадку ми можемо використовувати дамп — один файл, який містить дані об'єкта в певному форматі, що дозволяє додатку зчитувати ці дані та інстанціювати об'єкти на основі цієї ініціалізаційної інформації. Ініціалізація тепер відбувається з останнього запуску вашого веб-додатку. Отже, ваш додаток зберігає стан. Навіть якщо він зламається або буде коректно вимкнений, він збереже дані, щоб ви могли продовжити з того ж місця наступного разу.
Робимо бекенд!
Але спершу робимо логіку бекенду.
Це магія створення сирого, повнофункціонального веб-додатку якомога швидше; спробуйте використовувати стандартні views якнайбільше. Тому не зосереджуйтесь поки що на вигляді (фронтенді) додатку. Все буде працювати у вашому додатку, незважаючи на те, що на цьому етапі ви не будете задоволені естетикою. Продовжуйте працювати з логікою бекенду, поки не отримаєте робочий додаток.
Постійна ітерація — це ключ. Запустіть додаток. Внесіть зміни, тестуйте їх негайно.
Не повинно бути жодної такої маленької додаткової функції, яку можна було б пройти, не пройшовши ітерацію і не протестувавши, чи добре ви попрацювали.
Це справжній гнучкий та ітеративний підхід. Іноді я писав 150 рядків коду, не запустивши його між етапами — без використання будь-яких туторіалів, без ChatGPT — і о, чудо: це працювало. Такі речі не є професійним програмуванням. Повторюю: НІ. Це — хакерство. Хакерство — це не найкращий спосіб писати код.
Насправді, перед початком ітерації дуже корисно зробити ще один крок назад: створіть ітераційне коло, яке ви завжди можете запустити та вимкнути.
Логічне програмування для бекенду
C (контролер) — це частина, де будується ваша UX. Контролерний рівень відповідає за програмування функціональності через лінки та кнопки на веб-сторінці. Тому залишайтеся спокійними, і ще чекайте на повне натхнення для роботи з CSS. Ми можемо працювати з виглядами стандартних лінків і з простими старими веб-кнопками. Поки ви досягаєте через фронтенд того, що потрібно зробити, — все добре. Повірте, це вам служить добре. Ви швидко зробите бекенд.
Django, отже, є повноцінним MVC фреймворком — модель, вигляд, контролер.
Django є класичним, повноцінним фреймворком для розробки додатків. Це, мабуть, один з найпростіших варіантів для тест-драйву. Якщо у вас вже налаштований Python, то Django — це просто команда "pip install". [Як встановити Django та налаштувати.]
Step 1: Встановлення Pip | by Hariharan | Medium](https://medium.com/@princehari.selvaraj/how-to-install-django-setup-549f192361f8)
Що приносить Django?
Я вирушив вивчати та покращувати свої навички з Django. До цього часу це здається дуже привабливим, особливо мені подобається розділення архітектури розробки додатка від самого "основного": створення артефактів. Це важливий момент. Django дозволяє вам фактично розробляти логіку додатка в керованих частинах. Я намагаюсь скористатися цим, визначаючи функції за допомогою MVT:
План системи: Моделі
- дитина
- батько
- квиток
Мати дітей. Кожна дитина має свою веб-сторінку — їхній особистий вигляд, який відображається як маршрут. Гравці можуть переглядати свій банк часу за допомогою браузера.
Порада: якщо ви ще не можете створити живу сторінку в Django, зробіть просту HTML-сторінку в Sublime Text або подібному редакторі. Збережіть і завантажте цю сторінку безпосередньо у браузері, щоб побачити результат. Налаштуйте вихідний код сторінки та спробуйте використовувати дані моделі Django, інжектуючи їх у сторінку якомога швидше. Коли ви інжектуєте дані Django, замість використання вручну створеного HTML, ви вже там! Доказ концепції працює. Ви згодом зможете працювати над удосконаленням моделі, створюючи кращі вигляди та використовуючи дані більш багатим способом. Але побачити перший погляд на вашу сторінку, навіть як макет, дуже надихає.
Маршрути
Django створює маршрути для ваших виглядів. Щоб додати вигляд, все, що вам потрібно зробити — це сказати Django, що ви хочете новий вигляд. Вигляд персоналізований, оскільки його дані надходять від живого об'єкта (моделі), що належить конкретному гравцеві.
Шаблони
Сторінки (views) можуть мати шаблони. Це дозволяє вам дотримуватись стандартів для різних виглядів додатка, а також допомагає організувати ваш код, знову ж таки, у стилі об'єктно-орієнтованого програмування Django.
Шаблони — це те, що не обов'язково включати на перших етапах. Django також дуже гнучкий, оскільки дозволяє вам наздогнати пізніше та почати використовувати шаблони пізніше.
Django зберігає ваш додаток як внутрішню модель, а артефакти (будь-що, що є фактичним кодом або даними) можуть бути згенеровані.
Отже, це одна з найпотужніших функцій Django. Вона універсальна, і Django дозволяє вам працювати на будь-якому рівні абстракції та архітектури вашого веб-додатка, утримуючи контроль — і водночас дозволяючи вам вдосконалювати свої навички кодування, роблячи налаштування будь-яких артефактів вручну, якщо це потрібно.
Один із найпотужніших способів скористатися можливостями Django — це насправді ознайомитись з тими можливостями, які вона надає. Ви інвестуєте у майбутню зручність обслуговування додатка.
Прочитайте про архітектуру Django та найкращі практики тут:
Адміни
Адміни — це батьки, які можуть створювати квитки часу. Аутентифікація та безпека мають бути інтегровані в додаток, щоб запобігти обману системи іншими типами акаунтів.
Код надається, його можна надіслати по електронній пошті, через Whatsapp або просто написати на аркуші паперу.
Генератор коду — це функція, яка генерує рядок для коду. Рядок є вказівником на дані. Ми можемо легко оцінити довжину коду: кожен код є одноразовим, тому він генерується і, можливо, поглинається дитячим акаунтом на сторінці — пізніше. Декілька проблем дизайну зручності можуть бути вирішені пізніше.
Діти — це користувачі, які можуть:
- переглядати розподіл часу на тиждень
- поглинати квиток, вводячи код
- система показує, що квиток було підтверджено, і час (награда) додається!
Логіка банку часу
Банк часу розподіляє час на основі зареєстрованого запису в базі даних. [F1]
Функції для створення:
Отже, основна база даних, база даних показує типи квитків для батьків, і батьки можуть натискати, щоб призначити код для будь-якої з зареєстрованих дітей.
Діти поглинають коди. Після поглинання код додає час до дитини безпосередньо.
Правила конфігурації часу та підсумування ще не включені в план. За замовчуванням час можна використовувати протягом визначеної фіксованої дати.
Правила системи для часу
- Час, який не використано в зазначену дату, не накопичується, що означає, що час можна використовувати тільки в цю дату.
- Час очищається — але історичний перегляд накопичених максимальних ігрових часів, за датами, завжди доступний для всіх сторін.
Пункти проблем, які потребують дизайну — для вирішення:
Часова частка витрат відзначається батьком, натискаючи на...?
Чи потрібно явне позначення "витраченого часу"?
Власне, щоб це мало ефект, ідея полягає в тому, що діти в родині заробляють час, виконуючи домашні завдання. Окремо від домашніх завдань, як ми це представляємо, це те, що часові квитки надаються батьками та поглинаються дітьми.
Але може нам чогось не вистачає? Для того щоб час (ліміти) мав ефект, нам потрібно також мати механізм контролю, щоб ліміт часу справді діяв. Тут виникає реальна проблема: як найкраще це вирішити?
Я насправді шукаю ідею. Повідомте мене!
І нехай ваш 2024 рік буде чудовим!
Перекладено з: Django-based TimeBank web app