У нас суперновость. Билеты на RUNIT 2025 уже в продаже: https://runit.digital

До Нового года осталось всего ничего, а значит, пора строить планы на 2025-й. Поэтому мы решили уже сейчас открыть регистрацию на следующий фестиваль IT и спорта RUNIT.

Пока выбираем оптимальную площадку и дату, но точно можем сказать: всё пройдет летом. И мы 100% учтем расписание крупных IT-конференций, чтобы вы могли везде успеть.

Что будет по-новому:

- теперь регистрируемся сразу в RussiaRunning — так вы сможете сами управлять регистрацией через личный кабинет;

- заявки от компаний и команд ждем на почте runit@agima.ru — для каждого участника тоже создадим личный кабинет;

- заказать гравировку на медали также можно заранее — такая опция на сайте RUNIT уже доступна при покупке билета.

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

Так что готовим телегу зимой и планируем лето. Следить за новостями можно в телеграм-канале RUNIT.

Какими бывают лидеры в IT и почему они тоже выгорают: https://clck.ru/3FSULp.

Недавно на митапе про управленцев в IT мы вместе с бизнес-тренером Алексеем Кельиным разбирали его исследование об органичном лидерстве. Оно, по сути, отвечает на вопрос: «Как руководителю найти органичный подход к лидерству, чтобы не выгорать и уберечь от этого своих сотрудников».

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

Статья точно будет полезна СТО, руководителям IT-департаментов, руководителям IT-рекрутмента, IT-лидам и CPO — всем, кто отвечает за управление и развитие команд в IT.

Читайте текст на Хабре по ссылке выше и делитесь им с коллегами.

Нанять нельзя вырастить: стоит ли прибегать к аутстаффингу, чтобы найти лидера для IT-команды? https://clck.ru/3FiaCS

Инвестировать время и ресурсы в выращивание лидеров внутри команды или оперативно найти готового специалиста через аутстаффинг? Секрет в том, что и тем и другим подходом можно умело пользоваться, если знать как.

Руководитель Outstaff-направления AGIMA Константин Мовчан поделился с редакцией «Бизнес-секретов» критериями успеха для обеих стратегий найма.

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

Читайте материал по ссылке выше и делитесь своим мнением в комментариях!

Глава Sonos ушел в отставку после провального запуска приложения

Генеральный директор Sonos Патрик Спенс, который руководил компанией более десяти лет, объявил о своей отставке. Причиной стало катастрофическое обновление мобильного приложения, которое привело к огромным финансовым потерям и утрате доверия клиентов.

Под руководством Спенса Sonos выросла из небольшой компании в многомиллиардного производителя беспроводных наушников и колонок. Однако несколько месяцев назад всё пошло не так: выпуск полностью переработанного приложения на Flutter в «сыром» состоянии обернулся провалом.

Что пошло не так?

- Новое приложение сделало существующие продукты практически бесполезными.
- Пропали базовые функции, например одновременная регулировка громкости на нескольких колонках.
- Пользователи столкнулись с проблемами подключения и стабильности.
- App Store наводнили негативные отзывы, которые позже были удалены.

Спенс попытался спасти ситуацию и выпустил видео с извинениями. Но этого оказалось недостаточно. Он покинул пост с выходным пособием в $1,8 млн, что считается скромной суммой для CEO, который построил компанию с миллиардной капитализацией.

Технические причины провала

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

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

Разработчики не смогли (или не успели) должным образом протестировать и стабилизировать все новые функции, что привело к многочисленным проблемам со связью. Итого неготовность продукта к релизу и давление со стороны руководства сыграли роковую роль.

Что дальше?

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

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

Как обновить Битрикс методом миграций

Что потребуется прежде всего:

✅ Убрать ядро (папка /bitrix/) под гит, например, завернуть в сабмодуль.
✅ Отдельная тестовая площадка с отдельной и актуальной БД.
✅ Скрипт для очистки лога запросов в БД (архив прикреплен).

Дальше идем по процессу:

1. Переходим на тестовую площадку.
2. Включаем режим отладки БД:

//bitrix/php_interface/dbconn.php
 
$DBDebugToFile = true;

3. Заходим на страницу обновления платформы и запускаем обновления: /bitrix/admin/update_system.php?lang=ru.
4. Очищаем лог-файл от лишнего с помощью скрипта.
5. Готовим миграцию.
6. Пушим всё в гит.
7. Выкатываем на прод изменения и запускаем миграцию.

Как подготовить миграцию

Файл mysql_debug.sql с логом изменений в БД довольно большого размера >50Mb. В нем есть и запросы, и время их выполнения, и stacktrace — в общем, много лишнего. Скрипт всё это вычищает и оставляет только запросы: в итоге вместо ~100Mb мы можем получить, например, ~300Kb.

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

