Предисловие

Что такое полнота по Тьюрингу?

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

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

Меня зовут Олег Чуркин. Я больше 10 лет занимаюсь разработкой на Python и сейчас руковожу разработкой нового процессинга платежей в QIWI. Расскажу, как мы реализовали boilerplate-шаблон для сервисов — на примере небольшого стартапа внутри нашей большой компании.

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

Меня зовут Василий Материкин, я — Android-разработчик в QIWI. В этом посте я расскажу о применении фича-флагов в QIWI Кошельке.

Внедрение Trunk-Based Development и Feature Flags

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

Поэтому мы решили перейти на Trunk-Based Development (TBD). TBD предлагает работать в небольших ветках и, желательно, чтобы они как можно быстрее были влиты основную ветку. Для этого, конечно же, реализацию нового функционала нужно оформлять небольшими пулл-реквестами, чтобы они быстро проходили ревью и были влиты в основную ветку. Это, в свою очередь, создает другую проблему — когда в главной ветке может появиться код, который ещё не готов к релизу, но при этом нам нужно как-то релизить с этим кодом приложение. Мы же релизы выпускаем достаточно часто. И для этого TBD предлагает пользоваться такими подходами, как Branch by Abstraction (BBA) и Feature Flags (FF).

BBA позволяет выделить какой-либо функционал в отдельную абстракцию. Для этого создается интерфейс, который описывает контракт для работы с этим функционалом. Сразу же можно создать его текущую реализацию, просто скопировав код, который сейчас в продакшене. Также создается другая реализация (уже с новым функционалом) и с ней уже начинается работа. То есть обычно первый пулл-реквест при работе с фичей — это выделение кода, создается две реализации, эти изменения вливаются в главную ветку и далее продолжаем работать уже над новой реализацией. При этом в проекте (в продакшене) используется всё ещё старая реализация, пока мы не закончим работать над фичей.

Это продолжение нашего рассказа о внедрении Kotlin Multiplatform Mobile в QIWI. Если хотите узнать больше про технику, посмотреть на код, переходите в первую часть. В этой статье будет больше контекста про то, как мы принимали решение, готовили прототип и внедряли технологию в команды. Наш опыт может помочь вам “продать” KMM в вашей компании и вашим стейкхолдерам. Я расскажу о плюсах и сложностях, с которыми мы столкнулись на нашем пути.

Немного истории

В QIWI мы часто пробуем что-то новое в наших процессах и в разработке. За последние 5 лет мы создали несколько приложений с нуля, используя разнообразные подходы. Например, мы впервые попробовали кросс-платформу, когда делали приложение QIWI Инвестор. Мы использовали инструмент J2ObjC, чтобы конвертировать общий модуль с кодом на Java на Objective-c для iOS. Это решение было смелым, но не самым надежным. По ходу использования было много проблем, самые большие — с конвертацией кода сторонних библиотек. В итоге проект закрылся, как и этот эксперимент. Кросс-платформенный подход оказался рабочим, но мы отложили его в сторону пока не появился более надежный инструмент.

В 2018 году мы перешли от платформенных команд к кросс-функциональным. Это стало самым большим изменением в процессе разработки c внедрения скрама. “Совместное владение кодом” стало нашей новой ценностью. Границы между платформами начали размываться, мы стали внимательнее изучать код на других платформах, вместе принимали решения и делились лучшими практиками.

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

Меня зовут Кирилл Васильев, и я хотел бы рассказать, как мы в QIWI внедряли Kotlin Multiplatform Mobile (KMM). 

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

Слишком мало запятых

Привет! В следующий четверг, 9 декабря, мы проведём наш седьмой QIWI Server Party.

Обсудим оптимизацию приложений на MongoDB, поделимся опытом проведения интеграционного тестирования в условиях множества сторонних API. Кроме этого — рассмотрим проблему с распределенными транзакциями в микросервисной архитектуре и поговорим об автоматизации создания дашбордов. В этот раз — всё в формате онлайн-трансляции на нашем Youtube-канале.

Зарегистрироваться можно на этой странице.

