Вступление

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

Наверняка каждый программист, работающий с OAuth 2.0, задумывался – зачем же нужны Refresh токены, неужели Access токенов недостаточно? 64 KB — Их должно хватать каждому!

Эта тема довольно активно дискутируется – вот и на Stackoverflow вопрос есть и на Хабре тоже обсуждается. Собственно, именно обсуждение на Хабре и заставило меня высказаться.

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

«Refresh токен можно хранить более защищенно!» — можно и нужно, хотя почти никто так не делает.
«Access token передается по сети чаще – и вероятность его утечки больше» — полноте, мы ведь всегда используем TLS, правда?
«Утечка Ассеss токена на так страшна как утечка Refresh токена» — да, и это тоже правда, именно поэтому в браузер Refresh токен и не выдается…

Есть много нюансов, есть много сценариев использования, при которых использование разных токенов становится полезным, просто видно их не сразу!

Но есть и еще один аргумент, который я почему-то ни разу не встречал – хотя он, на мой взгляд, полностью объясняет, зачем же нужен Refresh токен и почему нельзя, абсолютно, категорически нельзя обойтись только Access токеном.

Производительность.

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

Вот только потом, когда встает вопрос о поддержке, рефакторинге и введении новых фич, оказывается, что в контроллерах у нас тонны кода, количество boilerplate застилает 4к экран, а вкорячивать новые фишки сложнее, чем переписать все снова. И вот вы уже снова перепиливаете все в стиле *уяк-*уяк и в продакшн…

А может стоило выделить время и выбрать не просто модную, а подходящую вашей задаче архитектуру?


Под катом ответы на распространенные вопросы и некоторые советы, которые помогут создать качественный продукт.

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

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

Если микросервис перестает отвечать на запросы в результате аварии, его клиенты должны быть мгновенно перенаправлены на резервный. Для управления потоком запросов часто используют так называемые очереди сообщений (message queues).

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

Некоторое время назад мы рассказали вам об автоматическом тестировании нашей Почты на Android и получили огромное количество вопросов от читателей. Сегодня приоткроем вам часть нашей «внутренней кухни», которая касается автотестирования на iOS. Для тестирования каждой сборки мы проводим более 500 автотестов, которые выполняются менее чем за один час. Как мы их реализовывали и зачем? С какими проблемами сталкивались и как смогли их решить? Обо всём этом читайте под катом.

Вопрос с реального собеседования (6 лет назад)

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

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

Прошел год. Оплата получена вся, 100%. А тех задание выполнено на 80%. Нужно ещё 20% сделать. Самое главное, что архитектор проекта утверждает — эти 20% в модель не вписываются, надо переписывать заново. Я, как кандидат на руководителя разработки, должен проанализировать ситуацию, принять решение, согласовать с заказчиком.

1 марта в офисе Avito состоялась очередная встреча сообщества iOS разработчиков CocoaHeads. Под катом вас ждут небольшой рассказ о том, как прошёл митап, и, самое главное, видеозаписи докладов. Приятного просмотра!

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

Введение

В последние годы вездесущие нейронные сети находят все больше и больше применений в различных областях знаний, вытесняя классические алгоритмы, использовавшиеся многие годы. Не стала исключением и область компьютерного зрения, где год за годом все больше и больше задач решаются при помощи современных нейронных сетей. Настало время написать об еще одном павшем бойце в войне "Традиционное зрение vs. Глубокое Обучение". Долгие годы на задаче поиска локальных особенностей изображений (так называемых ключевых точек) безраздельно властвовал алгоритм SIFT(Scale-invariant Feature Transform), предложеный в далеком 1999 году, многие сложили головы в попытках превзойти его, но удалось это лишь Deep Learning'у. Итак, встречайте, новый алгоритм поиска локальных особенностей — LIFT (Learned Invariant Feature Transform).

Наталия Ефремова погружает публику в специфику практического использования нейросетей. Это — расшифровка доклада Highload++.

Добрый день, меня зовут Наталия Ефремова, и я research scientist в компании NtechLab. Сегодня я буду рассказывать про виды нейронных сетей и их применение.

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

Первая часть моего доклада будет направлена тем, кто незнаком с нейронными сетями. Я занимаюсь непосредственно deep learning. В этой области я работаю более 10 лет. Хотя она появилась чуть меньше, чем десятилетие назад, раньше были некие зачатки нейронных сетей, которые были похожи на систему deep learning.

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



Но обработка данных — это не проблема. Проблема в том, как и в каком виде сохранять результаты обработки, чтобы с ними можно было удобно работать. В процессе разработки нам приходилось несколько раз полностью менять подход к организации хранения данных. Мы начинали с таблиц MyISAM, использовали LSM-деревья и в конце концов пришли к column-oriented базе данных. В этой статье я хочу рассказать, что нас вынуждало это делать.

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

Если спросить у десяти разработчиков о лучшей (или достойной) книге о проектировании, то как минимум 6 из них назовет книгу Боба Мартина «Принципы, паттерны и методики гибкой разработки». Если же после этого показать им на некоторые интересные моменты писанины «дядюшки» Боба, то большая часть из них с недоумением почухает лоб и несколько изменит свое мнение.

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

