Эволюция запуска E2E-тестов в нашем проекте

Пора признаться: в нашем проекте есть проблема — мы не успеваем писать E2E-тесты... так как мы не успеваем писать E2E-тесты, за нас их пишут LLM, и они справляются лучше человека!

Также у нас в проекте используется Editor.js, и если вы знаете, то знаете: тестировать Editor.js — боль. Большинство элементов просто не имеют селекторов, их приходится находить по CSS классам, а при запуске в Playwright эти самые элементы ведут самым непредсказуемым образом, отлично от того, как они ведут себя в браузере: могут не появиться, либо появиться с большой задержкой, либо появиться, но Playwright почему-то не будет в упор видеть их и подобных проблем огромное количество. Благо можно дать задачу LLM по-умнее и она за тебя сделает всю грязную работу: потыкает, найдёт почему не работает и исправит (само собой обычных возможностей LLM будет недостаточно, нужно подключать Playwright MCP, чтобы моделька творила свои непотребства в браузере самостоятельно — если нужно раскрыть эту тему подробнее, дайте знать).

Но до выхода Gemini 3 Pro LLM не могли решить одну нашу проблему: корректно написать локальный запуск E2E-тестов с поднятием всех необходимых зависимостей. Да, чего уж греха таить, мы и сами не могли справиться с этой задачей из-за сложности системы и ограниченного количества времени. Теоретически, если бы мы потратили целый спринт на эту задачу, то мы бы с ней разобрались, но в ситуации, где бизнес ожидает от вас продукт ещё вчера эта, ситуация только и остаётся теоретической.

Как мы писали запуск E2E-тестов в хронологическом порядке:
— Разработчик и тестировщик (февраль 2025): научились запускать тесты, но только в CI/CD, а данные для запуска тестов подтягивалсь с прода т.е. отследить баг, который возник при разработке можно было только ретроспективно, из-за чего тесты во многом теряли свой смысл;
— Claude Sonnet 4 (июнь 2025): LLM дала нам несколько подсказок (но не решение), которое помогло самим реализовать подтягивание данных не с прода, а с конкретного рана в CI/CD. Тесты стали полезнее, но до сих пор оставалась фрустрация в связи с тем, что для написания тестов приходилось постоянно пушить коммиты в ветку;
— GPT-5 (8 августа 2025): она позволила создать нам отдельный скрипт, который в свою очередь позволил запускать тесты локально. Да, работало оно криво-косо, руками ничего не поправить, так как в файле было спагетти, но локальный запуск тестов позволил нам сильно увеличить количество покрытых сценариев, а также избавить от фрустрирующих пушей в ветки для запуска тестов;
— Gemini 3 Pro (ноябрь 2025): к этому моменту в целом всё уже стабильно работало. Было всего пару претензий: невозможно что-то исправить в скрипте для запуска, так как 100% что-то поломаешь, сам запуск был долгим, а также тесты запускались только в UI-оболочке т.е. LLM не могли нормально их гонять из терминала. Со всем этим можно было жить и мы так бы и жили, но Gemini 3 Pro перевернула игру и всего за один промпт решила все три проблемы. Запуск стал мгновенным, от костыльного скрипта не осталось и следа, а сама конфигурация расползлась по нужным файлам, где изначально и должна была жить.

Мне очень нравится вся эта ситуация, так как она наглядно показывает как то, насколько модели продвинулись за столь короткий промежуток времени, так и то, где LLM показывают себя лучше всего: на стыке, где человек знает, что ему нужно и как это сделать, но при этом задача всё равно никогда не была бы закрыта из-за внешних факторов.

Знакомьтесь, Blok!

Blok — это блочный, визуальный open-source редактор типа Notion.

В основу Blok лёг Editor.js — прекрасный визуальный редактор, который в своём развитии остановился где-то в 2018-м году, где было приемлемо иметь средненький UX, плохую документацию и решение не поддерживающее современные фреймворки.

Blok призван решить все эти проблемы и стать тем самым визуальным редактором, который вы искали.

Уже сейчас в Blok, в отличие от Editor.js, исправлены многие баги и проблемы безопасности, повышена стабильность и тестируемость редактора, а также появилась возможность перетаскивать блоки с помощью drag&drop!

