Вот уже полгода я работаю в роли Developer Advocate в iOS-команде inDrive. Позиция достаточно редкая и не так хорошо описана, особенно на русскоязычных ресурсах. Я решил рассказать, что делает дев-адвокат, как помогает разработке и как начать делать тоже самое. 

Меня зовут Аят, я Android-инженер команды антифрода в inDrive. Эта статья не связана с продукционной разработкой, но будет касаться программирования. Я расскажу о Dynamic Programming (DP) и о том, как эффективно использовать предыдущий computation-опыт. Надеюсь, будет интересно. 

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

Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. В этой статье буду делиться своим выводами, а также прикладывать дополнительные ссылки, чтобы познакомить вас с материалом более подробно.

Live Activity был показан Apple на презентации iOS 16 и нового iPhone с Dynamic Island. Обновление доступно только для тех, кто обновил iOS до 16.1. 

Меня зовут Азиз, я iOS-разработчик в inDrive. В статье расскажу, как мы добавляли Live Activity в наше iOS-приложение. Постараюсь ответить на все вопросы, которые возникли у нас в процессе разработки.

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

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

Про жизненные неурядицы и то, как мы их решали и продолжаем решать — об этом и немного об устройстве DWH в inDrive я и расскажу. А еще на примере кейсов разберу, что в проекте может пойти не так.

Стейт-менеджеры уже давно стали своеобразным мемом среди разработчиков. Бытует мнение, что фронтедеры только тем и занимаются, что вместо решения действительно важных и актуальных проблем постоянно переписывают проект с одного стейт-менеджера на другой. Благо их количество и поток новых, выходящих в open source, позволяют. 

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

Меня зовут Женя, я все еще фронтенд-разработчик в команде Quick Experiments inDrive. И я тоже не люблю выделяться из толпы, поэтому предлагаю обратить внимание на новое решение от команды Preact — Signals. Во вступительной статье создатели библиотеки заявляют о том, что сегодня создано огромное количество решений по управлению состоянием приложения, но они требуют сложной и долгой интеграции с фреймворком. Это усложняет проектирование, так как нужно постоянно держать в уме особенности стейт-менеджера. Усложняется и разработка, так как нужно тратить много времени и сил на интеграцию стейт-менеджера и библиотеки рендеринга. 

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

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

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

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

Мы используем preact/compat — с его помощью получаем доступ к множеству библиотек экосистемы React, что делает разработку более гибкой, и при этом можем использовать Preact. Но эти же плюсы зачастую оборачиваются в обратную сторону: например, нет единой методологии по проектированию приложений, как, например, в Angular. Кроме того, многообразие библиотек усложняет погружение в проект, а свобода в реализации и проектировании может обернуться захламлением кодовой базы, что пугает разработчиков, особенно новичков. 

Я встречал проекты, в которых раскиданы несколько одинаковых по функционалу компонентов. Например, пять вариаций одной кнопки, а чистые UI-компоненты находились рядом с компонентами, напрямую связанными с доменной областью приложения.

Для нашей команды эти проблемы также актуальны. Чтобы их решить раз и навсегда, мы обратились к активно развивающейся методологии Feature-Sliced Design (FSD). Ниже я познакомлю с ее главными принципами и с нашим опытом ее использования. Забыл представиться — я Женя, фронтенд-разработчик в команде Quick Experiments inDrive. Расскажу, как мы занимаемся разработкой внутренних стартапов на основе бизнес-гипотез с помощью FSD.

Когда заходит речь про тени на Android, возникает сразу несколько вопросов. Первый: зачем они нужны? Второй: почему нельзя использовать системные тени и жить счастливо? Третий: если нельзя использовать системные тени, как реализовать кастомные?

Это Сергей Петров, Android-разработчик в команде Design System inDrive, и вместе мы поговорим о тенях на Android.

Всем привет! Я Айыына Егорова, Agile Coach в inDrive. Хочу поделиться небольшим опытом работы с командами без спринтов с применением Kanban-метода. Cтатья будет полезна руководителям команд, скрам-мастерам и любым агентам изменений.

