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

Сегодня хотелось бы поговорить о код-ревью, но не о коде. Думаю, не я один такой, и многие замечали, что если пишешь код для себя, то спокойно (ну не всегда, конечно) переписываешь его хоть десять раз. Но как только в твой код приходит кто-то и пишет что-то вроде "сделай здесь по-другому", то у тебя запросто может полыхнуть. Ты же старался, писал этот шедевр дня три. Там какая-нибудь сложная логика, много краев, да и вообще гордишься ("я сделяль", да). А тебе прилетает список из двадцати замечаний, и хорошо если без едкого комментария. И вот ты готов биться как лев за каждую строчку. Стараешься придумать достойный ответ (возможно, даже саркастичный). Потом серия препирательств, кто правее, а в итоге вообще может оказаться, что кто-то из вас изначально чего-то недопонял в задаче. 

Собственно, к чему это я? Просто сейчас мне кажется, что код-ревью - это вообще-то не только про код. Это еще и про людей. 

Сегодня обсудим развёртывание агентов, созданных в Yandex Cloud AI Studio Agent Atelier. Atelier — это такой очевидный UI для настройки PromptTemplate для Responses API.

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

Примерно год назад наша команда загорелась идеей создать продукт, который позволил бы «поговорить с кодом». Мы, как и многие, находились под впечатлением от возможностей LLM. Казалось, что ещё немного – и нейросеть возьмёт на себя всю рутину по анализу легаси, аудиту систем и онбордингу новых разработчиков.

Мы представляли себе идеальную картинку: загружаем исходники, документацию, ТЗ в модель, нажимаем кнопку и на выходе получаем JSON с описанием архитектуры, связей, интеграций и методов. Вишенкой на торте должен был стать умный чат, в котором можно спросить что-то вроде «как у нас реализованы выплаты по убыткам?» и почти мгновенно получить ответ.

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

Но не тут-то было. Идея разбилась о суровую реальность enterprise-разработки. За несколько месяцев мы собрали коллекцию из 12 ошибок, которые едва не похоронили наш проект Code Scope (именно так мы назвали решение). Сегодня расскажу о пяти, на мой взгляд, самых показательных. Спойлер: в итоге наш код на 99% состоит из «инженерии», и только 1% – это тексты промптов.

Ошибка 1: Один запрос обо всём

Мы начали красиво. Взяли внутреннюю систему, написали «классный» промпт и попросили LLM вернуть все возможные факты о коде в виде структурированного JSON-объекта: описание методов, интеграции, точки входа, расчёт метрик и так далее. 

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

Итак, тема у нас сегодня вроде бы избитая, но ее актуальности это никак не отменяет. Синдром самозванца в ИТ. Когда у тебя нормальный опыт, нормальные проекты, но внутри все равно как будто бы ощущение, что это просто случайно. Что скоро все догадаются, что не такой уж ты крутой специалист, каким казался сперва, и прогонят поганой метлой. И, по крайней мере для меня, интересен здесь не сам факт существования такого явления (на мой взгляд, спорить с тем, что это имеет место быть, как минимум странно), а то, как оно вообще устроено и как влияет на то, что мы в итоге делаем. Статья эта, в общем-то, в основном состоит из размышлений, предположений и моих личных выводов, с которыми вы имеете полное право не соглашаться и даже аргументированно возражать. 

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

В этой статье я хочу рассказать о том, как и зачем мы в «Рексофт» строили интеграционную платформу BRAIN ERM, которая объединяет HR бизнес-процессы, проектное управление и финансы в одной экосистеме.

Итак, довольно часто возникает потребность в том, чтобы прикинуть, допустим, ресурсы на новый проект. А вот тут возникает сложность. И она ведь вовсе не в отсутствии инструментов. Обычно их даже слишком много: табеля отпусков, оценка эффективности, постановки целей для дальнейшего развития сотрудников и так далее. Данные о людях размазаны по десятку систем, а общая картинка складывается с трудом. И в какой-то момент мы решили, что нужно собрать этот пазл в единое целое. Платформа BRAIN ERM стала ответом на возрастающие потребности рынка в комплектных инструментах для управления персоналом и бизнес-процессами компании. 

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

Плюс к тому - высокая стоимость всего HR‑цикла. Найм, адаптация, обучение, оценка, увольнение. На каждом этапе мы теряем время и деньги. И главное - нет системной работы с талантами. Люди, которые могли бы стать лидерами, уходят просто потому, что их проблему заметили только тогда, когда они уже написали заявление.

Всем привет! Сегодня я расскажу, как мы переводили наши Java-команды на новые рельсы.

Проблема:

В прошлом год стало ясно, что покупать лицензии Intellij IDEA проблематично. Предложения с ресурсов вроде «Авито»выглядели сомнительно и небезопасно. И российский рынок разработки очень плотно занялся переездом на свои решения, заказчики требовали использовать сертифицированное по местным реалиям ПО и все такое прочее. О переезде на новую среду не говорил разве что кто-то совсем уж ленивый.

