Привет! Меня зовут Оля, я ведущий дизайнер в Домклик. Работала в бигтехе (Сбер, Московская биржа).

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

Здравствуйте, уважаемые читатели. Вот и настал тот день, когда мы поняли, что наш замечательный проект стал сложным. Спустя три года разработки его поддержка начала требовать значительных ресурсов, внедрение новых фич бизнеса замедлилось, а команда уже давно растеряла прежний интерес. Большинство из разработчиков неоднократно проходили эту стадию. Если посмотреть на ситуацию с другого ракурса, то всё далеко не так уж плохо: проект стал «взрослым», приносит деньги, что позволяет его развивать. Но всё-таки сложность только нарастает, проблемы напоминают снежный ком, и что-то с этим нужно делать.

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

А что если я скажу вам, что при таком подходе мы, скорее всего, получим с десяток микросервисов, которые по цепочке синхронно вызывают друг друга, знают подробности внутреннего устройства каждого, ходят в общие таблицы (крайне запущенный случай), и отказ одного из них вызовет крах всей системы? Прямо как с костяшками домино. Встречайте, Его Величество Распределённый Монолит!

Привет, Хабр! Меня зовут Антон, я фронтенд‑разработчик в Домклик. Наша команда отвечает за библиотеку «Продуктовых сниппетов» — те самые карточки недвижимости, которые вы видите в нашей поисковой выдаче.

Проблема в том, что этих карточек у нас более 40 видов (сниппеты вторичной, первичной, загородной, краткосрочной недвижимости, каждый тип имеет несколько размеров под разные разрешения), и все они живут в одной монорепозиторной библиотеке на React 19. Любая правка в общих стилях или глобальных дизайн-токенах, или элементарное обновление компонентов дизайн-системы превращалось в игру «Сапёр»: поправил отступ в одном типе сниппета — поехала вёрстка или поплыл паддинг в другом, о чём мы узнавали уже при тестировании релиза или, что хуже, от пользователей после релиза.

Я расскажу, как мы внедрили полноценное визуальное регрессионное тестирование (Visual Regression Testing) на основе Storybook, Playwright и Jest, с какими трудностями столкнулись при стабилизации скриншотов и как заставили тесты работать стабильно.

Всем привет! Сегодня хочу поделиться своим подходом к локальной разработке backend‑приложений. Речь пойдёт о том, как вернуться к использованию виртуальных окружений, отказавшись от контейнеризации там, где она начинает мешать, а не помогать.

Каждый разработчик давно знает обо всех преимуществах Docker: мы привыкли воспринимать его как универсальный ответ на любые вопросы инфраструктуры. Некогда революционная парадигма разработки стала чем‑то обыденным и сегодня часто принимается как no‑brainer решение при разработке очередного проекта на локальной машине. Но давайте на минуту остановимся и зададимся вопросом: всегда ли эта избыточная изоляция оправдана? Действительно ли мы нуждаемся в «мини‑сервере» на каждом этапе написания кода, или мы просто следуем моде, жертвуя скоростью и комфортом.

У меня была видеокарта NVIDIA A100, максимальный объём памяти 79,254 Гб. Нужно было извлечь ключевую информацию (задача Qwestion Answering) из 6000 многостраничных документов. Всего было 15 полей разного типа:

Фродо_Бэггинс_паспорт — серия и номер паспорта в Средиземье Сэмуайз_Гэмджи_инн — ИНН, полученный в Мордоре
Хоббит_номер_страховки — номер страхового полиса (эльфийского) Мериадок_Брендибак_пол — пол
Хоббит_диаметр_кольца — диаметр кольца Всевластия
Перегрин_Тук_вес — вес
Гэндальф_Серый_длина_посоха — длина посоха в сантиметрах Майар_количество_упоминаний — количество упоминаний в документе его имени Арагорн_дата_рождения — дата рождения
Леголас_Эльф_количество_стрел — количество стрел
Гимли_фио — ФИО полностью
Боромир_дата_смерти — дата смерти
Саурон_количестов_пальцев — количество пальцев после войны
Орки_количество — сколько орков указано документе
Волки_количество — сколько волков указано в документе

Ну, понятное дело, все поля обфусцированы (на самом деле это обычные юридические документ, причем их форма различается в зависимости от того, кто их делал). Особенность была в том, что все поля могут быть расположены на одной странице документа или размазаны по всему документу, а страниц может быть до 80.

и как не утонуть между БКИ, Госуслугами и тремя платформами одновременно?

Один QA. Три платформы. Шесть внешних сервисов. Легаси-код. И огромное количество неопределённости — в требованиях, в поведении интеграций, в том, что вообще считать корректным результатом. Рассказываю, как выстроить тестирование сложного финансового процесса так, чтобы до релиза добиралось не более 5–7 багов — и все они были известны заранее.

Написал агента который за ночь переписал 100 тестов с Mockito на MockK, а за следующую — исправил 1700 ошибок линта.

