В общем, тривиальная ситуация — пишу коллеге в рабочий чат с целью уточнить сроки по проекту. Вроде коротко и по делу, без всяких подтекстов: «А ты уверен насчет пятницы?». Я имел в виду буквально: есть ли у нас полная уверенность, что дедлайн реален, не подведет ли нас что‑то, давай уточним этот момент. Потом я на что‑то отвлекся, через время захожу в чат, а там с десяток сообщений. Коллега решил мне объяснить (это я в общих чертах пересказываю), что он вообще‑то ответственный человек, что все будет как надо и зря я его так. Я перечитал свое сообщение раз пять. Где? Вот где там был упрек? Три слова и вопросительный знак. 

В общем, я задумался, как так выходит. Текст же вроде имеет фиксированное значение. Это не устная речь, где можно сослаться на тон. Это буквы, одинаковые для всех. Откуда такой разброс интерпретаций? И я решил кое‑что почитать по теме, и вот чего узнал. 

Во‑первых, меня заинтересовал тот факт, что мы привыкли думать, будто глаз плавно скользит по строчке и считывает каждую букву. А вот и нет. На деле все несколько… странно.

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

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

Почти каждое бытовое действие - это набор маленьких решений. Что надеть, что приготовить, когда стирать, сделать сейчас или отложить. Встречалось мне в психологической литературе такое понятие - усталость от принятия решений (Рой Баумайстер). Смысл в том, что ресурс на принятие решений ограничен, как у батарейки, и по мере его расходования нам становится сложнее выбирать и держать фокус. На уровне повседневных задач, как мне кажется, он проявляется довольно ярко. К вечеру даже простой выбор из двух вариантов начинает раздражать.

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

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

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

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

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

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

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

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

Начну, пожалуй, с прописной истины. Мы все разные: кто‑то громкий и напористый, кто‑то — тихий и сдержанный. И в этом многообразии нет ничего плохого, пока эти особенности не мешают общему делу. Но иногда случается так, что даже классный специалист неосознанно начинает действовать во вред себе и окружающим. Его модели поведения (будь то агрессивная критика или полное погружение в себя) медленно, но верно создают барьер на пути его же карьеры. Давайте попробуем разобраться, почему так происходит и что с этим можно сделать. 

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

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

Привет, Хабр! А давайте поговорим о том, как быть, когда спать некогда, ибо дедлайн близок.

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

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

Я — бизнес‑аналитик Рексофт, работаю в проектах по разработке ПО уже более 5 лет, а суммарно в ИТ сфере более 15 лет.

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

Со мной такое было. Вот, например, мое яркое воспоминание, как я была на конференции и, подойдя к зоне отдыха, у меня было три задачи: налить себе кофе, не расплескать его и, собственно, с кем‑нибудь познакомиться. С первыми двумя я справилась, на третьей забуксовала. Я стояла и думала: «А вдруг человек не хочет разговаривать? Может быть, он занят? Может, устал? А что он вообще обо мне подумает?». В итоге я так и не подошла. 

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

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

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

(Потом, конечно же, никто ничего не почитал.) 

И вот скажите, как вы думаете, сколько из этих ваших открытых вкладок увидят свет в ближайшие… дни? Недели? 

Бардак этот и мешает, и раздражает. Дело даже не во вкладках. На самом деле это ведь только макушка, как говорится, айсберга. А если поковыряться по всем приложениям? Сотни нечитанных сообщений в мессенджерах. Неразобранные не слишком важные задачи в таск-трекере. В личную почту вообще заходить страшно, а уж если там что-то надо найти… И, кстати, это все неплохо так подрывает мотивацию и портит рабочий настрой. Заметил, что, кажется, даже устаю от этого больше. Каждый раз преодолевать эти завалы практически подвиг.  

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

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

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

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

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

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

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

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