С чего мы начали:

Изучив заново рынок, мы (я и другие лиды, которым на плечи легла эта ноша) стали анализировать доступные решения. Пишем мы чаще всего, используя Spring Framework и технологии около него, хотя иногда и вынуждены адаптироваться к конкретным пожеланиям заказчика и рекомендуемым им технологиям. Но фокус-группа акцентировала внимание вокруг Spring.

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

Некоторое время назад я заметил, что #архитектура создаваемых решений сама собой структурируетcя в конвейер-пайплайн, например что-то вроде. Термин, кстати, идёт от БЭСМ-6.

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

Сейчас я переживаю бурный месяц в клауде. И с клаудами связан один интересный вопрос. Ресурсы в веб-консоли управления собраны по типам: базы, контейнеры, функции, джобы/флоу, бакеты/их фолдеры, и т. п. И возникает проблема навигации среди них. Целый день щёлкаешь по табочкам, ищешь объекты по спискам… (Кстати, надо будет перечитать что-нибудь вроде этого).

Workflow Automation be like

Сегодня пост для тех, кто не наигрался в пошаговые стратегии: о Yandex Cloud Serverless Integration Workflows. Нетрудно догадаться, что это представитель обширнейшего поля Workflow Automation Tools, eg OSS: Apache Airflow/Hop, n8n to name a few. Но YC Wokflows не Open Source, конечно же. Окей, ближайший аналог, скажем, AWS Step Functions.

Одна из его характерных особенностей — использование JQ как одного из краеугольных камней. Прямо скажем, не Yandex's vibe 🚲 ⛔. Не могу сказать, что было легко с JQ, нахлынули какие-то воспоминания об XSLT (не кликайте, не надо!). В целом, конечно, работает, но у любой абстракции существует критическая точка взаимодействия с реальным миром: по отдельности $global, Foreach и сложные шаги, например, работают замечательно, но их комбинация пока является крайним случаем, где всё не совсем очевидно.

Рассмотрим пример простого вызова языковой модели:

Сегодня хотелось бы затронуть тему мотивации. Но не в целом и вообще, а в определенном процессе, который многим разработчикам знаком. Я говорю о долгосрочных проектах. Очевидно, что, когда изо дня в день, из месяца в месяц, из года в год пилишь один и тот же проект, как бы он тебе ни нравился поначалу, ты устаешь от однообразия и рутины. Даже если проект очень-очень хороший. И со временем становится сложно сохранять былой запал и писать код, как говорится, от души и с огоньком в глазах. Бесконечная вереница однообразных задач, которые решаются на все тех же инструментах – не самый лучший мотиватор.

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

Как же так получается вообще? Ты в долгоиграющем проекте. Проект жив-здоров, тебе в нем платят вполне приличную зарплату. Собственно, и что не устраивает-то? Стабильность – это же хорошо. Но проблема таки есть, гложет. И виной тому, как мне кажется, три основных фактора.

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

В предыдущей статье мы говорили о текстовом поиске, а в сегодняшней я расскажу о векторном (семантическом) поиске.

Итак, если мы используем OpenSearch, в Yandex Cloud представляется логичным использовать модели вложений этого же облака.

Этот код можно запустить как Python Cloud Function. Написан он исходя из того, что в каталоге сервисного аккаунта, под которым запускается функция, доступна модель вложений (embedding). Детали подключения к кластеру описаны в документации.

Рассмотрим один крайний случай: если мы подключаемся, указывая FQDN DATA-узлов, у которых не включен публичный доступ, то функция должна запускаться в сети кластера OpenSearch, иначе они будут недоступны. Альтернативные варианты: подключаться через «Особый FQDN» или узел DASHBOARD с публичным доступом.   

Код создаёт тестовый индекс с текстовым и векторным полем, явно вызывает embedding model через REST API, создавая векторы вложений для документов и запроса, и выполняет векторный поиск, демонстрируя способ интеграции. Обратите внимание на способ выбора разных моделей для документов и запросов.  

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

Сегодня предлагаю обсудить Managed OpenSearch Yandex Cloud. Поговорим о том, как автоматизировать управление кластером, чтобы сократить расходы на разработку, и как улучшить качество поиска на русском языке, используя доступные в сервисе инструменты морфологии.

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

Команда подкаста «Скрамное ИТ» снова на связи. И на очереди наш новый выпуск, в котором мы, два его ведущих Зураб и Савелий, обсуждаем айтишные стереотипы. Да, нас стало на одного ведущего меньше, но, как я уже сказал, его место занял немногословный коллега. И знаете, его молчаливая мудрость и тонкая ирония задали тон всей беседе. 

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

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

Классическая ситуация:

«Я данные отправил!»

«А я не получил!»

«А они зависли где-то, потому что формат не тот!»

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

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

