Comments 91
Программа помогла ветеринару скорректировать лечение Манишки? Манишка теперь бодрее? Вы достигли цели в поддержании здоровья своей четверолапой питомицы?
AI - ускоритель для того кто умеет.
А уметь надо всё-таки достаточно, по крайней мере интуитивно и логически понимать архитектуру проекта и всего что AI предлагает. В рамках такого проекта - использование AI просто прекрасное. Но если всё-таки уметь чуть меньше, или проект несколько больше, то есть гигантские риски напороться на проблемы определенных решений, за которыми будет следовать бесконечный реинжениринг и рефакторинг. Тут я не докапываюсь, но считаю это важным уточнением.
А сам проект просто замечательный, бесконечный респект автору за такой сервис.
Спасибо за высокую оценку. Согласен, если проект разрастется будет гораздо сложнее его поддерживать через ИИ. Но тут довольно простая бизнес логика, и сервисов по сути всего два. Зато их можно горизонтально масштабировать =)
Вообще я Lead DevOps, и в разработке разбираюсь довольно поверхностно, но на мой взгляд достаточно чтобы выстроить архитектуру проекта. Нагляделся уже на узкие места в реальных прод окружениях, опыт мне кажется помог)
То есть вы вполне могли и написать это все сами. Только времени ушло бы много. А написал ИИ под вашим чутким руководством. Ну и отлично! Вот он, эталонный пример как пользоваться ИИ, а не вот это вот всё. Обычно пишут промпты "у меня кошки диабет инсулин напиши прогу чтобы поле ввода и график по времени, и чтобы ветеринар видел" - они же обычно и орут, что ИИ бесполезен и не нужен.
Вы сделали просто отличную работу и для себя, и для кошки, и ваша статья должна стать примером для других.
Мог бы наверное. За полгода где-то)
Каждый коммит - отдельный промпт.
Только в мастере этих коммитов уже хорошо за 2 сотни)
За полгода? Такое простое приложение? Серьёзно?
От силы за неделю, из которых последние 3-4 дня будет допиливание логики и красивостей.
Я с нуля, вкатываясь в докер, джангу и реакт за 3 месяца написал внутреннее вебприложение с кучей моделей, сложными вложенными формами и прочими графиками.
Вместо того, чтобы себя расхваливать, лучше бы Автора поддержали.
Круто! Значит для вас это простая задача - микросервисы на FastAPI с роутерами, Swagger API, AI интеграция с промпт-инжинирингом, интерактивный Plotly, Redis для синхронизации состояния, PostgreSQL, Docker Compose, автотесты 82%, CI/CD в GitHub Actions.
Но я и не разработчик, я маску на стройке нашел)
Для меня результат за 5 дней вечерами после работы - хороший темп.
Главное что приложение работает в проде и помогает людям. Остальное вторично.
Да, можно написать всё самому, но ведь мы же упираемся в лимит времени и ресурс внимания. Одно дело заниматься всем этим в 20 лет, когда его куча. Другое дело в 35-40.
У меня похожая история с переделкой приложения под себя https://habr.com/ru/articles/967024/ . И если делать самому то это займёт уйму времени, когда ты сталкиваешься с технологиями, с которым никогда не работал.
И выходит, да, что ИИ это отличный инструмент ускорения разработки.
Добавьте ещё возможность офлайн работы с сохранением данных на устройстве. Без этого не надёжно.
Я может проглядел, что использовали для взаимодействия исходного кода и Claude? Какие инструменты? Или копировали исходники из чата и обратно? Спасибо.
https://claude.ai/code оказался довольно удобным для работы с репо на гитхабе.
Также использовал в vscode плагины Claude Code и Codex.
Ещё периодически юзал Aider в связке с OpenRouter, когда заканчивались лимиты, но тут грант от Claude Code оказался весьма в кассу и стало проще)
В целом если подправлять нейронку, то результат выходит более чем приличным. На 12000 строк проекта Code coverage > 80%, maintability по версии Sonarqube рейта "А".
Сейчас вот например за 4 часа прикрутил фичу подтверждения email при регистрации, причем много где я включал ratelimiting.
Т.е. Claude анализировал код на гитхабе, и вносил коммиты туда? Или комиты локальные? Т.е. вопрос скорее, обязателен ли гитхаб, можно было бы это проделать без него?
В случае использования вебморды от Claude коммиты действительно вносятся прям на гитхаб, естественно в каждой новой сессии в новую ветку, причем это поведение невозможно изменить. Одна сессия - одна ветка.
В случае использования локальных средств разработки коммиты создаются непосредственно локально же, тут уже можно самому выбирать куда коммитить и в каких количествах)
Типичный МР выглядит вот так примерно:
Осторожно, длинная картинка
Понял, спасибо! К сожалению не каждый проект можно разрабатывать с открытым гитхабом, а в наших реалиях, и вообще с любым гитхабом. Отдельная благодарочка за пример с промптом :) Это был следующий вопрос, выгоднее ли разбивать разработку на маленькие итерации, как это делается в обычных командах, или большими постановками. Ещё интересно, может ли ИИ съесть постановки задач, как это делается для людей, например в Confluence-Jira, но это наверное тема для отдельных статей.
Ну гитхаб-то тут как раз закрытый) Утилиты что codex что claude code прекрасно работают с приватными репозиториями. Другой вопрос что контекст может рано или поздно куда-то утечь. Фичи нейронка "прожевывает" довольно неплохо.
Вот например вернемся к подтверждению email - исходный промпт выглядел так:
Сейчас регистрация доступна без подтверждения Email Нам нужно реализовать подтверждение, вероятно, в рамках сервиса auth (но через роутеры/сервисы, вот это вот всё) Использовать будем для этой цели Yandex Cloud Postbox. Юнит тесты обязательно. Обязательны рейтлимиты (желательно конфигурируемые) Письмо с подтверждением регистрации должно быть оформлено в фирменном стиле. В письме должен приходить код подтверждения, который надо ввести на этапе регистрации (шестизначный) Подумай, может я что-то ещё забыл.
И дальше ряд (около 20) мелких уточнений, включающих в себя требования написать юнит тесты, поправить фронт, разобраться с проблемами при регистрации.
В целом вполне себе короткая постановка задачи.
Конечно чем детальнее промпт тем лучше. Но ведь никто не мешает "готовить" промпт через ту же нейронку?)
Вот кстати шаблон, который был нагенерен в рамках промпта выше:
Тыц
Кстати да, я немного поработал с Claude и ChatGPT, для написания развесистой утилиты, меня результат удовлетворил. Правда только через чат. Но понял, что сначала надо поработать над самим заданием вместе с ИИ, прежде чем позволить нейронке срочно бросаться код генерить. Так получается меньше корректировок и меньше необходимости повторного ревью кода. С этой стороны открывается огромный простор для системных и бизнес-аналитиков :)
Отдельно плюс за требования к рейтлимитам :) Видимо на опыте.
Это прям агент. Подключается к репе и делает все сам. Почти вот истратил свой 250 долларовый грант - чуток в шоке от того какое кол-во кода он может переварить, отрефакторить... Сделать типовой лендинг с огромной кучей контента, анимациями и всем таким. В общем круто очень, но реальные таски с реализацией бизнес логики делать очень неудобно...
Только что допилил фичу по восстановлению пароля по емейлу. Заняло ровно 2 промпта.
Секрет тут прост - промпты надо просить у chatgpt codex, дав возможность ознакомиться с проектом)
Вот пример на мою фичу:
Промпт
Ты — senior fullstack разработчик в проекте Diabnostic (микросервисная архитектура: отдельный Auth-сервис на Python/FastAPI, отдельный API-сервис и React/TypeScript SPA-фронтенд). В проекте уже реализованы:
Подтверждение e-mail при регистрации (с 6-значным кодом, TTL 15 минут, отправка через Yandex Cloud Postbox по AWS SES-совместимому API, фоновые задачи через FastAPI BackgroundTasks).
Рейтлимиты для e-mail-верификации (отдельно на отправку, проверку и повторную отправку).
Авторизация через JWT в HTTP-only cookies.
Капча (Cloudflare Turnstile / Яндекс Smart Captcha) на формах регистрации/логина.
Задача: реализовать фичу “Восстановление пароля по e-mail” на бэкенде (Auth-сервис) и фронтенде (SPA), в том же стиле, что и текущая e-mail-верификация. Учти безопасность, UX и рейтлимиты.
1. Общие требования
Нужен полноценный flow:
Пользователь на странице логина нажимает “Забыли пароль?”.
Переходит на отдельную страницу, вводит свой e-mail (и капчу, если она включена).
Получает письмо со ссылкой для сброса пароля (одноразовый токен + ограниченный срок действия).
По ссылке попадает на страницу “Сброс пароля”, вводит новый пароль, подтверждает.
Пароль меняется, все активные сессии этого пользователя инвалидируются.
Никаких утечек информации: во всех ответах API нельзя явно говорить, существует ли пользователь с таким e-mail. Ответ всегда “Если такой e-mail зарегистрирован, мы отправили инструкцию по восстановлению пароля”.
Используй уже существующую инфраструктуру:
тот же механизм отправки писем, что и для e-mail-верификации;
ту же систему рейтлимитов (slowapi или что сейчас используется);
ту же систему шаблонов HTML/текст-писем (сделай отдельный шаблон “reset password”, но в том же стиле).
2. Backend (Auth-service, FastAPI)
2.1. Модель данных
Добавь сущность для токенов сброса пароля. Вариант: отдельная таблица
password_reset_tokens:
id(UUID или serial).
user_id(FK на таблицу пользователей).
token(достаточно длинный случайный urlsafe string, ≥ 32 байт).
created_at(timezone-aware).
expires_at(timezone-aware, TTL ~ 30–60 минут).
used(BOOLEAN, по умолчанию false).Требования:
Один пользователь может иметь несколько токенов в истории, но одновременно активным должен быть только один:
при создании нового токена все предыдущие неиспользованные токены этого пользователя помечаются как
used=trueили логически инвалидируются.Желательно индекс по
token.Напиши alembic-миграцию в том же стиле, что и существующие миграции.
2.2. Эндпоинты
Реализуй следующие эндпоинты в Auth-сервисе (пути можешь скорректировать, но придерживайся духа):
POST /auth/password-reset/request
Вход: JSON
{ "email": "<string>", "captcha_token": "<string>" (опционально, если включена капча) }.Логика:
Нормализовать e-mail (lowercase, trim).
Если пользователь с таким e-mail существует и активен:
создать запись в
password_reset_tokensс новымtokenиexpires_at= now + 30 или 60 минут;отправить e-mail со ссылкой вида:
https://<frontend_host>/reset-password?token=<token>
(URL берём из конфигурации, не хардкодим).Если пользователя нет — просто не делать ничего, кроме фиктивной задержки (чтобы не было времени ответа в качестве сайд-канала).
Ответ всегда 200 OK:
{ "message": "Если такой e-mail зарегистрирован, мы отправили инструкцию по восстановлению пароля." }Безопасность:
Рейтлимит по IP и по e-mail (см. ниже).
Валидация капчи, если она включена (использовать текущую реализацию).
POST /auth/password-reset/confirm
Вход: JSON
{ "token": "<string>", "new_password": "<string>" }.Логика:
Найти
password_reset_tokens.token == token.Проверить:
существует ли токен,
used == false,
expires_at > now().Если что-то не так — вернуть 400 или 422 с общим сообщением вида
"Неверный или просроченный токен", без деталей.Если всё ок:
обновить пароль пользователя (используй тот же хешер/валидатор, что и при регистрации/смене пароля),
пометить токен как
used=true,инвалидировать все существующие сессии/refresh-токены этого пользователя (если у нас есть такая механика; в простом варианте можно обновить поле
password_changed_atи завязать проверку токенов на него).Ответ 200 OK:
{ "message": "Пароль успешно изменён" }Опционально:
Если удобно, можно добавить вспомогательный эндпоинт
GET /auth/password-reset/validate?token=..., который просто говорит фронту, что токен жив/мертв, чтобы красиво показать страницу.2.3. Рейтлимиты
На
POST /auth/password-reset/request:
Рейтлимит по IP: например, 5 запросов в час.
Рейтлимит по e-mail: например, 3 запроса в час и 10 в сутки.
Используй ту же систему, что и для e-mail-верификации (slowapi или аналог). Если уже есть утилиты для рейтлимита, добавь отдельные ключи/константы, аналогично:
RATELIMIT_PASSWORD_RESET_REQUEST_IP
RATELIMIT_PASSWORD_RESET_REQUEST_EMAILЛогика:
При превышении лимита возвращать 429 с локализованным сообщением.
2.4. Безопасность и логирование
Не логировать токен в явном виде в обычный лог (можно частично замаскировать).
Логировать события:
запрос сброса пароля (user_id если найден, IP, user-agent),
успешный сброс пароля.
Не раскрывать в API, есть ли аккаунт с таким e-mail.
3. Frontend (React/TypeScript SPA)
3.1. Страницы и маршруты
Ссылка “Забыли пароль?” на странице логина
На странице логина добавь ссылку/кнопку “Забыли пароль?”.
При клике — переход на новый маршрут, например
/forgot-password.Страница “Забыли пароль” (
/forgot-password)
Форма:
поле
виджет капчи, если включена (используй тот же компонент, что и в регистрации/логине),
кнопка “Отправить инструкцию”.
Состояния:
начальное,
loading (крутилка на кнопке),
success (показываем сообщение “Если такой e-mail зарегистрирован…”),
ошибки (сетевые, 429, капча, прочие).
Поведение:
После успешного POST запросе всегда показывать один и тот же success-экран, не держа пользователя в неведении.
Если пришёл 429 — показать аккуратное сообщение о слишком частых попытках.
Страница “Сброс пароля” (
/reset-password?token=...)
При монтировании:
прочитать
tokenиз query-параметров;если токена нет — показать ошибку и ссылку “На страницу логина”.
Форма:
новое поле пароля,
подтверждение пароля,
валидация сложности пароля в том же стиле, что на регистрации (длина, допустимые символы).
При сабмите:
отправить
POST /auth/password-reset/confirmс{ token, new_password }.Показать:
успех — “Пароль успешно изменён, теперь вы можете войти” + кнопка “Войти” (редирект на
/login);ошибку — “Неверный или просроченный токен” + кнопка “Запросить новый” (ссылка на
/forgot-password).3.2. Локализация
Добавь все новые тексты в i18n (RU/EN), в стиле уже существующих ключей:
auth.forgotPassword
auth.resetPassword
auth.resetPasswordDescription
auth.resetPasswordEmailSent
auth.resetPasswordSuccess
auth.resetPasswordInvalidTokenи т.д.
3.3. UX/детали
После отправки формы “Забыли пароль?” не оставляй пользователя на той же форме — показать отдельный “success state”.
На странице сброса:
два поля пароля с проверкой совпадения,
показать ошибки валидации локализованно.
4. E-mail шаблон
Реализуй новый e-mail шаблон для сброса пароля:
HTML + plain text версии, как и для e-mail-верификации.
Содержимое (пример, RU/EN):
Заголовок: “Восстановление пароля в Diabnostic”.
Текст: “Вы (или кто-то ещё) запросили сброс пароля. Если это были вы, перейдите по ссылке ниже… Если нет — просто проигнорируйте это письмо.”
Кнопка/ссылка вида
{{ reset_link }}.Информация о сроке действия: “Ссылка действительна 60 минут”.
Вставлять имя пользователя или e-mail, если есть.
5. Тестирование
Напиши базовые тесты:
Backend:
запрос сброса пароля с существующим e-mail → создаётся токен, уходит e-mail;
запрос сброса пароля с несуществующим e-mail → токен не создаётся, e-mail не отправляется, но ответ такой же;
повторный запрос до истечения TTL → создаётся новый токен, старый инвалидируется;
успешный
password-reset/confirm→ пароль меняется, токен помечается использованным;повторный
confirmс тем же токеном → ошибка;
confirmс просроченным токеном → ошибка.Frontend:
базовые unit/интеграционные тесты компонентов (по возможности): рендер форм, обработка success/error state, редиректы.
6. Оформление результата
Внеси изменения последовательно:
backend (Auth-service: модели, миграции, роуты, сервис, tests);
frontend (маршруты, компоненты, i18n);
e-mail шаблоны.
Обнови документацию Swagger/OpenAPI для новых эндпоинтов.
При необходимости обнови
.env.example(например, если добавляются переменные для фронтенд-URL для reset-ссылок).Сгенерируй весь необходимый код (backend + frontend + миграции + тесты) в том же стиле, в котором уже написаны e-mail-верификация и существующие Auth-эндпоинты. Если есть сомнения по структуре проекта — сначала кратко опиши план изменений по файлам, затем приводи фрагменты кода по частям.
Глядя на этот невдетских размеров промпт, никак не могу отделаться от ощущения, что написать авторизацию самому тупо заняло бы меньше символов.
Спасибо за статью и за аппу. Вопрос немного вбок: как у Claude грант получить?
Прямо сейчас зарегистрироваться там, и до 18 ноября дадут 250$
support.claude.com/en/articles/12690958-claude-code-promotion/
Но работает этот грант только в вебморде Claude Code (https://claude.ai/code/)
Спасибо. Жаль, только, что кредиты сгорят уже 19 ноября.
Уберите рекомендации из ИИ-анализа - он вам кошку до смерти залечит, а потом скажет, что и правда, you are absolutely right, рекомендации могли быть другими, с новой кошкой будем аккуратнее.
Всё верно, поэтому внизу и есть дисклеймер. В целом ещё думаю над корректным промптом.
Дисклеймер не защитит кошку от действий владельца, он защищает только вас от судебного иска. Анализ данных должен проводить дата-аналитик - лечащий врач. Правильный промпт - "удали дисклеймер с сайта".
Возможно, формировать ответ от ИИ в духе "Что мне рассказать ветеринару при визите?"
"Наблюдались падения сахара по вечерам от... и до..."
При этом исключить даже намек на какие-либо рекомендации по лечению. Что думаете?
На самом деле актуальный вопрос вы задали, сам над ним думаю.
Просто выдайте данные врачу, не надо советов, ничего не надо придумывать. Неправильный пересказ графиков может сбить врача с толку. Лучше добавьте возможность залить фото, бывает, что кота тошнит чем-то, а потом ветеринар спрашивает, как оно выглядело.
На приёме должно быть так: вот график, вот цифры, вот кот (усы-лапы-хвост) - доктор, что думаете? Никаких предположений с вашей стороны и тем более со стороны генеративной модели, которая токены предсказывает.
Рекомендации убрал. Спасибо вам за подсказку. Теперь AI только собирает данные в общий отчет и прилично отупел. Думаю то что нужно)
Пример
Дисклеймер я бы вынесла наверх.
«Средние значения», «Минимальное / Максимальное значение» — что‑то не понимаю, зачем «Вердикт нейросети» для этого, это же делается наипростейшим кодом?
Оффтопик
Давно ли диабетом болеете? Сам кошатник со стажем, интересно)
Одна девушка написала что у неё огромный Excel с формулами и она боится его потерять.
...но мысль о бэкапах в светлой голове так и не заворочалась.
Бэрримор, какое такое "защищённое DRM аудио или видео" этот пепелац пытается воспроизвести???
Вероятно капчу) О баге знаю, буду фиксить) Хотя это наверное даже не баг а фича. Сейчас используется яндекс смарткапча, которая иногда просит ввести что-то там текстом. И там есть возможность проигрывания текста на слух. Наверное оно.
Спасибо Вам! Очень круто, что делитесь проектом.
Для данного кейса (ведение статистики без ненужных AI-советов) можно просто сделать толковую гугл-таблицу и поделиться ей ридонли, пользователь создаёт копию и работает в ней, цена вопроса 0 рублей.
Я так и делал! =)
Проблемы начались на приёме у ветеринара. Показываю таблицу на телефоне - мелко, неудобно. Распечатка - врач не понимает мою структуру. Расшарить файл можно, но каждый владелец приходит со своей таблицей в своём формате - ветеринару каждый раз надо вникать.
Плюс у врача должны быть все его пациенты с диабетом в одном месте, а не россыпь чужих Google Sheets. И временный доступ через код удобнее чем "дать права → не забыть отозвать".
Так что таблица отлично работает для личного учёта. Но для взаимодействия "владелец → врач → 10-20 пациентов" нужна стандартизация.
И кстати, именно эту фичу с доступами для ветеринаров я сейчас и пилю.
У меня возник всего один вопрос - что изначально мешало принести ветеринару не таблицу Excel а график? Или ваш Excel строить графики не умеет?
Умеет, я так и делал. Строил график, сохранял PNG, показывал с телефона.
Проблемы:
Один статичный график без интерактивности - нельзя зумить в интересный период, кликнуть на точку чтобы увидеть точное значение
Надо было показать несколько метрик - отдельный график глюкозы, отдельный инсулина, скользящую среднюю. Получалось 3-4 картинки
Перед каждым приёмом обновлять графики, сохранять, закидывать на телефон
Да, это работает. Но это костыль. Веб-приложение с интерактивными Plotly графиками просто удобнее - открыл ссылку, всё актуальное, можно покрутить.
Плюс для ветеринара это будет разовая картинка от одного владельца, а система где все пациенты в одном интерфейсе.
Отличная статья, спасибо.
Вопрос - приложение планируется становится платным? Как вы будете хотя бы расходы на сервер покрывать?
Базовый функционал (трекинг, графики, экспорт, шеринг) планирую держать бесплатным. Могут появиться премиум-фичи для продвинутых пользователей, но это опционально.
Основная ставка - на B2B. Ветклиникам нужен единый интерфейс для всех пациентов с диабетом, статистика, возможность оставлять рекомендации. Это уже профессиональный инструмент за который готовы платить.
Сейчас расходы - 1500 руб/мес на сервер. При десятках пользователей это копейки. Если вырастет до тысяч - тогда монетизация станет актуальной.
Ветклиникам нужен единый интерфейс для всех пациентов с диабетом, статистика, возможность оставлять рекомендации. Это уже профессиональный инструмент за который готовы платить.
Вы уверены?)
Пишу, как человек, который недавно чуть ли не ушел в разработку нового сервиса, но перед этим решил сделать опрос ЦА и понял, что это мало кому нужно.
Честно? Не уверен :) Это гипотеза.
Сейчас фокус на владельцах - делаю бесплатный инструмент. MVP кабинета ветеринара с доступом по кодам уже написал, но пока не знаю нужно ли это рынку. Если соберу пару сотен активных пользователей - пойду валидировать B2B у реальных клиник.
А может окажется что им вообще не нужно, и проект останется некоммерческим для комьюнити.
Расскажете про свой опыт? Какую ЦА опрашивали и что выяснили?
Расскажете про свой опыт? Какую ЦА опрашивали и что выяснили?
Собирался делать сервис видеоповторов для тенниса, сходил к хозяевам кортов и понял, что им это не очень интересно (или готовы за копейки). А еще у меня был опыт разработки устройства для кошек (вот статья) и там тоже с экономической частью пролет)
Если соберу пару сотен активных пользователей - пойду валидировать B2B у реальных клиник.
Мне кажется можно не ждать и уже сходить.
У Вас получается ЦА - это хозяева кошек, а зарабатывать хотите с клиник. Боюсь им это будет не очень интересно если не решает их какую-то боль.
Девайс для кошек очень понравился, классное решение) У моих кошек правда лотки не в туалете стоят, но потенциал у такого решения как мне кажется есть)
В теннисе к сожалению разбираюсь как свинья в апельсинах, так что ничего не могу сказать)
Боюсь им это будет не очень интересно если не решает их какую-то боль.
Прежде всего это довольно удобный трекер глюкозы, и прежде всего для меня) С клиниками если не взлетит - я не расстроюсь =)
Но наработки некоторые по клиникам уже есть, смею надеяться они могут заинтересовать тот же Белый Клык =)
Чуть скриншотов
Не все же продукты должны требовать плату за прямой функционал, при набранной аудитории затраты могут покрываться дальнейшей рекламой.
Условно, на примере этого трекера, что мешает после показывать по партнерке баннер с препаратами для питомцев, или другие товары для животных.
Классное начало, респект!
Интересный заход с фокусом на владельцев. Я начинал копать похожую тему после смерти кошки. Пришел к тому, что клинике как будто не сильно интересно и подзабил.
Эта архитектура применима не только для инсулина, ещё же очень много биомаркеров, динамика которых важна при тех или иных заболеваниях.
Есть ветеринарный софт, который позволяет строить графики.
Динамику тоже можно обсчитывать и иллюстрировать (снижается за неделю быстрее чем за прошлую или так же, и тд).
Есть ещё индивидуальная норма - что для одного ещё нормальный показатель на грани, для другого уже нет.
Если смотреть в сторону клиник - имхо для них важна автоматизация парсинга результатов лаборатории, чтоб не забивать руками (да и владельцам хорошо).
Если интересно - можем пообщаться подробнее, я бы может вернулся к теме, как-то поучаствовал в свободное время.
Какая знакомая стилистика дизайна :)
Вы огромный молодец!) Спасибо!) Да будут здоровы наши братья меньшие
я не увидел у автора ресерча по существующим решениям. Для людей,например, давно есть https://nightscout.github.io/
В том и дело, что для людей подобных решений полно, а для животных, извините, кот наплакал.
Ну оно ж не принципиально от чьего имени данные вносить? Графики строит, шарить данные тоже можно. Прекрасно в докере поднимается (равно как и в прочих сервисах типа хероку и т.д.) Может правда не такое красивое. Я без критики и претензий, если честно. Чем больше решений на рынке диабета, тем лучше нам - диабетикам. Я как пользователь CGM с более чем 7-ми летним стажем (и стажем диабета 24 года) таким проектам только рад.
Отличный и полезный pet-проект. В буквальном смысле
Может уже кто-то написал, но всё равно повторю - на главном экране в описании пациента нужна графа "стерилизован/кастрирован или нет"
Спасибо за увлекательную и вдохновляющую историю. Меня заинтересовала точка разворота в сторону переработки архитектуры. Сначала были таблички, python скрипты, потом web приложение на fastapi, как я понял. Потом проверка юзабельности у супруги - POC получен. Насколько правильным вам сейчас кажется такой подход? Как вы писали, многое удалось «перенести в новую архитектуру», но многое ,видимо, и «ушло». В итоге, python полностью вытеснили?
Если честно, сначала я просто делал фичи, которые самому казались интересными. Таблички, скрипты, мини-вебка — всё это были быстрые эксперименты, чтобы понять, что вообще работает.
Приложение изначально было на flask, теперь на fastapi.
Когда стало понятно, что проект растёт и им потенциально могут пользоваться другие люди, уже пришлось собрать нормальную архитектуру. Рабочие вещи я перенёс, экспериментальный мусор — выкинул.
Python остался в основе, просто теперь это не куча скриптов, а аккуратный сервис.
Я правильно понимаю, что все промпты с постановками задач писались на английском?
Как за 5 дней с помощью Claude я создал приложение для кошки с диабетом (и кажется запустил стартап)