В ближайших обновлениях Blok станет React-first для максимально удобной интеграции с вашими приложениями.

Blok доступен бесплатно прямо сейчас!

Забавно, что ещё до всех анонсов репозиторию поставил звёздочку один из core-мэйнтейнеров Summernote — редактора, из-за которого и появился Blok.

Ещё до того, как я попал в Додо, ребята затащили в Базу знаний Summernote, и он настолько не подходил для создания сложных статей для Базы знаний, что первое же, что мы сделали при планировании обновления Базы знаний, — начали искать новую основу для редактора.

Чудеса:)

Да, чо вообще происходит...

Почему Anthropic вдруг выпустили топовую модель и сделали её в 5 раз дешевле, чем их предыдущий Opus... я ещё даже не успел дописать статью про Gemini 3 Pro... АААААА

Чувствую себя буквально как на картинке. Но, да, идите попробуйте Claude 4.5 Opus. Она в моих тестах порвала как GPT-5.1 Codex Max, так и Gemini 3 Pro. А я пока пойду глубже разбираться с новой моделькой.

Я уже даже не знаю, что тут ещё сказать:)
Кажется, что где-то в Калифорнии разбился грузовик с классными большими языковыми моделями)

The State of AI в разработке (модели)

С учётом того, как быстро всё движется последнюю неделю, кажется, что нужно сделать какой-то чекпоинт, чтобы уложить всё немного в голове. В списке чем выше цифра у модели, тем она умнее/круче.

1️⃣ GPT-5.1 Codex ($1.25/$10)

Была лучшей моделью для кодинга две недели назад (лол), возьмём её как отправную точку.

2️⃣ Gemini 3 Pro ($2/$12)

Прекрасная модель, вероятно, умнее GPT-5.1 Codex Max и Claude Opus 4.5, но какая же она нестабильная... Ни с одной моделью мне не приходилось писать «Continue» по несколько раз за один запрос (особенно больно с этим в Windsurf, но о нём чуть позже). Также модель ужасно быстро тупеет с ростом контекстного окна. Да, в задачах «сгенерируй картинку» или «напиши компонент» она показывает себя, вероятно, лучше любой другой модели прямо сейчас, но в реальных бизнесовых задачах, где запрос выполняется 15+ минут, она быстро начинает теряться.

3️⃣ GPT-5.1 Codex Max ($1.25/$10)

Те задачи, с которыми не мог справиться Gemini 3 Pro, я отдавал GPT-5.1 Codex Max Extra High (господи, OpenAI, какого хера) и со всеми, кроме одной задачи, она справилась. В целом, отличная модель, к которой почти нет претензий, кроме того, что она медленная (хотя она стала быстрее GPT-5.1 Codex за счёт уменьшения количества генерируемых токенов), а также она иногда зарывается в размышления и просто тратит всё контекстное окно на размышления, не выдавая никакого ответа.

4️⃣ Claude Opus 4.5 ($5/$25)

Ту самую задачу, которую не смогла решить GPT-5.1 Codex Max XHigh (надеюсь, мне больше не придётся писать это название), я сегодня отдал Claude Opus 4.5, и она с ней на удивление быстро разобралась! Вообще, Anthropic — короли тул-колов, и с этой моделью они подтвердили это звание и даже превзошли сами себя. Теперь, если у модели не получается сделать тул-кол, она не валится с ошибкой (привет, Gemini 3 Pro), а выполняет ту же операцию, используя возможности LLM. Просто и гениально!

Поэтому прямо сейчас это самая стабильная модель (она стабильна даже в Windsurf, а это о многом, очень о многом говорит). Не буду скрывать: я сильно удивлён тому, что Anthropic выпустили такую умную и, относительно их ценообразования, дешёвую модель. Думаю, что по крайней мере до конца года Claude Opus 4.5 будет лучшей моделью для агентного кодинга, и можно будет немного поработать вместо того, чтобы тестировать новые модели 🙈

🏆 GPT-5.1 Pro ($15/$120)

Фактически GPT-5.1 Pro не в этой гонке, так как она крайне дорогая и доступна только на сайте ChatGPT, но она вышла на прошлой неделе, так что не упомянуть её не могу.