📌Как работать со скриптом описано в файле readme в прикрепленном архиве.

Дальше берем очищенный файл и начинаем миграцию. Для этого отлично подойдет модуль sprint.migration:

🔹 Если запросов достаточно много (особенно, если вы обновляете несколько мажорных версий за раз), то хорошо бы разбить файл на чанки — по 50 запросов в 1 чанке.

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

Финальный шаг

Когда вы всё обновили, зафиксили, подготовили миграцию и запушили в гит, проверьте всё еще раз. Тут рекомендуем проверить работу миграции на чистой площадке с БД до обновления. Если всё ок, то можете планировать обновление stage/prod окружений.

И помните: у самурая нет цели, только путь! 😉

Фон — это не просто бэкграунд, а важная часть дизайна, которая задает стиль и влияет на восприятие сайта. Делимся классной подборкой эффектов для фона на CSS — целых 40 вариантов: https://prismic.io/blog/css-background-effects.

В подборке куча категорий:

- кастомные фоны на CSS;
- градиенты;
- эффекты скролла;
- узоры и текстуры;
- SVG-эффекты;
- и другие крутые решения.

Еще отдельно выделены генераторы и разные библиотеки.

Можно взять готовый эффект или вдохновиться идеями для своих проектов. В общем, загляните!

Ссылочка: [тык]

Семь ключевых ошибок тимлида (и как их не допускать): https://habr.com/ru/companies/agima/articles/884270/

Все тимлиды на заре карьеры встают на одни и те же грабли: кто-то начинает делать задачи вместо команды, кто-то ставит ТЗ как попало, а кто-то напрочь игнорирует техдолг.

Чтобы не допускать подобных ошибок, тимлид нашего отдела PHP Артем Валевич составил для себя что-то вроде кодекса, в котором перечислил самые вредные установки руководителя.

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

💧NiFi Registry а-ля Git

Если вы работаете с Apache NiFi, то, скорее всего, сталкивались с проблемой контроля версий потоков данных. Здесь на помощь приходит NiFi Registry — инструмент для хранения, восстановления и управления версиями потоков. А с недавних пор появился способ контроля версий через Git. Давайте разберемся, как с ним работать и какие альтернативы есть у разработчиков.

Настройка родного реестра NiFi Registry

Для хранения версий потоков используется отдельный сервис реестра. Устанавливаем его рядом с NiFi, например, в контейнере (можно найти на просторах DockerHub с инструкцией установки и параметрами), открываем его Web UI по адресу http://localhost:18080/nifi-registry и создаем в настройках бакет — основную единицу для хранения и управления версиями.

Далее в NiFi настраиваем клиент реестра: Controller Settings -> Registry Clients, выбираем NifiRegistryFlowRegistryClient и устанавливаем настройку URL с адресом, прописанным до Web UI реестра: http://localhost:18080/nifi-registry. Теперь можно подключать процессорные группы к реестру через Version Control, выбирая бакет и имя версии. После коммита в реестр появится JSON-файл, а в интерфейсе NiFi — зеленая галочка, подтверждающая сохранение версии. Если внести изменения, можно откатиться к предыдущей версии или продолжить разработку.

Это похоже на Git с коммитами, пулами и возможностью клонировать потоки из реестра — разница в том, что в NiFi Registry можно подтянуть конкретную группу процессоров, а не весь проект целиком.

GitLab как хранилище потоков

Альтернативный подход — хранить версии не в родном реестре, а в Git-репозитории (например, GitLab). В этом случае вместо NiFi Registry используется контроллер GitLabFlowRegistryClient. Настройки схожи: указываем URL репозитория, access token, ветку и путь к папке с бакетами.

Важно: NiFi не умеет создавать бакеты в GitLab, поэтому их нужно завести вручную — в виде папок в репозитории. JSON-файлы потоков загружаем через git commit - push. Затем можно клонировать их на рабочий холст в NiFi и использовать.


Как выглядит процесс работы:
1. Разработчик клонирует репозиторий, настраивает GitLabFlowRegistryClient.
2. Создает ветку, разрабатывает поток, экспортирует JSON в репозиторий (bucket2/flow.json).
3. Коммитит, пушит и создает merge request.
4. Ревьюеры клонируют поток, проверяют, вливают изменения в main.
5. На боевом NiFi можно подтянуть обновленный поток из мастера.

Этот же процесс работает и с GitHub.

Продвинутый вариант: родной реестр + GitLab

Можно настроить NiFi Registry для работы с GitLab. В конфиге nifi-registry.properties подключаем GitLabFlowRegistryClient, а в самом NiFi — стандартный NifiRegistryFlowRegistryClient. Тогда реестр сам разберется, где хранить и откуда забирать версии.