Я ведущий Java-разработчик в компании «Рексофт». Помимо основной работы, я преподаю в вузе. И при подготовке к занятиям мне постоянно приходится готовить презентации и сопутствующие материалы. Именно о том, как упростить этот процесс, и пойдет речь.

Что не так с классическим Power Point?

Когда готовишь материалы для обучения программированию, Power Point превращается в идеально подогнанную сковородку, на которой мучительно жарится преподаватель. Как вставить фрагмент кода? А чтобы была подсветка синтаксиса? А что, если студентам надо скопировать кусок кода, а вставляются дополнительные символы? И на сладкое: как быть, если слайды надо переделать или поменять темы местами в разных презентациях?

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

В текущих условиях удаленки возможностей поблагодарить коллегу сильно уменьшилось.
И мы увидели потребность в удобном инструменте для обмена словами поддержки и признательности.

Так и родилась идея «Портала Благодарности», который недавно отпраздновал свой второй день рождения. 

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

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

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

Это подкаст «Скрамное ИТ», и у нас готов новый выпуск. Сегодня разбираемся, как за несколько лет изменились правила нетворкинга, почему удаленка и ИИ перевернули привычные схемы общения и как теперь выстраивать профессиональные связи. 

Вот представьте: вы пишете в мессенджер коллеге четкое и вполне дружелюбное (по-вашему, разумеется, мнению) сообщение, а в ответ получаете ледяное «ок» или и вовсе улавливаете между строк враждебный подтекст. Возможно, даже несуществующий. Но осадочек-то, как говорится, остался. Бывало такое? Казалось бы, наоборот, сейчас нетворкинг должен был стать проще, когда все сидят в зоне своего личного комфорта на удаленке, а на деле он превратился в новую сложную систему и порой напоминает прохождение мудреного текстового квеста с неочевидными правилами. На эту тему побеседовать с нами и пролить свет на современные профессиональные связи согласилась Александра Стадник — DevRel лид с большим опытом в IT и наш хороший друг. 

Сейчас я вкратце расскажу, что именно мы успели обсудить, ну а для тех, кто уже готов смотреть/слушать – вот ссылки на сам выпуск YouTube, Rutube, VK Видео, Аудио-подкаст.

Итак, в этом выпуске мы разбираем, во что превратился нетворкинг. Сильно ли поменялось общение за последние 5-7 лет? Живое рукопожатие в большинстве случаев теперь невозможно, зато практически у каждого есть свой QR-код (и даже не один). Первое впечатление о кандидате при найме складывается по его постам в соцсетях. Написать простое сообщение, которое точно правильно поймут, — это теперь почти искусство, и тут нет места случайным смайликам и недосказанностям. И почему голосовые сообщения и «кружочки» спасают общение с одними людьми, но ужасно раздражают других? 

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

В этой статье речь пойдет об интересной задаче на одном из моих проектов. Он был разработан на React для документооборота сотрудниками. Так уж вышло, что со времен старта проекта основным текстовым WYSIWYG-редактором был небезызвестный Jodit. За долгие годы было написано много кастомных плагинов, например, для работы с упоминаниями сотрудников, и нас устраивала его надежность, хоть его внешний вид был далек от идеала.

И вот однажды заказчик пришел с запросом:

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

А вы интересуетесь современными возможностями CSS и HTML? Может, некоторые из вас думают, что нового там ничего не появится или что свежие фишки не поддерживаются браузерами? Это мнение давно устарело. Современные HTML и CSS позволяют реализовывать интерактивные элементы, которые раньше были доступны только с помощью JavaScript. Можно сказать, что границы между разметкой, стилями и программированием постепенно стираются.

На написание этой статьи меня подтолкнуло большое количество новых возможностей в современных HTML и CSS, да и не только современных: некоторые приёмы, о которых знают немногие, поддерживались ещё со времён IE. Многие по привычке используют готовые UI-библиотеки или CSS-фреймворки, опасаясь изучать что-то новое.

Я собрал компиляцию полезных практик и оформил их в сокращённом текстовом виде.

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

Это снова мы, подкаст «Скрамное ИТ», и у нас готов новый выпуск! 

Вы когда-нибудь пытались применить ИТ-логику в личной жизни или распланировать отпуск как рабочий проект? Если да, то этот выпуск точно для вас. Мы поговорим о том, как ИТ-мышление выходит за пределы работы и начинает управлять нашей жизнью — со всеми вытекающими последствиями. 

На этот раз нашим гидом по теме стала Юлия Уварова.

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

Сегодня я хочу поговорить о лени. Точнее о том, что мы часто за нее принимаем – о прокрастинации. Решил я разобраться, как (и почему) она работает и что с этим вообще делать (в моем конкретном случае). Я не буду рассказывать о видах, типах и классификациях прокрастинаторов. Эта информация широкодоступна, основное можно прочитать, допустим, на Википедии. Я напишу исключительно о том, как справился я и что мне помогло.  

Начну немного издалека.