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

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

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

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

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

Итак, если мы используем 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-фреймворки, опасаясь изучать что-то новое.

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

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

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

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

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

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

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

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

У нас вышел новый выпуск подкаста «Скрамное ИТ», и он — о таких же «динозаврах», как мы. О тех, кто некогда был счастливым обладателем компьютера с пузатым экраном и коллекционировал диски, а теперь оказался в мире, где искусственный интеллект перестал быть чем-то фантастическим. Этот разговор — не просто ностальгия по эпохе ЭЛТ-мониторов. Это попытка осмыслить головокружительную скорость изменений и заглянуть за горизонт будущего.

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

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

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

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

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

Вот вы когда-нибудь задумывались, почему, даже имея стабильную работу, квартиру и, возможно, пару седых волос, все равно не чувствуете себя настоящим взрослым?  

Нас этот вопрос очень зацепил. И мы решили разобраться, как технологии и социум изменили понятие «взрослости», почему мы не спешим взрослеть, но хотим успеха прямо сейчас? 

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

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

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

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

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

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

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

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

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

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

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

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

Собственно, спешу сообщить: у нашего подкаста новый сезон, новый формат, новое качество. В общем, все новое, только лицо старое (ну, три лица, точнее). Да, мы не сменили состав — Леонид, Савелий и я, ваш покорный слуга — Зураб, все так же в строю. Но все остальное вокруг нас сильно поменялось. Те, кто с нами уже давно, конечно, помнят наши прошлые сезоны: сначала был только звук, потом добавили картинку, и теперь мы перезагрузились полностью. Студия, оборудование, оформление, качество съемки и подхода к подготовке материалов. А главное — контент. 

Но давайте по порядку. Во-первых, мы «переехали». Теперь подкаст снимается в Москве, в профессиональной студии. Так что это не просто смена декораций, это новый уровень картинки и звука. (Приходите посмотреть, чтобы убедиться лично.) 

Говорим мы по-прежнему много и от души, но теперь у нас появились рубрики, и это не для галочки. Как нам кажется, они делают обсуждение более структурированным, динамичным и интересным. В общем, меньше воды, больше сути. Раньше было много импровизации, планы строились «на коленке», а теперь у нас есть сценарий (но и место для спонтанности осталось). Наверное, мы стали немного серьезнее (но это неточно). 

И вот, наш первый выпуск в этом новом формате... Ну, на мой (разумеется, предвзятый) взгляд, он получился отличным, как по форме, так и по содержанию. Наша первая тема — «Гуманизм vs Искусственный Интеллект. Как развивать технологии, чтобы не потерять смысл жизни?». Сильно спойлерить не буду, но вот несколько тезисов, вокруг которых разворачивалось обсуждение. 

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

Предыстория

У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что‑то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований.

За несколько итераций проведённых 1-to-1 я выяснила, что нам было бы удобно построить это следующим образом: разделиться на подкоманды согласно функционалу, который мы реализуем, и до груминга читать аналитику, разбираться, оставлять комментарии с вопросами в спокойной обстановке без строго ограничения по времени.

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

Ранее мы разбирались с основами Kafka (часть1), рассматривали, как тестировать микросервисы (часть2) и предугадывали ошибки offset explorer и kafka ui (часть 3). В этой части – так сказать, невошедшее, но полезное, что ещё можно предусмотреть при работе с брокером. 

Преимущества брокеров

Когда я готовила материал из первой части, у меня возникло несколько предположений. Мне казалось, что некоторые преимущества относятся именно к брокерам сообщений и не имеют прямого отношения к API (временное хранение данных, обмен в реальном времени, вычитка раз в сутки, отслеживание Kafka-лага). Особенно я задумалась об этом, когда разбирала пример с мобильным веб-приложением и форматами данных для Kafka (см. раздел из статьи часть1). Казалось бы — зачем Kafka, если можно просто забирать данные из БД через API?

Я решила проверить свои догадки у знакомого бэкенд-разработчика. Его первый вопрос был: «Зачем тебе как тестировщику это знать?», а потом добавил, что API можно настроить похожим образом. Но всё же я выделила два ключевых отличия брокеров: 

1. Асинхронное взаимодействие

API — это всегда запрос-ответ. Если сервис упал, мы получим 503, и данные могут потеряться. В Kafka продюсер просто оставляет сообщение в топике, и ему всё равно, читает ли его кто-то. Даже если консьюмер упал — поднимется и дочитает. 

2. Масштабируемость

В случае с Kafka это значит, что можно гибко добавлять продюсеров и консьюмеров. Данные можно переиспользовать — допустим, создать один топик для нескольких консьюмеров. Либо, что очень важно в продакшене, например, если продюсер начал слать мусор — его можно просто отключить.