Спойлер: секрет не в крутом промпте, а в правильно выстроенном цикле — чётком DoD, автоматической проверке результата и обратной связи с моделью.

Gunicorn кажется простым, пока не сталкиваешься с эксплуатацией: внезапные ошибки 502, зависшие воркеры и странное поведение при перезапусках. За этими симптомами стоят вполне конкретные причины — от медленных клиентов и отсутствия буферизации до особенностей реализации GThread и механики Graceful Shutdown.

В этой статье разберём реальные сценарии отказов, посмотрим, как менялась архитектура GThread в разных версиях Gunicorn, и соберём практичную конфигурацию с Nginx, Docker и Kubernetes, которая ведёт себя предсказуемо под нагрузкой.

Привет! Меня зовут Егор Молчанов, я разработчик в компании Домклик.

В прошлой статье мы познакомились с новыми функциями input(), output() и model(), которые закладывают фундамент для будущего Angular без Zone.js. Сегодня мы поговорим о том, как эти изменения дошли до самой, пожалуй, наболевшей темы в любом приложении — работы с формами.

В Angular v21 появился новый, экспериментальный способ управления формами — Signal Forms. Он не отменяет старые добрые Reactive Forms, но предлагает совершенно иной подход, основанный на сигналах. Давайте разберёмся, как работали формы раньше, как они будут работать с Signal Forms, и что это нам даёт.

Недавно перед нами встала задача быстро реализовать микросервис для конвертации видео. Стандартным решением для таких целей является FFmpeg, который умеет читать файлы чанками (запросы HTTP Range) с URL и выводить результат в stdout. Поэтому я решил попробовать подход с потоковой конвертацией.

Важно уточнить, что под «потоковой обработкой» здесь подразумевается передача данных в виде последовательности чанков (Chunked Streaming), а не классический Continuous Streaming, как в случае с live-видео.

Это история о граблях, на которые вы можете наступить при миграции на Kotlin 2.2+, а также о развитии и закулисье удобства языка Kotlin.

Когда Kotlin только появился, он уже обладал всем привычным теперь синтаксическим сахаром в виде неабстрактных методов интерфейсов, параметров по умолчанию у функций. Тогда это была версия 1.0.0, совместимая с Java 6. Java 6 и 7 не умела создавать неабстрактные методы интерфейсов, эта возможность появилась только в Java 8.

Чтобы иметь возможность создавать такие методы, Kotlin генерировал специальный класс DefaultImpls, в котором располагались статичные методы, выглядящие в Kotlin как обычные методы. Далее язык пошёл по долгому пути миграции на Java/JVM default method, появившиеся в Java 8.

Большинство кандидатов теряют шанс на оффер не из-за опыта и просадки по хардам, а из-за того, как отвечают на простые вопросы.

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

Я разобрал топовые вопросы, которые встречаются почти на каждом собеседовании, и показал, как отвечать так, чтобы сразу захватить внимание HR или менеджера; какие формулировки лучше использовать и почему; проверенные ответы, которые можно брать за основу.

Java-разработчики годами жили по принципу «Everything is an object». И всё бы хорошо, если бы за это нам не приходилось платить «налогом на объект»: каждый раз, когда вы создаёте простой класс из двух полей int, JVM бережно дописывает к нему тяжёлый заголовок, упаковывает в ссылку и разбрасывает по куче, заставляя процессор страдать от постоянных промахов кеша.

Мы привыкли к этому компромиссу. Мы научились использовать примитивные коллекции и костыли, чтобы выжать производительность там, где объектная модель Java начинает буксовать. Project Valhalla призван изменить сами правила игры.

Привет, Хаббррр! Сейчас я расскажу, как использую агенты, чтобы упростить себе backend-разработку и не тратить на рефакторинг больше, чем на написание кода.

Какие задачи идеально подходят для оптимизации с помощью ИИ, а какие не стоит отдавать агенту.

Эта статья не про «правильную» архитектуру. Здесь я постарался ответить на вопросы «почему микросервисы дороже, какие компромиссы неизбежны и по каким критериям выбирать архитектуру?»

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

Всем привет! Меня зовут Алексей, я техлид Android-направления в компании Домклик.

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

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

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

Наш продукт позволяет клиенту подать заявку на нецелевой кредит под залог недвижимости.

Привет! Меня зовут Алексей Сидоров, я Python-разработчик в команде краткосрочной аренды в Домклик. В этой статье разберём, как и зачем проверять код миграций схемы БД и как написать свой линтер.

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

Всем привет! Сегодня с вами Серёжа Сажин. Мы в команде дизайна сейчас активно работаем над эмоциональной составляющей в наших продуктах. Когда мы говорим про эмоциональность в интерфейсах, то чаще всего вспоминаем клиентские продукты: яркие иллюстрации, анимации и те самые «приятности», которые делают опыт живее. Но как только речь заходит о внутреннем продукте для сотрудников, в воздухе звучит: «Нам не эмоции нужны, нам надо, чтобы работало».

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