Вы узнаете, как быстро запустить работу в команде без спринтов: с чего начать, какими инструментами мы пользуемся в компании и какие ошибки нельзя допускать. Отдельно разберем пример проведения воркшопа STATIK в команде Localization.

Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент. 

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

Я Лиза, UX писатель в inDriver. В предыдущих статьях я рассказала про то, кто такой UX писатель, зачем он нужен продукту, и чем отличается UX писатель от копирайтера. Если пока не знаете ответов на эти вопросы, советую начать с этих материалов. Если вы уже погружены в сферу — приятного чтения!

Всем привет, меня зовут Авксентий, я backend-разработчик в inDriver. Думаю, каждый начинающий разработчик сталкивался с проблемой, как правильно выстроить архитектуру и структуру проекта. Ведь организация кода проекта — постоянно развивающаяся проблема, а следование стандартной структуре сохраняет чистоту кода и повышает производительность команды. 

Когда я начинал писать на Go, то потратил много времени на поиски стандартов структурирования проекта. В итоге так и не нашел официального и точного стандарта — либо информация была неполной, либо это было не то, что нужно. Я решил написать свой гайд на основе опыта. Он для начинающих разработчиков и посвящен тому, как структурировать проект на Golang.

Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье хочу вольно порассуждать о схожести моделей когнитивной деятельности в тестировании ПО и расследовании уголовных дел. Мне кажется, у этих сфер много общего — например, оба процесса представляют из себя исследование результатов неправильного поведения, причин и следствий такого поведения и документирование результатов.

UX писатель (UXW) и копирайтер (CW) — две разные профессии. Их путают по одной причине: у них один и тот же основной рабочий инструмент — текст. 

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

Копирайтер и UX писатель не могут быть взаимозаменяемыми: у них разный опыт, цели и рабочие процессы. Без одного из них вселенная потеряет свою красоту и очарование или будет неудобной для жизни. Но почему писать все тексты не может только один специалист?

Я Лиза, UX писатель в продуктовой команде inDriver. В этой статье собрала отличия UX писателей и копирайтеров по пунктам и в картинках. 

Привет, Хабр! Я Екатерина Колесникова, Agile Coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement. Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании. 

Всем привет, я Алексей, iOS-разработчик в inDriver. Наше приложение представляет собой суперапп с множеством сервисов и услуг: городские, межгородские и грузовые поездки, курьерская доставка, услуги мастеров и так далее. Над каждым сервисом работают отдельные команды, которые имеют свободу принятия решений и вольны делать с продуктом почти все, что захотят.

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

Всем привет! Меня зовут Иван, я QA-инженер релизной команды в inDriver. В этой статье расскажу о том, как мы сократили время регрессионного тестирования релизной сборки мобильного приложения и релизный цикл до одной недели, с какими проблемами столкнулись и как их решали.

Ранее мы рассказали, как и почему перешли от хаотичных релизов к еженедельному выпуску нашего приложения на iOS и Android. Ниже поделюсь, как при этом мы уменьшили время проверки релиза с 3-4 дней для одной из платформ до 4 часов на проверку сразу двух платформ.

Хабр, привет. Я Леся, Senior QA Manual в команде Release Management. В статье поделюсь опытом проведения встреч формата 1-on-1 и правилами, которые я регулярно применяю. Расскажу, для чего нужна эта встреча, как вести себя на ней руководителю и сотруднику, а также какие ошибки могут допустить обе стороны. Поехали! 

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

Меня зовут Лиза, я UX писатель в продуктовой команде inDriver. UX писателей не всегда зовут в компанию в момент ее основания. Чаще всего о найме задумываются, когда продукт уже сформировался, и, кажется, все и так хорошо работает.

Но любой продукт можно бустануть с помощью хороших текстов. Давайте разберемся, как это работает, на примере нашего приложения inDriver.