В итоге, у вас есть два варианта: использовать родной NiFi Registry или хранить версии в GitLab. Оба решения удобны, а выбор зависит от архитектуры проекта и команды. Какой подход вам ближе?

Незаменимых нет: про бас-фактор, или Что делать, если Вася Пупкин уйдет

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

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

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

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

Поэтому бас-фактор — это не паранойя, а здравый смысл. Он позволяет бизнесу быть гибким, команде — уверенной в завтрашнем дне, а руководителям — спать спокойно.

А как устроено у вас? Думаете наперед или надеетесь, что ключевой человек вечно будет на своем месте?

Монолит на чистой архитектуре — зачем он вам: https://habr.com/ru/companies/agima/articles/889962/

Классная идея — завершить вторник сложной технической статьей от нашего заместителя CTO Павла Лукьянова. Он как раз рассказал на Хабре об опыте работы с чистой архитектурой.

В тексте всё самое важное:

- зачем вообще выбрали такой подход;
- как он себя показал на практике;
- какие паттерны использовали на проекте;
- почему аналитики не были в восторге.

Если команда разработки и бизнес-заказчик говорят на разных языках и не понимают друг друга — это точно маст-рид. Ждем по ссылке выше тимлидов и senior-разработчиков.

🤝Сила благодарности: почему важно говорить «спасибо»

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

Почему это важно

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

Как благодарить, чтобы всем было хорошо

✔️ Будьте конкретны. «Спасибо за работу» иногда звучит как формальность. Лучше сказать, за что именно вы благодарите. Детали добавляют искренности и ценности. Например: «Спасибо, что доверился интуиции, и мы наконец-то локализовали эту плавающую проблему до отправки релиза заказчику».

✔️ Не откладывайте. Благодарность имеет «срок годности». Лучше скажите спасибо сразу, чем потом, когда забудете. Например, коллега помог с авралом. Поблагодарите его в тот же день — в идеале, если уместно, в присутствии команды на очередном скрам-дейлике.

✔️ Замечайте мелочи. Важно ценить не только большие достижения, но и повседневные проявления доброты, надежности и взаимопомощи. Кто-то помог новичку разобраться с документами, взял на себя внеурочное дежурство или скинул мем после тяжелого созвона. Всё это часто остается невидимым, но хорошо влияет на командный дух.

✔️ Покажите влияние. Всегда объясняйте, как и какие действия специалиста повлияли на общую картину. Расскажите, как сотрудник помог достичь общих командных целей и/или целей проекта и компании.

Как сказал Джон Гордон: «Когда вы ощущаете благодарность, у вас нет времени на стресс».

А как у вас в команде? Есть ли культура благодарности и какие-то традиции, связанные с этим? Или считаете, что лучшая благодарность — это деньги?

ByteDance представила Lynx — новый фреймворк для кросс-платформенной разработки

Компания ByteDance, создатель TikTok, решила зайти на территорию кросс-платформенной разработки и представила Lynx. Это open-source фреймворк, который позволяет веб-разработчикам писать нативные интерфейсы для iOS, Android и веб с помощью привычных технологий.

В чем фишка Lynx
- Один код — все платформы. Не нужно писать отдельные версии для мобильных приложений и веба.
- Высокая производительность. Используются Rust и многопоточная архитектура для плавного UI.
- Нативный CSS. Можно стилизовать интерфейс так же, как в вебе.
- ReactLynx. Интеграция с React для удобного использования в веб-проектах.

Чем отличается от Flutter и React Native

ByteDance делает ставку на скорость и удобство. В отличие от React Native, здесь обещают лучшую производительность, а в сравнении с Flutter — привычный для веб-разработчиков подход без необходимости учить Dart.

Почему стоит попробовать

Если вы веб-разработчик и хотите быстро делать мобильные приложения без изучения новых языков — Lynx может быть отличным выбором. Проект уже доступен на GitHub и официальном сайте.

Делитесь впечатлениями, если уже успели попробовать Lynx.

«Через год мы можем оказаться в мире, где ИИ будет писать практически весь код», — заявил исследователь искусственного интеллекта и предприниматель Дарио Амодей на конференции Council on Foreign Relations в марте.

Заявление громкое, поэтому мы решили поговорить на эту тему с виновником холивара — ИИ в лице DeepSeek. Вот что получилось:

Как ты считаешь, разработчики останутся без работы из-за ИИ?

Вряд ли, но их роль и задачи значительно трансформируются. Вот ключевые моменты:

