Разработка

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

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

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

Вы когда‑нибудь мечтали стать лучшей версией себя? Моложе, красивее, идеальнее… А вот LoRA уже стала!

Меня зовут Вера Соболева, я научный сотрудник лаборатории FusionBrain Института AIRI, а также стажер‑исследователь Центра глубинного обучения и байесовских методов НИУ ВШЭ. Cегодня я расскажу про наше свежее исследование T‑LoRA: Single Image Diffusion Model Customization Without Overfitting. Мы с коллегами придумали эффективный способ как файнтюнить диффузионные модели с помощью LoRA всего по одной картинке. 

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

Хорошая новость: эту задачу можно решить, копнув поглубже в свойства диффузии! В этой статье я расскажу, как это сделать.

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

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

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

Привет, Хабр! Одна из задач при управлении роботами-манипуляторами – расчет обратной кинематики. Данный вид кинематики позволяет вычислить углы наклона суставов робота (joints) таким образом, чтобы захват (grip) робота пришел в заданные трехмерные координаты с правильным углом наклона. Для многих роботов уже есть алгоритмы и формулы вычисления обратной кинематики, мы (команда Zebrains) столкнулись с отсутствием готового решения для робота xArm 2.0.

В статье мы подробно опишем с какими сложностями столкнулись при управлении данным роботом, как получили формулы для расчета двух видов кинематики для данного робота и поделимся кодом на C++. В проекте использовался ROS2, ноды которого были написаны на C++.

«Дайте мне качественный датасет, и я переверну Землю!» — возможно, так перефразировал бы свою крылатую фразу Архимед, доведись ему тренировать современные LLM. Хороших наборов данных в открытом доступе не так много, а собрать свой — задача не из простых. О популярных способах сбора данных для датасетов, связанных с этим рисков и о решении, которое мы используем в YADRO, сегодня и поговорим. 

Привет, Хабр! На связи команда PT Cyber Analytics. Мы подготовили для вас материал по устройству и безопасности современных беспроводных сетей. В его основе — результаты проведенных проектов и экспертиза наших исследователей.

Представьте, что вы вернулись в 1995 год. Там, где вместо гигабитных скоростей — dial-up, вместо Netflix — видеокассеты, а Wi-Fi — это магия, передающая данные со скоростью всего лишь 1–2 Мбит/с. Сейчас все иначе: беспроводные сети — от домашнего Wi-Fi до корпоративных инфраструктур, поддерживающих сотни устройств одновременно, — стали неотъемлемой частью нашей цифровой жизни.

Когда компания только начинает проект по внедрению SIEM или подключению к SOC, разговор обычно крутится вокруг выбора вендора и сценариев корреляции. А вот о EPS (events per second) вспоминают редко. И зря: от этой метрики напрямую зависит эффективность обработки событий и, как следствие, надежность всей системы защиты.

EPS — это количество событий, поступающих в систему мониторинга каждую секунду. На практике с этим показателем всё неоднозначно: одни клиенты SOC рассчитывают его «на глаз», другие ждут, пока этим займется интегратор, а те, кто внедряет SIEM своими силами, часто просто делят общее число логов на количество систем — и в итоге получают цифры, мало похожие на реальность. Между тем, точный расчет EPS на старте способен сэкономить миллионы рублей и спасти от ситуации, когда система захлебывается от потока событий, а часть логов не доходит до SIEM.

В этом гайде мы разберем:

• почему компании полезно знать свой EPS;

• как этот показатель влияет на архитектуру SOC и стоимость лицензирования SIEM;

• как определить свой EPS без «угадывания на глаз» и ошибок в расчетах;

• и, наконец, что стоит спросить у провайдера SOC, прежде чем подписывать договор.

## Всем привет!

В этой статье я хочу рассказать о небольшой расширении, которое упрощает хранение и использование feature toggles, работающих через cookie.

Наши фича-тоглы работают по принципу указания ключа и значения в cookie. Однако при тестировании (и не только) возникает несколько болей:

* Количество тоглов уже перевалило за сотню, и хранятся они в Confluence. Постоянно ходить туда или держать их названия в голове — то ещё удовольствие.

