Клиентская оптимизация *

С нуля собрали кредитное PWA-приложение за 6 месяцев. Рассказываем, какие решения помогли быстро выйти на рынок и выдержать рост.

Обычно, в 1С много показателей и отчётов по ним, а при желании почти каждый можно собрать под свои потребности, так как платформа гибкая и легко поддается доработке. Но это долго и разработка стоит дорого, особенно если речь про кастомный отчёт под руководителя. А с обработкой можно получать короткий отчет сразу в Telegram.

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

Всем привет! Меня зовут Сергей Бунатян, я руководитель службы в Техплатформе Городских сервисов Яндекса. 

На сегодняшний день существует довольно много брокеров сообщений. Наиболее часто используемыми в индустрии, пожалуй, будут те, которые, реализуют парадигму очереди сообщений. Самых известных представителей вы наверняка знаете, — Apache Kafka и RabbitMQ, а внутри Яндекса широко используется Logbroker. И, тем не менее, как нетрудно догадаться из этого вступления, мы зачем‑то решили написать свой брокер сообщений.

Сегодня я расскажу про нашу систему, которая называется STQ — Sharded Tasks Queue. По названию системы можно было бы подумать, что это ещё один сервер очередей, однако это будет не совсем верно. STQ — это скорее message broker. 

В этой статье я постараюсь рассказать о том, какие задачи перед нами стояли и как это нас привело к решению написать что‑то своё. А заодно поделюсь опытом эксплуатации нашей системы и расскажу про влияние STQ на опыт разработчиков.

Вы работаете над устоявшимся продуктом, в котором уже достигли PMF. Команда выкатывает новую фичу за фичей. A/B‑тесты показывают +3% к конверсии. Продакт ставит задачам статус «Done», команда получает поздравления от СРО.

Через два месяца выясняется: 40% пользователей по‑прежнему отваливаются на том же критичном шаге. Проблема не решена. Но в бэклоге она больше не приоритетна — там уже 47 других «важных» задач. СРО требует результат.

Все сделали свою работу. Метрики зелёные. А продукт стоит на месте.

Вот это и есть симптом. И чинят обычно его бэклогом — добавляют ещё задач, меняют приоритизацию, внедряют новый фреймворк. Я разбираю, что находится глубже: почему так происходит и как с этим работать. С вами Александр Козуб — и сегодня как раз про то, о чём в продукте не принято говорить вслух. Читайте в статье по ссылке.

Привет, Хабр! Меня зовут Алексей, я занимаюсь беспроводными технологиями и сегодня хочу рассказать об опыте проведения большого исследования - опроса абонентов провайдеров, который охватил почти сто тысяч абонентов и длился больше трёх лет. История, которая началась как товарищеский спор, но которая быстро смогла нас всех увлечь и поразить полученными результатами. Это был действительно увлекательный опыт. Первые опросы мы проводили в домовых чатах, до которых могли достучаться, и нужно сказать, что это, наверное, самый действенный механизм взаимодействия с целевой аудиторией. Затем мы создавали опросы в Google и Яндекс.Формах, пробовали даже поднять свою опросную платформу на базе Limesurvey, привлекали в качестве помощников в опросе студентов (спасибо коллегам из вузов и студенческих профсоюзов). Некоторые ответы ставили нас в тупик, а некоторые порождали ещё больше вопросов. Тогда мы отступали на шаг, проводили проблемные интервью с некоторыми из опрашиваемых и вновь повторяли опросы.

Это история о том, как написать компилятор Python, генерирующий оптимизированные ядра и при этом позволяющий сохранить простоту кода.

Этот пост станет глубоким разбором того, как мы снизили задержки P95 конечной точки API с 5 до 0,3 секунды при помощи нишевого трюка computer science под названием «фильтр Блума».

Мы расскажем о том, почему конечная точка была медленной, о решениях, которые мы рассматривали для повышения её скорости, и о критериях выбора между ними. Также мы объясним, как всё это устроено внутри.

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

До этого я десять лет работала в финтехе. Разрабатывала банковские приложения, карточные продукты, транзакционные сервисы. Привыкла к метрикам типа конверсии и среднего чека. А потом попала на производство.

В первую неделю коллега уронил телефон в реактор полимеризации. Экран расплавился. Началось помутнение гранул. Тонны полипропилена превратились в брак. А мы не могли запустить новую функцию на склад, пока не вывезем весь этот брак.

Я тогда поняла — здесь все по-другому.

Однажды я заехал в гости к знакомому — владельцу цеха по металлообработке и невольно оказался свидетелем скандала. Произошло это в день зарплаты.

Чтобы был понятен контекст, немного опишу суть процесса.

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

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

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

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

Яндекс Карты — это не просто приложение для навигации, а один из самых высоконагруженных мобильных сервисов с широкой аудиторией. В центре всех наших сценариев — сама карта, которая уже сегодня не уступает по сложности отдельным игровым движкам. Мы постоянно работаем над тем, чтобы сделать её более удобной для ориентирования, и постепенно идём к высокодетализированным и реалистичным картам будущего: добавляем трёхмерные здания, разметку на дорогах, детализированные развязки и другие городские объекты. 

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

Меня зовут Игорь Зверев, я руководитель группы разработки автонавигации в Яндекс Картах. Сегодня я расскажу, как мы подошли к решению этой задачи: что изменили в процессе разработки, как создали и используем систему RAM‑классов для выпуска требовательных функций и какие технические выводы сделали на этом пути.

Продолжаю цикл статей из серии давно минувших дней.

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

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

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

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

