Как из миксинов для валидации форм вырастает полноценная TypeScript-библиотека с плагинами, масками и 500+ скачиваниями в неделю. История рефакторинга, архитектурных решений и работы над ошибками длиной в 10 месяцев.
Всем доброго дня! В предыдущей статье Кавай-Фокус 2.7: путь к MVP1 — цепочка таймеров и воспроизведение звука:
1. Добавлено воспроизведение звука таймера через Web Audio API;
2. Написана механика воспроизведения цепочки из таймеров для Pomodoro.
После того как я закончил экран «Таймер», который воспроизводит образцы сессий, наступило время дать пользователю возможность добавления своих таймеров, которые будут ему удобны. Для этих целей я напишу экран-конструктор, в котором пользователь будет создавать свой таймер.
Все новые таймеры будут сохраняться в базу данных SQLite3, поэтому нужно будет написать CRUD-операцию для создания таймера. Также я добавлю операции для удаления и редактирования записей. К новому функционалу я подключу кнопки редактирования и удаления. Это позволит пользователю полноценно управлять таймерами.
Заваривайте чай, доставайте вкусняшки — пора «высаживать грядки из помидоров»! 🍅
Миграция большого legacy-проекта с Vue 2 на Vue 3 — это не только про код. Основная сложность начинается ещё до первого коммита: оценка объёма работ, поиск несовместимых API, планирование и организация процесса разработки.
Почему вообще это важно, и как донести эту мысль до бизнеса я уже описывала в другой своей статье «Ты всё ещё думаешь или уже мигрируешь на Vue 3». Рекомендую почитать.
А тут я поделюсь своим опытом, где мне пришлось лидировать миграцию: самостоятельно составлять план миграции, оценку времени, рисков и проводить саму миграцию.
Принципы SOLID, DRY, KISS во фронтенде работают ровно так же, как в любой другой разработке. Но если открыть почти любой проект, всё равно натыкаешься на мешанину.
Причём дело обычно не в том, что код «грязный» — он как раз бывает типизирован и проходит linter. Дело в том, что эти принципы отвечают на вопрос «как написать», а не «зачем мы вообще это пишем». А без ответа на «зачем» чистый код превращается в красиво оформленную путаницу.
На примере такой вещи, как store попробуем ответить на вопрос: что вообще такое контракт, зачем же нужна типизация и действительно ли это помогает в разработке.
Зачем на свете нужен ещё один трекер привычек? Их же и так - на любой вкус и цвет. Проблема в том, что ни один из них не нравился моей жене, поэтому пришлось в список идей для пет-проектов добавить и его.
Последние полгода я активно применяю LLM в своей работе. Автокомплитом от Github Copilot я пользуюсь с момента начала бесплатного бета-тестирования, а с выходом Opus 4.5 стало возможно отдавать железяке на реализацию целые блоки логики. Нужно только организовать виртуальную клетку, внутри которой он будет вынужден писать работающий код.
Новый проект, фреймворк, с которым не работал несколько лет, приложение в процессе миграции. Раньше на погружение уходил месяц. В этот раз — неделя.
Всем привет. Я занимаюсь фронтендом в небольшой команде сервиса бронирования отелей. Хочу как я 8 дней ловил утечку памяти на проде, несколько раз думал, что починил, и каждый раз ошибался. А последний фикс был не в нашем коде, а в патче самого Vue, который через неделю апстрим откатил как регрессионный. У нас в результате осталась одна патч-версия, в которой утечки нет; обычный minor/patch update сейчас для нас не безопасен без повторной проверки heap-снапшотами.
Наш стек Nuxt 3.18 + Vue 3.5.x + TypeScript, SSR, Pinia, PM2 cluster, nginx перед Node. Обычный каталог отелей с тысячами SEO-страниц вида /oteli-v-{город}/{подборка}
Привет. Недавно пришлось повозиться с @tanstack/vue-table. Задача была стандартная: нужна таблица с сортировкой, фильтрами и редактированием ячеек. Казалось бы - идеальное время подключить готовое решение. Но не всё так гладко. Делюсь мыслями, граблями и тем, как я в итоге выкрутился.
Как перестать копировать формы и построить масштабируемую архитектуру
В enterprise-приложениях формы множатся быстро: create, edit, import, create-from-lead, duplicate — и вот у вас уже шесть копий одной формы, а внутри условный ад из if (mode === …).
Почему mode prop и giant form component не масштабируются, как разделить форму на четыре слоя: presentation, orchestration, context, data source. Что такое capabilities и почему они лучше условной логики. Как адаптеры отвязывают форму от source entities. Куда прятать submit, валидацию и внешний store. Как тестировать такую архитектуру изолированно.
Когда я начинал делать Gooly, мне казалось, что главная проблема — отсутствие нормального инструмента для организации мероприятий.
Но спустя месяцы разработки и общения с пользователями я понял гораздо более неприятную вещь: большинство social-продуктов умирают не из-за плохого кода, а из-за пустоты внутри системы.
В этой статье — про cold start, хаос чатов, выгорание организаторов, network effects и то, почему живой Telegram часто побеждает «идеальный» новый сервис.
Когда я публиковал первую статью про Gooly, то не ожидал какого-то серьёзного отклика. Казалось, максимум получу несколько комментариев и немного критики. Но спустя несколько дней произошло то, чего я вообще не ожидал: мне начали писать люди из совершенно разных сфер.
Кто-то организовывал футбольные сборы. Кто-то - походы. Кто-то - локальные сообщества. Были люди из event-сферы, туризма и даже те, кто несколько лет назад уже пытался запускать похожие проекты.
И почти у всех повторялась одна и та же мысль:
Да, мы тоже живём в хаосе чатов.
Сначала мне казалось, что проблема довольно узкая. Есть организатор, есть люди, которых нужно собрать на футбол, волейбол или другую активность. Но чем больше я читал комментарии и общался с людьми, тем сильнее понимал: проблема гораздо глубже, чем просто «сбор людей».
На самом деле офлайн-активности до сих пор во многом держатся на ручной координации:
Привет, Я Ваня Демидов, разработчик Selectel.
Осенью наша компания решила запустить платформу, на которой сотрудники могли бы купить ненужную офисную мебель. Например, ту, что перестала подходить к обновленному дизайну переговорок, кофе-пойнтов или рабочего спейса. В этой статье я расскажу, как создавал такую платформу и поделюсь опытом использования Nuxt3 и Pocketbase.
После публикации первых статей про Gooly мне написало довольно много людей.
Кто-то рассказывал, как годами собирает футбол через чаты. Кто-то показывал свои таблицы учёта. Кто-то даже писал собственные приложения для организации игр.
Но больше всего меня зацепило одно очень простое сообщение.
Команда Socket Threat Research обнаружила компрометацию 84 npm-пакетов в пространстве @tanstack: в них внедрили вредоносный имплант Mini Shai-Hulud, нацеленный на кражу учётных данных и секретов из CI/CD-сред, включая GitHub Actions.
Атака особенно опасна тем, что вредонос автоматически запускается при установке зависимостей через lifecycle-хуки npm, а среди затронутых пакетов есть крайне популярные — например, @tanstack/react-router с более чем 12 млн загрузок в неделю, что делает инцидент серьёзной угрозой для безопасности цепочки поставок ПО.
В статье подробнее разберём механизм заражения, риски для разработчиков и компаний, а также первоочередные меры реагирования — от проверки зависимостей до ротации секретов и аудита CI-пайплайнов.
Собеседования по TypeScript всё чаще проверяют не только знание синтаксиса, но и умение видеть «узкие места» в уже работающем коде. Задача кандидата - не просто сказать «тут ошибка», а предложить более безопасное, читаемое и поддерживаемое решение.
В этой статье собраны практические вопросы, основанные на реальных принципах рефакторинга TypeScript. Каждый пример показывает типичный код, который можно улучшить, и задаёт направление для размышлений.
Правильная файловая структура - скелет любого фронтенд-приложения. В Vue 3 нет строгих предписаний, как раскладывать файлы по папкам, кроме базового разделения components/, views/. Но с ростом проекта хаотичное размещение кода быстро превращается в проблему. В этой статье разберём популярные подходы к организации Vue-проектов: от простейшего плоского до микрофронтендов.
После первой статьи про Gooly мне написало несколько человек, которые годами собирали футбол, волейбол, настолки и другие офлайн-активности.
И что интересно — почти у всех были одни и те же проблемы.
Причём независимо от города, возраста людей или самого формата мероприятия.
В какой-то момент я понял:
Проблема вообще не в Telegram, VK или WhatsApp.
Проблема в том, что чат сам по себе плохо подходит для координации повторяющихся офлайн-активностей.
Особенно когда людей становится больше 10–15.
Я дизайнер в сервисе бронирования отелей. Расскажу про 3 анимации, которые мне нравятся и над которыми я долго работал. Показываю что получилось, и как реализовали анимации в коде.
Когда я был студентом, мы постоянно пытались собрать людей на футбол. И каждый раз всё выглядело одинаково:
— в чате 20 человек
— нужно 16
— кто‑то «точно будет»
— кто‑то «скорее всего придёт»
— кто‑то уже перевёл деньги
— кто‑то ещё нет
— а за пару часов до игры начинается хаос
«Я не смогу»
«А есть ещё места?»
«Кому переводить?»
«А поле вообще забронировано?»
Тогда я впервые поймал себя на мысли:
Почему в 2026 году люди до сих пор координируют офлайн‑жизнь через хаос в чатах?
Тогда же я сделал первый сырой прототип.
Сегодня посмотрим на вымышленный пример, как не надо делать стор. Любые совпадения - случайность. Все истории выдуманы.
Представьте: есть у нас герой Алекс. Перекидывают его на проект - «поправить пару простых багов, делов на пять минут». Открывает Алекс код, а там… У него сердце замирает. Подумаешь, с кем не бывает. Но внутри начинается дилема: просто пофиксить баги и забыть этот ужас как страшный сон, либо как настоящий богатырь проектов взять и отрефакторить весь этот бардак. Сделать по-человечески, заложить нормальную основу. Да, потом спросят за новые баги - ну и что. Зато внутри тепло разольётся, что не забил на плохой код и навёл порядок.