Привет, Хабр! Меня зовут Георгий, я руководитель команды Ozon Банк iOS. Я занимаюсь разработкой и развитием мобильного направления финансовых продуктов Ozon.

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

Часто разработчики используют только встроенный API взаимодействия JavaScript c нативными кодом, например Web API, но нам этого оказалось мало, и мы расширили спектр возможностей подхода web-native. Внутри статьи я расскажу, какой подход выбрал, как к этому пришёл и как обошёл возникшие проблемы. Подчеркну плюсы и минусы использования своего решения и в конце предложу несколько идей дальнейшего развития выбранного пути.

Привет, Хабр! Меня зовут Виктория Юльская, и я старший системный аналитик в Ozon.

Я думаю, здесь найдётся много людей, которые хоть раз работали с документацией API в Confluence. Да-да, те самые километровые страницы на каждый метод — с описанием всего и вся в виде текста, таблиц, диаграмм последовательности и т. д.

Зачастую такая документация API в Confluence устаревает ровно в тот момент, как её закончили писать. После передачи задачи в разработку, как только что-то непонятно, куда все идут? Правильно, к аналитику — «А как это работает? А что это значит? А что если...?».

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

Есть ли более эффективный способ ведения и поддержания документации API в актуальном состоянии? Давайте разбираться.

Привет! Меня зовут Маша, и я являюсь руководителем  первой линии Security Operation Center в Ozon.

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

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

Привет всем! Это не обычная статья, это целый курс про UX-редактуру от Ozon. Мы с вами разберем, что такое UX-редактура, какие бывают форматы интерфейсных текстов и как их писать качественно, быстро и просто.

Меня зовут Кира Калимулина, мы с командой занимаемся всеми интерфейсными текстами в Ozon. Я задумала этот курс, чтобы помочь дизайнерам, продакт-менеджерам, копирайтерам, разработчикам и другим специалистам научиться писать тексты для интерфейсов.

Этот курс подойдёт тем, кто только погружается в мир UX-редактуры и хочет стать продуктовым редактором. А также тем, кто вынужден писать тексты для приложений, но не умеет (или думает, что не умеет).

Я подготовила 4 урока, где разобрала, как мы пишем тексты в Ozon. Для вашего удобства основная информация продублирована в видеоуроках. В роликах есть ещё много приколов, которые невозможно передать в статье, так что можно и смотреть, и читать — как вам удобнее! 

Хей-хей! Меня зовут Айя, и я старший продуктовый дизайнер в Ozon, занимаюсь опытом покупателя в команде оформления заказов и геосервисов. 

Замечали когда-нибудь, как приложения цепляют настолько, что у вас случается любовь, и вы без раздумья готовы отдавать им свои деньги за продукты и подписки, дабы оставаться ближе к ним? Как же компаниям удаётся на подсознательном уровне заставлять вас платить, и при чём тут геймификация?

В 2024 году уже незачем рассказывать об S3-интерфейсе и сравнивать его с другими вариантами организации объектного хранилища. Вот и мы в Ozon, конечно, предоставляем такое платформенное решение широкому спектру внутренних потребителей. От сервисов, которые хранят картинки товаров для каталога, до бэкапов баз данных. От собственных внутренних разработок, до open-source-решений, таких как Gitlab и Thanos.

Пока у вас десятки терабайт и сотни RPS, вас устраивают такие решения, как MinIO. Но по мере роста объёмов и запросов приходится смотреть в сторону таких решений, как Ceph с RGW (RADOS Gateway / Object Gateway). Ну, а когда у вас 3 дата-центра, десятки петабайт данных, миллиарды объектов и десятки тысяч запросов в секунду — в таких условиях и у RGW начинаются проблемы.

Эта история началась с того, что и мы с проблемами масштабирования столкнулись. Под хабракатом вы узнаете, как мы прошли через отрицание проблемы, гнев на Ceph, торг с CTO и разработку собственного решения. Как выбирали технологии, на какие грабли наступили, и что в итоге получилось.

Привет, Хабр!

Меня зовут Дмитрий. Я успел отучиться в колледже, поступить в университет, окончить стажировку в Ozon Tech, перейти в штат и по сей день не прекращаю учиться, учиться и ещё раз учиться. Сейчас я работаю младшим аналитиком информационной безопасности в отделе Compliance и безопасности данных.

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

Всем привет! Меня зовут Газимагомед, я занимаюсь разработкой внутреннего распределённого профайлера Vision в Ozon. В этой статье я раскрою понятие профиля, расскажу о том, что такое распределённый профайлинг, чем отличается автоматический сбор профилей от ручного. А также рассмотрим проблемы, возникающие при построении профайлера. Что ж, усаживайтесь поудобнее, мы начинаем.

Меня зовут Ира и я руковожу отделом тестирования мобильной платформы: наш отдел занимается разработкой инструментов для автоматизации тестирования мобильных приложений Ozon и тестированием внутренних библиотек, которые используются в наших приложениях. Около года назад мы пытались понять, почему у одной из команд джоба с автотестами отваливается по тайм-ауту. К слову, это был проект мобильного приложения для продавцов, и на нем у нас для автоматизации тестирования используются нативные фреймворки: Kaspresso + Kotlin для Android и XCTest + Swift для iOS.

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

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

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

