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

Меня зовут Вильян Яумбаев, в этой статье я расскажу вам про наши приключения на пути к SPM.

В 2015 ПСБ начал разрабатывать проект для бизнеса. Для него, в свою очередь, было нужно приложение. Сперва всё находилось в одном репозитории одного проекта в одном воркспейсе. Первые авторы подключали сторонние зависимости через CocoaPods, поскольку проприетарного менеджера зависимостей ещё не существовало. Но в тот же год в Apple началась работа над Swift Package Manager. Им предстояло встретиться в нашем проекте.

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

Нередкая ситуация: бизнес хочет быстро вносить изменения в такие справочники, как продуктовый каталог и тарифы. Уровень критичности этих справочников — mission/business critical. Самый быстрый вариант — менять сразу на проде. Но если вносить изменения в такие справочники без тестирования, то в случае ошибки рискуешь получить страховки с комиссией в разы больше или меньше нужной, да ещё полный сбой оформления кредитных заявок.

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

<Погрузиться в изменчивый мир бизнес-справочников/>

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

Но порой неизбежно вылезают различия. «Гражданский брак» значит разное для юриста и не-юриста. Обыватель назовёт цифрой то, что математик — числом. Слово «крайний» имеет особое значение для лётчиков и парашютистов.

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

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

Однажды бизнес попросил меня создать минималистичный график, который будет отображать сглаженную кривую с градиентом под ней. По этому графику можно перемещаться между значениями, водя пальцем. При этом за пальцем должна следовать вертикальная линия, а текущее значение должно отображаться в выноске — «баблике» с дополнительной информацией. В будущем хотелось бы заложить возможность поддержки нескольких графиков в одной координатной сетке. Версии iOS и Android должны быть максимально похожи. Примерно такие графики есть в системном приложении «Акции», в финансовых приложениях и фитнес-трекерах. 

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

В декабре мы участвовали в хакатоне «Цифровой прорыв» со своим кейсом. Мы просили участников разработать программное решение для онбординга 
новых IT-специалистов банка.

Задача состояла в том, чтобы объединить информацию из нескольких систем. И команды справились. Например, предложили web- + Android- + iOS-версии системы для хранения данных банка, чтобы новичку было удобно знакомиться с проектами, командой, правилами работы, системой и её архитектурой. Решения содержали разные варианты проверки знаний нового IT-специалиста. Так новичкам будет проще адаптироваться к работе в банке.

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

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

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

Мы не сможем показать техническую часть, как это реализовано, но расскажем всё остальное:

- как мы привлекали участников,

- функционал чат-бота,

- как выглядела геймификация,

- какие получили результаты.

Если вы тоже задумываетесь о подобном чат-боте для будущих конференций — наш опыт может вам пригодиться.

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

Меня зовут Татьяна Бельская, я работаю управляющим по обеспечению качества в Промсвязьбанке. Мы с коллегами отвечаем за процессы, которые влияют на качество работы всех наших систем.

У меня возникла потребность исследовать мировые тенденции QA, чтобы понимать, какие технологии сейчас актуальны, какие из них мы используем, насколько мы в тренде как компания и что стоит взять на вооружение. Исследование показало, что большая часть статистики и прогнозов основывается на данных «Мирового отчёт по качеству» (World Quality Report), поэтому я решила обратиться к первоисточнику. Анализ этой информации был чрезвычайно полезен при составлении стратегии развития нашего направления на ближайшие несколько лет. В этой статье я разобрала пять направлений отчета. Хочу поделиться итогами анализа и обсудить их с сообществом. Например, было неожиданно узнать, что в среднем по мировой статистике автоматизировано только 15–20% всех тестов, включая регресс. Если вам интересны тренды тестирования и что будет влиять на QA в 2022-м году — добро пожаловать под кат!

В этой статье мы расскажем про принципы безопасной работы с переключателями функционала – Feature Toogles: 

— Что из себя представляют переключатели функционала и для чего их использовать.

— Какие проблемы возникают при неправильном использовании.

— Что такое «горячие» и «холодные» переключатели, и как они способны решить проблемы из прошлого пункта. 

— Реализация «холодных» toogle-ов с помощью условной компиляции и линковки.

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

Начало декабря. Утро понедельника. В переговорной собралась команда для обсуждения планов на спринт.

Накидали несколько задач из бэклога. По требованиям — всё понятно, по срокам — всё адекватно, но в воздухе чувствуется какая-то недосказанность.

Владелец продукта кивнул, принимая тяжёлое, но важное для команды решение, и твёрдо произнёс: «Нам нужно поставить ёлку».

Мы не внедряли Sсrum ради Scrum’а — мы хотели дать клиентам онлайн-доступ к продуктам и сервисам банка и использовать обычный проектный подход, а не кросс-функциональные команды. Но у этой задачи была особенность, которая вынудила нас прийти к гибкой методологии.

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

