Разработка

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

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

Меня зовут Алексей Исламов, я администратор СИБ в Точка Банк. В статье предлагаю готовый вариант реализации такой системы из open‑source инструментов, которым может воспользоваться каждый.

28 июня 2009 года легендарный астрофизик Стивен Хокинг провёл вечеринку для путешественников во времени с шампанским и шариками. Он никому не сообщил заранее, а только постфактум, с указанием точного времени и места встречи.

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

К сожалению, это не помогло: на вечеринку всё равно никто не пришёл. Стивен Хокинг сидел там в одиночестве.

Всем привет! Меня зовут Олег Смоляков, в Яндексе я больше 15 лет занимался разработкой, а теперь отвечаю за улучшение процесса найма разработчиков.

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

TLDR: мы решили обновить процесс найма, вместо порой хаотичных собеседований в каждом отдельном сервисе внедряем единую систему оценки по профессии и уровню (например, «Senior C++ Developer»), кандидат, успешно прошедший оценку навыков, теперь сможет претендовать на аналогичные вакансии в любом из 90+ сервисов компании, а всё это вместе делает процесс найма прозрачным, понятным, без дублирования технических интервью и в целом эффективным для всех участников.

А теперь подробнее о том, почему мы на это пошли и как всё устроено.

В поисках идеального подхода к автоматизации UI-тестирования? В этой статье вы найдёте реализацию фреймворка UI-автотестов на Kotlin, основанного на компонентной архитектуре с использованием популярного инструмента Playwright.

Исследование показывает, что наиболее востребованная технология в 2025 году — контейнеризация. Kubernetes закрывает эту потребность и помогает управлять контейнизированными приложениями. Среди специалистов нет определенного мнения, какой вариант развертывания лучше: самостоятельное или готовое решение. На этот вопрос каждой компании нужно ответить самостоятельно. 

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

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

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

Проблема в том, что люди пытаются анализировать LLM как объект сам в себе, не до конца понимая, что такое LLM. Эта статья утверждает: вопрос не в том, что LLM знает или умеет, а в том, чем она является.

В 2025 году Kubernetes стал практически таким же распространенным решением, как и операционная система линукс. Действительно, с внедрением микросервисов и необходимостью управлять парком серверов нам нужна распределенная операционная система. Именно такой системой и является оркестратор Kubernetes. 

Не я один подметил это, этот факт подсвечен во многих материалах по K8s. Например, вот: 

Ваш код принимает данные извне? Поздравляем, вы вступили на минное поле! Любой непроверенный ввод от пользователя может привести к уязвимости, и найти все "растяжки" вручную в большом проекте почти невозможно. Но есть "сапёр" — статический анализатор. Инструмент нашего "сапёра" — taint-анализ (aka анализ помеченных данных). Он позволяет обнаружить "грязные" данные, дошедшие до опасных мест без проверки. Сегодня мы расскажем о том, как он работает.

Статусы вошли в жизнь пользователей коммуникационных инструментов очень давно: вспомните легендарную «Аську» или Mail.ru Агента. Это действительно удобно – заранее видеть информацию, которую потенциальный собеседник хочет сообщить о себе. В корпоративной среде статус играет более утилитарную роль. При помощи статусов сотрудник транслирует свой уровень доступности, сообщая коллегам важную информацию о том, что он, например, «В отпуске», «На больничном», «На звонке» или «На встрече».

Мы запустили статусы в июне 2025 года, и это стало долгожданным событием для сотен тысяч наших пользователей. Не каждое нововведение настолько круто «заходит» в корпоративной среде. И конечно, за удобной и простой фичей стояла большая работа. О том, как это было, мы расспросили в команде разработки eXpress.

Меня зовут Илья Куликов, я руковожу разработкой веб-терминалов в компании «Столото». Сегодня хочу рассказать, как мы превратили ручные релизы и вечные конфликты в почти автономный CI/CD. За почти 10 лет в компании я прошёл путь от бэкенд-разработчика до руководителя направления, в «Столото» же за это время родился и вырос целый продукт — веб-терминал для агентов розничной сети. Изначально у нас был парк дорогих аппаратных терминалов, установленных у агентов. Но как расширить сеть и снизить входной порог? Возникла идея: а что, если сделать аналогичное приложение в браузере? Тогда любой желающий мог бы стать агентом — достаточно старого ноутбука и договора с нами. Так появился полноценный веб-аналог аппаратного терминала со всеми необходимыми функциями для продажи лотерей.

Но вместе с ростом продукта росла и боль: релизы занимали часы, всё постоянно ломалось на проде, а после каждого деплоя команда судорожно грепала логи в поисках причины падения. Мы поняли: без серьёзной перестройки процессов дальше — только хуже. И тогда решили кардинально пересмотреть наш подход к CI/CD. Отказались от классического GitFlow в пользу trunk-based development, полностью перестроили пайплайны в GitLab и внедрили автоматизацию на всех этапах — от сборки и тестирования до деплоя и мониторинга.

В этой статье я делюсь реальным опытом:

- как мы ушли от ручных релизов к автоматическому деплою в прод;

- какие практики и инструменты позволили нам перестать бояться каждого коммита;

- как повысить качество кода и ускорить вывод фич на рынок без ущерба для стабильности.

Этот материал будет особенно полезен техлидам, инженерам DevOps, разработчикам и командам, которые всё ещё живут в мире ручных деплоев, боятся нажимать «мердж» в пятницу вечером. Если вы задумываетесь, как перейти от хаоса к предсказуемости в релизах — вы по адресу.

