​​Безопасность библиотек
#статьи

Вчера читал историю, в которой автор рассказал, как он легко воровал персональные данные пользователей. 

Он создал библиотеку, которая имела полезный функционал, но при этом отправляла данные с форм на сайте: пароли, номера карт, имена пользователей. При этом, зловред имел две особенности:
1) Не отправлял никаких данных между 7 утра и 7 вечера. Это значительно уменьшало шанс того, что отправку данных заметят. 
2) Если сайт запушен на локальном IP или домене, который содержал dev, test, qa, то не предпринималось никаких действий.

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

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

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

А. Ну и совет: проверяйте звездочки на GitHub!

В одном из чатов по Android обсуждался вопрос про тесты для разработчиков. Порекомедовали интересный ресурс.

Залип на этом ресурсе, здорово проверяет теорию. Кроме Android, есть много тестов по другим языкам программирования. Прошли больше 3 уровней с первого раза?

​​Кайдзен. Стратегия от японцев
#разработка #планирование

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

Основа состоит из 5 элементов, иначе 5S:
1) Seiri — аккуратность, сортировка. Нужно, чтобы на вашем рабочем месте остались только те вещи, которые используете. Важно убрать и очистить его от всякого хлама.
Мне кажется, что при разработке проекта и рефакторинге важно удалять ненужный код, а не комментировать его, надеясь, что он пригодится. В таком случае лучше взять из репозитория.

2) Seiton — порядок. Те вещи, которые остались, важно располагать на своем месте. Нужно, чтобы было удобно.
В разработке, важно правильно струкрурировать проект, не складировать все в одном месте и дробить функционал по классам и пакетам.

3) Seiso — чистота, уборка. Нужно всегда держать рабочее место в чистоте, выделять время на уборку, а не ждать конкретного захламления.
В кодинге выделяйте время на рефакторинг, очищайте проект от deprecated методов, обновляйте библиотеки.

4) Seiketsu — стандартизирование. Если есть повторяющиеся действия, то опишите их и стандартизируйте. Не нужно тратить время на обдумывание того, что уже было решено.
Важно использовать готовые решения, если они подходят.

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

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

Посмотрел доклад Максима Лапшина про опыт создания собственного продукта программистом. До своего бизнеса, он был веб-разработчиком.
Интересно было узнать о проблемах, которые возникли у автора.

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

Ну и куча других инсайтов. А, ну и ещё мысль: «Софт делает что-то, а продукт — решает проблему человека»

​​Решил попробовать новое для себя, вдохновившись статьей про голосового помощника.

В статье описывается создание приложения для голосового помощника на основе Android Things. Автор использует NXP Pico i.MX7D, но я решил заказать более мощную поддерживаемую версию — Raspberry Pi 3. Зашел на любимый многими китайский ресурс и заказал его.

Теперь буду пробовать всякие интересные вещи, связанные с #things. А кто-нибудь делал что-то интересное с этой библиотекой?

Нашим следующим респондентом в рубрике «Интервью с разработчиком» будет Николай Ясинский.

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

​​Яндекс.Заправки
#приложение

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

А недавно попалось мне приложение Яндекс.Заправки. Одним из способа выбора ниши в бизнесе является «боль». Предприниматель видит проблему, которая встречается в жизни, видит решение и предлагает его. Мне кажется, что это приложение как раз и решает хоть и небольшую, но проблему. Теперь можно не выходить с машины в мороз, чтобы оплатить топливо и не обязательно видеть недовольных теток на кассе. Да и вообще стоять в очереди, если спешите.

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

​​Developer Assistant
#разработка #приложение

Попалось приложение для дебага, которым не терпится поделиться. Developer Assistant очень помогает в разработке и исследовании любых установленных приложений. По функционалу напоминает Chrome’s Developer Tools.

Что же умеет? Есть несколько вкладок. Дизайнеры, разработчики и тестировщики могут быстро проверить размер, стиль, свойства и положение View. Причем видны все идентификаторы элементов. Для переводчиков, доступен перевод конкретной строки в приложении. Работает шикарно.

Какие же недостатки? Если используете кастомную View, то приложение не покажет вам её класс в приложении. Это было бы удобно для отдела тестирования. Само приложение платное, хотя лицензия распространяется на Google-аккаунт, так что для офиса вполне можно купить. Первые 30 дней бесплатно, так что посмотреть кучу приложений сможете без труда.

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

Ужасно не терпелось рассказать про Assistant, хотя вчера уже делал разбор приложения. Интересно, а есть ли на iOS нечто подобное?

​​Код для марсохода
#разработка

Задумывались ли вы, что значит отказоустойчивое приложение? Для кого-то — 99.9% crash free в Crashlytics. Для других — полное покрытие тестами. Действительно, такие характеристики показывают, насколько хорошо работает приложение и как сильно разработчики задумались о различных сценариях поведения приложения.

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

