Технотекст

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

Первыми пошли Готики — хороши до сих пор (я из тех людей, кто больше любит третью). Потом горячо любимая Neverwinter Nights (в преддверии выхода Baldur's Gate 3), но, к сожалению, сейчас в нее играть было довольно скучно. А следом шел Морровинд — ох уж эта боевая система (miss, miss, miss).

И тут я дошел до одинокого забытого бриллианта. Игра, взбудоражившая умы и сердца подростков так же сильно, как легендарный фильм Ямакаси. После нее все заборы города были измалёваны однотипными надписями дешевой краской. И я про Marc Ecko's Getting Up: Contents Under Pressure.

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

В этой статье, созданной по мотивам выступления на DevOpsConf’25, вы узнаете о самых популярных инструментах доставки секретов из Hashicorp Vault в Kubernetes, таких как External Secrets Operator, Hashicorp Vault Secrets Operator, Hashicorp Vault Agent Injector, Hashicorp Vault CSI Provider, Bank Vaults-Vault Secrets Webhook. Для каждого инструмента будет приведён пример настройки, объяснено, как именно секрет попадает в приложение, а также мы с вами сравним их с точки зрения ротации секретов и удобства использования.

Меня зовут Михаил Кажемский, я Lead DevOps из Hilbert Team. Я в IT уже больше 10 лет и пришёл в DevOps из разработки, поэтому побывал по обе стороны баррикад. Соавтор ряда курсов для инженеров на Яндекс Практикум по направлениям DevOps, Security и Data. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.

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

Поинт мой примерно таков: со смертью (консольных) эксклюзивов пришла медленная смерть домашних консолей, что нанесло серьёзный урон по и без того нестабильной современной видеоигровой индустрии, и последствия чего нам только предстоит увидеть. Многовато слов, кажется, перегружено, но по-другому в формате одного предложения я пока выразить не сумел. И, кажется, я бы мог дальше рассуждать на эту тему сам с собой или с неприветливыми онлайн-комментаторами и собирать годами доказательства для своего тезиса, однако Гейб вместо «HL 3» решил анонсировать другую троицу: новый Steam Controller, Steam Frame и Steam Machine. И, увидев последнюю, я сразу понял — надо действовать. Это устройство было той недостающей деталью, винтиком, который идеально демонстрирует современный ландшафт индустрии видеоигр и отношения между создателями железа/игр и игроками. Но обо всём по порядку.

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

С детства я хотел иметь систему, которая бы охватывала все (или почти все) аспекты моей жизни. И главное — чтобы она тратила минимум моих усилий. Абсолютный минимум. И у меня это получилось.

Я расскажу о системе, к которой шел почти 18 лет, потому что системы GTD для обычных людей у меня не работали. Я пробовал ежедневники, Google Keep, Evernote, Notion, физическую белую доску для маркеров, делал локальный сайт на HTML, писал себе в личные сообщения и в канал в соцсетях и мессенджерах, пока, наконец-то, не дошел до Obsidian.

Картинка: prostooleh, freepik.com

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

Задача эта весьма простая и сложная одновременно, так как массив приводов требуется для создания «управляемых выпуклостей», предназначенных для чтения незрячими людьми…

Остаться в темноте... Это страшно даже представить, а ведь множество людей так и живут, и это для них суровая реальность...

Хорошо, если слух есть, а если его нет... Сложно представить, насколько осложняется коммуникация, когда пропадает зрительная составляющая в мире, где так много информации передаётся в визуальном, в частности текстовом, формате. По сути, человек остаётся изолированным один на один...

Ниже будет некоторый обзор темы, после чего, мы плавно придём к ОЧЕНЬ интересной (на мой взгляд) идее, думаю, что будет интересно!

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

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

В 1994 году, когда вся страна шла вразнос, а парламент стоял обгорелый после обстрела танками, я почему-то решил завязать с торговлей и поступить в МГТУ им. Баумана на кафедру «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроение».

То ли потому, что детство провёл рядом со Смоленской АЭС и нахватался радиоактивных выбросов от советского реактора РБМК-1000. То ли потому, что в подростковом возрасте, будучи выгнанным из 8-го класса школы за асоциальное поведение, я поступил в Брянский машиностроительный техникум. А там один из моих преподавателей хвастался тем, что подавал документы в Бауманку - нет, поступить ему не удалось, но саму попытку он считал большим достижением. Видимо, на неокрепшие мозги 15-летнего ботаника это произвело неизгладимое впечатление. И когда я заработал на дикой торговле времён распада СССР немного денег, я решил, что надо учиться в Бауманке и стать инженегром.

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

Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.

Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.

Я решил написать серию статей о том, как мы проходили этот путь: что сработало, какие ошибки допустили и какие решения реально помогли. Этот текст — первый из серии.

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

Что ж. Попробуем в этом разобраться.

У нас на слуху яркие истории про Apple и Стива Джобса, Microsoft и Билла Гейтса, Intel и Эндрю Гроува, Tesla / SpaceX и Илона Маска, Telegram / ВКонтакте и Павла Дурова, Virgin Group и сэра Ричарда Брэнсона. Но я решил расширить свой кругозор и разобрать кого-нибудь из неизвестного мне списка. Я подумал, что мир музыкального стриминга и кто-нибудь из известных исполнителей прекрасно подойдет для этой цели. Надеюсь, что мой обзор будет вам полезен и пополнит вашу копилку историй о компаниях и лидерах, а также даст почву для размышлений и действий в области строительства непобедимых брендов и компании.

Привет! Меня зовут Александр Фролов, я data scientist отдела машинного обучения в Нетологии. В этой статье я коротко расскажу, откуда взялись LLM, чем они стали сегодня, куда всё идёт и где в этом хаосе найти точку опоры.

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

Привет, Хабр! Меня зовут Николай, и я ML-инженер в команде контента в Купере,
где уже год занимаюсь задачами автоматчинга. Этот материал — адаптация моего недавнего выступления, на котором я рассказывал, как мы стараемся сэкономить бизнесу время и деньги. 

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

Привет, Хабр! С вами Максим Коровенков, DevSecOps Lead в Купер.техе. Продолжаем цикл статей про построение DevSecOps с нуля. Это большой гайд from zero to, надеюсь, hero.

Всем привет! Меня зовут Роза и я MLOps-инженер в Купере. Пока одни учат модели, а другие пытаются их запустить, наша команда строит «мост» между этими мирами — и сегодня под катом расскажу, как мы создавали нашу ML-платформу: от тренировочных стендов до продакшн-инференса, который не падает в пятницу вечером.

Отдельное внимание мы уделим тому, как выстраивать взаимодействие между разными стейкхолдерами платформы — от собственно ML-инженеров до DataOps и Security-инженеров. 

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

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

Привет! Меня зовут Александр Баранов, я аналитик данных в команде поиска Купера. Цель этого рассказа, поделиться наработками в деле оптимизации разметки текстовых данных при помощи большой языковой модели (LLM). Если после прочтения вы захотите что-то добавить или спросить, буду только рад!

В IT-сообществе только и разговоров об эмбеддингах, metric learning, косинусных расстояниях и семантическом поиске. На конференциях все хвастаются красивыми слайдами про нейросети и векторные пространства. Но если заглянуть под капот и посмотреть, что реально работает в поиске крупных маркетплейсов и e-commerce платформ, то там, как правило, он — добрый, старый полнотекстовый индекс.

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

Меня зовут Игорь Самарин, я Machine Learning Engineer из команды поиска в Купере, где уже полтора года занимаюсь проектами, связанными с векторами. В этой статье я расскажу, как на самом деле работает поиск внутри компании, поведаю о полнотекстовом поиске — его сильных сторонах и недостатках. Затем объясню специфику векторного поиска и разберу, какие именно проблемы старого подхода он решает и продемонстрирую, как обучить векторную модель на своих данных, чтобы она понимала специфику каталога. А в конце вас ждут реальные результаты из A/B тестов и небольшой панч о перспективах. 

Всем привет! Меня зовут Марина Гончарова, и я IT-проджект-менеджер в Купере.

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

Именно во второй роли я сейчас работаю в Купере. Легко ли это? Нет, но безумно интересно и драйвово!