Привет, Хабр! Инструмент, который генерирует производительный и безопасный код для работы с базой данных — миф или реальность? В этой статье обсудим, что такое sqlc, откуда он появился и какие идеи в него заложены. Разберём его возможности и ограничения, а также кейсы, когда он подходит лучше всего.
В прошлой моей статье мы разобрались, как сделать так, чтобы ожидания менеджера продукта совпали с реальностью, а в этой статье обсудим, как сделать так, чтобы задача вышла в продакшен раньше, чем она потеряла смысла. В современном конкурентном бизнесе побеждает и захватывает новую нишу тот, кто первый сделает классные доработки и захватывает этим внимание пользователя.
Мы должны очень быстро бежать, чтобы успевать за конкурентами. С другой стороны, мы должны выдавать качественный продукт, а иначе в нем нет никакого смысла. В этой статье расскажу, какой инструмент мы нащупали, чтобы ускориться и повысить качество. А еще, конечно, снизить стресс команды разработки. Меньше стресса — лучше результаты.
Меня зовут Фарит, я ML-инженер в команде рекомендаций Uzum Market. Сегодня я расскажу, как мы с нуля разработали персональные рекомендации для главной страницы нашего маркетплейса. Мы разберем архитектуру системы, используемые алгоритмы и способы измерения успеха проекта.
Всем привет! Меня зовут Ксения, я Engineering Manager в кластере Buyers Experience в Uzum Market. Наша команда занимается разработкой страницы товара и отзывов на вебе и в мобильных приложениях.
Путь нашей команды начался достаточно интересно: мы очень долго и упорно разрабатывали новую функциональность, потом очень долго и упорно ее тестировали, пока не довели до идеала ее работу и дизайн. Мы много созванивались друг с другом и обсуждали задачу, и наконец отправили ее в релиз. Вся команда, гордая собой, пришла к Product-менеджеру, чтобы он увидел плод наших стараний, но он оказался не так рад. Продакт сказал, что это не то, что он хотел изначально. Повисла ужасающая тишина. Эта задача называлась: «Форма для оставления отзывов на главной». Запомните это название, мы еще с ним встретимся.
Следом за продактом пришел дизайнер, который сказал, что вообще эту форму не видел, а мы вроде бы показывали, но все было достаточно суматошно, так что мы действительно не были уверены.
Так начался наш путь к улучшению процесса разработки.
Привет! Меня зовут Геннадий, я Oracle и PostgreSQL DBA в компании Uzum. По пути еще иногда занимаюсь NoSQL, люблю автоматизировать информацию из Ansible и визуализировать нужные мне метрики в Grafana. Хочу поделиться дашбордом для Grafana, который отображает историю активных сессий PG с их текущим SQL, отсортированных по группам ожиданий. Он помогает мне искать проблемы производительности PG-баз, и может пригодиться тем, кто администрирует Postgres.
Обработка заказов — это один из самых сложных аспектов в e-commerce, особенно когда речь идёт о микросервисной архитектуре. Большинство существующих систем используют хореографию для управления заказами, что сложно реализовать и часто приводит к беспорядку. Бизнес-требования разбиты на множество мелких задач, и обеспечить отказоустойчивость бывает трудно. В таких системах часто возникает низкая прозрачность, поиск дефектов может занять дни, а внедрение новой функциональности — месяцы. Проблему можно решить с помощью платформы для оркестрации рабочих процессов.
Привет, Хабр. Меня зовут Владимир Утратенко, я — Head of Infrastructure and Security в Uzum Market. У меня богатый опыт найма DevOps-инженеров, ведь последние 6 лет я — нанимающий менеджер. А ещё много лет подряд занимаюсь DevOps как моделью разработки. Сегодня мы поговорим про боли в CI/CD, которые часто упускают из вида DevOps-специалисты, лиды и CTO.
Всем привет. Меня зовут Кирилл, я маркетинговый аналитик в Uzum. В этой статье я хочу поделиться с вами практическими примерами, которые демонстрируют реальную ценность методов причинно-следственного анализа. Отдельно расскажу, как библиотека CausalImpact помогает в решении бизнес-задач.
Привет, с вами снова Даша и Uzum Market. В прошлый раз мы глубоко погрузились в пайплайн работы поиска нашего маркетплейса, и я обещала вам вернуться с новостями о его улучшении. Так вот, время пришло, и сегодня мы поговорим про наш опыт внедрения векторного поиска!
Всем привет! Меня зовут Иван Кузнецов, я Head of Frontend в Uzum Market. Расскажу о сложностях, с которыми мы столкнулись на пути к реализации микрофронтендовой архитектуры, и поделюсь результатами, которые мы получили в процессе пакетирования наших решений с помощью Lerna. Надеюсь, тебе, дорогой читатель, будет очень интересно :)
Отфильтровав для Вас большое количество источников и подписок, сегодня собрал все наиболее значимые новости из мира будущего, машинного обучения, роботов и искусственного интеллекта за последнее время.
Меня зовут Рушан, и я автор Telegram-канала Нейрон. Не забудьте поделиться с коллегами или просто с теми, кому интересны такие новости.
Итак, а теперь сам дайджест:
Привет! Меня зовут Саша, я продакт-лид в Uzum Market, в этом посте я расскажу вам, как вывести ecom-приложение на новый для вас рынок. Может быть, этот опыт пригодится вам, если вы тоже работаете в ecommerce (да и не только) и планируете выходить на новые рынки или просто любите читать подобные истории.
Итак, под катом:
• наш процесс запуска маркетплейса и ПВЗ в Узбекистане;
• особенности национального менталитета и потребительских привычек;
• BNPL-рассрочка как ощутимый драйвер продаж и потребительской лояльности;
• чек-лист — что нужно обязательно учесть при выходе на непривычный вам рынок.
Последние годы преподнесли нам целую серию испытаний. Из четырёх всадников один только Голод потерялся где-то по дороге, остальные успешно доскакали и поприветствовали нас. А кроме глобальных потрясений и фонового ужаса и стресса, есть ещё и простые личные проблемы — семья, горящие проекты и вся остальная жизнь со своими тревогами и заботами.
Когда накатывает сразу много трудностей со всех сторон, легко стать нервным и раздражительным, злым и неэмпатичным. Если же вы менеджер, то в таком состоянии можно утянуть за собой на дно ещё и команду. Шторм отступит, а вы останетесь без неё.
Я сам проходил через такой период в своей жизни и хочу рассказать, как я чуть не развалил свою команду, что мне помогло этого не сделать и как я выбрался из пропасти.
Привет, Хабр! Давно не виделись (2 года, ровно).
Отфильтровав для Вас большое количество источников и подписок, сегодня собрал все наиболее значимые новости из мира будущего, машинного обучения, роботов и искусственного интеллекта за июль. Не забудьте поделиться с коллегами, друзьями или просто с теми, кому интересны такие новости.
Итак, а теперь дайджест за июль:
1. Представьте на мгновение, что вы ИИ. Часы длинные, но годы короткие.
Привет, меня зовут Даша, я отвечаю за ранжирование в команде поиска Uzum Market. За время существования нашей команды мы успели накопить достаточный багаж факапов знаний, чтобы начать делиться им с вами.
Поиск — один из основных источников дохода маркетплейсов. Сценарий, где пользователь приходит на платформу с конкретной целью приобрести товар гораздо более вероятен, чем тот, где он зашел полистать ленту.
Ежедневно сотни тысяч пользователей полагаются на поиск Uzum Market, чтобы найти нужные им товары. Наша цель как команды, ответственной за поисковый движок, — предоставить им лучший сервис и помочь найти именно то, что они ищут.
С каждым днем количество товаров в нашем маркетплейсе растёт, и если раньше мы показывали десятки релевантных товаров по одному поисковому запросу, то сейчас их уже тысячи. Как правильно отранжировать товары, чтобы пользователь дошёл до чекаута? Какие данные нужны, чтобы определить релевантность товара по запросу? На какие метрики ориентироваться, чтобы измерить качество поиска?
На эти и другие вопросы мы пытаемся ответить ежедневно. И сегодня я приоткрою завесу над некоторыми решениями, которые мы уже реализовали на нашей площадке, а также расскажу про боли и трудности, с которыми пришлось столкнуться на пути к статистически значительным изменениям в метриках.
Велком всех под кат в увлекательное путешествие по внутренностям поиска Uzum Market!
Нередко руководители, особенно молодые, оказываются завалены делами, большими и маленькими. Один эпик, второй, третий, договориться с другой командой, поговорить с руководителем, зафиксировать последние соглашения, написать текст вакансии, согласовать ставки, согласовать бюджет на обучение, обсудить с Васей блокеры по задаче, что-то часто начала админка 403 отдавать, где-то просадка по метрикам… На это всё накладываются проблемы вне работы.
Вроде бы понятно, что́ нужно сделать — настроить процессы, разгрести дела, чтобы не было этих завалов. Но возникает проблема курицы и яйца: чтобы разобрать завалы, нужно время, а оно всё уходит на решение бесконечных текущих задач.
Что же делать? Как снять эту боль?
Привет! Я — Дарья, руководитель проектов в Uzum Data. В этой статье поделюсь с вами опытом работы с OpenSource SMS‑шлюзом Jasmin: какие у нас были требования, с какими препятствиями столкнулись, как выбирались из трудностей.
C чего всё началось
Нам нужно было подключить новый канал смс‑рассылки, т.к. по старым каналам мы начали упираться в лимиты. Новый канал представляет собой коммуникацию с использованием A2P каналов, то есть коммуникации от бизнеса пользователям. A2P используется как в маркетинге, так и в сервисах: для подтверждения покупки, авторизации, напоминаний, рассылок и т. д.
Привет! Я – Валерия Дымбицкая, технический руководитель команды дата-инженеров в OneFactor. Это вторая часть статьи о том, как автоматически подбирать параметры для Spark-приложений на примере spark.executor.memory.
В первой части мы разбирали, как читать логи событий Spark и как достать из них три показателя того, насколько можно уменьшить память экзекьюторам (а также зачем это делать). Здесь я расскажу о том, как превратить это всё в работающую систему на продуктиве, используя довольно простые средства.
Всем привет! Меня зовут Валерия Дымбицкая, я технический руководитель команды дата-инженеров в OneFactor. В этой статье я расскажу о том, как мы научились автоматически подбирать параметры для Spark-приложений на основе логов.
Проблема, которую мы решали, может встретиться при регулярном, предсказуемом, интенсивном использовании Hadoop-кластера. Я расскажу, как мы простыми средствами сделали рабочую автономную систему тюнинга, сэкономив в итоге 15-16% ресурсов кластера. Вас ждут детали с примерами кода.
В первой половине статьи я расскажу про то, какая перед нами стояла задача, и разберу ключевые пункты для её решения. Во второй половине будет рассказ о том, как это решение подготовить к работе на продуктиве и что мы из этого всего получили.
Зачем нам вообще понадобился автоматический тюнинг?
Начнём с инфраструктуры. Сетап у нас "классический": ограниченный Hadoop-кластер из купленных серверов. В нём на тот момент, когда мы начали всё это делать, было около 30Тб RAM и 5к CPU. В этом кластере запускается множество разноплановых приложений на Apache Spark и в какой-то момент им стало тесновато. Всё больше приложений висели в PENDING значительное время, потребление памяти утроилось за последние 4 месяца. Сохранять такую тенденцию не хотелось.
Довольно много приложений были от продукта Лидогенерация. Базово он устроен так: есть список номеров телефонов (база) и есть Spark ML Pipeline, который каким-то образом отбирает из этой базы лидов абонентов для некоего целевого действия – например, для предложения продукта клиенту. База может меняться от раза к разу. Вот такую пару из
Привет, Хабр! Меня зовут Александр, в компании oneFactor я являюсь руководителем платформенных продуктов, и одна из моих целей — это развитие платформы конфиденциальных вычислений. Именно о них мы и будем говорить в данной статье, пройдя путь по преобразованию Платформы работы с данными в Платформу конфиденциальных вычислений над данными, где основной целью является – обеспечить нераскрытие информации, загружаемой в Платформу, даже для администратора Платформы.