Эту статью я решил написать под впечатлением от выступления Евгения Ртищева (@katleta) на конференции Mobius. Так же как и в его докладе, в этой статье я хочу показать, как можно, используя подзабытые нативные средства iOS, без труда выполнять простые и очень частые задачи.

Я расскажу о том, как предельно легко перенаправлять действия пользователя внутри приложения без ненужных усложнений — с помощью нативного инструмента под названием Responder Chain.

В мобильных приложениях табличные экраны занимают значительное место в общем объёме интерфейса. Это происходит благодаря их возможности отображать большое количество контента. Но есть и обратный эффект — программирование таких экранов порождает много однотипного кода.

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

Вне зависимости от того, какую архитектуру (MVC, MVVM, VIPER и др.) вы используете, компоненты из этой статьи помогут сократить время разработки, поиска и исправления ошибок и добавления нового функционала.

Многие из вас прекрасно знают, что такое Google Ассистент. Это голосовой помощник, подобный Siri, Алисе, Алексе и другим. Когда пользователь что-то говорит, Google Ассистент понимает это с помощью natural language understanding (NLU). NLU преобразует человеческую речь в специальную структуру данных, которую уже можно обработать.

У разработчиков Android есть возможность интегрировать NLU в свои приложения через специальный api, который называется App Actions. Точнее, существует два вида интеграции: мы можем получить и использовать Deep Link из речи пользователя или получить данные из приложения, не открывая его, и показать их прямо в Google Ассистенте через Slice.

Примечание

Слова layout, autolayout и constraints я перевёл, соответственно, как вёрстка, автовёрстка и ограничения.

Работа с автовёрсткой

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

Interface Builder неплох как визуальный редактор вёрстки. В нём есть индикация некорректных граничных параметров. Однако ваша вёрстка может отличаться от видимой в IB. На экран приложения могут влиять различные параметры — например, ответы на сетевые запросы или локально сохранённые данные. Более того, могут быть экраны, частично или полностью построенные на информации, заданной сервером. От сервера может поступать вообще всё что угодно, в том числе шрифты, цвета и формы.

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

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

●      Подробно расскажем про переиспользуемый провайдер табличного источника данных,

●      Покажем использование на конкретном примере,

●      Опишем результат с позиции SOLID,

●      Обсудим достоинства и недостатки подхода.

В основе решения лежат принципы SOLID. Цель состоит в том, чтобы составляющие элементы нашего подхода были независимыми, не влияющими друг на друга.

Девять из десяти экранов любого iOS-приложения имеют табличный вид. Неважно, как реализовано это представление — на UITableView или UICollectionView, но для его реализации необходимо каждый раз писать шаблонный код:

1) реализация табличного источника данных (UITableViewDataSource);

2) реализация табличного делегата (UITableViewDelegate);

3) реализация обратных уведомлений вью об изменениях данных;

4) типичный код по работе с различными коллекциями (плоские, секционные списки на основе массивов, упорядоченных множеств и прочих коллекций) и преобразование их к табличным структурам для источника данных коллекции;

5) все предыдущие пункты придётся повторить, если вы вдруг решите использовать UICollectionView.

Такое большое количество шаблонного кода значительно увеличивает время разработки, тестирования и ревью. Для уменьшения time-to-market мы в ПСБ создали микромодуль, который скрывает в себе весь шаблонный код. Новый модуль представляет собой набор абстрактных реализаций, лёгких в переиспользовании и достаточно универсальных для использования в 90% общих задач. В этой статье расскажем подробности.

В основном идея использования CI/CD для iOS, да и для других платформ, — это автоматизация рутинной работы. Когда мы работаем над одним приложением, можем вручную собирать небольшой проект. Но команда растёт, хочется тратить время эффективнее, чем вручную собирать проект или объяснять новичкам, что же там с Code-signing нужно делать.

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

В этой статье я хочу подробно рассказать о пути настройки Gitlab CI + Fastlane + Firebase + Testflight. Примеры приводятся на основе одного проекта, в котором участвовали 10 разработчиков. В конце будут описаны проблемы, с которыми мы сталкивались, и их решения.

Для кого будет полезен этот опыт? Для всех, кому нужен CI/CD и кто сидит на Gitlab. Для Github будет другая связка, например с Travis, — остальные компоненты неизменны. В нашей команде все используют Gitlab CI, Fastlane вместо голого xcodebuild для быстроты и удобства разработки, Firebase и Testflight.

Если у нас бесплатный Gitlab и мы укладываемся в лимит Firebase, то получаем бесплатное решение по настройке CI/CD.

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

Обо всем по порядку.