🔹Автоматизация рутины: ИИ (например, GitHub Copilot, ChatGPT) упрощает написание шаблонного кода, тестирование и документирование. Это освобождает время для более сложных задач, но не заменяет инженерное мышление.
🔹Усиление креативности: разработчики смогут фокусироваться на проектировании архитектуры, оптимизации пользовательского опыта и решении уникальных бизнес-задач, где требуется человеческая интуиция и креативность.
🔹Новые специализации: появятся роли вроде инженера по промптам, специалиста по интеграции ИИ-моделей или эксперта по этике ИИ. Спрос на навыки работы с ML/AI-инструментами вырастет.
🔹Эволюция, а не замена: исторически технологии (компиляторы, фреймворки, облака) не заменяли разработчиков, а повышали их эффективность. ИИ станет таким же инструментом, как и предыдущие инновации.

Какие риски и серые зоны ты видишь в разработке с применением ИИ?

Есть несколько аспектов, которые стоит учитывать:

🔹 Утрата глубины знаний: разработчики разучатся писать код без ИИ, теряя понимание основ.
🔹 Шаблонность: ИИ часто предлагает типовые решения, но не самые инновационные варианты.
🔹 Вопросы безопасности: есть риск генерации небезопасных участков кода — например, подверженных SQL-инъекциям, с плохой аутентификацией.
🔹 Этика и авторские права: возникают сложности с пониманием, кому принадлежит код, созданный ИИ, особенно если он напоминает чей-то чужой код из тренировочной базы данных.
🔹 Проблема прозрачности: как честно объяснить заказчику, что значительная часть работы выполнена нейросетью.

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

Сделайте ИИ своим напарником, а не соперником. Используйте его как ускоритель — пусть генерирует шаблоны или ищет баги, но не делегируйте ему всё. Ваша фишка — глубокая экспертиза: архитектура, нестандартные задачи и «человеческое», то есть переговоры, менторство, креатив. Учитесь там, где ИИ слаб: DevOps, кибербезопасность, этика ИИ. И да, создавайте свой open-source или блог — нейросеть не придумает вашу уникальную историю.

А что думаете вы? Доверяете ИИ в задачах, связанных с генерацией кода? Какие инструменты уже используете в своей работе?

База про жизненный цикл разработки ПО (SDLC): этапы, виды моделей и их различия:
https://habr.com/ru/companies/kaiten/articles/893866/

Тут коллеги из Kaiten выпустили статью с разбором Software Development Life Cycle (SDLC), или жизненного цикла разработки. Мы тоже поучаствовали: рассказали, как в AGIMA выстроен процесс разработки и как мы управляем командой.

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

Текст уже на Хабре — читайте его по ссылке выше.

Что делать, если разработчик работает хорошо, но очень медленно: https://habr.com/ru/companies/agima/articles/895046/

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

Наша новая статья как раз о том, как выстроить рабочий процесс, если какой-то разработчик сильно отстает от остальных. А еще о том, что это может говорить о проекте в целом.

Ее написал наш PHP-тимлид Александр Борщев. Он делится личным опытом и предлагает всем рассказывать о своих лайфхаках. Текст уже в блоге, ссылку оставили выше.

🛠 Управление техническим долгом: советы для архитекторов

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

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

Почему возникает технический долг

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

⚙️ Как управлять техническим долгом

1. Регулярные архитектурные ревью:
- Проводите встречи для оценки текущего состояния кода и архитектуры.
- Обсуждайте, какие решения можно улучшить или переписать.

2. Автоматизация тестирования и CI/CD:
- Внедряйте автоматизированное тестирование, чтобы быстро выявлять проблемы.
- Настройте CI/CD, чтобы автоматизировать деплой и снизить вероятность ошибок.

3. Документация как код (Documentation as Code):
- Поддерживайте актуальную документацию рядом с кодом.
- Это ускоряет внедрение новых членов команды и помогает избежать повторения ошибок.

4. Infrastructure as Code (IaC) и Infrastructure as Service (IaaS):
- Автоматизируйте управление инфраструктурой для минимизации ручных ошибок.
- Это позволяет быстрее масштабировать и поддерживать систему.

5. Планирование и мониторинг технического долга:
- Ведите учет технического долга и планируйте регулярное его погашение.
- Определите метрики, по которым можно отслеживать рост или сокращение долга.

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

Вопросы, которые стоит задать при оценке технического долга:

- Какие участки кода вызывают наибольшие проблемы при поддержке?
- Насколько легко новым разработчикам понять систему?
- Как часто происходят инциденты из-за устаревших решений?
- Какие расходы по времени и ресурсам связаны с поддержкой текущей архитектуры?
- Готов ли бизнес инвестировать в рефакторинг для долгосрочной стабильности?

🔥 Техдолг — это не враг, это показатель компромиссов, на которые вы шли ради скорости. Главное — планомерно работать над его уменьшением. Если делать это грамотно, снизится стоимость владения проектом, а жизнь команды станет проще.

Какие методы и процессы помогают вашей команде бороться с техническим долгом?