Планирование, отслеживание и контроль
GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.
А зачем покупаете WAF, который можно обойти?
С таким вопросом разработчиков периодически сталкиваюсь. Добавлю контекста. Работаю AppSec инженером в финтехе. Когда нахожу уязвимости — сообщаю разработчикам. Среди прочего - доношу мысль: если в данном случае можно смягчить потеницальные последствия угрозы через WAF — это не значит, что уязвимость не нужно исправлять в приложении. Нередко разработчики спорят. Примерный диалог:
— Ну, есть же WAF — на нём и делайте фикс, зачем нам-то в код лезть? WAF — он же для того и нужен, чтоб уязвимости устранять.
— WAF — не панацея: на нём мы сделаем правило. Но это не значит, что в самом приложении не нужно устранять.
— Почему?
— Например, потому, что практически любой WAF можно обойти.
— А зачем покупаете WAF, который можно обойти?
Отвечаю так: потому что WAF пишут такие же разработчики, как Вы, и они тоже иногда ошибаются (как и все люди). Некоторые особо настырные разработчики желают доказательств, что WAF можно обойти. В целом я солидарен, что практика "а ты докажи" в управлении уязвимостями - не очень хороша. Но, если есть под рукой на что можно быстро сослаться - можно это сделать. Я ссылаюсь на эту статью.
В моей практике были случаи, когда WAF из-за сбоя переставал применять правила на несколько дней. Т.е. трафик через него шёл, сервис за WAF продолжал быть доступным. Но, правила на WAF не работали — будто их и нет.
Эта история в очередной раз показывает: насколько бывают различны в оценке ситуации разработчики и "безопасники". Более интересный вариант — когда разработчики считают, что только они могут решать: что является уязвимостью, а что — нет (подробнее об этом я писал в статье "Как я зарегистрировал CVE и разозлил вендора").
Ааа! Я не могу это смотреть! "В чём отличие внешнего ключа от внутреннего?" Или вопрос в Сбере на з.п в 200 косарей (руб/мес если чё): "что такое гит".
Дебилы собеседуют дебилов. Видимо, соревнуются в своей дебильности. Отрицательный отбор в действии.
Я конечно, давно понял, что в больших ИТ-компаниях изрядная доля штата с ОЧЕНЬ низкой квалификацией, но чтобы вот такой убогий уровень - это даже не плинтуса ниже, это ниже уровня пола. Таких ИИ конечно обделает, как можно проиграть абсолютному нулю?
Индустрия, тебе плохо? Пора откачивать?
В продолжении поста "Как я передаю структуру проекта при работе с AI-агентами"
Там описал утилиту sumr, которая саммаризирует файлы проекта через LLM и выдаёт дерево с однострочными описаниями. Коротко: запускаешь sumr в корне — и она выдает структуру папок и файлов с кратким описанием каждого элемента. Это помогает AI-агенту быстро понять, что где находится, без необходимости читать весь код.
Что добавил с тех пор:
Теперь инструмент держит кэш у себя и не трогает ваш проект.
Добавил watch mode. Достаточно запустить sumr watch или sumr watch --detach на папке с проектом — и утилита начинает следить за изменениями. Появился новый файл или изменился существующий — саммари обновляется автоматически. Не нужно каждый раз вручную перезапускать. Запустил один раз в фоне и забыл.
Ещё добавил два флага: -p для указания конкретной папки и -d для ограничения глубины дерева, как tree -L. Их можно комбинировать:
sumr -p ./src # начать с конкретной папки sumr -d 2 # показать только 2 уровня глубины (как tree -L 2) sumr -p ./src -d 1 # папки верхнего уровня с саммари
После запуска watch в инструкцию CLAUDE.md добавил рекомендацию:
* Всегда начинай ЛЮБУЮ задачу с команды 'sumr -p ./... -d ...' для получения общей структуры проекта и понимания, где что находится. Вот примеры использования команды sumr: sumr -p ./src # начать с конкретной папки sumr -d 2 # показать только 2 уровня глубины (как tree -L 2) sumr -p ./src -d 1 # папки верхнего уровня с саммари
И это действительно работает на моих проектах - буквально 1 read корня - 2 read подпапки - старт выполнения задачи :)
Установить последнюю версию:
npm i summariser@1.0.1 -g
Репозиторий: https://github.com/BuddaArt/Summariser
В октябре 2025 года в сети распространился ролик,в котором девушка расплачивается улыбкой, используя ... фотографию своего знакомого. Комментаторы, как обычно, разделились на 2 лагеря: на обывателей, которые чихвостят "систему", и технических специалистов, утверждающих, что это фейк. Ну а мы давайте теоретически разберемся, что это и как такое в принципе возможно.
«Оплата улыбкой» — это сервис Сбербанка, который позволяет оплачивать покупки на кассах в магазинах с помощью биометрии. Проект был запущен летом 2023 года как альтернатива ушедшим с рынка платежным сервисам... Для оплаты нужно посмотреть в камеру, которая распознает изображение лица и сопоставляет его с уникальным номером, привязанным к биометрическим данным. Этот номер также привязан к счету карты. Если данные совпадают, оплата проходит. (с) РБК
Вообще, распознавание лиц в биометрических системах обычно работает как конвейер из нескольких шагов. Верхнеуровнево порядок следующий:
Набор камер получает кадр лица
Алгоритм находит лицо на изображении (рамку вокруг лица)
Система ищет ключевые точки (глаза, нос, уголки рта) и “выравнивает” лицо
Нейросеть преобразует лицо в вектор признаков (эмбеддинг) — набор чисел, который компактно описывает уникальные черты
Дальше считается “близость” двух векторов, например, косинусное сходство или евклидова дистанция: если сходство выше порога, то доступ/оплата разрешена.
Системы безопасности в таких устройствах настроены на защиту от подстановки фотографий, масок, а также добавляют проверки на "человечность". Так, системы анализируют блики и глубину, микродвижения, отражения от ИК-камера (кожа и материалы отражают по-разному); определяют объемность и т.д.
Поэтому, в профессиональных системах биометрии обычно используется нескольких камер:
• обычная RGB: получение изображения лица
• ИК: даёт надёжную проверку "человечности"
• глубина (3D/ToF): уверенное отделение “лица” от плоской подделки.
Возвращаясь к видео: если мы внимательно изучим аппаратную часть представленного PoS-терминала (можем даже сходить в ближайший магазин и физически его потрогать), то обнаружим только 1 обычную RGB камеру для селфи. В таких обстоятельствах программно-аппаратный комплекс не может провести дополнительные вышеуказанные проверки и надеется только на изображение. В таких обстоятельствах, как показывает международная практика, система может верифицировать злоумышленника по чужой фотографии, видео или даже маске.
При изложенных обстоятельствах, я бы предположил, что видео более похоже на правду, чем на фейк и не рекомендовал бы пользоваться функцией "Оплатить улыбкой" пока все терминалы оплаты не будут оснащены современным техническим оборудованием.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
💥 Новое в Gramax 💥
Gramax Enterprise Server:
Корректные ссылки из приложения. Раньше ссылки на статью или каталог копировались как https://app.gram.ax/repo-name.... Теперь приложение подставляет домен вашей компании (где развернут веб-редактор), поэтому ссылки ведут в приложение в вашем контуре.
Фильтр по файлам в поиске. Добавили режимы «Без вложений», «С вложениями» и «Только во вложениях», чтобы искать не только по тексту статей, но и по содержимому PDF и DOCX-файлов.
Другие улучшения:
Автоматическое решение конфликтов в комментариях. Если несколько пользователей одновременно отвечают или редактируют один и тот же комментарий, изменения корректно объединяются и не ломают комментарии. В связи с этим в «Проверить на ошибки» появился пункт «Комментарии» — он показывает статьи с комментариями, которые не привязаны ни к одному блоку.
Улучшения поиска:
Поиск стал быстрее. Ускорили примерно в 2 раза и оптимизировали индексацию.
Обязательные слова в запросе. Добавили оператор +: поставьте его перед словом или фразой, и они точно будут учитываться в результатах.
Окно поиска по статье сохраняет состояние. При переходе между статьями окно закрывается, но при повторном открытии сохраняется введенный текст (пока приложение открыто).
ИИ-поиск стал точнее. Мы улучшили RAG, поэтому ответы в поиске стали более релевантными и полезными. Подробнее — в статье на Хабре.
Инлайн-тулбар в комментариях, сниппетах и шаблонах. Теперь над полем ввода комментария доступно базовое форматирование: жирный, курсив, код и вставка ссылок. А в редакторе сниппетов и шаблонах появился полный набор инструментов, включая редактирование таблиц.
Превью Excel-файлов. Теперь Excel-файлы можно открыть в режиме предпросмотра: при клике отображается превью в модальном окне.
Быстрая публикация. Список изменений загружается в 3 раза быстрее.
Автоматическое обновление ссылок при редактировании. Если вы меняете текст ссылки и он совпадает с ее адресом, адрес тоже обновится. Если текст и адрес разные — ссылка не меняется.
Сохранение позиции прокрутки между статьями. Если вы перешли в другую статью и вернулись назад, статья откроется там, где вы остановились, а не в начале.
Версия приложения в деталях ошибки. Это помогает быстрее понять, на какой версии возникла проблема и быстрее ее воспроизвести.
Исправление уязвимостей. Теперь перед выпуском новых версий мы автоматически проверяем используемые библиотеки на известные уязвимости.
Подробнее об изменениях читайте в статье — https://gram.ax/resources/docs/whats-new
Как перенести AI-платформу из‑за рубежа в Россию и не переписать код: кейс Worken AI
👨💻 Что за компания
Worken AI — разработчик одноименной платформы, на которой пользователи создают или выбирают готового виртуального сотрудника — Виртса. Такой сотрудник становится частью отдела продаж, поддержки или HR: он отвечает на заявки, обрабатывает заказы или поддерживает в адаптации новых членов команды.
Изначально проект строился на зарубежном облаке с прицелом на глобальный рынок, используя cloud native подход: сервисы платформы работают в Docker-контейнерах, а базы данных и хранилища — на управляемых облачных сервисах.
🚀 Задача
Когда пришли первые российские клиенты с повышенными требованиями к 152-ФЗ и локализации персональных данных, встал вопрос: как быстро и безболезненно развернуть локальный контур в России, не переписывая архитектуру? Задача звучала так:
поднять backend-сервисы и вспомогательные компоненты платформы в Docker-контейнерах, оркестрируемых Kubernetes;
отдельно разместить frontend-часть (веб-интерфейс) платформы;
подключить управляемую СУБД для транзакционных данных и векторного поиска по базам знаний клиентов;
организовать объектное хранилище для документов и других файлов, на основе которых строятся векторные представления (Vector Store) пользователей Worken AI.
Разработчику было критично, чтобы облако одновременно соответствовало требованиям 152-ФЗ и предлагало современный стек managed-сервисов и AI-инструментов.
☁️ Что сделали
Сохранив cloud native подход, Worken AI развернул российский контур платформы на управляемых сервисах платформы Cloud.ru Evolution. Основные backend-сервисы и API-шлюзы разработчик вынес в кластеры Evolution Managed Kubernetes. Для хранения данных пользователей и векторных представлений документов Worken AI использует Evolution Managed PostgreSQL, управляя только схемой базы и запросами приложения. Файлы баз знаний, вложения и резервные копии размещаются в S3-совместимом объектном хранилище. Автоматизации на базе n8n и ряд вспомогательных сервисов разработчик развернул на бесплатных виртуальных машинах. Отдельные контейнерные приложения, которым не нужен полноценный Kubernetes-кластер, запущены в Evolution Container Apps.
🦾 Что получили в итоге
Все ключевые сервисы российского контура платформы Worken AI работают в российском облаке: входящие запросы пользователей проходят через frontend- и backend-сервисы, обращаются к управляемой базе данных и объектному хранилищу, а затем — к выбранным AI-моделям.
В планах сделать работу с моделями еще проще и ускорить вывод новых сценариев в продакшен. Это возможно в цифровой среде AI Factory, где строится единый контур: готовые LLM с OpenAI-совместимым API, сервисы для инференса и дообучения собственных моделей, управляемые Kubernetes-кластеры, объектное хранилище и управляемые СУБД.
Благодаря этому Worken AI может развивать Виртсов одновременно для глобального рынка и российских заказчиков на привычном cloud native стеке, удерживая данные и модели в инфраструктуре, соответствующей требованиям 152-ФЗ и уровню защищенности УЗ-1.
Смертельный марш: почему ваш проект обречен и как в этом выжить
Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).
Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.
Генезис катастрофы: Политика, политика и еще раз политика
Йордан честен: большинство безнадежных проектов рождаются не из-за технических сложностей. Они рождаются из-за того, что кто-то наверху играет в свои игры. Маркетологи наобещали невозможное, чтобы закрыть сделку; менеджеры побоялись сказать «нет» вице-президенту; а высшее руководство живет в мире, где девять женщин могут родить ребенка за один месяц.
В этой среде вы — не просто разработчик, а участник социальной драмы. Вы знаете, что проект обречен. Вы знаете, что обещания руководства — пустой звук. Вы принимаете эти правила игры не из наивности, а потому что это текущая реальность, в которой нужно как-то функционировать.
Классификация неизбежного: В каком аду вы находитесь?
Йордан делит безнадежные проекты на четыре типа. Понимание того, где вы, определяет вашу стратегию поведения:
«Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.
«Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.
«Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.
«Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.
Принцип «Сортировки» (Triage)
Термин заимствован из военной медицины. Когда раненых слишком много, врач не спасает всех — он выбирает, на кого тратить ресурсы. В «Смертельном марше» происходит то же самое.
Вы понимаете, что 80% функционала, о котором мечтает заказчик, никогда не будет реализовано. Профессионализм здесь заключается в том, чтобы сосредоточиться на тех 20%, которые позволят системе выдать хоть какой-то результат в день релиза. Всё остальное — белый шум и декорации. Вы просто игнорируете второстепенные задачи, не тратя на них ни капли энергии, даже если менеджер бьется в истерике.
Эстетика процесса
Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».
Смертельный марш — это не про успех продукта. Это про вашу личную устойчивость в условиях тотального хаоса. Пока вы сохраняете дистанцию и понимаете, что это просто роль в плохой пьесе, вы остаетесь профессионалом.
P.S. Циатата:
Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.
Включая меня. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот.
В минувшею пятницу, 26 февраля, на площадке Кибердома прошла премьера фильма «Как получить доступ ко всему: реверс-инжиниринг».
Исходя из описания под трейлером, этот
Документальный фильм расскажет, как люди учатся вскрывать сущность комплексных технологических систем. Разбирая устройство или технологию по частям, мы получаем доступ к их структуре и замыслу создателей. Эксперты в области обсудят реверс-инжиниринг в СССР и России – от промышленности после Первой мировой до искусственного интеллекта и «киберпанка», который ждет нас в ближайшем будущем.
Я, к сожалению, на премьеру попасть не смог по причине конфликта в графике. Поэтому, чтобы "изучить материалы по теме" мне пришлось посмотреть фильм в четверг, то есть за день до его официальной премьеры!
Enumeration is the key (c) OffSec, и если хорошенько прошерстить интернет, то можно найти и посмотреть документалку без регистрации и СМС на официальном портале PREMIER: Как получить доступ ко всему: реверс-инжиниринг.
Естественно, не буду спойлерить детали, однако скажу, что фильм снят очень качественно, а в создании участвовали эксперты из Positive Technologies, «Лаборатории Касперского», Т-Банка, «Иви», SR Space, Музея криптографии, «Росатома», Elverils, интернет-проекта «Я помню» и другие неравнодушные люди и организации.
Как посмотрите, приглашаю вас в комментарии, чтобы обсудить увиденное и высказать свои мысли по поводу фильма!
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
Как перестать быть центром всех решений и не потерять контроль :)
Когда команда растет, руководитель постепенно становится обязательной точкой во многих процессах. Кажется, все логично, ведь так быстрее и надежнее. Проблема становится заметной, когда появляется вопрос: что будет, если руководитель на время выпадет из работы?
С этим столкнулась Катя, руководитель операционного отдела. Консультации, планирование дежурств и часть сложных решений постоянно замыкались на ней. Это замедляло работу, снижало самостоятельность команды и создавало риски на случай ее отсутствия.
Попросили Катю рассказать, как она пересобрала процессы так, чтобы решения не требовали ее обязательного участия, а система оставалась управляемой и прозрачной.
1️⃣ Что происходит, когда процессы держатся на одном человеке
Я пришла в Naumen в 2015 году. В 2020 у меня появилась первая команда из трех аналитиков. Через год — уже две команды. Сейчас это три команды: три тимлида, два техлида и двадцать аналитиков.
У нас закрывались задачи, клиенты получали ответы. Но по факту консультации, планирование дежурств и нестандартные решения замыкались на мне. И чем больше становилась команда, тем сильнее росла эта зависимость.
2️⃣ Три страха, которые мешают передавать процессы
Когда я решила что-то менять, сначала пришлось разобраться со своими страхами:
Я стану не нужна
Перегружу команду
Команда что-то сделает не так
Самым тяжелым оказался последний страх. Руководителю трудно осознать, что кто‑то может принять решение иначе. Но иначе не значит хуже.
А еще я поняла: если процесс живет только при моем участии — это слабое место, а не моя ценность.
3️⃣ Как мы перестроили систему консультаций
Раньше все было просто: любой сложный вопрос — ко мне. Я объясняла одно и то же разным людям, и это отнимало все больше времени.
Поэтому мы разложили консультации на типы: технические, процессные, бизнесовые. Дальше я посмотрела на реальную экспертизу внутри команды и распределила роли.
Опытные аналитики по каждой заявке
Скриптолог дня для базовых техвопросов
Техлиды для сложных техвопросов
Третья линия как финальная инстанция
В этой схеме больше нет обязательного шага «спросить у Кати» :)
Важно, что я не просто объявила новые правила. Я объяснила команде, зачем им это, и дала возможность сказать, если что‑то не работает.
В результате консультации ускорились, экспертиза выросла, а я перестала быть узким горлышком.
4️⃣ Как мы перестали тратить часы на планирование дежурств
Каждую пятницу я собирала пожелания в чате и сорок минут составляла график, учитывая личные обстоятельства и роли. Когда меня заменяли, на это уходило по два-четыре часа.
Теперь оставила себе только рамки: сколько слотов нужно закрыть и какие роли должны быть в дежурствах. Все остальное передала команде.
Мы сделали общую таблицу, где каждый выбирает удобные слоты. Если остается неудобное время, люди договариваются между собой. Через несколько минут после сообщения в пятницу график уже заполнен.
Я больше не держу в голове десятки нюансов — команда решает их самостоятельно.
5️⃣ Как быть с кризисными ситуациями
Передавая процессы команде, важно понимать: это не означает, что руководитель больше не нужен. В кризисной ситуации именно руководитель остается тем, кто подключается, принимает решения и берет на себя ответственность. Но разница в том, что кризис перестает быть повседневностью.
У нас был показательный случай: у команды одновременно отсутствовали тимлид и техлид. Младший аналитик пришел ко мне и сказал, что сам проведет встречу по планированию, потому что понимает, что процесс не должен останавливаться.
В этот момент я поняла, что эта система — уже часть нашей культуры, и она работает. Команда не ждет указаний — каждый понимает, что он часть процесса и может на него влиять.
Я не считаю этот подход универсальным. Но если есть процесс, который держится только на вас, это повод задать вопрос: это стратегическое решение или просто привычка?
Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»
Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».
Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.
1. Программист — это не «печатающая машинка»
Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.
Но программист — это не тот, кто знает, где поставить точку с запятой. Программист — это переводчик. Мы переводим смутные человеческие «хотелки» на жесткий язык логики, понятный машине.
2. Эволюция «костылей»
Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.
ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструкты чистого смысла
3. Проблема «идеального мусора»
ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.
4. ИТ-поликлиника
Представьте, что в больнице появился робот-санитар, который идеально моет полы и делает уколы. Означает ли это, что врачи-хирурги или диагносты больше не нужны? Наоборот! Теперь им не нужно отвлекаться на мытье полов.
А кого вообще не заденет? (Спойлер: Работы будет завались)
Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.
Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.
Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))
SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.
Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».
Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?
Итог
Ребята, расслабьтесь. Программирование не умирает, оно взрослеет. Уходит эпоха «кодинга ради кодинга». Наступает эпоха Качества Мышления. Теперь важно не то, насколько быстро ты стучишь по клавишам, а то, насколько структурированно ты умеешь формулировать смыслы.
ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.
Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.
Как будет выглядеть рабочий день инженера в 2029 году?
Ответ на этот вопрос можно найти в подкасте руководителя клиентской разработки RUTUBE Максима Ульянова. В гостях — Артём Арюткин, CPO платформы для разработчиков в Авито.
В этом выпуске обсуждаем, зачем компаниям нужны платформы, что важно учесть при их проектировании, для каких команд они действительно дают эффект, в чем измерять «счастье разработчика» и к каким изменениям стоит готовиться разработчикам в 2029 году.
Из выпуска вы узнаете:
▪Чем CPO в DevEx отличается от CTO и зачем платформе продуктовый подход?
▪Что входит в техническую платформу Авито и почему важен принцип iPhone для разработчика?
▪Почему онбординг — это не «приятный бонус», а одна из ключевых метрик DevEx?
▪Зачем нужна технологическая стратегия и в каких бизнесах она реально избыточна?
▪Какие метрики первыми стоит начать считать для эффективности инженерных команд?
▪Почему платформы в крупных компаниях похожи и какие этапы развития они обычно проходят?
▪Каким компаниям нужна платформа и что меняется на масштабе 100 vs 500 инженеров?
▪Почему IT-индустрия «не зрелая» и какие ответы давно найдены в других отраслях?
▪Что такое «счастье разработчика» и почему его проще всего услышать в «разговорах у кулера»?
▪Почему в эпоху GenAI платформы могут стать ещё важнее?
Приятного просмотра и прослушивания!
Больше о том, как разрабатывают медиасервисы, читайте в телеграм-канале Смотри за IT. Там делимся опытом и рассказываем о жизни в цифровых активах «Газпром-Медиа Холдинга» таких, как PREMIER, RUTUBE и Yappy.
Продуктовая разработка с агентами, замена agile-команд и роль продакт-инженера — эти и другие темы я обсудил с Юрой Агеевым, основателем ProductSense, в новом выпуске подкаста make sense.
Слушайте на удобной платформе:
> Telegram
> Mave
> Apple
> Яндекс Музыка
> YouTube
Таймкоды:
00:00 — Введение
01:58 — Личный сетап агентов, эксперименты и первые сценарии
03:34 — Почему тема агентов — это про орг. модель, а не про игрушки
06:05 — Откуда взялся Agile: ответ на рост сложности продуктов
09:10 — Идея мини-команд для быстрого тестирования гипотез с агентами
11:10 — Риски одиночки: туннельность, критика, фактор автобуса
12:05 — Платформенная команда: стандарты, «золотой путь» и «ворота качества»
14:05 — Зависимость централизации от культуры компании
16:12 — Продакт-инженер: продукт и инженерия в одном цикле
17:32 — Схлопывание ролей: инженеры учат продукт, продукты учат технику
19:33 — Практика пайплайнов в работе с агентами: сначала документация, потом код
26:03 — Контекст как главная ценность и способ удержания клиентов
29:01 — Один в поле не воин: почему запуск и масштаб важнее кода
30:28 — Можно ли доверять агентам?
33:54 — Конкуренция заставит ускоряться: когда агенты станут нормой?
35:55 — Практика внедрения агентов: выделенные пилоты и команды добровольцев
37:35 — Главные риски: стоимость токенов и деградация навыков
42:09 — Как будут трансформироваться процессы и agile-роли?
50:57 — Как правильно строить эксперимент: задачи, команды, обучение и метрики
А еще я много пишу про продуктовую разработку и управление командами в своем блоге. Так что если прониклись темой подкаста, рекомендуем заглянуть туда.
Жду, когда Cursor и Claude Code будут стоить по $2000-$3000 в месяц. Они уже заменяют джунов, но скоро под нож пойдут и миддлы, и сеньоры. А здесь простой ROI (возврат инвестиций) для компаний: не болеет, не ходит на перекуры, не выгорает, не увольняется. Соответственно, нет сопутствующих затрат. Сейчас идет этап адаптации и принятия, поэтому действуют «дешевые» тарифы по $200.
Одной из важнейших задач реверс-инжиниринга является восстановление электрической схемы. Для того чтобы полностью и на низком уровне понять, как работает устройство, необходимо не только его разобрать, но и часами "прозванивать" дорожки: берем мультиметр, включаем диодную прозвонку и начинаем устанавливать связь между элементами.
В зависимости от сложности схемы, печатная плата может быть выполнена в 1-2 слоя: тогда дорожки можно визуально "проследить", просветив их фонариком. К слову сказать, лет 20-30 назад инженеры вообще не испытывали таких проблем, так как печатные платы были формата сквозного монтажа и все дорожки были снаружи и, как правило, контрастные.
К современным сложностям восстановления схемы я бы еще отнес SMD компоненты, которые отличаются между собой разве что только цветом: черный - резисторы, коричневый - конденсаторы, синий - индукция и т.д. И так как размеры элементов достаточно малые, производители не маркируют их характеристики: соротивление резисторов, емкость конденсаторов... Для того чтобы установить характеристики, необходимо выпаять каждый SMD элемент и измерить его мультиметром, после чего запаять на схему обратно.
Ну и вишенка на торте - использование чипов, даташиты на которые отсутствуют "в природе": сколько не гугли маркировку, ничего не найдешь. В узких кругах и для избранных производитель чипов, конечно же, предоставляет документацию. Но нам, как аппаратным хакерам, такая роскошь не всегда доступна )
В общем, производители все делают для того, чтобы производимое ими устройство сложно было скопировать, зареверсить или ... отремонтировать.
В данном случае, у меня на исследовании ключ автомобильной сигнализации. Как можно видеть по схеме, вся электроника крутится вокруг чипа A3XA5 QFN, работающего на частоте 27.6 МГц. С учетом того, что данное устройство является элементом безопасности, в интернете ноль информации по плате, чипу, алгоритму и т.д. Но это ненадолго: я провел собственное исследование и в скором времени опубликую свои находки! Поэтому, не переключайтесь ;)
п.с. Кстати, навык восстановления схемы нередко является одним из требований к вакансии, когда вы ищите работу по +- смежному направлению. Поэтому, если вы нацелены на данную профессию, советую потренироваться на несложных устройствах.
🧠 Обязательно поделись с теми, кому это может быть полезно 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте | ⚡️Бустануть канал
Когда задача считается выполненной
Для нас, например, в работе важен результат — хорошо сделанная задача и закрытая потребность пользователя. Этого легко достичь, когда команда продумывает план действий, реализует решение и доводит его до результата, который действительно приносит пользу.
При этом у каждого в команде свое понимание того, что значит выполненная задача. Разработчик, тестировщик и аналитик оценивают результат по разным критериям — через свою роль и зону ответственности.
Мы поговорили с коллегами и попросили их рассказать, в какой момент для них задача считается завершенной. Их ответы читайте ниже.
Настя, тестировщик:
Я считаю задачу выполненной, когда функционал соответствует требованиям и критериям приемки. Для этого проверяю основные сценарии, убеждаюсь, что нет критичных и серьезных багов, смотрю, чтобы мелкие дефекты были зафиксированы и не влияли на результат.
Важно, чтобы все работало стабильно в разных условиях и было понятно пользователю. Если после проверки к задаче не остается вопросов, я считаю ее завершенной.
Ваня, системный аналитик:
Для меня выполненная задача — это структурированный и согласованный набор информации. Такой результат позволяет мне продолжить работу самостоятельно или передать задачу дальше без постоянных уточнений и дополнительных вопросов.
Поэтому важно определить стейкхолдеров: кто источник требований, кто принимает решение, кто конечный пользователь фичи. Должен быть понятен контекст — какую проблему и для кого мы решаем.
Дальше я фиксирую границы задачи: что в нее входит, а что включать не нужно. Кроме того, должен быть чек-лист для проверки кейсов при приемке.
И наконец, пункты задачи должны быть приоритизированы, а сроки выполнения — обозначены, чтобы работа двигалась предсказуемо и без постоянных возвратов к деталям.
Олег, android-разработчик:
Задача выполнена, когда:
Функциональность реализована и проверена вручную — примерно так, как это сделал бы тестировщик, но без учета конкретных тест-кейсов.
Новое поведение решает цель задачи, а не просто повторяет постановку. Иногда по ходу работы находится вариант проще для разработки/поддержки или удобнее для пользователя — выбираю его. Фича должна закрывать потребность.
Пограничные случаи поведения (corner cases) проработаны и учтены. В постановке не всегда учитываются моменты, которые становятся заметны в коде. Например, что показать на мобильном клиенте при 500 ответе сервера или при долгой загрузке из-за задержки ответа сервера.
Новое поведение покрыто тестами, есть уверенность, что его не сломают случайно. Также важно, чтобы оно не сломало существующие автотесты.
Новое поведение поддерживаемо и расширяемо: его сможет понять и продолжить другой разработчик.
Выбор вакансии: как я кинулась во всё — и это не дало результата.
Есть разработчики, у которых развитие идёт линейно и предсказуемо: верстальшик → джун фронтендер → мидл → мидл в сильной компании → сеньор/лид/уход в бэкенд
Красиво. Понятно. Логично.
Но у меня кривая черта развития сначала бэк на Java в закрытом предприятии. Потом фулстек в фудтехе: в основном Vue, но ещё и Go (и все сопутствующее), и CUBA Platform (lowcode на java, он же «Тезис»), и n8n.
Широко. Разнообразно. Интересно.
Как я начала откликаться - на всё, что блестит
И сейчас Когда я вышла на рынок, то сначала я откликалась на все что близко:
Frontend - Vue / React / Angular
Ну фронт же. Есть мнение, что «не нужно учить конкретный фреймворк — важны принципы».
Go
а почему бы нет? Знаю , умею , курсы закончены, писала на нем
Fullstack (Go или JDK + фронт)
N8N, автоматизаторы особенно с ИИ
Интересно. Растущее направление.
Lowcode платформы CUBA, тезис, WebTutor - замаскированный под фронтенд Опыт есть. Почему не использовать?
И это фатал еrror
Ошибка №1. Переключение контекста
Очень сложно переключать контекст и даже синтаксис языка - на первом собесе по TS я не смогла вспомнить синтаксис (на ум приходил только java, так как он изучался более долго и в закрытой среде, ирония: хоть я на нем и не пишу, но разбуди среди ночи - код напишу)
Ошибка №2. Рынок
Рассматривать вакансии на Angular, React без опыта в продакшене - на данный момент наивно.
Рынок перегрет:
- Vue ~ 1000 откликов за неделю,
- React - 4000 ,
Неужели Арина (или тот кто читает эту статью) ты думаешь, что кто-то будет рассматривать ваше резюме со Vue? Каким бы в целом хорошим инженером вы не были. Рынок не покупает «в целом».
Ошибка №3. Fullstack со связкой Go + Vue или JDK + Vue
Фуллстеки со связкой go или jdk - это бред вакансии, это карьерный тупик.
- PHP + Vue - норм
- Node + Vue - норм,
но Go + Vue - это нонсенс, это только подработка для поддержания штанов. Чаще это небольшие команды, поддержка, нестабильные проекты.
Ошибка №4. n8n — нравится, но это уже не совсем разработка
Автоматизация, интеграции, AI — это интересно. Но это больше аналитика и orchestration, чем классическая инженерия. Если хочешь быть разработчиком — нужно понимать, куда ты смещаешь фокус.
Ошибка №5. Low-code — карьерный тупик
Проблем с окружением больше. Кода меньше. Рынок уже. Ты становишься зависимой от конкретной платформы. И выйти обратно в «чистую разработку» становится сложнее.
Мой Hotfix: Фокус
Я поняла, что на падающем рынке выживают либо "универсалы" c ИИ подбоком, либо эксперты
Моя новая стратегия:
Vue 3 + TypeScript + Nuxt (как зона роста)
n8n — как подработку и интересный дополнительный навык.
Иногда рост — это не добавить ещё стек. А убрать лишнее.
Стоит ли давать разработчику второй шанс? Кейс об «эффекте бумеранга»
Год назад мы расстались с разработчиком. Причины были классическими: просела скорость, пропал фокус, исчез драйв, перформанс ближе к нулю. Решение об увольнении было непростым, но на тот момент честным для обеих сторон. Процессы в моей кросс-функциональной команде требуют высокой вовлеченности, и «пассажиров» мы себе позволить не могли.
Недавно он написал снова. За этот год человек успел закончить вуз, сменить обстановку и, по его словам, переосмыслить приоритеты. Он хочет вернуться.
В такой ситуации тимлиду важно отделить эмоции от управления.
Второй шанс — это не про «пожалеть» и не про «наказать». Это холодный расчет изменившихся условий. Прежде чем принять решение, я задаю себе вопросы:
Что изменилось в его ресурсе и фокусе?
Появилась ли внутренняя мотивация вместо внешней?
Готов ли он брать ответственность за результат, а не просто закрывать тикеты?
Иногда люди действительно перерастают свой прошлый этап, совершают качественный скачок. Иногда — нет, и тогда система просто воспроизведет прежний негативный результат.
Для меня критерий прост: изменились ли вводные данные настолько, чтобы математически ожидать другой исход?
Как руководитель, я отвечаю не только за конкретного человека, но и за микроклимат и перформанс всей команды. Решение о возврате должно быть выгодным для проекта, а не просто актом доброй воли.
А как вы относитесь к «бумерангам»? Стоит ли входить в одну и ту же реку дважды, или в ИТ это не работает?
Плагин Tasks. Часть 1
Этот плагин лежит в основе моей системы планирования.
Представляет собой простой, но мощный инструмент для работы с задачами.
1. Создаём в заметке задачу:
- [ ] Задача
2. Появляется выпадающее меню, в котором можно назначить даты начала и завершения задачи, выбрать приоритет.
3. С помощью палитры команд или горячих клавиш открываем расширенные настройки. Там можно сделать задачу повторяющейся.
💬 Больше про ведение заметок и планирование в Obsidian в моём тг-канале
Разработчик публично сообщил, что ему не нравится обновление для Obsidian, но не рассчитал свои силы. В реплаи пришёл CEO проекта и по-русски написал, что разработчик просто «не прочитал документацию». Ответ разработчика: да, я реально её не читал.
