Uzum Tech

Что может пойти не так, если просто взять и создать ещё одно правило в поиске? 👀 Например, по запросу «наушники» вы увидите… спальные гарнитуры. В новой статье Дима Шипилов из команды поиска Uzum Market рассказывает, что ещё происходит с запросом до и вокруг привычного ранжирования. Внутри — опечаточник и подсказки, синонимы и катпреды, персонализация, эксперименты с ML и LLM и много примеров из прода: что сработало, что пришлось откатить и какие выводы команда забрала с собой. 🔗 Читайте «Поиск в глубину: какие инструменты помогают работать поиску в Uzum Market» 💜💜💜 Agar shunchaki qidiruvda yana bitta qoida yaratsangiz, nima noto‘g‘ri bo‘lishi mumkin? 👀 Masalan, "quloqchinlar" deb qidirsangiz, yotoqxona garniturlarini ko‘rasiz. Yangi maqolada Uzum Market qidiruv jamoasidan Dima Shipilov odatiy tartiblashdan oldin va uning atrofida so‘rov bilan yana nimalar sodir bo‘lishi haqida so‘z yuritadi. Ichida xatolarni tuzatish qo‘llanmasi va maslahatlar, sinonimlar va katpredlar, shaxsiylashtirish, ML va LLM bilan tajribalar hamda productiondan ko‘plab misollar mavjud: qaysi biri ish bergani, qaysi birini bekor qilishga to‘g‘ri kelgani va jamoa bundan qanday xulosalar chiqargani haqida. 🔗 Chuqur qidiruv: “Uzum Market'da qidiruvni amalga oshirishda qanday vositalar yordam berishi"ni o‘qing”

Нет, это не тревел-блог из Еревана 😍 Это наш коллега Абай Асенов съездил на Back to Back — масштабную бэкенд-конференцию Яндекса, которая в этом году прошла сразу в трёх городах: Белграде, Москве и Ереване. В треке Architecture & Performance Абай выступил с докладом «ALLOW ≠ ALLOW: архитектура деградации в real-time антифроде» и рассказал, почему fail-open — это прежде всего бизнес-решение, как механизмы отказоустойчивости влияют на доверие к системе и почему одинаковый ответ ALLOW не всегда означает одно и то же. 🎥 Запись уже можно посмотреть по ссылке, а фото из Еревана — в этом посте. 💜💜💜 Yo‘q, bu Yerevandan sayohat blogi emas 😍 Hamkasbimiz Abay Asenov bu yil bir vaqtning o‘zida uchta shaharda: Belgrad, Moskva va Yerevanda bo‘lib o‘tgan Yandeksning keng ko‘lamli Back to Back konferensiyasiga tashrif buyurdi. Architecture & Performance yo‘nalishida Abay "ALLOW ≠ ALLOW: real vaqt rejimidagi firibgarlikka qarshi kurashda degradatsiya arxitekturasi" mavzusida ma’ruza qildi va nima uchun fail-open birinchi navbatda biznes yechimi ekanligi, nosozliklarga chidamlilik mexanizmlari tizimga bo‘lgan ishonchga qanday ta’sir ko‘rsatishi va nima uchun bir xil ALLOW javobi har doim ham bir xil ma’noni anglatmasligi haqida so‘zlab berdi. 🎥 Yozuvni allaqachon havola orqali, Yerevandan olingan suratni esa ushbu postda tomosha qilishingiz mumkin.

От @Deprecated до собственного KSP-процессора Если в вашем проекте есть хотя бы одна аннотация, этот пост для вас. В новой статье разбираем всё, что давно хотелось понять про аннотации в Kotlin: как они работают, что происходит во время компиляции, чем отличается KSP от kapt и где annotation processing приносит пользу. Разбираем вместе с Тимуром Боргалиновым, Android-разработчиком в Uzum E-com. 🔗 Читайте эту и другие статьи в нашем блоге 💜💜💜 @Deprecated'dan xususiy KSP-protsessorigacha Agar loyihangizda hech bo‘lmaganda bitta annotatsiya bo‘lsa, bu post siz uchun. Yangi maqolada Kotlin'dagi annotatsiyalar haqida uzoq vaqtdan beri bilmoqchi bo‘lgan barcha narsalarni tahlil qilamiz: ular qanday ishlaydi, kompilyatsiya paytida nima sodir bo‘ladi, KSP kaptdan nimasi bilan farq qiladi va annotatsiyalarni qayta ishlash qayerlarda foyda keltiradi. Uzum E-com kompaniyasining Android dasturchisi Timur Borgalinov bilan birgalikda tahlil qilamiz. 🔗 Ushbu va boshqa maqolalarni blogimizda o‘qing