Это единственная модель из перечисленных, которой я не пользовался, потому что она доступна только в $200 тире, но очень рекомендую посмотреть это видео — оно того стоит, потому что модель удивительная, вероятно это именно то, что нужно вам, если вы проводите масштабные исследования.

Продолжим во второй части, где я расскажу про текущее состояние агентных IDE.

Claude Opus 4.5 — лучшая модель для написания кода

Но при этом не самая умная... давайте разбираться как так произошло и почему более умная модель от Google хуже пишет код.

Но для начала разберём что такое тул-кол и компьютер-юз:
• тул-кол — это когда модель может вызвать заранее определенный инструмент, который позволяет совершить ей какое-либо действие, например, найти информацию в интернете, сделать скриншот или накликать что-то в браузере;
• компьютер-юз — это режим в котором модель может полноценно управлять компьютером: любой программой, файловой системой, процессами и так далее (по сути следующий шаг в развитии тул-кола).

Может показаться, в текущей ситуации с моделями всё сложно, но всё до банальности просто: Claude Opus 4.5 просто невероятно хороша в тул-колах, а это самое важное в задаче написания кода (во всяком случае на данный момент).

Вообще, если всё и дальше так пойдёт, то именно Anthropic возглавит AI гонку в ближайшие несколько лет за счёт того, что их модели самые стабильные, а также за счёт их достижений в тул-коле и компьютер-юзе. Уже совсем скоро эти достижения позволят давать задачу не чатику где-то в браузере, самому браузеру или IDE, а сразу операционной системе, которая сама установит весь нужный софт, откроет все нужные программы и не поможет решить задачу вам, а решит её сама.

Anthropic также выпустили большую статью про advanced tool use в Opus 4.5, которая подробнее раскрывает эту тему (если лень читать статью, то можно посмотреть короткий видосик, он наглядно показывает преимущества программного тул-кола).

Получается, что более умные модели больше не нужны? Нужны, конечно... но мы уже на том этапе, когда AI достаточно умный, чтобы решать большинство задач (если у него есть достаточно времени и контекста). В связи с этим на первый план выходит развитие тул-кола, компьютер-юза и долгосрочной работы модели.

Моя ставка на 2026 год: всем взорвёт мозг модель от Anthropic, которая будет ловко обращаться с компьютером и будет выполнять задачи, которые мы даже не надеялись автоматизировать в ближайшее время.

Теперь, когда меня будут спрашивать про то, стоит ли того «вайб-кодинг» я буду показывать им эту картинку.

Месяц работы, 150к строк кода, $2000, 3300+ тестов и полностью переписанный EditorJS, который потихоньку превращается в полноценный open-source клон Notion со всеми его маленькими деталями, которые делают Ноушен Ноушеном.

Очень рад, что события сложились так, что я начал создавать Blok т.к. я жёстко угараю как по редакторам, так и по крутому UX и понимаю как сделать реально крутой и удобный редактор, а в мире вайб-кодинга видение — это основное, что тебе нужно, чтобы воплотить свою идею в жизнь.

P.S.
По факту на весь проект ушло ~$300, оставшиеся $1700 набежали с халявных и полу-халявных подписок.

Чем глубже я погружаюсь в то, как устроен Notion, тем больше мне кажется, что его создал безумный гений.

Есть такая игра Prince of Persia, 1989 года выпуска. Её создал всего один человек, и это технический шедевр, а также игра, которой не должно существовать, во всяком случае не в том виде, в котором она существует.

Джордан Мекнер в свои 25 лет сотворил что-то невозможное и создал сложную игру, которая даже спустя 36 лет с момента создания выглядит неплохо, при том что для её запуска требовались всего 4 килобайта оперативной памяти и 1 мегагерцовый процессор Apple II. Полную историю создания смотрите здесь.

Как связаны Prince of Persia (1989) и Notion (2016)? Оба не должны существовать.

В последний месяц я часто сталкиваюсь с тем, что многие не понимают, насколько Notion — сложный продукт. Notion настолько сложен, что его просто никто не может повторить.

В нашем мире ужасной конкуренции, где есть:
- Десяток «ТикТоков»: Youtube Shorts, Instagram Reels, Snapchat Spotlight, Likee, VK Клипы и другие.
- Миллион дейтингов: Tinder, Badoo, Bumble, Hinge, Pure, Grindr, Mamba, LovePlanet — на любой вкус и цвет.
- Бесконечное количество разных моделей: ChatGPT, Claude, Gemini, Llama, Grok, DeepSeek, Qwen...