А как мы этого добились — читайте под катом!

Привет! Меня зовут Марина Павлова, я технический писатель в отделе документации 1С-Битрикс. В этой статье я расскажу, как мы полностью переделали документацию по Bitrix Framework и как команде из двух человек удалось выпустить доку за 9 месяцев с помощью ИИ.

Забудьте о ручном склеивании строк: с pathlib пути элегантно конструируются с помощью оператора /. Проверка существования, чтение, получение родительской директории — всё это становится методами и атрибутами самого объекта. В результате код получается не просто чище и читабельнее, он становится более надежным и по-настоящему "питоничным" (Pythonic).

С 1 октября у нас проходит открытое бета-тестирование нативного КОМПАС-3D для ОС на ядре Linux. Мы подумали, а что если провести здесь обзорную экскурсию для нового пользователя ОС Linux, который не имеет отношения к IT-сопровождению и не должен заниматься администрированием систем? Такой сотрудник работает, используя не операционную систему, а доступные в ней программы и инструменты. Цель этой статьи — показать эти инструменты.

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

Пока вы с удовольствием наблюдаете в отчетах красивые 200ms — ваши пользователи стучат в службу поддержки со словами "у меня все висит".
И они не врут, у них действительно TTF порядка 6 секунд. Но и вы не врете, у вас действительно 200ms в отчете!

Врет метрика, а вы ей верите.

Давайте разбираться.

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

Сегодня доступно множество инструментов: Selenium, Playwright, Cypress и другие. Каждый имеет свои преимущества. Но в подавляющем большинстве наших проектов мы используем Selenium. Расскажу, почему мы сделали такой выбор.

Цель автоматизации — экономия

Главная задача автоматизации — снизить ручную нагрузку и минимизировать человеческий фактор. Рассмотрим на примере интернет-магазина. Если компания выпускает по 5 версий в месяц, перед каждым релизом необходимо проверять ключевые сценарии: добавление товара в корзину, оформление заказа, оплату. Регулярные ручные проверки требуют времени, увеличивают затраты и подвержены ошибкам.

Автотесты выполняют эти проверки быстрее и точнее. С экономической точки зрения, однократные инвестиции в разработку автотестов, как правило, окупаются за счет экономии на многократных ручных проверках.

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

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

Требования клиентов и гибкость технологий

Как IT-компания, мы сталкиваемся с разными требованиями заказчиков. Клиенты часто просят использовать определенный язык программирования, чтобы их команды могли поддерживать тесты. Например, если бекэнд написан на C#, то и автотесты предпочтительнее на нем.

Что важно фронтенд-разработчику при создании веб-приложений? Поддержка текущей кодовой базы, удобство внедрения новых фич и возможность повторно использовать компоненты. Создать такие условия помогает популярный подход к проектированию — FSD (Feature Sliced Design). Разбиваем интерфейс на независимые, переиспользуемые модули (виджеты, фичи и т. д.), получаем чёткие правила, единую структуру проекта и ускорение разработки за счёт переиспользования кода и изоляции ответственности.

Подход FSD во многом прекрасен, но всё же нам в нём не хватало некоторых важных аспектов: внятного разделения слоёв бизнес-логики, удобства работы с кастомными хуками (они быстро разрастаются, обрастают связями и становятся сложными для тестирования). Также было неясно, куда выносить сложные общие компоненты из разных частей проекта. И, например, как легко отделять один бизнес-модуль от другого, не ломая всю систему…

Меня зовут Иван Соснович, я тимлид фронтенд-разработки в СберТехе, тружусь в команде Platform V Kintsugi — это графический инструмент для сопровождения, мониторинга и диагностики Postgres-like СУБД. В этой статье я покажу, как мы доработали FSD под себя, и дам ссылку на пример со структурой приложения. Надеюсь, будет полезно фронтенд-разработчикам.

Уголовка руководителя за предоставленный сотрудником логин и пароль

Что учесть работодателю и сотрудникам компании?

Заместитель начальника ОАО «Р» Г. осужден по ч. 3 ст. 272 УК РФ – неправомерный доступ к компьютерной информации, повлекший ее копирование, совершенный с использованием своего служебного положения.

Новость о том, что Qualcomm покупает Arduino сначала вызвала чувство тревоги. Примерно такое же, как когда Broadcom купил VMware. С чудесным миром микроконтроллеров я тесно познакомился именно благодаря Arduino. Оригинальная Uno базировалась на ATmega328P и стоила на момент выхода 30 $. Реальная себестоимость, по оценкам коммьюнити, была около 15 $, а все остальное пользователь платил за бренд и открытость дизайна.

Последнее, кстати, привело к тому, что спустя короткое время плата была скопирована китайцами. Они не просто нашли способ заменить дорогие компоненты более дешевыми аналогами, но и наладили крупносерийное производство. Это привело к тому, что купить ноунейм-клон аля Nduino Uno можно было на порядок дешевле.

Совсем недавно публике представили новую плату Arduino Uno Q, которая уже была создана с использованием разработок Qualcomm. Она мгновенно вызвала интерес, благодаря новому видению того, как должна выглядеть современная плата микроконтроллера. Мне уже удалось добраться до серийного образца Uno Q, так что спешу поделиться с вами впечатлениями!

Тревожная тенденция, о которой заговорил даже Дуров. О том, как работает цензура на Западе, В Китае и США, не касаясь России.

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