AI, FinTech и инженерные кейсы: хороший план на вечер, согласны? 9 июля наш коллега выступит на AI in FinTech Meetup, который организуют GDG Tashkent вместе с Salmon и Uzum. Сергей Чамкин, Senior Backend Developer в Uzum FinTech, расскажет, как превратить опыт команды в навыки AI-агента и получать предсказуемый результат. Лоокуут Стручков, Head of Data Platform в Salmon, поделится опытом использования AI при работе с production-данными и тем, как избежать неприятных сюрпризов. 📅 9 июля, 19:00 📍 IMPACT.T 🎟️ Участие бесплатное, регистрация по ссылке До встречи на митапе! 💜💜💜 Sun’iy intellekt, FinTech va muhandislik masalalari: oqshom uchun ajoyib reja, shunday emasmi? 9-iyul kuni hamkasbimiz GDG Tashkent Salmon va Uzum bilan birgalikda tashkil etayotgan Sun’iy intellekt FinTech Meetup'da nutq so‘zlaydi. Uzum FinTech kompaniyasining Senior Backend Developer Sergey Chamkin jamoa tajribasini sun’iy intellekt agenti ko‘nikmalariga qanday aylantirish va kutilgan natijaga erishish haqida so‘zlab beradi. Salmon kompaniyasining Head of Data Platform Lookuut Struchkov ishlab chiqarish sun’iy intellektdan production ma’lumotlari bilan ishlashda foydalanish tajribasi hamda kutilmagan muammolarning oldini olish usullari bilan o‘rtoqlashadi. 📅 9-iyul, 19:00 📍IMPACT.T 🎟️Ishtirok etish bepul, ro‘yxatdan o‘tish havolasi orqali Uchrashuvda ko‘rishguncha!

Почему экран работает не так плавно, даже если код работает быстро? Всё дело не только в отдельных оптимизациях, но и в том, какой путь проходят данные до первого кадра. В новой статье Android-разработчик Uzum E-com Тимур Боргалинов рассказывает, где чаще всего теряется плавность, разбирает типичные ошибки в Compose, Flow и корутинах и делится практическими способами сделать сложные экраны быстрее. Если уже читали предыдущий материал Тимура про оптимизацию изображений в Android, новая статья станет отличным продолжением. 🔗 Читать 🔗 Ссылка на первую статью для тех, кто пропустил 💜💜 Kod tez ishlayotgan bo‘lsa-da, nega ekran ravon ishlamayapti? Hamma gap nafaqat alohida optimallashtirishlarda, balki ma’lumotlarning birinchi kadrgacha qanday yo‘l bosib o‘tishida hamdir. Yangi maqolada Android dasturchisi Timur Borgalinov ravonlik ko‘pincha qayerda yo‘qolishi haqida so‘zlab beradi, Compose, Flow va korutinlardagi odatiy xatolarni tahlil qiladi hamda murakkab ekranlarni tezlashtirishning amaliy usullari bilan o‘rtoqlashadi. Agar siz Temurning Androidda tasvirlarni optimallashtirish haqidagi oldingi maqolasini o‘qigan bo‘lsangiz, yangi maqola uning ajoyib davomi bo‘ladi. 🔗 O‘qish 🔗 O‘tkazib yuborganlar uchun birinchi maqola havolasi

Что лучше: сначала поднять весь стек целиком или последовательно доводить до ума каждый компонент? Для большинства это теоретический вопрос. А для нашего коллеги из Uzum Fintech Кирилла Кулакова вполне практический: пока команда строила MLOps-платформу, вокруг этого выбора разгорелась нешуточная дискуссия. Рассуждения в какой-то момент зашли так далеко, что превратились в полноценную статью. В ней Кирилл разбирает два популярных подхода к развёртыванию платформ, объясняет, почему ни один из них не идеален, и показывает модель развития через waves: от инфраструктурного фундамента до полноценного ML-стека. Если работаете с Kubernetes, GitOps, Platform Engineering или просто строите что-то сложнее одного сервиса, статья может подкинуть несколько полезных идей. 🔗 Читайте 💜💜💜 Qaysi biri ma’qulroq: avval butun stekni birdaniga ishga tushirgan yaxshimi yoki har bir komponentni bosqichma-bosqich takomillashtirganmi? Ko‘pchilik uchun bu nazariy savol. Lekin Uzum Fintech'dagi hamkasbimiz Kirill Kulakov uchun esa ancha amaliy: jamoa MLOps-platforma yaratayotganida, aynan shu tanlov atrofida qizg‘in bahs-munozaralar boshlanib ketdi. Mulohazalar shu darajaga yetdiki, oxiri to‘laqonli maqolaga aylanib qoldi. Unda Kirill platformalarni joriy etishning ikkita mashhur yondashuvini tahlil qiladi, nima uchun ularning hech biri mukammal emasligini tushuntiradi va waves orqali rivojlanish modelini ko‘rsatib beradi: infratuzilmaviy poydevordan to to‘liq ML-stekgacha. Agar Kubernetes, GitOps, Platform Engineering bilan ishlasangiz yoki shunchaki bitta servisdan murakkabroq narsa qurayotgan bo‘lsangiz, maqola sizga bir nechta foydali g‘oyalarni berishi mumkin. 🔗 O‘qing

