Для разработки iOS-приложений можно использовать два основных фреймворка: UIKit и SwiftUI. Однако при переходе на SwiftUI многие разработчики сталкиваются с трудностями, ведь парадигмы программирования у двух инструментов сильно отличаются.

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

Сегодня мы немного расскажем вам о работе IT-поддержки в Ozon Tech: что мы делаем и зачем, как используем Python и как именно он нам помогает решать рутинные проблемы и не только.

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

Всем привет! В предыдущих двух статьях мы подробно рассмотрели технические и методологические аспекты A/B-тестирования в Ozon. А сейчас время перейти к не менее интересным темам. Так как наша команда занимается не только A/B-тестами, но и в целом развитием методов принятия решений с помощью causal inference, стоит уделить внимание многоруким бандитам. 

В этой статье мы рассмотрим методологию и границы применимости классических многоруких и контекстуальных бандитов, а также реализуем контекстного бандита, в основе которого будут сэмплирование Томпсона и нейронная сеть. Ну и, конечно, мы постараемся ответить на главный вопрос: могут ли многорукие бандиты заменить A/B-тесты? 

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

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

Под катом вас ждет:

• История о том, как я сам пришёл к тому, чтобы проводить РРИ для коллег.

• Краткий рассказ о том, что из себя представляют такие игры.

• Примеры решения реальных командных задач.

• Полная методология подготовки и проведения игры. Полезно будет вам и вашему мастеру.

Йоу, всем привет! Меня зовут Анастасия, я бизнес-аналитик во внутреннем продукте Ozon по автоматизации закупок собственных товаров. Я расскажу, как мы пересмотрели ценность нашего продукта и дали ему новую жизнь.  

Внутренний продукт не видят покупатели и продавцы Ozon — с ним работают наши коллеги. В системе по автоматическому оформлению закупок они каждый день выводят заказы для поставщиков, проверяют корректность рассчитанных объёмов закупок, настраивают входные параметры закупок. Последнее, что они хотят, — тратить время на блуждание по сервисам в поисках причин ошибок и отсутствующих нужных данных. А именно этим приходилось заниматься коллегам во времена старой логики нашего продукта. Чтобы это исправить, мы с командой затеяли увлекательное «приключение на 20 минут». 

Привет! Меня зовут Сергей Балалаев, я руковожу отделом разработки мобильного приложения для ПВЗ в Ozon. Это то самое приложение, которым сотрудники пунктов выдачи сканируют штрихкод, чтобы выдать товар получателю. Оно внутреннее, для сотрудников. iOS-версией постоянно пользуются 12 тыс. человек, поэтому при постановке задачи нас не просили делать мультиязычную версию. Но мы с самого начала разработки решили поддерживать несколько языков — когда возникнет необходимость локализации, справимся в спокойном режиме и без проблем, свойственных проектам, в которых локализацию не закладывали.

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

UPD: Добавили записи докладов и слайды

Всем привет!

Меня зовут Михаил Кабищев, я руководитель направления «Базовые сервисы» (Платформа).

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

Go, C#, Java, Python – мы поговорим о каждом языке и расскажем, почему выбрали именно их.

Если вдруг вам негде провести код-ревью вашего проекта, присылайте код в программу Bug Bounty – там ваши наработки как минимум кто-нибудь посмотрит ? 

Такой мем появился у нас в команде продуктовой безопасности Ozon после второго запуска Bug Bounty программы. Как и во многих шутках, в этой есть доля правды: нашу программу по поиску уязвимостей мы стараемся развивать так, чтобы каждый багхантер гарантированно получал адекватный ответ на свою заявку в разумные сроки.  

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

Именно так я решил назвать эту статью, чтобы описать свои эмоции на прожаривании кода спонтанном публичном код-ревью моего open-source Portal от участников Go-чата, в котором я активно участвую. Главным ревьюером был Глеб Яльчик, что делало ситуацию ещё более волнительной для меня. Расскажу, как я на это решился, что мы обсудили, к чему пришли и какой эффект это дало. А внедрять Portal мы будем на примере мини-приложения по мотивам (всеми любимой) мобы Dota.

Примечание: это приложение будет что-то делать только в учебных целях, чтобы понять, как Portal сможет нам помочь передавать данные. Логика в нём будет достаточно простой, без ряда проверок и, возможно, с багами. Если станет достаточно интересно, то можем обсудить и его в комментариях!

UPD: Добавили записи докладов и слайды

Здесь мог быть каламбур про Go в Екат. Эх, всё-таки просочился. 

Привет, меня зовут Ильяс, и я – старший разработчик в Ozon.

Мы постоянно говорим, что Go – один из наших самых любимых языков. А почему? А потому что эффективен. Мы можем просто и быстро писать высокопроизводительные решения, а потом без труда их поддерживать и масштабировать. На Go написано более 1000 микросервисов, обеспечивающих работу сайта, склада, систем логистики. 

Ждём всех в гости на открытый Ozon Tech Community Go Meetup 20 апреля в 18:00 в Екатеринбурге (16:00 по Москве). И, конечно, будет онлайн.

