Привет! Меня зовут Андрей. В Tinkoff.ru я отвечаю за системы принятия решений и управления бизнес-процессами. Я решил кардинально пересмотреть стек систем и технологий в своем проекте, мне были очень нужны свежие идеи. И вот, не так давно мы провели в Tinkoff.ru внутренний хакатон на тему принятия решений.

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

Я работаю бекенд-программистом в отделе внутренней разработки. Мы помогаем запускать новые бизнес линии, автоматизируем рабочий процесс и пытаемся сэкономить банку денег там, где это возможно (например отказаться от покупки лицензии на какой нибудь дорогой софт). Рабочий процесс у нас весьма стандартный: менеджеры придумывают бизнес-фичи, технологи их формализуют и ставят задачи, аналитики анализируют данные, а разработчики уже решают поставленные перед ними задачи. В жизни все сложнее, но вы и так это знаете.

Статья публикуется от имени Иванова Андрея и Батеевой Екатерины, neifmetus

Автоматизация мобильных приложений довольно молодая сфера: фреймворков много и многие проекты сталкиваются с проблемой выбора самого «быстрого, стабильного, простого в использовании». Также и мы около двух лет назад стояли перед выбором нового инструмента автоматизации тестирования Android приложений.
Все популярные инструменты так или иначе базировались на UIAutomator и Espresso, поэтому мы решили затестить их в чистом виде и сравнить с теми же Appium (самый популярный) и seeTest (использовался до этого, лучший среди платных на тот момент).

Из достоинств Appium можно выделить привычный многим WebDriver API, возможность использования большинства популярных языков и библиотек. Кроме этого, он широко используется во многих компаниях и позволяет писать тесты сразу под платформы iOS и Android. И, наконец, это бесплатное коробочное решение — что может быть лучше?

Так думали мы, пока не обнаружили следующие недостатки:

• низкая стабильность Appium Server
• нельзя взаимодействовать с публичными методами Activity (в 2018 году про создание backdoor в Appium рассказал в своей статье Николай Абалов из Badoo, прочитать можно здесь)
• сильно уступает по скорости выполнения тестов Espresso

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

Итак, фреймворк был выбран, оставалось найти остальные компоненты:

1. Runner — должен позволять запускать тесты параллельно и конфигурировать пулы устройств
2. Reporter — должен предоставлять удобочитаемый отчет, которым мог бы пользоваться любой член команды

Привет, меня зовут Илья. Я — iOS разработчик в компании Tinkoff.ru. В этой статье я сделаю краткий обзор основных изменений в Swift 5. Данные изменения описаны в release notes. Для тех, кто еще не ознакомился, добро пожаловать под кат!

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

Вступление

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

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

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

Всем привет!

Меня зовут Дмитрий. Так получилось, что я являюсь тим лидом в команде из 13 iOS разработчиков уже на протяжении двух лет. И вместе мы трудимся над приложением Тинькофф Бизнес.

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

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

Поехали!

Введение

Angular предоставляет удобный декларативный способ подписки на события в шаблоне, с помощью синтаксиса (eventName)="onEventName($event)". Вместе с политикой проверки изменений ChangeDetectionStrategy.OnPush подобный подход автоматически запускает цикл проверки изменений только по интересующему нас пользовательскому вводу. Иными словами, если мы слушаем (input) событие на <input> элементе, то проверка изменений не будет запускаться, если пользователь просто кликает по полю ввода. Это значительно улучшает
производительность, по сравнению с политикой по умолчанию (ChangeDetectionStrategy.Default). В директивах мы также можем подписаться на события на хост-элементе через декоратор @HostListener('eventName').

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

Статья публикуется от имени Кочеткова Александра и Красс Снежаны

Сколько отличий вы найдете за 10 секунд?



Наш тестировщик найдет ВСЕ отличия. И даже те, которые не видны. Ниже я расскажу о том, как он это сделает, но для начала немного введу вас в курс дела.

Всем привет! Меня зовут Илья, я — iOS разработчик в Tinkoff.ru. В этой статье я хочу рассказать о том, как уменьшить дублирование кода в presentation слое при помощи протоколов.