При этом Notion будто в отдельной лиге. Кто его конкуренты?
Coda? Слишком урезанная и багованная.
Obsidian? Борется за другой рынок.
Buildin? Поделка на коленке в попытке захватить часть рынка, которая освободилась благодаря санкциям.

У Notion нет конкурентов.

И это напрямую связано с его сложностью: Notion тупо почти нереально скопировать. Это удивительный продукт. В мире, где банальные баги в банальных продуктах не фиксятся годами, у нас есть доступ к невероятно сложному сервису, который по большей части работает идеально.

Ребята из Notion не идут на компромиссы: они хотели сделать идеальный редактор — они его сделали. Notion — это проект мечты, над которым работали ночами.

Это видно даже в таких мелочах, как фейковое выделение.

В чём суть? Редактирование в Notion — это костыль. Когда создатели HTML-спеки давали возможность редактировать стандартные HTML-блоки, то никто не мог предположить, что через 20 лет на основе этой идеи появится Notion, в связи с чем даже самые базовые взаимодействия приходится создавать самостоятельно.

Но ребятам из Notion было глубоко пофиг, ведь они делали проект мечты. Так что, когда они встретились с очередной проблемой редактируемых блоков, а она заключалась в том, что стандартное браузерное выделение сбрасывалось, когда открывалось поле для ввода ссылки, они просто сделали фейковое выделение...

И может показаться, что в том, чтобы нарисовать прямоугольник позади текста, имитирующий выделение, нет ничего сложного, и это действительно так. Но когда ты понимаешь, что у этого прямоугольника нельзя задать фиксированную высоту, в связи с чем приходится рисовать его с помощью теней. При этом тени должны быть не в высоту текста, а в высоту строки, потому что браузерное выделение рисуется в высоту строки. Также тени нельзя просто взять и нарисовать позади текста, так что отдельно под высоту текста нужно рисовать отдельный прямоугольник, а вокруг него — идеально прилегающие тени. Если немного промохнёшься, получишь либо дырки, либо наложение полупрозрачных прямоугольников друг на друга... а потом ты вспоминаешь, что у тебя есть элементы разной высоты в проекте, и сами пользователи могут поменять размер шрифта, поэтому вычислять нужно динамически. Но, выдохнув и пройдя весь ад, ты понимаешь, что твоё решение не работает, если пользователь выделелил несколько строк вместо одной, и тебе нужно переделывать его, чтобы учесть этот сценарий.

Как я узнал обо всём этом? Я реализовал почти идентичную логику в Blok. Если сравнивать браузерное выделение и выделение в Blok под лупой, можно увидеть небольшия отличия. А в Notion — нет. Сколько я ни пытался, я не увидел разницы.

Вот именно из-за такого подхода у нас никогда не будет второго Notion. Разве что какой-то другой безумец не доведёт до идеала один свой open-source проект.

Как же круто жить в мире, где есть AI

Только что понадобилось сжать 20 гиговый видос, чтобы отправить его в телеге, но открывать Final Cut Pro для такой простой задачи неохота, а закидывать в онлайн-сервисы стрёмно, так ещё и нужно найти тот, в который можно залить 20 гигов видео, да и вообще дождаться пока оно зальётся.

В общем, вместо всего этого скопировал название видео, открыл Claude Code, сказал ему: «найди вот это видео и компресни его, чтобы места так много не занимало». И всё! Через десять минут мои 20 гигов чудесным образом превратились в 300 метров.

Да, я понимаю, что мог также обратиться к доке FFmpeg и ввести простейшую команду для конвертации, но серьезно, я им так редко пользуюсь, что каждый раз смотрю на него как на новые ворота, а тут 30 секунд моего внимания, 10 минут ожидания и видос уже сконвертирован.

Как же модели хороши в адаптации текста интерфейсов!

Если вы хоть раз делали мультиязычность в проекте, причём неважно с какой стороны: разработчика, менеджера или дизайнера, то знаете, что это боль.

