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

Мы уже разобрали анатомию страницы (HTML) и её визуальное оформление (CSS) (1, 2, 3). Но как увидеть это всё вживую? Как понять, почему кнопка на сайте съехала на два пикселя ниже, чем в вашем макете?

Ответ прост — инструменты разработчика (Developer Tools, или сокращённо DevTools). Это встроенный во все современные браузеры набор утилит, который позволяет в реальном времени просматривать код, стили и структуру любой веб-страницы. Для дизайнера это не просто любопытная игрушка, а незаменимый инструмент для проведения авторского надзора.

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

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

Этой статьёй я открываю цикл материалов, в которых будут собраны мысли, советы и инструкции о том, как сделать приложение и процессы его разработки измеримыми, как находить «узкие места», диагностировать проблемы и причины их возникновения, а также фиксировать их наличие. Минимум кода, сложных терминов и «rocket science» — только практический опыт и наработки по различным метрикам.

В первых двух частях (1, 2) мы разобрали, зачем дизайнеру знать основы вёрстки, и поближе познакомились с языком разметки HTML. Сегодня давайте подбробнее обсудим, как из простой разметки рождается дизайн: поговорим о CSS.

Привет, Хабр!

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

Когда я только начинал карьеру во фронтенд-разработке, то постоянно задавался вопросами: «Зачем на интервью просят обходить граф, если на работе я просто правлю CSS-отступы?» или «Зачем мне знать сложность O(N), если вёрстка всё равно ломается в Safari?» С развитием ИИ подобные вопросы стали звучать ещё громче: «Зачем мне вообще думать, если агент напишет этот цикл за меня?»

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

В первой части мы разобрали, зачем дизайнеру знать основы вёрстки и как это помогает создавать реализуемые макеты и экономить время. Теперь перейдём от теории к практике и познакомимся с главным языком разметки — HTML.

Если CSS отвечает за то, как выглядит страница (цвета, шрифты, отступы), то HTML (HyperText Markup Language) отвечает за то, что на ней находится и какую смысловую роль играет каждый элемент. Это скелет вашего сайта.

ИИ уже давно стал неотъемлемой частью наших жизней, иногда он полезен, а иногда бывает даже вреден, но что если я скажу, что он может очень сильно помочь вам в написании автоматизаций и разработке дашбордов для Home Assistant!

В этой статье рассмотрим The Unofficial and Awesome Home Assistant MCP Server и как он может облегчить жизнь и сэкономить время.

Хочу рассказать об основах вёрстки для дизайнеров. Научить базовым принципам и показать, как проверять реализацию макета в коде. Статья будет полезна начинающим дизайнерам, которые пока не представляют, как их макеты оживают на реальных сайтах.

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

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

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

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

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

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

Проблема в том, что этих карточек у нас более 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 или менеджера; какие формулировки лучше использовать и почему; проверенные ответы, которые можно брать за основу.