А что если ошибка или краш софта приведет к потерям миллиардов долларов и нескольких лет подготовки? Недавно попалась лекция Джерарда Хольцмана из Лаборатории реактивного движения, который рассказал о стандартах программирования при разработке софта для марсохода Curiosity.

Например:
• 3,5 миллиона сверхнадежного кода на языке C;
• 10 строк кода в час в течении 5 лет;
• 40 разработчиков;
• обязательное тестирование всего кода;
• warning считается за ошибку;
• ежедневные сборки и анализ билдов на 5 анализаторах;
• штраф за сломанный билд;
• доска позора для разработчиков.

Наверное, такой продукт один из самых дорогих в мире. Интересно, сколько было бы приложений в Google Play, если бы такие подходы применялись к мобильной разработке?

​​Дизайн приложения
#разработка #статьи

Последние пару дней, читая статьи на Medium, попадаются авторы, которые рассказывают об опыте дизайна на Android.

Узнал, что в последней версии Android ввели Color management. Он помогает правильно отображать цвета на различных устройствах и добавляет расширенную поддержку цвета. Если приложению важно верное отображение цветов, то подобная опция будет очень кстати. Почитать подробности можно тут.

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

Ну и напоследок: статья, рассказывающая о разработке дизайна приложения Google Primer. Автор делится опытом создания образовательного приложения, в котором пользователи могут быстро получать нужные знания, уделяя приложению минимум времени.
Интересная статистика: только 3% взрослых с США ежедневно тратят время на обучение чему-то новому.

Друзья! Я хочу провести небольшой опрос. Очень интересно, кто меня читает.
Пожалуйста, ответьте на вопросы. Это поможет мне дать вам наиболее интересную и полезную информацию.
- опрос не займет много времени, это очень быстро (буквально 10 секунд);
- анонимно: полученную информацию я хочу использовать исключительно в целях улучшения качества контента.

Пожалуйста, не игнорируйте мою просьбу!😉

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

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

Рад, что вам хочется слышать о поэтапной разработке проекта. У меня есть задумка сделать разработку проекта, для начала какого-нибудь простого и рассказать о каждом этапе при его разработке: начиная от создания проекта и подключения библиотек, заканчивая вылизыванием дизайна и публикаей его в Google Play Market. Мне кажется, что это будет больше интересно новичкам. Подумаю над идеей и в путь.

При этом и дальше будут обзоры инструментов, сервисов и ресурсов, которые помогают при разработке. Их много, какие-то распространены, о каких-то никто и не слышал. Буду их пробовать, изучать, находить и говорить своё мнение о них. Кстати, если вам интересно послушать, что я думаю по поводу того или иного инструмента, то пишите.

Ну и постараюсь писать почаще. Хотя и это не всегда получается из-за недостатка времени. Но я помню про вас и не перестану поставлять контент. До новых постов!😉

​​Сегодня выходной, поэтому очередной топ статей из Medium
#статьи #medium 

1) Android Tasks: раз и навсегда.— (6 минут)
Уверен, что каждый Android-разработчик гуглил: «single instance Activity». Нужно смотреть в сторону launchMode, но ведь их не так уж и мало, и не все сразу очевидны. В статье автор объясняет каждый из Android Tasks, причем очень доступно. Даже если вы и сходу знаете их, то все равно не мешает освежить знания.

2) Android Strings XML. Советы и приемы. — (4 минуты)
Интересная статья о строковых ресурсах в Android. Как лучше сделать строки с цифрами? Как отключить проверку правописания для конкретного языка в редакторе? Как сделать строку непереводимой? Прочитав статью, узнаете ответы на эти и еще некоторые вопросы.

3) Советы по Deeplinking в Android. — (5 минут)
Каждому создателю приложения очень хочется, чтобы его продуктом пользовались как можно чаще. Deeplinking помогает в этом. Это технология, благодаря которой можно переместиться в нужный раздел приложения, например, с сайта. Удобно и оставляет положительное мнение о приложении. Автор делится советами по этой технологии и рассказывает о проблемах, с которыми ему пришлось столкнуться.

Быстрый запуск приложения. Статические запросы.
#разработка #опыт

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

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

В моём случае выяснилось, что идет получение статических данных с сервера. Выполняется параллельно 6 запросов, ожидается получение всех этих данных и идет запись в БД. После исследования, выяснилось, что данные не так часто меняются на сервере, и стоит получать все только один раз, а в дальнейшем дописывать изменения с определенной даты. Также, интересно, что для работы приложения постоянно нужны данные только из 4 запросов. Поэтому, дописав методы получения этих данных по timestamp получилась достаточно хорошая экономия по скорости и трафику.

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

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