Во время обсуждения адаптации интерфейсов можно услышать, как у всех потихоньку закипает мозг, а пальцы активно бьют по клавишам в тщетной попытке найти подходящий перевод в интернетах. Обычно результаты таких брейнштормов варьируются от плохо до невыносимо плохо.

К счастью, эта проблема уже не проблема, так как современные модели могут проанализировать вашу кодовую базу и предложить переводы, которые будут подходящими для вашего интерфейса, а также будут звучать натурально на языке перевода.

Мне сложно оценить переводы, если они не на русском, английском или армянском, в силу своей кожанно-мешковости. Но к предложенным переводам, которые я понял, у меня почти не было претензий — она точно сделала работу на несколько голов лучше, чем получилось бы у меня.

И тут важный момент: я тщательно просмотрел переводы на языках, которые я знаю, чтобы быть уверенным, что они правильные и подходящие. Где было нужно — поправил текст. Благодаря этому, когда модель будет работать с остальными языками, которые я уже не знаю, у неё будет больше контекста, благодаря которому она более вероятно сделает правильный перевод.

Ну и, следуя этой же логике, нужно начинать переводить с языков, которые модель знает лучше всего, и идти к тем, которые она знает хуже. А узнать это можно, напрямую задав вопрос модели:

Which natural languages do you, as a model, know best? List them in order.

Для анализа самих переводов использовал вот этот промпт с Claude Opus 4.5 в Plan Mode (но GPT-5.2 не хуже, если не лучше справится с такой задачей):

Use UX-friendly, natural [LANGUAGE] translations suitable for real product interfaces.
Prioritize clarity, brevity, and common UI patterns over literal translation.
Avoid slang, transliteration, and technical jargon.
Adapt wording to context (buttons, tooltips, hints, mobile vs desktop).
Prefer action-oriented, user-centric phrasing.

На картинке пара примеров анализа переводов промптом, где он нашёл точки для улучшения и объяснил, почему те переводы, которые он предлагает подходят лучше.

Суперсилы для ваших агентов

Вот, похоже мы и стали на шаг ближе к тому, чтобы заменить разработчиков на продуктовых менеджеров. Последние две недели я активно пользуюсь суперсилами для агентов.

Коротко: суперсилы внедряют в вашу работу автоматический пайплайн, который собирает с вас требования и помогает проектировать фичи.

Суперсилы — это набор скиллов для Claude Code, Codex и OpenCode.
Всё, что вам нужно сделать, чтобы базово начать ими пользоваться — установить плагин в вашего любимого агента, после чего суперсилы определят какой задачей вы занимаетесь и включат необходимый скилл.

Что такое скилл в этом контексте?
Это обычный набор инструкций для вашего агента (читай промпт).

Если вы занимаетесь дебагом, то суперсилы сами выберут скилл /systematic-debugging, который укажет вашему агенту, что прежде чем приступать к дебагу нужно сначала найти корневую причину из-за которой появился баг, затем найти минимально рабочий фикс и только потом приступать к исправлению бага (да, это упрощение, там гораздо больше инструкций, если интересно узнать что на самом деле происходит велкам в репу).

Если вы разрабатываете какую-то фичу, то суперсилы сами выберут скилл /brainstorming и начнут собирать с вас требования. Порой может показаться, что они задают глупые вопросы и вы уже сами будете задаваться вопросом «а как вообще можно было подумать, что нужно как-то иначе?». Но в этом и прелесть скилла /brainstorming: он дает LLM ответы на вопросы, которые были очевидны для вас, но не очевидны для LLM.

Если задача сложная, то суперсилы сами напишут для вас план выполнения, запустят разработку в отдельном worktree, отревьюят изменения, напишут коммит-месседжи и запушат их на GitHub.

Само собой вы можете вызывать скиллы вручную, чтобы иметь больше контроля над задачей.

Что по итогу?
У нас появился инструмент, который позволяет выстроить нам понятный и удобный пайплайн для быстрой современной разработки. В отличие от того же spec-driven development, который выглядит хорошо на бумаге и подходит для создания прототипов, но в реальной разработке применим только для крайне ограниченного круга задач.

Причём для того, чтобы разрабатывать приложения с суперсилами нужно иметь гораздо меньше инженерных навыков, так как суперсилы сами подсветят вам места, где ваша фича может работать не так, как вы ожидаете, что ещё больше уменьшает необходимость в том, чтобы смотреть на написанный код.