- Делать свою или взять готовую? Прыг.

- Платформенная или универсальная? Прыг.

- Версионировать компоненты или всю библиотеку? Прыг...

И ещё много таких «прыгов».

Давайте подготовимся к сложному контенту. Закроем глаза, успокоимся и представим идеальную дизайн-систему. Представили? Умные компоненты, продуманные паттерны, подробная документация. Автоматическая генерация кода. Кайф? А то! Только такая дизайн-система оставит нас без работы.

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

Привет, Хабр!) Меня зовут Ильяс. В этой статье мы разберём известную идею — keepalive в межсервисном взаимодействии, которая спасла уже не одну компанию в трудное время :). Но чтобы добавить интереса, мы разберём, какие проблемы в keepalive принесли современные технологии (ведь что может пойти не так с этой простой идеей?). Поэтому в статье мы рассмотрим механизмы, которые позволяют проверять стабильность соединения между клиентом и сервером в случае, когда обычные TCP keepalive из-за сложности архитектуры не могут определить состояние сервера.

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

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

Как с помощью Jobs To be Done принимать продуктовые решения, и почему сейчас мы используем этот подход для работы над нашими продуктами.

Сотрудники каждого склада, которые хотят выстроить логистические процессы оптимальным образом, должны знать фактические габариты и вес товаров, которые хранятся на его площадях. Совокупность габаритов и веса товара в Ozon называют объёмно-весовыми характеристиками (ОВХ). 

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

Всем привет! Меня зовут Андрей, и я делаю iOS-приложение для продавцов Ozon Seller. Наша команда поставляет фичи, красит кнопки, работает над перформансом и  всячески улучшает пользовательский опыт работы продавцов на Ozon.

Нашим приложением активно пользуются юзеры из разных стран, и поэтому день Х, когда мы решим добавить поддержку разных языков, был неизбежен. В этой статье я расскажу про стандартный процесс локализации iOS-приложения, про то, с какими трудностями мы столкнулись и как их решили. Разберём системный алгоритм определения языка и объясню, почему он нам не подошёл. Сделаем перевод приложения «на лету», а также посмотрим, как изменился наш флоу работы со строками.

Интересное начало, не так ли? Меня зовут Роман, и я младший инженер информационной безопасности Ozon. В этой статье я расскажу о проблеме отсутствия авторизации доступа к Docker daemon / Docker Engine API / командам Docker при работе с контейнерами в экосистеме Docker и как это можно решить при помощи 11 почти стихотворных строчек bash.

Говоря о стихотворчестве, первое, что приходит мне в голову, это уроки литературы, где моим самым любимым романом был «Евгений Онегин». В школе учитель литературы говорила нам: «Это вы сейчас это не понимаете... Уже потом, спустя год, пять или даже 20 лет, вы вновь прикоснётесь к книгам, которые, казалось бы, вы уже знаете вдоль и поперёк. И вот тогда вы поймёте всё то, что мы с вами тут обсуждаем, или даже откроете для себя что-то, о чем и не догадываетесь».

На просторах необъятного можно найти массу статей про выгорание. По этой теме проходят конференции, у многих есть личный опыт. Проблема актуальна и останется такой надолго, ведь первое «выгорание» — это не про вопрос «случится или нет», это про вопрос «когда» и «насколько сильно».

Я начал свой путь как разработчик и был им 15 лет, а сейчас руководитель группы разработки. Прошёл всю дорогу от младшего до ведущего и шагнул дальше. Пока я гнал по карьерному треку, я полноценно выгорал два раза, а потом решил, что хватит это терпеть. И не выгорел третий. Как получилось? Об этом и будет эта статья.

Поговорим сегодня про context receivers — фиче Kotlin, про которую я узнал давно, но смог найти применение лишь пару месяцев назад. Расскажу о том, что такое context receivers, где их можно использовать, и, конечно же, про «успешный успех» — минус 60% самописного DI в OzonID SDK. Но обо всём по порядку.

В мире разработки программного обеспечения термин «Насмотренность» крайне редко встречается, в то время как дизайнеры постоянно всё насматривают 😅. Однако понятие насмотренности не менее важно для разработчиков, поскольку оно помогает понять, зачем и как нужно создавать красивый и чистый код.

Если вы только начинающий разработчик, вам будет полезно узнать как прокачивать насмотренность и что она дает.

Боитесь стажёров? Не хотите тратить своё время на обучение начинающих специалистов? Задач много, а специалистов по ИБ мало?

Делюсь опытом построения стажёрского конвейера на базе SOC. Может, это решит ваши проблемы.

Многие российские современные IT-компании имеют стажёрские программы. Я знаком с несколькими примерами ИБ-стажировок в таких компаниях, но ничего близкого к описанной далее реализации не нашёл. Мне кажется, что всё просто и очевидно, но почему вы так не делаете? Не найдя ответа на вопрос, решил написать об очевидном, подкрепляя личным опытом.

Привет! Меня зовут Валерия, я дизайнер внутренних сервисов в Ozon Tech. Наша команда занимается продуктами, которые коллеги используют для доступа к инфраструктуре Ozon, приоритизации задач, проведения регламентных работ, выкатки и управления релизами.

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