Всем привет! Меня всё так же зовут Сергей, я разработчик в Ozon. 

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

В этой статье речь пойдёт про новые возможности CUTE:

- Построение multistep-тестов.
Рассмотрим, как можно сделать тест, состоящий из нескольких шагов, как достать данные из одного теста и перенести их в другой и как это всё выглядит в Allure.

- Загрузка файлов и построение multipart-тесты.
Один из популярных кейсов — когда при проверке ручки регистрации нужно убедиться, что API может принимать картинки и информацию о пользователе в одном запросе. Рассмотрим, как такое тестировать.

- Написание табличных тестов.
Рассмотрим возможность создавать массивы тестов с проверками, параметризацией и Allure-отчётами.

И много других фич. Готовы? Let's read it again!

Когда я в последний раз менял работу и проходил собеседования, конечно, основные вопросы были про навыки продакта и особенности продуктов, которыми я занимался. Вопросы касались метрик, экономики продукта и взаимодействия с пользователями. Поскольку мой опыт специфичен :), в какой-то момент у меня даже закралось сомнение, а точно ли я продакт? Начал размышлять, откуда родился такой вопрос — и понял.

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

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

Меня зовут Денис Соловьев, и так получилось, что я работал и продолжаю работать как раз на таких внутренних ИТ-продуктах. Я хочу сравнить, какие из инструментов и подходов работают для них.

Думаю, кому-то из вас будет интересно, как организованы процессы развития IT-продуктов в Ozon.

Продукты создаются командами. Деление на команды, а также их интеграция – важная и сложная задача. Каждая компания решает её по-своему, а идеального решения, наверное, не существует вовсе. 

Бывает полезно посмотреть на опыт конкретной компании и сравнить с тем, как это устроено у вас. Или прикинуть, насколько вам подходит такая организация, если рассматриваете Ozon как потенциального работодателя.

Вот вам взгляд изнутри, а именно - из той части IT, которая занимается автоматизацией логистики. 

UPD: Добавили записи докладов и слайды

1С – это не просто язык программирования, это целая экосистема, которая позволяет автоматизировать бизнес-процессы любого уровня сложности. 

Всем привет!
Меня зовут Таня, я занимаюсь тестированием 1C-решений в Ozon. Мы используем 1С для автоматизации бухгалтерского и финансового учета, ведём процессы, связанные с управлением персоналом для всех юридических лиц группы компаний Ozon. И, куда без этого, справляемся с составлением и сдачей разной отчетности, согласно действующему законодательству.

UPD: Добавили записи докладов и слайды

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

C# можно встретить везде: в огромных монолитах, в десктопных приложениях, в мобильной разработке, даже в геймдеве, не говоря уже о самых передовых разработках на  микросервисной архитектуре. У нас в Ozon C# — один из основных языков, даже есть свои курсы Route 256 для Net-разработчиков, где мы в течение двух месяцев делимся опытом разработки микросервисов в лидирующем e-com, и, кстати, я там преподаю. 

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

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

В Ozon много различных сервисов и систем. Они общаются друг с другом и внешним миром по доменным именам. DNS — центральное звено, без которого не обходится почти ни одна инфраструктура. Понятно, что когда DNS отдаёт некорректные данные, то это неприятно, когда таймаутит — плохо, когда прилёг — очень плохо, когда прилёг надолго — в принципе, можно расходиться. Значит, одна из основных задач команды инфраструктуры — обеспечить сервисам надёжное и, желательно, быстрое разрешение доменных имён. Об этом мы и поговорим. Также затронем вопросы управления ресурсными записями, жизнь в Multi DC-среде, обслуживание DNS, кеширование, журналирование запросов и возможные проблемы.

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

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

Если вы спросите у прожжённых системных администраторов, используют ли они realtime‑конфигурацию в Asterisk, с вероятностью 90% ответ будет отрицательный. В качестве обоснования, скорее всего, услышите «При недоступности источников данных телефония станет неработоспособной». Если интересно узнать, как мы обошли это ограничение, читайте дальше.

UPD: Добавили записи докладов и слайды

Привет, Хабр! Меня зовут Кирилл Семушин, в Ozon я руковожу направлением продуктового дизайна и исследований. В нашей компании более 150 дизайнеров, десятки исследователей и не менее дюжины UX-редакторов. Все они работают над бесчисленным количеством продуктов, чтобы наши пользователи становились чуточку счастливее.

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

Приглашаем в наш московский офис 17 февраля в 18:00, где честно поделимся опытом:
• Кирилл Семушин расскажет дизайне в Ozon.
• Виктор Теплов: «Пилим Библу или Рефакторинг дизайн-системы».
• Богдана Кибза: «Дизайн-система ✕ SDUI: как мы собирали грабли».
• Алексей Авдеев: «Как подружиться c фронтенд-разработчиком».
• Евгений Антонов, Никита Новоселов проведут интерактив: ревью макетов глазами мобильного разработчика.

UPD: Добавили записи выступлений и слайды

Мы делаем приложения для всех — для покупателей, продавцов, курьеров и сотрудников пунктов выдачи заказов. И каждое чем-то уникально.

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

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