Классный пример того, как Superpowers позволяют делать то, что не получается без них.

Мы долго боролись с тем, что E2E тесты (а с ними и весь пайплайн) долго гоняются в CI. Средний прогон занимал ~25 минут. И это треш как долго.

Для того, чтобы ускорить пайплайн нужно было обладать полноценными навыками DevOps (если посмотрите на то, как усложнился пайплайн, то всё станет очевидно). У нас таких навыков не было, но было верхнеуровневое понимание, что это можно и нужно ускорять. А как вы уже знаете: AI не может заменить навыки которых нет, но может усилить имеющиеся, так что мы были в некотором тупике.

На днях я попробовал решить эту задачу с помощью Superpowers. Мы с ним сделали пару десятков подходов и каждый раз немного ускоряли пайплайн. Время выполнения пайплайна постепенно сокращалось с 25 минут, до 22 минут, до 16 минут и в конечном итоге пайплайн стал занимать меньше 10 минут т.е. ускорился в 2.5 раза!

Каждый подход к ускорению я начинал с простого «E2E tests are too slow in CI» или «Analyze bottlenecks in the workflow» (с приложенным скриншотом того, сколько какие части воркфлоу занимают). А дальше мы с ним как с обычным человеком думали о том, как мы можем сделать лучше: он задавал вопросы, я отвечал.

Почему это сработало?
Нет, я не превратился в DevOps'а чудесным образом, но Superpowers выступили в роли моего персонального, очень терпеливого и эрудированного наставника, который на каждом шаге сопровождал меня, предлагал варианты ответов и отвечал на мои вопросы.

Они не просто выдали готовое решение, а провели меня через процесс исследования и принятия решений, как если бы я работал с опытным коллегой, который знает все тонкости DevOps, но при этом умеет объяснять сложные вещи простым языком и подталкивать к правильным выводам.

Можно сказать, что Superpowers — это гений-коллега из соседнего отдела, который ничего не знает о твоём продукте, но знает как сделать красиво, но без тебя он не справился бы с задачей, так как у него нет необходимого контекста.

Забавно, но в одном только Cursor набил 2 миллиарда токенов (1.63 лярда здесь и 400 лямов на другом акке).

Интересно, сколько получилось в других агентах.

Думаю, что за год во всех тулах нагенерил более 5-7 миллиардов токенов.

Пойду траву потрогаю 😅

cursor.com/2025

Этот скриншот идеально описывает насколько ужасно в последнее время стали работать модели от OpenAI и ChatGPT.

Также это прекрасная иллюстрация к большому посту о китайских моделях и о том, почему они настоящие лидеры рынка, а также о том, как ситуация в AI-гонке может перевернуться с ног на голову в 2026 году.

Я создал честный ипотечный калькулятор! (часть 1/3)

И мне потребовалось всего два дня!

Для тех, кто хочет сразу потыкать — вот ссыль.

Немного истории

У меня есть ипотека. И у меня очень долго горит одно место из-за ипотечных калькуляторов. Горение началось, когда я только собирался взять ипотеку, так как половина сайтов пытается втюхать тебе своё говно, а вторая просто ужасно работает, из-за чего такая простая задача, как посчитать платёж по ипотеке, превращалась в пытку, где половину вычислений мне приходилось производить самому.

Примерно тогда (пару лет назад) у меня и появилась мысль создать собственный калькулятор, но всё как-то не доходили руки.

Затем, уже в этом году, когда мы с моей невестой обсуждали ипотеку, она сказала, что я неправильно подхожу к погашению ипотеки, потому что у меня ипотека на 30 лет, а я не вношу вообще никаких досрочных платежей, хотя бы 10 000 рублей.

Я тогда возмутился и сказал, что 10 000 рублей ничего не решат. Мы закончили обсуждение, но в свойственной мне манере я начал глубже исследовать тему и понял, что она была права (я потом извинился).

Я узнал, что все платежи по ипотеке, которые идут сверх 15 лет, идут на погашение процентов. То есть, если вы берёте ипотеку на 30 лет, то первые 15 лет будете буквально платить за неё проценты. Основной долг почти не будет уменьшаться.

