Путь создания фитнес-платформы: от идеи, которая изменила меня, к проекту, который меняет других. Часть 2
*Для тех, кто не читал статью "Путь создания фитнес-платформы: от идеи, которая изменила меня, к проекту, который меняет других. Часть 1" - рекомендую начать именно с нее перед прочтением текущей. Там описано, как мне пришла идея, с чего я только начинал реализацию и небольшое наставление ребятам, кто также как и я берется за разработку своего проекта)
Глава III. Разработка
Данная глава будет, как не странно, наиболее объемной и информативной. Не буду прям очень подробно вдаваться в детали по типу что, зачем и почему, но в общих чертах опишу процесс разработки своего проекта.
Глава III. Часть 1. Базовый минимум
Написав «консольные калькуляторы» я приступил к изучению библиотеки aiogram. Параллельно изучал принципы работы с базами данных и общую матчасть СУБД для более корректного понимания дальнейшей архитектуры проекта. Не постыжусь сказать, что далось мне все это не сильно просто и времени было затрачено приличное количество, однако по итогу я разобрался в изучаемых темах и достиг нужного уровня для продолжения создания своего детища
На самом деле тут вставлю небольшой абзац о том, какая на самом деле была глупость писать часть функционала будущего бота в виде консольного приложения. До изучения аиограма я думал, что для перевода созданных структур в интерфейс телеграма достаточно будет просто заменить стандартные инпуты и принты, после чего все, аналогично консоле, будет отображаться в телеграме, однако тут, откуда не возьмись, взялась какая то машина состояний и полностью сломала мой зловещий план обмана системы по внедрению кода в выбранную визуальную оболочку. По итогу - я полностью переписываю консольные приложения под аиограм, оставляя неизменными только сами расчеты
На дворе конец лета 2024 года, я наконец то завершаю перевод основных калькуляторов под интерфейс бота и перехожу к созданию регистрационной формы и личного кабинета с подвязкой к БД. Ах да, отдельно забыл упомянуть о пройденных кругах ада при тестировании калькуляторов, на которое я в сумме потратил времени примерно как половина написания полного кода этих же кальков. К моему счастью создание последовательности действий для регистрации и разработка личного кабинет прошли гораздо более шустро. Но естественно не обошлось и без проблем - одной из таких стала функция отправки уведомлений с мотивационными фразами, которая выступала в качестве вопроса в анкете «Желаете ли вы получать уведомления с мотивационными фразами, если да, то вручную задайте расписание их получения» (кстати в дальнейшем я эту функцию вырезал, уже после исправления всех ошибок). Сама же сложность заключалась в сохранении и возобновлении задач в планировщике в случае, если бот перезапускается. Не много, не мало провозился я с этим почти до конца октября того же года, но сделаю оговорку, работал в это время не только над сохранением/извлечением задач, но и над другими функциями, однако та, о которой мы сейчас говорим, наибольшим образом забирала меня и выделяемое на бота время. Изначально я начал делать костыльный вариант с сохранением самих задач в отдельную таблицу в MySQL и при перезапуске подтягивать их оттуда, но к сожалению ничего не сработало и уведомления просто не приходили. Спустя еще n-ое количество попыток я наконец то дошел до базы данных Redis, используемой для кэширования необходимой мне информации. Сказать честно, я и немного ранее знал, что внедрение редиса решит мою проблему, однако, несмотря на это, продолжал долбиться в стенку (не знаю зачем, в дальнейшем Redis мне помог реализовать огромное количество дополнительных логик в проекте). Redis смог решить мою проблему и я наконец то двинулся дальше
Следующим этапом я решил реализовать логику поздравления пользователей с Днем Рождения. Данная идея совмещала приятное с полезным: отправка теплого сообщения и автоматическое обновление возраста в базе данных (с возрастом обновлялись и некоторые дополнительные параметры). Тут встали две новые, еще более сложные проблемы:
Я же планирую сделать бота не для трех человек, вероятно нужно учитывать часовой пояс пользователя, чтобы поздравление приходило в нужные дату-время, верно?
Как мне реализовать функцию отправки поздравления максимально корректно, учитывая часовой пояс, а также чтобы она выполнялась независимо от контекста работы пользователя с ботом?
Я решил идти по порядку. С часовым поясом удалось разобраться достаточно быстро, если бы не одно НО. В анкетировании достаточно было просто ввести дополнительный вопрос, однако при изменении данного параметра в личном кабинете пришлось учитывать изменение и планировщика (ой, проболтался раньше времени о способе решении второй загвоздки), что вызвало некие дополнительные трудности. Решением второй проблемы, как вы уже поняли, стало очередное использование планировщика задач, да не простого, а золотого. Суть в том, что он не сохраняет задачу для каждого пользователя, когда ему присылать поздравление. Вместо этого каждый час он ищет пользователей, у которых, согласно часовому поясу, сейчас полночь, затем проверяет, сегодня ли День Рождения и если да, то уже выполняет необходимые действия. Дополнительно к этому прикрутил логику при наличии простоев, когда бот не работает и вуаля, готово!
После планировщика и мысли о ежегодном обновлении возраста и иных параметров я решил вернуться к разработанной на тот момент анкете. В голову пришла мысль, что при сборе такого пласта данных пользователей необходимо ввести корректное пользовательское соглашение на обработку этих самых данных. В этом мне помог deepseek, однако я немного засомневался в его компетентности, потому, после прочтения соглашения, решил обратиться к знакомому юристу, дабы удостовериться в качестве работы. На выходе я получил документ с уймой правок и внес уже корректную версию в стартовое окно бота :)
Глава III. Часть 2. Расширение функционала и первый «отпуск»
После этих действий бот уже в целом представлял из себя архитектуру, которая может впустить пользователя и дать ему возможность воспользоваться калькуляторами и прочими маленькими дополнительными функциями. Далее я решил серьезно дополнять функционал. Передо мной встала задача придумать что то такое, что будет интересно, востребовано и самое главное - полезно. Так родилась на свет идея с уникальной функцией «Донабор КБЖУ». Рассказывать о ней в статье не стану, предлагаю вам лично зайти и протестировать, она как раз доступна для ознакомления в бесплатной подписке. После этого решил добавить еще парочку новых калькуляторов, одним из которых стал калькулятор биоритмов. Ранее я сам пользовался таким кальком на каком то случайном сайте, но когда решил добавить его в свой проект крайне был ошеломлен тем, что то, чем я лично пользовался ранее, оказалось некорректно по производимым расчетам. Спросите как я это узнал? Да очень просто (нет). Всего лишь пришлось изучить архивные методические указания одного из медицинских университетов и сопоставить их с +-актуальным исследованиями. Окончательно побудило меня на это то, что воспользовавшись калькулятором на разных сайтах везде, АБСОЛЮТНО ВЕЗДЕ, был разный результат. Я же решил расставить все точки над i и ввести в свой калькулятор точные и единственно корректные найденные формулы. Затем я решил дополнить калькулятор статистикой о критических фазах и подкрутить возможность получения уведомлений об актуальных биоритмах в заданное пользователем время (снова встреча с планировщиком задач).
Кстати разработанный калькулятор наконец то стал реально коррелировать с моим состоянием, что помогло мне немного изменить распорядок дня и добиться большей продуктивности
Наконец то настало время заслуженного отдыха, а точнее в моем институте наступила сессия. Так уж повелось, что с начала разработки и по сей день во времена, когда наступает сессия, я приостанавливаю разработку своего проекта и готовлюсь к сдаче экзаменов. Тот раз, о котором идет речь - не стал исключением. Скажу даже больше, я настолько разгубастился, что еще и после сессии не кодил проект около двух недель. За это время изучал Docker, как правильно деплоить проект и тд, тогда я еще не знал, что до этого мне придется разрабатывать проект еще примерно около 8-9 месяцев (думал будет намного меньше, но мой внутренний перфекционист, кричащий о качестве и честности победил). Спустя «отдых» я вернулся за плотную работу. Начал с более приземленных вещей, чем разработка нового функционала, а именно с оптимизации запросов к базе данных (сделал их гибридными с кэш слоем, где это было наиболее предпочтительно), полностью переработал анкету и личный кабинет, провел глобальное тестирование и начал двигаться дальше
Генерация индивидуальных рационов питания. Тут больше и нечего сказать. Вспоминаю то время как страшный сон. Я сидел и разрабатывал днями и ночами в постоянном беспокойстве, что у меня ничего не получится при том что расчет был на то, что данная функция будет одной из ключевых в боте. Честно, если углубляться, то история разработки данной функции и мои переживания можно растянуть на еще одну главу, но все же опишу в общих чертах. Пришлось проделать очень много работы. Изучить реальные рационы, составленные фитнес-тренерами и диетологами. Проанализировать ассортимент популярных магазинов, чтобы понять, какие продукты могут быть в рационе, а какие нет. Прикинуть время на приготовление тех или иных блюд и взвесить их пользу, согласно имеющимся нутриентам в продуктах. Визуально проанализировать как выглядит n-ое количество граммов определенных продуктов. После этого я начал писать код. Было огромное количество правок, тестов, тестов и правок, правок и тестов… Спустя три месяца я впервые сгенерировал полностью готовый, корректно составленный рацион, который отвечал всем поставленным требованиям, однако проблема - генерация на одного пользователя занимает около 3-х минут. Пришлось делать разбивку по неделям, подкручивать брокер задач и стараться максимально оптимизировать код. Стало намного лучше. Подтянул функцию генерации рационов в PDF-файл и наконец то перешел к чему то иному
Глава III. Часть 3. Разработка концепции бота. Зарождение названия и дизайна
Мне явно требовалось отдохнуть от всего, что может быть связано с питанием и я решил заострить внимание на дизайне бота. К сожалению, стартовый бюджет у меня был сильно ограничен, но имелось много добрых знакомых, которые делали всякого рода скидки и уступки. Одним из таких знакомых был мой будущий дизайнер. На тот момент в боте уже было что то наподобие черновых вариантов картинок с пояснением к замерам, которые я делал в фотошопе, благо дело имел опыт работы с ним.
Моя кривая работа, сделанная в фотошопе :)
Названия у бота еще не было, как и идеи по общей концепции, однако в скором времени на ум, совершенно случайно, взбрела следующего рода мысль: «Так, я делаю проект по улучшению фигуры человека без вреда для здоровья, учитываю множество параметров его организма. Что если назвать бота в честь элемента, на всестороннюю проработку которого он нацелен? А именно в честь нашего организма? Так-так-так, организма? Да нет же, лучше тела! Как наше тело звучит на английском? Правильно, body. А как можно изменить это слово, чтобы получить его модифицированную версию, которую можно использовать в качестве нейминга проекта? Bodix!». Честно говоря мне безумно понравилось это название, но после данной мысли я отнесся к нему скептично, а все потому что я думал, что такое звучное название ну 100% занято какой то крупной корпорацией по разработке иновационных лекарственных средств и придется придумывать все заново. Насколько же я был приятно удивлен (да что уж там удивлен - ошеломлен!) когда понял, что по сути это слово (а точнее извращенная модификация слова:)) никем и ничем не занято
Пришло время прорисовывать дизайн. Как таковых заготовок и идей не было, но слава Богу, дизайнер был, на мой взгляд, очень компетентен и хорош в своем деле. Он прислал эскиз логотипа и после этого мы вместе стали разрабатывать полноценную концепцию. В основе лежала идея легкости, ненавязчивости и узнаваемости, но в стиле минимализма. Окончательно разработанный логотип представил из себя совмещенные воедино два тела - мужское и женское, что подчеркивало корректность подхода работы бота для обоих полов. Цветовая гамма (сине-розовая) во всем проекте продолжает мысль баланса соотношения. Далее дизайнер разработал, согласно уже продуманной идеи, три фона под наполнение различным контентом. После этого я с чистой совестью оплатил работу дизайнера и начал базово изучать Adobe Illustartor с целью добавления того самого соержания на подготовленные фоновые изображения. Спустя месяц все необходимые картинки были готовы и внедрены в код. Нужно было приступать к очередному добавлению функционала
В следующей статье из серии будет описано продолжение разработки BODIX...