* Тестирование на фичевых ветках осложняется тем, что из-за разных доменов UI и API невозможно авторизоваться: cookie не проставляются автоматически. Чтобы их добавить, приходится заходить на мастер-ветку, брать оттуда cookie и вручную подменять домен. Не страшно, если речь идёт об одной-двух куках, но когда их больше десяти — это уже боль.

* Просмотр результата на проде тоже не всегда прост: фича-маппер не позволит просто так поменять значение cookie и вернёт исходное.

Чтобы упростить жизнь, был создали Fookie — инструмент, который позволяет хранить, выгружать, загружать, добавлять, удалять cookie и многое другое.

Разберём всё по порядку 👇

---

### Как появилась идея

Изначально задумывалось, что Fookie будет хранить информацию о feature-флагах и менять домены.

Цель — чтобы пользователь мог зайти на страницу в Confluence, нажать кнопку «Обновить», и все фича-флаги подтянулись бы в расширение. Также одной кнопкой можно было бы заменить домен у всех кук на странице.

Первая версия Fookie была неказистая, но рабочая — а это главное. Уже тогда можно было:

Как защитить свой VDS сервер: 53 000 попыток взлома за 5 дней

Представьте себе: вы арендовали скромный VDS, чтобы поэкспериментировать. Ничего грандиозного — пара тестовых сайтов, простенький веб-сервер на nginx, пара скриптов в cron для автоматизации рутины, SSH для удалённого доступа. Обычная песочница для разработчика, никому, казалось бы, не интересная. Сервер тихо живёт своей жизнью где-то в облаке, отдаёт странички, выполняет задачи, ждёт ваших команд. Вы даже не подозреваете, что за этой тишиной уже разворачивается настоящая цифровая охота.

За два года работы в технической поддержке облачного хостинга я видел множество взломов, помогал клиентам с восстановлением серверов. Видел всё: от примитивных майнеров до полностью стёртых проектов без бэкапов. Сейчас я работаю инженером технической поддержки в компании CleverData (входит в холдинг LANSOFT).

Однажды, ради чистого любопытства, я решил заглянуть в логи свежеиспечённого VDS, созданного всего пять дней назад...

Я работаю по схеме Time & Materials (T&M) над проектами с высокой степенью неопределённости, где на старте часто только общее представление о продукте, его структуре или задачах. В этой статье я покажу, как проходит первый ключевой этап работы — от сбора вводных материалов до набора проектных артефактов, которые формируются в первый блок часов.

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

Теперь, набив собственных шишек, я готов заглянуть к «соседям». Чем они завлекают свою аудиторию? Есть ли уникальные игровые механики? Какие плагины используются и какие ограничения в игровом мире? Paper или Spigot? Velocity или BungeeCord?  

Этот текст подходит даже тем, кто никогда не занимался администрированием и не планировал — в процессе исследования я нашел множество потех.

Всем привет! Меня зовут Алексей, я техлид Android направления в компании Домклик.

На одном из собеседований зашла с кандидатом дискуссия об образовании. И была произнесена примерно такая фраза: «Зачем тратить 4–6 лет на обучение в вузе, если нужные по вашей вакансии навыки можно получить за год?» Пообщавшись ещё с некоторыми недавно вошедшими в отрасль знакомыми, сложилось впечатление, что этим вопросом задаются многие. И действительно, если, условно, на заводе требуется фрезеровщик, и у кандидата есть стаж работы или он окончил профильное училище, то какая разница, получал ли он высшее образование или нет?

Так почему многие крупные компании в ИТ при найме отдают предпочтение кандидатам с «вышкой»? Чем такие специалисты выгодно отличаются от остальных с таким же практическим опытом и профильными знаниями? Попробуем разобраться с этими вопросами и прояснить их. Все предложенные выводы — личное мнение автора и может (и должно) не совпадать с чьим‑либо ещё или общепринятым.

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

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

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

Так обычная подготовка к соревнованиям превратилась в увлекательный эксперимент, результатом которого стала эта статья и реализация шахмат с туманом войны на Python

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

