«Rose and Cross» — это короткий психологический хоррор в жанре «симулятор ходьбы».
Среднее время прохождения игры: 40 минут
ВНИМАНИЕ: У некоторых людей могут возникать припадки при воздействии вспышек света и мигающих изображений, даже если у них никогда не диагностировалась эпилепсия. Игра содержит сцены насилия и убийств, которые могут негативно повлиять на психику. Некоторые элементы могут быть неподходящими для определенных возрастных категорий. Рекомендуется разумно ограничить аудиторию игры. Все совпадения случайны и не имеют ничего общего с реальностью. Рекомендуется использовать наушники для полного погружения в игру.
На окраине небольшого городка стоит заброшенная ферма В окружении бескрайних кукурузных полей. Горожане рассказывают ужасные легенды о том, что когда-то на этой ферме обитала секта, практикующая темные ритуалы, и что эти кукурузные поля были засеяны кровью и страхом. Главный герой одержим изучением различных сект и оккультных движений и, по слухам, отправляется на заброшенную ферму, где найдет то, что так любит…
Ваш босс говорит вам, что вы должны отправиться в старый летний лагерь, заброшенный после резни, произошедшей 20 лет назад.
Как играть
Лагерь 76 — уникальная игра. Когда вы доберетесь до лагеря и начнете записывать и наблюдать, вам нужно будет ответить на 6 вопросов типа «верно/неверно». Вы можете ответить на них только после посещения каждого места, указанного в расписании.
Управление
[WASD] Ходьба
[E] Взаимодействие
[SHIFT] Бег
[SPACE] Продолжить
[F] Включение/выключение камеры
[LMB] Масштабирование камеры
[RMB] Стрельба из оружия
[CTRL] Приседание
[ESC] Пауза игры
Об игре
Camp 76 — это хоррор-игра, созданная по ощущениям и внешнему виду, как оригинальная игра для PSX.
Делали мы тут бота для бухгалтеров. Назвали BuhBot. И да, мы знаем, как это звучит.
— «БухБот? Это типа пьяный бухгалтер?» — спросил первый же человек, которому мы про это рассказали.
— «Кнопка вызова помощи с шампанским?» — уточнили следующие.
Хотелось ответить «Да, конечно, именно для этого», но нет. «Бух» — это всё-таки про бухгалтерию. Хотя двойное дно в названии осталось, и мы с этим смирились.
Как это началось
Изначально хотели сделать простую штуку: чтобы у бухгалтеров в фирмах не разрывался Telegram от клиентов. Типа кнопки «Пришлите счёт», «Где платёжка» и стандартные ответы на вопросы типа «когда сдавать отчётность».
Ну думали: за пару недель накидаем, запустим, будет радость.
Ага. Как же.
Начали разбираться — поняли, что просто пересылать сообщения туда-сюда это как пластырь на переломанную ногу. Бизнесу нужно было:
Видеть, кто из клиентов уже начинает бесить (чтобы успеть среагировать, пока не ушёл к конкурентам)
Контролировать, чтобы бухгалтеры не забывали ответить на важное
Фильтровать клиентские голосовые на 3 минуты, где про счёт — 10 секунд, остальное — про погоду и планы на отпуск
Короче, проект начал расти. Из «простого бота за две недели» получилась какая-то платформа автоматизации. Мы сами охренели.
Что в итоге сделали (и что работает)
SLA-мониторинг. Бот засекает время: если бухгалтер не ответил клиенту за разумный срок — прилетает напоминалка. Чтобы важные запросы не терялись в потоке сообщений типа «Привет, как дела?».
Особенно актуально в сезон сдачи отчётности, когда бухгалтер уже не помнит, как его зовут.
AI-фильтр (Yandex GPT). Клиенты любят отправлять голосовые на 3 минуты. Там про счёт на аренду — 10 секунд в середине, остальное — про погоду, семью, собаку и планы на отпуск.
Нейросеть вытаскивает суть: «Нужен счёт на аренду офиса до пятницы». Бухгалтер сразу видит, что важно. Экономия нервов — колоссальная.
Анализ настроения клиентов. Система понимает, когда клиент начинает раздражаться или терять терпение. Типа: «Вы уже третий раз спрашиваете про платёжку, человек явно на взводе». Это помогает вовремя среагировать.
Безопасность (152-ФЗ). Всё хранится в зашифрованном виде на серверах в России (Yandex Cloud). Для финансовых данных это не опция, а требование закона. Тут мы не косячили — сразу сделали нормально.
Автоматизация рутины. Повторяющиеся задачи (отправить напоминание, запросить документы, подготовить шаблон) бот делает сам. Людям остаётся только то, где нужна голова.
Что планируем дальше (если не забросим)
Сейчас работает базовая версия (Фаза 1 из трёх). Дальше хотим добавить:
📊 Предиктивную аналитику Бот будет предсказывать проблемы заранее:
«Через 2 недели у вас не хватит денег на зарплату. Вот откуда можно взять» (кассовые разрывы)
«Вы приближаетесь к порогу УСН. Вот сколько осталось до перехода на ОСНО» (налоговые лимиты)
📄 Автоматизацию документов Отправил фото чека в чат — бот распознал текст, подготовил проводку, сохранил в базу. Сказал голосом «Подготовь договор с ООО Ромашка» — получил готовый PDF на подпись.
💳 Платежи внутри чата Налоги, зарплата, счета поставщикам — всё по кнопке в Telegram. Без переходов в банк, без копирования реквизитов. YooKassa + 54-ФЗ (онлайн-кассы).
🏆 Геймификацию для клиентов Типа: сдал документы вовремя — заработал баллы. Накопил баллы — получил скидку. Уровни клиентов (Bronze / Silver / Gold) с плюшками: приоритетная поддержка, бесплатные консультации.
Звучит амбициозно. Посмотрим, сколько из этого реально запилим.
⚠️ Важное про реальность
BuhBot в активной разработке. Это значит: да, система работает, но местами могут быть шероховатости. Где-то интерфейс ещё изменится. Где-то мы добавим фичу, о которой не думали вчера. Где-то может что-то сломаться, потому что мы что-то обновили.
Мы не делаем вид, что всё идеально. Мы показываем как есть.
Если найдёте баг или придумаете полезную фичу — пишите. Это реально ускоряет разработку. И да, мы правда читаем сообщения, а не просто делаем вид.
🏄 Пасхалка (потому что можем)
На сайте спрятали маленького серфера. Он там есть, просто не бросается в глаза.
Первому, кто его найдёт и пришлёт нам скриншот, подарим скидку 20% на любую IT-разработку нашей команды. Будь то сайт, бот или сложная интеграция.
Почему серфер? А хз. Показалось забавным.
Итог
BuhBot начинался как шутка с названием. Превратился в систему, которая реально экономит время бухгалтерам и нервы их клиентам.
Мы не обещаем «революцию в бухгалтерии» или «изменить индустрию». Мы делаем инструмент, который убирает рутину и оставляет людям только то, где нужна голова.
Есть вопросы, идеи или критика — пишите. Мы реально читаем и отвечаем. Даже если вы скажете, что название дурацкое. Мы уже в курсе.
P.S. Да, мы знаем про алкогольную ассоциацию. Нет, переименовывать не будем. Запоминается же.
P.P.S. У меня есть телеграм-канал, где я пишу про разработку, всякое айтишное, а иногда бизнесовое. Там сейчас 87 подписчика. У тебя есть уникальный шанс стать 88-м и войти в историю. Или 89-м, если кто-то успеет раньше. Давления никакого — просто если вдруг интересно: t.me/maslennikovigor
Почему каскадная модель не так «жёстка», как кажется, а Agile — не методология.
На написание статьи сподвигла статья с Хабра и обсуждения в чате одного сообщества по бережливому производству.
Хочу сразу обратить внимание, что здесь будем обсуждать ложную дихотомию в управлении проектами.
Споры о превосходстве Agile над Waterfall или наоборот давно стали клише в IT-среде. Однако корень этой дискуссии — фундаментальное непонимание сути обеих концепций. Agile часто ошибочно называют методологией, тогда как на деле это набор ценностей, а выбор реальных инструментов управления происходит между каскадной моделью (Waterfall) и итерационными подходами — Scrum, Kanban, XP. Почему этот нюанс так важен? Потому что смешение философии и инструментов ведёт к мифам, которые мешают эффективно управлять проектами.
Кажется, что waterfall (каскад) это старая и неповоротливая система
Agile — это ценности, а не методология
Манифест Agile, созданный в 2001 году, провозглашает четыре ключевые ценности:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
Это не инструкция «как управлять проектом», а напоминание о приоритетах. Agile не отменяет документацию или планирование — он лишь предостерегает от их абсолютизации. Например, детальное ТЗ необходимо при разработке ПО для автомобиля, но нужно меньше заострять на этом внимание в условиях полной неопределённости — например, для стартапа.
Если коротко, то Аджайл - это крик души замученного разработчика
Waterfall: миф о жестком подходе
Каскадную модель традиционно изображают как жёсткую последовательность этапов: анализ требований → проектирование → разработка → тестирование → поддержка. Критики утверждают, что Waterfall не допускает изменений после завершения этапа, что якобы делает его непригодным для современных проектов. Однако на практике это утверждение неверно.
Собственно говоря, Waterfall манифеста нет, поэтому ориентируемся на заполнение документации в классической разработке. Есть такая нормативка, которую можно условно отнести к каскадной модели разработки - ГОСТ 19.102-77 Единая система программной документации (ЕСПД). Стадии разработки. Устанавливает стадии разработки программ и программной документации для вычислительных машин, комплексов и систем независимо от их назначения и области применения:
Техническое задание
Эскизный проект
Технический проект
Рабочий проект (Разработка программы, Разработка программной документации, Испытания программы Корректировка программы и программной документации по результатам испытаний)
Внедрение (Подготовка и передача программы)
Но в таких регламентированных отраслях, таких как разработка ПО по ГОСТам, процессы предусматривают корректировки. Например, ГОСТ 19.603-78 прямо регламентирует внесение изменений в документацию по двум причинам:
Устранение ошибок.
Развитие и усовершенствование продукта.
Рассмотрим пример из строительства: если при возведении дома инженеры обнаруживают слабый грунт, они не продолжают работу по изначальному плану, рискуя обрушением. Вместо этого корректируют проект (например, углубляют сваи), а затем обновляют документацию. Такой же принцип действует и в IT: даже в рамках Waterfall команды вносят правки в ТЗ или архитектуру, сталкиваясь с новыми данными.
Ведь в Каскаде обратная связь не запрещена, просто требуется документирование
Почему возникает миф о несовместимости?
Противопоставление Agile и Waterfall часто служит маркетинговым инструментом. Консультанты и тренеры упрощают сложную картину, создавая «чёрно-белый» нарратив: «старое vs новое».
Если немного утрировать, то противопоставляя гибкую разработку каскадной, говорят, что строители будут строить дом по неправильному проекту без изменений, пока всё не рухнет, и только потом встанут, отряхнутся от пыли и скажут: - Давайте заново начнем.
Однако в реальности:
Waterfall не запрещает гибкость. Многие проекты в аэрокосмической отрасли или энергетике успешно комбинируют детальное планирование с оперативными корректировками. Agile не отрицает документацию. В регулируемых индустриях (финансы, медицина, машиностроение) документирование остаётся критичным, даже если команда разработки работает по Kanban или Scrum. Ключевое различие — не в наличии или отсутствии изменений, а в формализации обратной связи. Итерационные методы (Scrum, Kanban) встраивают её в процесс через короткие циклы (спринты), тогда как Waterfall требует явного согласования правок на каждом этапе.
Кажется, что это разные подходы, но это не так
Синтез вместо конфронтации: гибридные подходы
На практике чистые Waterfall, Kanban, Scrum встречаются редко. Большинство проектов используют гибридные модели. Например: Water-Scrum-Fall — детальная проработка этапов запуска и внедрения в стиле Waterfall с гибкой разработкой ядра продукта.
Такие подходы возникают не из-за «непонимания Agile», а из-за реальных ограничений: бюджетные циклы, требования регуляторов, необходимость согласования с внешними поставщиками. Например, команда может использовать Scrum для создания MVP, но переключиться на Waterfall при масштабировании продукта для enterprise-клиентов, где необходимы аудиты и сертификаты.
Например работа по непосредственной разработке ПО может идти итеративно, спринтами
Как же выбирать методологию? Нужно опираться на критерии, а не догмы Выбор между Waterfall и итерационными методами зависит от четырёх факторов:
Предсказуемость требований. Если цель проекта чётко определена и маловероятно изменится (строительство моста, разработка ПО для учёта налогов), Waterfall эффективнее. Если требования эволюционируют (стартап, исследовательский проект), нужны итерации.
Стоимость изменений. В разработке мобильного приложения правка дизайна в процессе дешевле, чем перепроектирование атомной станции. Waterfall оправдан там, где ошибки чреваты катастрофическими последствиями.
Регуляторные ограничения. В банковской сфере или здравоохранении документирование и согласования неотъемлемы, что делает чистый Agile невозможным.
Культура команды и заказчика. Если стейкхолдеры не готовы к частым демонстрациям и изменениям приоритетов, попытка внедрить Kanban или Scrum приведёт к конфликтам.
Выбор методологии зависит от многих вводных. Но нужно понимать плюсы и минусы каждой.
Примеров неправильного применения Scrum полно. Тот же Scrumfall существует уже повсеместно, потому что команды гонятся за мифом чистого Agile, там где никакой гибкостью даже не пахнет. Отсюда и вылезает такая проблема как "усталость" от Scrum
Agile и Waterfall не конкурируют — они решают разные задачи. Манифест Agile напоминает о ценностях, но не даёт готовых решений, а Waterfall — не догма, а инструмент, который можно адаптировать. Когда выбираем методологию управления проектами, вместо вопроса «Что лучше — Agile или Waterfall?» стоит спросить:
Какова степень неопределённости требований?
Какие ограничения накладывают регуляторы или бюджет?
Насколько команда и заказчик готовы к гибкости?
Управление проектами в разработке ПО это тоже инженерная дисциплина и должно быть прагматичным. Важно:
Нужно отказаться от догм и мифов. Waterfall не означает «отсутствие изменений», Agile — «отсутствие документов».
Ориентироваться на ценности, а не методы. Даже в каскадном проекте необходимо внедрить частые коммуникации с заказчиком (ценность Agile №3).
Признать контекст. «Идеальная» методология не существует — есть инструменты для решения конкретных задач.
Когда следующий раз услышите: «Мы Agile, поэтому не пишем ТЗ», или «Это Waterfall, тут нельзя менять требования», — задайте вопрос: «А почему?». Возможно, за этим стоит не разумный выбор, а миф, которому не место среди инженерной культуры.
Дворфы запускают Великую Машину и ищут командира, который возглавит буровой поезд и проведёт их народ через подземные глубины к затерянному городу.
Underground Nomads — это симулятор колонии с элементами выживания на огромном буровом поезде. Игрокам предстоит стать командиром и взять на себя управление буровой машины и дворфами-кочевниками. Руководите экипажем, добывайте ресурсы и прокачивайте оборудование.
Основная задача капитана – найти затерянный город и снова обрести дом. Соберите команду, назначайте роли и отправляйтесь в самые недры земли на поиски древних артефактов и реликвий.
1/4
Из особенностей игры можно выделить:
Уникальная команда бородачей: каждый персонаж влияет на производство в своём отсеке. Ошиблись с назначением — потеряли ресурсы;
Модульный поезд-база с постройкой отсеков;
Аварии и поломки в режиме реального времени: будущее экипажа зависит от вашей реакции. Важно вовремя реагировать на аварии и чинить отсеки;
Экспедиции и добыча ресурсов: можно ходить в разведку, добывать материалы для улучшения и выполнять новые контракты;
Прокачка поезда: вы будете открывать технологии и создавать станки, которые помогут команде пройти глубже;
Разнообразные биомы: исследуйте окаменевшие пустоши, лавовые тоннели и редкие руды.
Если хотите почувствовать себя капитаном буровой махины — присоединяйтесь. И вообще, меньше болтовни, бородачи её не любят.
В прошлых постах мы рассказывали про подготовку к сборке уровня, а сегодня приступим к самому интересному - самой сборке вплоть до финального результата. Итак…
- Сборка блокаута. Имея на руках референсы и набросок, можно начинать собирать первый игровой прототип уровня. Он не должен быть детализированным, но обязан быть интересным и приятным в прохождении. На этом этапе проверяются метрики и добавляются базовые механики.
- Настройка событий. Этот этап происходит одновременно со сборкой блокаута и является его неотъемлемой частью. События влияют на то, какие ощущения испытывает игрок во время прохождения, какие механики и действия ему доступны. Сюда можно отнести расстановку чек-поинтов в гоночном режиме, расставление ловушек и “абилок”, добавление интерактивности: взрывающиеся двери, сбивающие насмерть поезда, ломающиеся от удара предметы, запуск примитивных анимаций и кат-сцен.
- Тестирование. Оно проводится постоянно и с разным количеством людей. С помощью него можно проследить понятные и непонятные места на уровне, можно заметить, какие вещи кажутся людям интересными, а какие наоборот - вызывают скуку. Тестирование завершает одну итерацию и начинает новую: блокаут дорабатывается, события донастраиваются. И так пока результат не удовлетворит всю команду.
- Конечный вариант. Он подводит итоги всей проделанной ранее работы. В нём объединяются концепт, основная идея, референсы и наброски, а затем серые кубы блокаута заменяются на готовые модели. Окружение прорабатывается, настраивается освещение, проводится оптимизация.
И на этом всё. Карта готова! Хотя ещё предстоит финальное тестирование и полировка отдельных моментов, но это уже мелочи жизни :)
Про каждый из пунктов создания уровня на самом деле можно было бы расписать по целому посту. Есть очень много технических моментов, разных инструментов и прочего, здесь же мы лишь кратко описали основные моменты. Так что, если интересно, обязательно маякните в комментариях!
Последние пару недель занимаюсь унификацией технологического стека для всех своих pet-проектов и поделок. Цель — собрать единый тех-радар, чтобы не тратить время на переключение контекста между разными фреймворками и библиотеками.
Мой стек
Frontend: - React (без сюрпризов) - WXT (лучший фреймворк для браузерных расширений) - MUI (библиотека UI-компонентов под Material Design) - Netlify (бесплатный и надёжный хостинг)
Backend: - Supabase (как Firebase, только лучше) - Yandex Cloud (serverless-контейнеры + S3-хранилища)
Процесс
На выходных добрался до Speech to Text — браузерного расширения для транскрипции аудио. Оно было написано на vanilla JS ещё в первых версиях, и каждое обновление превращалось в квест по поиску багов и зависимостей.
С помощью Cursor (AI-ассистента для кода) переписал всё расширение за пару часов:
Перенёс на WXT (фреймворк для Chrome Extensions)
Заменил самописные компоненты на MUI
Добавил TypeScript для типобезопасности
Заодно запилил новую фичу: транскрипцию системного звука через Chrome Tab Capture API
Что получилось
Теперь Speech to Text может расшифровывать не только микрофон, но и всё, что играет на компьютере: YouTube-видео, Zoom-созвоны, лекции, подкасты и т.д.
Дополнительно добавил:
Аудиоплеер для предпросмотра файла перед отправкой
Анонимную расшифровку по прямой ссылке на аудио
Бонус
Модерация в Chrome Web Store прошла за 2 часа (обычно было 8-12). Предполагаю, что регулярные релизы дают "репутацию" у алгоритмов Google.
Выводы
Унификация стека — это не просто модное слово, а реальная экономия времени. Теперь могу быстро переключаться между проектами и переиспользовать компоненты без головной боли.
Хотите больше деталей? Про процесс унификации стека, выбор инструментов и другие эксперименты с расширениями пишу в своём Telegram-канале @debug_leg. Там более неформальный формат: короткие посты, скриншоты процесса и честные истории про грабли. Подписывайтесь, если интересна кухня разработки.
Это мой второй пост о разработке проекта "Atomic Atlas".
Хочу начать с огромной благодарности всем, кто читал первый пост, комментировал и поддерживал стрелочками вверх – это невероятно мотивирует и показывает, что тема интересна!
Работа над "Atomic Atlas" продолжается, и вот что мы успели сделать за это время:
Прогресс разработки:
Модельки орбиталей: Доработали и добавили все типы орбиталей, включая отсутствующие S-орбитали. Теперь картинка полная.
Оптимизация интерфейса: Это постоянный процесс. Мы продолжаем экспериментировать с расположением информации, чтобы сделать интерфейс максимально удобным и интуитивно понятным.
Новая вкладка "Изотопы":
Добавлена основная информация об изотопах, их параметрах и времени распада.
Реализована схематичная модель ядра, показывающая движение нуклонов (протонов и нейтронов). Важно понимать, что это временный вариант, ждущий доработки VFX.
Важный нюанс: База данных пока "встала криво", поэтому некоторые параметры изотопов могут быть неверными. Скоро поправим!
Вкладка с информацией об элементе:
Добавлены исторические справки и интересные факты для всех элементов.
В планах: добавить фотографии людей, связанных с элементами, и оформить особые свойства элементов как "перки" в стиле Fallout (с уникальными иконками и описанием).
Внутренняя архитектура: Сильно переработали код проекта для улучшения масштабируемости – это критически важно для такого рода приложений.
У меня дома живёт кошка Манишка. Ей 13, она 3 килограмма храпа, наглости и тихого мявкания по делу. Два месяца назад ей поставили диабет. Когда ветеринар сказал «меряем сахар несколько раз в день и колем инсулин», я стоял с переноской и уже понимал: я не помню, что записал вчера, не то что неделю назад.
Первые недели лечения Манишка спала у меня на столе и никуда не отходила. При сахаре под 30 вообще сложно куда-то ходить.
Пробовал вести дневник как «нормальный человек». Блокнот, таблица в телефоне, фотка тест-полоски в галерее между мемами и скриншотами. Через неделю — каша: утро одно, вечер другое, два измерения потерялись где-то между звонком курьера и сериалом. На приёме у врача я выглядел как человек, который ведёт учёт на бересте и уверен, что это «работает».
В какой-то момент стало страшно. Не от диагноза — а от мысли, что могу забыть дозу или пропустить опасный провал. И тогда это будет не история про лечение, а история «не заметил, потому что устал».
Я DevOps, не разработчик приложений. Но понял: без нормального инструмента я Манишку потеряю не из-за болезни, а из-за бардака в голове.
Взял лист бумаги, нарисовал квадратики: сюда сахар, сюда время, тут график. Сфоткал, отправил ИИ, попросил «сделай так, чтобы работало». ИИ сделал. Примерно. Кнопка уехала вправо, график стал фиолетовым без причины, интерфейс жил своей жизнью. Я делал скриншот, рисовал стрелочки «вот тут поехало» и отправлял обратно. Так мы вдвоём — я с каракулями, он с кодом — собрали первую версию.
Первая версия, простейший python скрипт рисующий картинку
Приложение заработало, я начал пользоваться им каждый день. И тут стало интересно.
Пока данных мало — ничего не понятно, случайные числа. А когда накопилось — на графике видно чётко: каждое утро в 10–11 сахар прыгает в космос. Я думал, это рандом. Показал ветеринару — за минуту стало понятно, как менять дозу.
Примеры утренних скачков
В другой день просто ради эксперимента измерил сахар днём, когда «всё нормально» — и увидел 3.0. Манишка спала спокойно, а это опасно низкое значение. Без графика я бы не заметил.
С тех пор меряю в разное время и вижу реальные паттерны, а не «утром много, вечером поменьше».
За последние недели есть прогресс. Средний сахар снизился — с 15 до 7 ммоль/л. Меньше опасных провалов. Это не чудо: сахар всё ещё скачет, мы экспериментируем с дозой, говорим с врачом. Но теперь — по цифрам, а не наугад.
1/2
Динамика за последние 7 дней
После того как я выложил ссылку на Пикабу, у приложения появились пользователи. У кого-то кошка, у кого-то собака. Оказалось, это не моя личная проблема — а обычная ситуация: диабет надо вести как дневник, а на бумажке всё теряется.
Сейчас около 60 пользователей. Приложение бесплатное, без рекламы, без подписок. Делаю его вечерами, когда Манишка уже уснула и заняла себе половину дивана.
Опять сахар мерить, да?
Мне нужна помощь.
Я не продвигаю продукт. Пытаюсь сделать инструмент, который понятен не только мне. Если попробуете — напишите честно: что удобно, что нет, что непонятно, чего не хватает. Может, скажете простую вещь, которую я в упор не вижу.
Если вы ветеринар — дам доступ к кабинету врача, посмотрите, удобно ли.
Манишка сейчас лежит рядом, хвостом заняла моё место. Ей всё равно, что у приложения появились пользователи. А мне — нет. Потому что я наконец вижу картину, а не хаос из чисел и страха.
Спасибо, что дочитали.
Для модератора: приложение полностью бесплатное, без рекламы и платных функций. Цель поста — получить обратную связь, а не что-то продать.