BaaS-платформы (Backend as a Service) сделали разработку и сопровождение backend'а для мобильных и веб-приложений достаточно простыми и предсказуемыми процессами. Одним из флагманов движения BaaS стала компания Parse, но в 2016 году она заявила о прекращении обслуживания клиентов с 2017 года.

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

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

Каждый раз когда в команду приходит новый сотрудник, приходится решать вопрос с тем, какие приложения стоит установить на его компьютер. Даже опытные разработчики не помнят всего списка того, чем они попользуются. Часть приложений запускается ежедневно. Часть — время от времени. Но, когда такого приложения нет под рукой — это часто становится потерей драгоценного времени. Как правило, первые дни отводятся на развертывание окружения и ознакомление со списком задач. Хорошо когда есть возможность пройтись по списку и отметить то, что было сделано перед погружением в проект. Из этих соображений был сформирован «портфель» с которым работает наша команда.

Знакомьтесь, Боб — матёрый ios разработчик, Алиса — не менее матёрая тестировщица. Дело было вечером дело было в пятницу. Боб дофиксил багу, вроде бы протестил на своих девайсах. Затем Боб запускает уже отточенные до автоматизма команды:

git checkout develop
git merge bug_fix_#999
git checkout master && git merge develop --no-ff ....
git push ....

На пуш на сервере срабатывает jenkins/teamcity/travis, который запускает билд. В это же самое время наш Боб пишет Алисе, что скоро пойдет домой, и хочет, чтобы аппа ушла сегодня в app store на апрув, дабы выиграть лишние пару дней, так как на носу выходные, если, конечно, приложение пройдет ручное тестирование Алисы.

Приложение Боба довольно обычное: пару сотен компилируемых класс файлов, еще с десяток cocoapods зависимостей ну и кучка сторибордов — Боб ценит своё время и время коллег поэтому не пишет UI в коде. Боб знает, что его приложение с чистого старта на сервере собирается за 4 минуты для develop версии, которое идет на тест Алисе, и столько же или чуть больше для production версии. Боб также знает, что ему нужно около 10 минут, чтобы дождаться окончания полной сборки и затем сообщить Алисе, что она может приступать к тестированию. Боб человек ответственный, поэтому по истечении 10 минут после пуша проверяет статус билда, так как знает, что сервер — это отдельный параллельный мир со своими правилами, законами и странностями.

Пятница, вечер, Боба отделяет от долгожданных выходных только 10 минут, после которых передаст эстафету Алисе. Боб вбивает в сафари bobcompany.ci/dashboard, где видит красную лампочку напротив своего приложения, глаза Боба потускнели, разочарованию не было предела. Боб жмет на show more, где его встречает ошибка:

Code Sign error: No codesigning identities found: No codesigning identities (i.e. certificate and private key pairs) that match the provisioning profile specified in your build settings (“com.company.bob”) were found.

Тут нервы Боба совсем сдают:

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

Введение

Если вы разрабатываете под Android, то наверняка сталкивались с тем, что открываете вы своё приложение, которое отлично работало несколько лет, и тут внезапно оказывается, что Apache httpComponents стали deprecated, и их не рекомендуется использовать. Сначала давайте разберём, что же произошло, а потом сделаем выводы, что делать.

Создатели шаблонов в C++ заложили основу целого направления для исследований и разработки: оказалось, что язык шаблонов C++ обладает полнотой по Тьюрингу, то есть метапрограммы (программы, предназначенные для работы на этапе компиляции) C++ в состоянии вычислить всё вычислимое. На практике мощь шаблонов чаще всего применяется при описании обобщенных структур данных и алгоритмов: STL (Standard Template Library) тому живой пример.

Однако, с приходом C++11 с его variadic-шаблонами, библиотекой type_traits, кортежами и constexpr'ами метапрограммирование стало более удобным и наглядным, открыв дорогу к реализации многих идей, которые раньше можно было воплотить только с помощью расширений конкретного компилятора или сложных многоэтажных макросов.

В данной статье будет разработана реализация бинарного дерева поиска времени компиляции: структуры данных, являющейся логическим «расширением» кортежа. Мы воплотим бинарное дерево в виде шаблона и попрактикуемся в метапрограммировании: переносе рекурсивных и не только алгоритмов на язык шаблонов C++.

Всем известный сервис Google Cloud Messaging (GCM) нужен для того, чтобы ваше приложение всегда показывало актуальные данные пользователю. Схема работы сервиса включает в себя три компоненты.



Непосредственно сервер GCM, ваш пуш-сервер и устройство с установленным приложением. Алгоритм работы простой: устройство регистрируется в GCM, получает registrationId – некий токен, который используется в дальнейшем, – сохраняет его у себя локально и передает серверу. Далее пуш-сервер использует этот registrationId для отправки сообщений вашему приложению на устройстве.

В этом материале будут рассмотрены проблемы на двух участках, который обозначены на схеме: пуш-сервер – GCM и GCM – устройство.

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