Прежде чем углубиться в детали, позвольте представиться. Меня зовут Анзар, я работаю фронтенд-разработчиком уже 9 лет, последние 3 из которых — в Ozon Tech, где я занимаю позицию тимлида. За это время я побывал на десятках, а может, и сотнях собеседований — и как кандидат, и как интервьюер. Кроме того, у меня за плечами многолетний опыт менторства и мне приходилось наблюдать, как различные факторы влияют на скорость роста. Все это заставило меня глубоко задуматься о системных проблемах найма разработчиков. Думаю, эта статья будет особенно полезна нанимающим менеджерам, рекрутерам и, возможно, HR-специалистам — она поможет пересмотреть подход к найму.

Лайфхаки для миграций, оптимизации и избегания граблей

Реальные лайфхаки и проверенные практики по миграциям, оптимизации запросов, управлению индексами и обратной совместимости кода. Узнайте, как:

• Не сломать прод при миграции.
• Избежать N+1 и других проблем SQL-запросов.
• Планировать откаты и работать безопасно на высоконагруженных БД.

Сегодня сложно представить технологическую компанию, которая бы всерьёз занималась разработкой и не использовала инженерные расчёты. CFD-, FEA-, тепловые, а также одномерные (1D) симуляции давно стали повседневными инструментами.

При этом расчёты могут быть очень дорогим удовольствием: бывает расчет требует сотни часов машинного времени, а также участия нескольких специалистов. А значит, результаты – это не просто «файлы», а важный и ценный актив компании.

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

Если расчёты – это актив, то ими нужно активно управлять. Расскажу, как подойти к этому шаг за шагом.

Те, кто имел дело с покупкой и продажей недвижимости, знает, что просмотры — очень хлопотное занятие. Неудивительно, что для экономии времени появляются предложения посмотреть квартиру онлайн или с помощью 3D‑тура. О таких виртуальных экскурсиях мы сегодня и поговорим.

В сентябре Яндекс Недвижимость рассказала о 3D‑турах для новостроек. С момента начала тестирования в июле на сервисе было сгенерировано более четверти миллиона виртуальных экскурсий по строящимся квартирам. Чтобы это стало возможным, мы обучили нейросеть анализировать планировки и превращать их в трёхмерные визуализации. Но чтобы это стало возможным, нужно было проделать большую и кропотливую работу, чтобы нейросеть понимала, где отрисовывать окно или класть плитку на пол.

Меня зовут Катя Шибанова, я работаю архитектором краудсорсинговых решений (CSA) в службе разметки данных Yandex Crowd Solutions. Недавно к нам обратились коллеги из Яндекс Недвижимости: нужно было помочь с разметкой для обучения модели компьютерного зрения, которую используют для создания 3D‑туров. Об этом интересном проекте и будет мой рассказ. Я расскажу, чем опасны миллиметровые зазоры между полигонами в разметке, почему помимо типов помещений (кухня, спальня, санузел и тому подобное) нужно размечать структурно важные элементы — двери, окна, несущие стены, а также почему приоритизация геометрической согласованности важнее «средней» точности по пикселям.

В «Экспресс 42» — подразделении «Фланта», которое консультирует компании по DevOps-практикам, — решили проверить, как можно реализовать GitOps по модели BSA (Base, Service, Application) с помощью Argo CD. Чистый эксперимент на тестовом репозитории.

Мы попробовали четыре подхода — от отдельного ApplicationSet на каждое окружение до матричного генератора — и оценили их по изоляции окружений, соблюдению принципа DRY, поддержке временных стендов, масштабируемости и другим критериям. В статье — кратко о самой модели и каждом варианте с их плюсами и минусами.

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

Задачи были такие: 1) проехать по известному «лабиринту» из двух комнат с фиксированными препятствиями, то есть запрограммировать фиксированный маршрут — кое‑кто бился над этим неделю и больше — но всё же решений около сотни; 2) проехать неизвестный лабиринт из стенок под прямыми углами — с этим справились вчетверо меньше команд; 3) проехать по змеевидной платформе, используя камеру глубины, и не упасть за край — мне известно примерно о двух с половиной решениях её.

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

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

Технологические компании наподобие Ticketmaster, BookMyShow, Airbnb, Delta Airlines и так далее сделали бронирование делом одного клика, позволившим покупать билеты из дома.

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

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

Поэтому важно создать надёжное решение классической задачи — двойного букинга.

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

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