💜Traffic Management PaaS-platformaning bir qismi sifatida Har kuni 230 dan ortiq mikroservis va o‘nlab relizlarga ega bo‘lsangiz, nima sodir bo‘ladi? DevOps Days'da bizning Uzum E-com Head of Infrastructure Dmitriy Krapivin jamoada traffic management qanday tashkil etilgani va nima uchun u allaqachon shunchaki muvozanatlovchining vazifasi bo‘lmay qolgani haqida gapirib berdi. Keyslar, kanareyka relizlari, multiklasterli Istio hamda o‘zgarishlarni production'ga xavfsiz tatbiq etishga yordam beradigan yondashuvlar — bularning barchasi taqdimot videosida. Biz albatta e’tibordan chetda qoldirmaydigan bir nechta jihatlar: 01:15 Platformaga traffic management nima uchun kerak? Kuniga 230 dan ortiq mikroservislar va 30 dan ortiq relizlar platforma darajasida boshqarishni talab etadi. 06:14 Istio qanday rol o‘ynaydi platforma xizmatlarning barqaror va yangi versiyalari o‘rtasidagi trafikni qanday boshqaradi 11:42 Kanareykalar nima uchun kerak? o‘zgarishlarni asta-sekin joriy etish va foydalanuvchilar uchun xavfni kamaytirish usullari 14:15 Jamoa duch kelgan muammo nima uchun Horizontal Pod AutoScaler'ning standart xatti-harakati yetarli bo‘lmadi 17:12 Relizda xatolik yuz bersa nima bo‘ladi tizim o‘zgarishlarni avtomatik ravishda qanday ortga qaytaradi va jamoalarni qanday xabardor qiladi Kimga qiziq bo‘ladi: • DevOps и Platform Engineers • SRE-muhandislarga • Backen-dasturchilarga • Kubernetes, Istio va CI/CD bbilan ishlaydigan barchaga 🎥 Chiqishni tomosha qilish

💜Traffic Management как часть PaaS-платформы Что происходит, когда у вас >230 микросервисов и десятки релизов каждый день? На Tashkent DevOps Days наш Head of Infrastructure Uzum E-com Дмитрий Крапивин рассказал, как в команде устроен traffic management, и почему он давно перестал быть просто задачей балансировщика. Кейсы, канареечные релизы, мультикластерный Istio и подходы, которые помогают безопасно выкатывать изменения в продакшен — в видео с выступления. Несколько моментов, которые мы бы точно не пропускали: 01:15 Зачем платформе нужен traffic management 230+ микросервисов и более 30 релизов в день требуют управляемости на уровне платформы 06:14 Какую роль играет Istio как платформа управляет трафиком между стабильными и новыми версиями сервисов 11:40 Зачем нужны канарейки как постепенно выкатывать изменения и снижать риск для пользователей 14:15 Проблема, с которой столкнулась команда почему стандартного поведения Horizontal Pod AutoScaler оказалось недостаточно 17:12 Что происходит при ошибке релиза как система автоматически откатывает изменения и уведомляет команды Кому будет интересно: • DevOps и Platform Engineers • SRE-инженеры • Backend-разработчики • все, кто работает с Kubernetes, Istio и CI/CD 🎥 Смотреть полностью

Как помочь человеку (и нейросети) быстрее разобраться в чужом API? Антон Тампер, системный аналитик команды трансграничных переводов в Uzum Fintech, рассказал об этом в новой статье. Немного спойлеров: • почему современной API-документации часто недостаточно • что такое стандарт Arazzo от OpenAPI Initiative • описание сценариев вместо отдельных методов • как запускать и проверять такие сценарии через Redocly Respect • и про Валеру, который начал писать YAML раньше автора 🔗 Читайте и делитесь мыслями в комментариях 💜💜💜 Qanday qilib insonga (va neyrosetga) boshqalarning API'sini tezroq tushunishga yordam berish mumkin? Bu haqda Uzum Fintech'ning transchegaraviy o‘tkazmalar jamoasi tizim tahlilchisi Anton Tamper o‘zining yangi maqolasida so‘z yuritdi. Qisqacha spoyler: • nima uchun zamonaviy API hujjatlarining o‘zi ko‘pincha yetarli emas? • OpenAPI Initiative tomonidan Arazzo standarti nima? • alohida metodlar o‘rniga ssenariylar tavsifi • Redocly Respect orqali bunday ssenariylarni qanday ishga tushirish va tekshirish mumkin? • va muallifdan oldin YAML yoza boshlagan Valera haqida biroz 🔗 Maqolani o‘qing va izohlarda o‘z fikrlaringiz bilan bo‘lishing