Я, конечно, прекрасно понимал, что ипотека на 30 лет — это невыгодно (хоть другую мне и отказывались выдавать), но осознание того, что от меня хотят, чтобы я 15 лет платил проценты, повергло меня в небольшой шок. В целом, шок был только небольшим, так как я видел, как медленно гасится мой основной долг.

Но затем я рассчитал платежи... И с ужасом для себя понял, что просто добавив 10 000 рублей к платежу (мой платёж увеличился бы до 81 000 рублей в месяц, или другими словами, я стал бы платить 14% поверх обязательного платежа), я уменьшу срок ипотеки на 13 лет и 10 месяцев и сэкономлю 9 948 408 рублей.

И тут до меня дошло, насколько сильно я профакапился...

Но ведь этого можно было избежать? Ведь да? Да?

По моему личному опыту, на эту тему в интернете чёрт ногу сломит. Да, вам дадут какие-то общие советы, но из них вам не станет понятно, сколько нужно вносить досрочным платежом, а это главный затык большинства людей.

Вам просто не объяснят, что если вносить даже по 1 000 рублей сверх обязательного платежа, то на горизонте 30 лет это сэкономит вам 640 000 рублей, 280 000 рублей из которых пошли бы на погашение процентов.

И совет о том, как рассчитать сумму, которую нужно вносить — это такая базовая информация, которую должен отображать каждый калькулятор, но факт в том, что её не отображает НИ ОДИН.

А логика до банального простая: нужно посмотреть какой платёж банк хочет от вас, чтобы закрыть ипотеку за 15 лет — столько и нужно платить. Это сумма, которая позволит вам сэкономить наибольшее количество денег и при этом не разориться на платежах. В моём случае мне нужно платить 12 097 рублей сверх обязательного платежа и это сэкономит мне 10 686 073 рублей, а также 15 лет жизни. На этом всё. Вы можете прямо сейчас перейти в сервис и посмотреть расчёт для своей ипотеки.

Также буду рад, если расскажите о сервисе своим друзьям, которые только думают об ипотеке или уже выплачивают её!
Я с сервиса ничего не получаю и в нём никогда не будет рекламы.

В остальных частях расскажу о других сервисах, и о том, почему вам скорее всего не стоит ими пользоваться (одним из них так уж точно).

honestcalc.ru

Я создал честный ипотечный калькулятор! (часть 2/3)

В тему остальных ипотечных калькуляторов

С ними всё очень плохо. Да, в некоторых калькуляторах вы можете узнать как будет уменьшаться ваш платёж, если вам позволят ввести информацию о досрочном платеже, но проблема в том, что почти все калькуляторы, которые выдаёт Google по запросу "ипотечный калькулятор" даже не имеют функции добавления досрочного платежа, потому что в топе выдачи будут калькуляторы от банков, которые живут на том, чтобы вы гасите ипотеку медленно и все 30 лет.

А те калькуляторы, что имеют такую функцию, либо неправильно считают (привет, Calculus), либо требуют докторской по калькуляторам, чтобы разобраться с тем, что в них происходит (привет, КонсультантПлюс и fincalculator).

Единственный нормальный калькулятор для расчёта ипотеки с досрочным погашением есть у Т-Банка, но для того, чтобы его найти придётся нормально так попотеть. Лично я узнал о нём совершенно случайно, пока читал статью в их журнале. Правда, у него максимально базовый функционал и ужасный UX, но он хотя бы правильно считает и для него не нужна докторская по калькуляторам. Так что Т-Банку, в этом плане, респект.

Ну, вот же вроде оно, да? Зачем тогда свой калькулятор? А затем, что:
1. Всё ещё хрен пойми сколько ты переплатишь за ипотеку: да, в калькуляторе от Т-Банк есть какие-то циферки, но нет наглядной визуализации;
2. Тебе ни один из этих калькуляторов не подсказывает сколько платить из ипотеку, а это основное понимание за которым ты вообще приходишь в эти калькуляторы.

Вот с этими двумя мыслями я начал создавать свой калькулятор.

Поэтому в приложении много наглядных графиков, которые позволят визуально понять сколько денег вы потратите и какая часть платежа пойдёт на погашение процентов, что уйдёт в основной долг и сколько денег будет сохранено благодаря досрочным платежам.