В прошедшие выходные наша команда участвовала в хакатоне. Я отоспался и решил написать об этом.

Это первый хакатон в стенах Tinkoff.ru, но в призах сразу же задали высокую планку — новый iPhone всем членам команды.

Итак, как все было:

В день презентации нового iPhonе команда HR прислала сотрудникам анонс про мероприятие:

На Google I/O 2018 была представлена замена существующим support-библиотекам — AndroidX

Изначально, support-библиотеки разрабатывались для обратной совместимости новых API-интерфейсов и были тесно связаны с операционной системой. Разработка support-библиотек велась во внутренних ветках, которые периодически вливались в Android Open Source Project (AOSP). Такой подход ограничивал мерж пулл-реквестов от сообщества небольшими отрезками времени когда код AOSP и внутренний код гугла были синхронизированы. Кроме того, для работы с support библиотеками необходимо было выкачивать весь код платформы, а это более 40ГБ исходного кода. Для моего диска объемом 250 ГБ это достаточно много.

Согласно поправкам к 54-ФЗ, с июля этого года практически все торговые предприятия обязаны использовать онлайн-кассы, передающие данные через интернет в налоговую службу. Чтобы обзавестись таким аппаратом, придется купить кассу и фискальный накопитель, подписать договор и оплатить услуги оператора фискальных данных, зарегистрироваться в двух личных кабинетах ФНС и ОФД, вбить реквизиты в кассу, получить бумажный отчет о регистрации. Ну а еще понадобится электронная цифровая подпись, иначе придется приехать в ФНС и лично отстоять в очереди.



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

За последние несколько лет мы выработали общие подходы создания Android-приложений. Чистая архитектура, архитектурные шаблоны (MVC, MVP, MVVM, MVI), шаблон “репозиторий” и другие. Однако до сих пор нет общепринятых подходов к организации навигации по приложению. Сегодня я хочу поговорить с вами о шаблоне “координатор” и возможностях его применении в разработке Android-приложений.

Шаблон “координатор” часто используется в iOS-приложениях и был представлен Сорушем Ханлоу (Soroush Khanlou) с целью упростить навигацию по приложению. Есть мнение, что работа Соруша основана на подходе Application Controller, описанном в книге Patterns of Enterprise Application Architecture Мартином Фаулером (Martin Fowler).

Шаблон “координатор” призван решить следующие задачи:

• борьба с Massive View Controller проблемой (о проблеме уже писали на хабре — прим. переводчика), которая зачастую проявляется с появлением God-Activity (активити с большим количеством обязанностей).
• выделение логики навигации в отдельную сущность
• переиспользование экранов приложения (активити/фрагментов) благодаря слабой связи с логикой навигации

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

Многие сталкивались с проблемой реализации красивого отображения кнопок для UITableViewCell при сдвиге влево. Некоторые использовали стандартный функционал «из коробки», другие заморачивались над собственной реализацией, а кто-то обошелся Unicode-символами. В этой статье я расскажу как добиться максимальной кастомизации UITableViewRowAction.

Одна из полезных (по моему мнению) фич iOS 12, представленных на WWDC 2018 — Siri Shortcuts.

Шорткат (англ. shortcut) — быстрая команда, короткий способ совершить какое-либо действие в обход стандартному сценарию.

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

Вопросов о работе сервисов на этапах разработки, тестирования и поддержки очень много и все они на первый взгляд непохожи: «Что произошло?», «Был ли запрос?», «Какой формат даты?», «Почему сервис не отвечает?» и т.д.

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

Об одеяле и особенностях решения — далее.

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

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

После авторизации и создания ПИН-кода, аутентификацию пользователя можно переложить на плечи Windows Hello. Общая последовательность необходимых действий выглядит следующим образом:

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

Давайте рассмотрим каждый шаг подробнее на примерах кода.

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

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

• Прототип web-интерфейса
• Блог с редко обновляемым контентом
• Отдельная статическая часть другого web-приложения
• Сайт-визитка или landing-page
• Онлайн-документация