Поэтому, если вам достался проект и он медленно открывается, то обратите внимание на то, какие запросы выполняются вначале. Вроде простые меры, которые игнорируются и забываются.

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

​​Vysor
#приложение

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

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

Приложение устанавливает как плагин к Google Chrome, а также как приложение на телефон. В итоге получаешь возможность управлять экраном с компьютера.
В бесплатной версии есть реклама, которая появляется на экране, что немного напрягает.

Теперь, если у вас появится необходимость в удаленном управлении смартфоном, то вы знаете, какое приложение использовать.

Полезны ли паттерны?
#разработка

Ранее, я описывал паттерны. Уверен, что каждый разработчик сталкивался с реализацией конкретного паттерна, иногда не понимая, что это он.

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

1. Проверенное решение. Если какой-то код написан на основе паттерна, то давно известно, какие подводые камни могут встретиться при его использовании. Также, если вы пишите свой код на основе известного шаблона, то не нужно изобретать велосипед.

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

3. Улучшение кода и проектирования. Паттерны упрощают проектирование. Архитектуру приложения можно делать на основе известного шаблона. В Android, например Clean Architecture.

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

Отличный ресурс, где можно изучать шаблоны Refactoring.Guru. Всё объяснено простым языком, с примерами из жизни. Очень рекомендую.

А вы используете паттерны?

​​Хитрость дизайна
#дизайн

Попалась недавно статья о недобросовестном маркетологе и гениальном дизайнере.

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

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

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

Дефицит разработчиков
#думы

Вчера по радио услышал новость, что Россия к 2027 году столкнется с дефицитом кадров в IT-сфере. Это говорит Фонд развития интернет-инициатив (ФРИИ), ссылаясь на своё исследование. Вот и хочу порассуждать. Немного статистики и цифр.

Фонд утверждает, что в 2016 в РФ было 1,9 миллионов айтишников, что равнялось 2,4% от общего трудоспособного населения. При этом, ссылаются на статистику США, Великобритании и Германии, где показатель на уровне 4,3%. Разница ощутимая.

ФРИИ утверждает, что высшее и среднее специальное образование выпускает около 60К айтишников в год. Чтобы не было кадрового голода в будущем, необходимо увеличить это количество до 100К человек в год, что весьма сложно.

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

А вот интересно. Если взять человека, который дико хочет научиться разработке на Android. И взять опытного наставника, который понимает, что сейчас требуется на рынке и актуально в разработке: какие библиотеки, какие архитектурные паттерны, какие ресурсы читать, то за какое время возможно обучиться до уровня junior?

⚪️ — 3-6 месяцев;
⚫️ — 6-12 месяцев;
🔴 — 1-2 года;
🔵 — больше 2 лет.

​​Новый топ статей из Medium. Сегодня хочу дать вам статьи-советы. Каждая статья внутри содержит еще кучу полезных ссылок. Уверен, что найдете для себя что-то новое.
#статьи #medium

1) 30 советов для Android-разработчиков, которые я почерпнул из своего опыта. — (3 минуты)
Люди делятся на тех, кто испытывает все на своем опыте и на тех, кто следует советам других людей. Автор делится своим опытом Android-разработки и дает 30 отличных советов.

2) Android Development Best Practices. — (5 минут)
Иногда следует почитывать статьи о хорошем качестве кода и разработке, чтобы понимать, что ты все делаешь верно. Автор дает советы, основанные на своем опыте о архитектуре, тестировании, дебаге и подобных повседневных вещах каждого разработчика.

​​Заглушки
#дизайн

Уверен, что при создании дизайна списков, больше внимания уделяется состоянию, когда в нем содержится большое количество элементов. Если в списке 1 или 2 элемента, то чаще дизайн выглядит так же, как и при большем количестве объектов. Но много ли внимания уделяется состоянию, когда нет элементов?

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

1) Уделяйте им внимание. Помните, что нужно уведомлять пользователя о ситуациях, когда проявилась некорректная работа приложения. Пустой экран — бесполезен для пользователя.

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

3) Делайте заглушки разнообразными. Я не говорю о том, чтобы делать их в разной стилистике в одном приложении. Например, можно вместо статических изображений использовать кроссплатформенную библиотеку Lottie, которая прям создана для заглушек. Она хорошо работает, замечал баги только со скоростью воспроизведениям объектов.

4) Подумайте над текстами. Их тоже следует делать понятными. Не нужно использовать одинаковые тексты во всем приложении, типа "Что-то пошло не так" или «Неизвестная ошибка». Я думаю, что тут уместен юмор и можно написать сообщение, которое сгладит ситуацию. Но не стоит перебарщивать. Если у вас банковское приложение, то надпись «Ой, похоже ваши деньги кончились или наш банк не работает» выглядит как насмешка.

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