В том отделе 4 человека. Одна из их задач была подбирать копейки для счетов-фактур. Чтобы строки с итоговой суммой сходились. Ну вы знаете про округление. Для этого у них был целый инструмент - документ в 1С аж с десятитысячными долями в ценах! Они там сидели вручную подбирали десятые доли копеек. Этот процесс был легендарным. Считалось, что его нельзя автоматизировать - кто ни пробовал, ни у кого не получалось, так мне сказал начальник.

Да как так? Не может такого быть! Я-не-ве-рю! Покажите!

Один из самых простых способов ускорить работу сайтов и снизить нагрузку на инфраструктуру — корректно использовать клиентское кэширование. Механизм одновременно и простой, и сложный. В этой статье посмотрим, как можно управлять клиентским кэшированием в веб‑сервере Angie.

Четыре месяца назад я сидел в офисе клиента в Минске. Владелец интернет-магазина спортивного питания смотрел на график Analytics. Линия трафика ползла вниз. Медленно. Но неумолимо.

«Мы делаем всё правильно», — сказал он. И был прав.

Контент. Техническая оптимизация. Ссылочная масса. Команда из трёх SEO-специалистов работала на пределе. Но конкурент из Москвы обгонял их каждую неделю. По всем фронтам.

Я открыл сайт конкурента. Замер. За последние три месяца они опубликовали 90 новых статей. Детальные гайды по спортпиту. Сравнения. Обзоры. Внутренняя перелинковка выстроена хирургически точно. Schema.org разметка на каждой странице. Технические параметры — как у enterprise-проекта.

Позвонил знакомому, который работает в той компании. Спросил прямо:

«У вас что, команда из двадцати человек?»

Пауза. Смех.

«Один SEO-специалист. Плюс AI-агенты. Автоматизировали 98% процессов.»

Вот тогда я понял. Правила изменились. И большинство об этом ещё не знает.

Всем привет! Меня зовут Илья Кара́псин, я работаю над производительностью Яндекс Браузера. Задачи моей команды включают не только работу над самим браузером, но и прямое улучшение используемых в нём опенсорс‑решений, например Chromium и применяемых в нём проектов (Blink, V8, Catapult), в том числе и компиляторов (LLVM Clang). Другими словами, мы вносим вклад в сообщество. При этом поиск и создание улучшений для сторонних опенсорс‑проектов может стать прямой рабочей задачей даже в ходе стажировки.

К слову, моя работа в Браузере как раз с неё и началась. При отборе положительно сказалось наличие у меня pet‑проектов: отдельного внимания заслужил проект, использующий озвучку и SFX (сноска: сокращение от англ. sound effects — звуковые эффекты) из Heroes of Might and Magic V. Так удивительно совпало, что мой будущий руководитель ранее работал в Nival Interactive как раз над этой игрой.

А в этой статье я расскажу о том, как обычное сокращение полных файловых путей в логах до имени файла (например, path/to/filename → filename) может повлиять на размер исполняемых файлов и производительность Браузера, а также внести вклад в проект LLVM Clang.

C# — гибкий язык. На нём можно писать мобильные и десктопные приложения, игры, веб-сайты, сервисы и API. Можно писать на нём, как на Java, со всеми абстракциями и AbstractionFactoryClassProvider. Но, в отличие от Java, на нём также можно писать низкоуровневый и небезопасный код. И когда я говорю о низкоуровневом, то имею в виду отсутствие сборщика мусора и сырые указатели.

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

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

Всем привет!
Меня зовут Прокошкин Леонид, я Frontend-разработчик в компании DDPlanet.

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

В проекте было около 30 Lottie-анимаций, некоторые весили ~100 KB, и нам нужно было оптимизировать их загрузку.

Как снизить трафик и нагрузку? Правильно - кеширование. Мы выбрали кеширование на стороне Service Worker.

В недавней публикации мы представили Tau² — инструмент для оценки больших языковых моделей. Сегодня же хотим поделиться неожиданным открытием: простое переписывание промпта увеличило успешность небольшой модели более чем на 20%. Ниже — подробный разбор того, как мы нашли и устранили узкое место в её работе, внеся всего несколько тонких изменений в политику агентов.

Предупреждение о возможном конфликте интересов: автор этого документа также является соавтором реализаций ipnsort и driftsort, используемых в стандартной библиотеке Rust.

Сценарий

Компоненту ПО передаются данные для сортировки. Известно, что значения могут иметь низкую кардинальность. Несмотря на тип u64, способный хранить 2⁶⁴ уникальных значений, в данных наблюдается всего четыре уникальных значения. Учитывая такие серьёзные ограничения, разработчик может разумно решить использовать специализированную реализацию сортировки, а не ту, которая есть в библиотеке, потому что он знает о данных больше, чем способна знать обобщённая реализация.

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

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

Привет, Хабр. Мы – Даша (инженер машинного обучения) и Наташа (ведущий аналитик в ЮMoney). В этой статье расскажем о системе машинного перевода, разработанной как end-to-end-решение для многоязычной поддержки в финтех-компании. Рассмотрим архитектуру, технические детали реализации и практические результаты внедрения системы. А ещё покажем, как общались с пользователем из Казахстана.

План статьи:

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

>> Обсудим выбор архитектурного подхода — почему остановились на специализированном агенте вместо универсальных LLM-решений.

>> Детально разберём техническую реализацию — как работают FastText для определения языка и NLLB для перевода и почему потребовалось 12 отдельных LoRA адаптеров.

>> Покажем систему в действии — полный цикл обработки обращения от клиента из Казахстана.

>> Завершим анализом результатов и метрик качества работы системы.