Под катом — программа митапа.

Чаще всего, когда читаешь про security awareness или повышение киберграмотности, то речь идет о фишинговых атаках - поддельные письма, сайты, странные вложения и прочее. Конечно, фишинг по-прежнему остается одним из основных сценариев атаки на сотрудников, но повышение осведомленности не должно ограничиваться только этим.

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

Привет!

Продолжаем публиковать текстовые версии докладов с QIWI Server Party 6.0, в этом посте — Александр Прокопьев и Developer Experience. Про инструменты, их качество и развитие инструментов разработчиков в QIWI.

Если предпочитаете формат видео — держите.

А вот и текст.

У меня есть любимая притча. Мужик пилит дерево. Другой к нему подходит и спрашивает: 

— Как дела? Давно пилишь?
— Три дня уже.
— Что-то долго. Может, тебе стоит пилу заточить?
— Не, некогда точить, нужно дерево пилить. 

И в IT такое бывает часто. Работаешь над какой-нибудь рутинной задачей и думаешь, что вот наверняка есть какой-то инструмент, который может автоматизировать эту работу. Но сроки горят, и мы говорим себе: «Не в этот раз». И оставляем на потом. А когда работа завершается, мы быстро забываем про эту боль. 

Я, например, до сих пор использую старый SQL Developer для работы с базой данных, хотя все коллеги давно перешли на DataGrip. И они периодически подталкивают меня, а мне все лень. Кто-то пользуется Git-ом и никак не соберется с силами, чтобы изучить его поглубже, добавить в свой багаж более глубокие команды. А кто-то использует IDE и не изучает горячие клавиши или плагины, которые могут помочь в работе.

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

Эта статья - расшифровка доклада с QIWI Server Party

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

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

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

В кодинге главное — не кодинг

Привет!

Меня зовут Тимофей, и я продуктовый разработчик. О продуктовой разработке подробнее можно почитать тут. 

В моей работе многое строится на трейдоффах и компромиссах. В этой статье речь пойдёт о балансе между сроками и качеством разработки.

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

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

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

Я дико люблю ковыряться в чужом коде. Это одна из моих любимых специализаций. То есть я просто беру чужой код, анализирую его, читаю. Как я читал его раньше: я переводил код в русский язык. Описывал, что происходит по флоу кода, и пытался понять, что там происходит. Эти записи я в дальнейшем использовал как для написания статей в Confluence, так и для общего понимания происходящего.

С одной стороны, решение работающее. С другой, буквально через неделю-две я уже начинал сомневаться, достаточно точно ли я «перевел» с кода на русский язык? И тогда вспомнил про UML-диаграммы. И вместо того, чтобы записывать текст, стал визуализировать его и исписал неимоверное количество тетрадей. 

Но в какой-то момент подумал, что хорошо бы перевести все это в электронный вид, чтобы какой-то инкремент оставался. Не фоткать же, например, для документации, свою тетрадь с каракулями. Так я нашел инструмент PlantUML — opensource-решение, которое использует графическую библиотеку graphviz, превращающее код в наглядные схемы.

Давайте вспомним, что такое Unified Modeling Language. Чаще всего в университете UML используется для описания диаграммы классов.

Привет!

Это будет наш первый митап, посвященный разработке на Android. Бесплатно, можете как приходить лично (Москва, 2-й Кожуховский проезд, д.29 корп. 6. LOFT HALL №4 (Зал Andy Hall)), так и подключаться онлайн. Если решите прийти лично, главное — зарегистрироваться заранее.

Поделимся опытом внедрения Kotlin Multiplatform Mobile, расскажем о фича-флагах и единой системе обработки диплинков с кодогенерацией. Докажем на примере, что кубер не только для бэкенда, но и для фермы девайсов для автотестов. А ещё поговорим о том, как мы переходили на продуктовую разработку, о работе в наших командах и о том, как продать свои фичи бизнесу.

Всего будет 7 спикеров, среди которых специальный гость — Илья Линник, человек, работающий с Android более 10 лет и заставший первые API.

Что такое softPOS и для кого он пригодится