А также есть подсказки и советы на тему того, сколько платить, вместо базовых и до жути запутанных советов-простыней на тему различий между уменьшением платежа и уменьшением срока.

Но вы можете спросить меня: «А почему на сайте нет базовых советов? Разве они не помогли бы людям, которые только погружаются в тему?».

А я вам отвечу, что в этом и есть прелесть визуализаций ✨: они позволяют в реальном времени отследить как ваша ипотека изменится, если вы, например, внесете досрочный платёж не в уменьшение долга, а в уменьшение платежа. И это помогает разобраться в теме в 10 раз больше, чем объяснение текстом.

И вот до меня дошло насколько полезный инструмент я создал в тот момент, когда я сам для себя лучше стал понимать как работает ипотека, благодаря тому, что я увидел как меняются цифры на графиках, а также когда понял, что калькулятор в Calculus всё это время неправильно считал... а это был основной калькулятор, которым я пользовался...

Что ещё есть в приложении?
1. Ну, во-первых я реализовал доступность для пользователей с ограниченными возможностями, так что им могут воспользоваться даже пользователи скрин-ридеров;
2. ВСЕ данные обновляются в реальном времени. Я вообще не понимаю почему на том же Calculus и других сайтах нужно нажать кнопку, чтобы получить расчёт ипотеки, ведь это элементарная математика, которую можно считать на стороне клиентского приложения. Ребят, ну мы же уже не мезозее, ей богу;
3. Вы можете поделиться ссылкой на получившийся расчёт;
4. А также скачать красивую картинку с вашим расчётом;
5. Вне зависимости от того, с какого устройства вы зайдёте, будь то смартфон, планшет, ноутбук или ПК — приложение будет красиво отображаться. Да, я понимаю, что это запретная магия и тот же Instagram уже 15 лет не могут адаптировать под разные размеры экрана, но на что не пойдёшь, когда тебе не плевать на пользователей ❤️;
6. При всём при этом в сервисе нет, и не будет никакой рекламы, а также ваши данные никуда не передаются (если честно, то сервис даже не привязан к бэкенду, ибо нафига);
7. А ещё калькулятор чертовски красивый 😈.

Я создал честный ипотечный калькулятор! (часть 3/3)

Ну, и немного технических деталей

Всё приложение занимает 8 000 строк кода (4 000 из которых — это JS).
Весь этот код находится в одном index.html файле и мне пофиг!
А ещё я деплою приложение простым перетаскиванием index.html в дашборд хостинга и мне опять же пофиг!

Вы даже не представляете как это круто не париться с зависимостями, бандлерами, настройкой CI/CD, деплоями и всем вот этим оверхедом, когда создаешь проект. Ты просто берешь и делаешь.

А что по метрикам?

Сайт летает быстрее, чем любое, самое заоптимизированное React-приложение. И это при том, что все графики, все таблицы, все пай-чарты и всё-всё-всё перерисоывается с красивыми анимациями, как только вы вводите что-то в инпуте, тяните за ползунок или нажимаете на какую-либо из кнопок. И это всё происходит без какого-либо троттлинга, дебаунса и других техник оптимизации. Мне не было лениво оптимизировать — оно просто не нужно. Всё и так летает!

Также Lighthouse выдаёт приложению 100 баллов за скорость загрузки, что в прочем неудивительно, учитывая, что приложение содержит в 10 раз меньше кода, чем один только бандл React.

Просадка в оценке best practices вызвана тем, что на сайте нет HTTPS, но его там и не будет, потому что сайт не имеет доступа к чувствительным пользовательским данным, да и вообще не общается с сервером.

honestcalc.ru

Как раньше ощущался продуктивный день: я создал большую модалку, связал её с бэком, покрыл всё тестами и добавил обработку различных состояний типа сохранения, отмены изменений.

Как ощущается НЕ продуктивный день сейчас: я перевёз 12 500 тестов с Enzyme на RTL, 5 000 из которых до этого вообще не существовали, проверил, что все они тестируют не детали реализации, а пользовательское поведение, добавил ESLint правила, чтобы улучшить тесты, убедился, что покрытие тестами достаточное (что добавило 5 000 тестов) и при всём при этом время выполнения сократилось, благодаря тому, что я перевёз весь проект с npm на bun.

В удивительное время, мы, конечно, живём:)