​​Выходной, воскресенье, самое время получить новый топ статей из Medium.
#статьи #medium

1) Базовое шифрование в Android. Что стоит делать, а что нет. (3 минуты)
Автор делится полезными вещами о шифровании Android-приложений. Показывает на противопоставлениях, что нужно делать для безопасности приложения, а каких вещей избежать. 

2) Разрешение конфликтов build.gradle. (4 минуты)
На практике несколько раз было так, что после добавления новой библиотеки в build.gradle не получается собрать проект. Одной из причин, почему так происходит — наличие пересекающихся зависимостей в новой и в одной из старых библиотек. Чаще это еще и разные версии, что может привести к нестабильной работе. Сама среда разработки подсказывает это. 
В статье автор дает способы лечения этой проблемы.

3) 10 советов для построения идеального продукта. (7 минут)
Порой мне нравится читать топы. Там часто даются вещи, о которых ты вроде знаешь, но статья снова тебе о них напоминает. Автор говорит о вещах, которые нужны для построения лучшего продукта. Это очень не просто, но к этому нужно постоянно стремиться.

Друзья, давно уже у нас не было свежего #интервью. Сегодня разговор с Николаем Ясинским — основатель проекта для разработчиков SHIFU, руководитель бизнеса в сфере IT и, конечно же, разработчик.

Надо ли идти разработчику свой бизнес? Стоит ли ограничивать разработчика? И можно ли стать разработчиком в 50 лет? Ответы на эти и другие вопросы в интервью.

Кандидат
#эксперимент

Итак, опишу человека, который желает обучиться Android-разработке.

Евгений. Не имеет опыта в разработке Android-приложений, но имеет достаточно большой опыт программирования на php. Есть опыт создания серверных приложений и работы с БД: mysql, sqlite, mssql.

Работает разработчиком и интересуется технологиями.

На мой взгляд, Евгений — отличный вариант для первого ученика:
• не нужно обучать базе программирования и ООП;
• есть понимание работы с базами данных;
• может самостоятельно создать и настроить сервер (а у нас будет обязательно клиент-серверное приложение);

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

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

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

Эксперимент начался, завтра напишу ТЗ для нашего проекта.

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

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

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

Список и правда впечатляет. Информация разбита по разделам, среди которых: система, батарея, камера, дисплей, сеть, сенсоры. Есть не только базовая информация, например размер дисплея в дюймах, но и продвинутая: user-agent в webview или версия OpenGL.

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

Техническое задание
#эксперимент

Итак, обещанное описание приложения. В следующем посте эксперимента опишу используемые библиотеки и подходы.

​​Надо ли наказывать людей в IT-сфере?
#думы #вопрос

В мире IT часто бывает так, человеку, недавно писавшему код, доверяют управление людьми. Тут начинается проблема: как себя вести с людьми? Как правильно наказывать и поощрять? Что делать для создания хороших условий труда?

Есть пара вещей, о которых стоит помнить при наказании:
1) Материальные наказания не эффективны. Если руководитель собирает по 100 рублей за опоздание на 5 минут, то человек купит абонемент на месяц, при этом наплюёт на авторитет начальника.

2) Если человек наказал сам себя, то не нужно его ещё как-то добивать. Наказания, которые идут от человека приносят гораздо бо́льший эффект.

3) Нельзя наказывать человека за те правила, которые до него не были доведены.

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

5) Не надо читать мораль. В такие моменты единственная мысль у человека: «Да когда ж этот гад-начальник уже заткнется».

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

Подробнее в статье. Там, кстати, шикарная инфографика.

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

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

У Йонатана звание Google Developer Expert, он сооснователь и технический директор компании KolGene, основатель Android Academy, автор многих статей по разработке.

Как всегда, вы можете задать ваши вопросы.

Смотрел видео про Raspberry PI. Стало интересно, а что вообще делают люди на этой платформе?

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

Первое больше похоже на 5 стартапов на Raspberry PI, но посмотреть было интересно. Порадовала платформа для создания роботов.

А тут видео про интересные проекты на Arduino и целый канал про разработку на нем. Дико понравилась копилка, которая сама считает монетки. Правда не уверен, что мне нужна такая штука в быту.

В общем, пока в поиске идеи для #things. Ведь хочется создать то, что можно хоть как-то применить в жизни.

​​Нужна ли безопасность в приложении?
#разработка #статьи

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

Но даже достаточно опытные разработчики не задумываются о безопасности своих приложений. Думаю, что не составит труда найти в Google Play не обфусцированный код в приложениях, а также важные данные в открытом виде.

Чаще всего такая ситуация возникает из-за недостатка времени на разработку. Бизнес требует фич. А о безопасности вспоминают тогда, когда это угрожает бизнесу. К сожалению, не все заказчики понимают, что это приводит к снижению качества приложения.

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

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

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

​​Используемые библиотеки
#эксперимент

Хочу описать то, что мы используем в нашем эксперименте:
• Kotlin — ранее уже писал о том, что сейчас не вижу смысла начинать новые проекты не на Kotlin. Не так давно добавлена официальная поддержка Google, синтаксический сахар, меньшее количество кода и популярность делают этот язык привлекательнее, чем Java в Android;

• Clean Architecture — если выбирать сейчас между Architecture Components от Google и Clean, то я выбираю второе. В ней решено большинство типовых вопросов, есть крутое русскоязычное сообщество и отличный кукбук. Кроме того, написано много крупных проектов. Architecture Components тоже хорош, но все же это пока достаточно молодой компонент и не стал бы его использовать в коммерческих проектах, а только для проб в небольших проектах;

• RxJava 2 — мощная библиотека, ставшая неотъемлемой частью мира Android. Мы будем использовать её для запросов к серверу, обработки данных и управления многопоточностью;

• Retrofit — использование в запросах к серверу;

• Glide — для загрузки изображений с интернета. В качестве альтернативы можно использовать Picasso;

• Room — для внутренней базы данных. Пока не добавляли эту зависимость, но для базы данных лучше использовать её. На мой взгляд, это сейчас наиболее удобная из БД;

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

Это не полный список используемых нами библиотек. Я не пишу тут support библиотеки, которые добавляются при создании проекта и обязательны, а также зависимости для социальных сетей. Это я буду описывать по мере использования их в проекте.

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

Классно, когда подход к поиску сотрудников творческий.

Попался тест от АльфаБанк для программистов. Тест состоит из 10 задач по Java, iOS, Android или JavaScript на выбор. Как обещают, лучшим предложат работу в «Альфа-Банке».

Ссылка на тест.

На сколько вопросов ответили?
⚪️ — 8-10;
⚫️ — 5-7;
🔴 — 3-4;
🔵 — меньше 3.

​​Что важно в работе?
#думы

Вы не задавали себе вопрос: почему вы работаете именно в том месте, где сейчас?

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

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

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

2) Проект. Я люблю делать проекты, которыми пользуются люди. Очень нравится получать от них реакцию, видеть их отзывы. Если постоянно делать «проекты-однодневки», то это не принесет внутреннего удовольствия. При устройстве на работу я обязательно оцениваю проект, который буду писать.

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

Кстати, вчера задумался о том, что у меня есть ещё вторичные критерии рабочего места. Пока придумал только один — лидерство руководителя.

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

Ищите работу по душе, ведь на ней мы проводим треть жизни.

А скажите, довольны ли вы текущим местом работы?

​​Runtime Permissons — это зло?
#разработка #думы #дизайн

В выходные прочитал мнение, что анонсированные в Android Marshmallow разрешения налету — это плохо.

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

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

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

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

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

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

Задача.
Имеется n-полей для ввода текста, а также кнопка, которая отправляет данные с этих полей ввода. Нужно, чтобы все поля были заполнены. Если хоть одно не будет заполнено, то это не даст отправить данные (блокирует кнопку). Кнопка изначально будет заблокирована, так как ни в одном из полей нет текста.

Решение.
Одним из распространенных способов решения является добавление TextWatcher и дальнейшая обработка там блокировки кнопки. Решение имеет не мало кода и выглядит это не красиво.

В качестве альтернативы могу предложить решение через RxJava и RxBinding. Нужно использовать функции Observable.combineLatest() и RxTextView.textChanges(). Примерный код функции тут. Как-то Telegram не умеет красиво верстать исходный код.

Получилось 5 строк кода, благодаря которым мы без труда решили задачу.

Интересны ли вам видеть на канале подобные #советы?

​​Важность сервиса
#думы

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

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

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

3. Дают чуть больше, чем конкуренты. Уверен, что всем нравится получать бо́льшее за меньшие усилия. Здорово, когда сервис предлатает какую-то незначительную, но приятную мелочь после определенных действий. Например, при заказе авиабилета можно показать пару интересных, но не заезженных мест из этого города и погоду в этот день.

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

​​Подключение зависимостей
#эксперимент

Первое задание, которое необходимо выполнить в рамках эксперимента — это подключение зависимостей.

Обычный путь подключения зависимостей — добавление в build.gradle на уровне модуля строки вида:
implementation 'com.android.support:support-v4:27.1.0'

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

Для группировки зависимостей рекомендую использовать Gradle structure. Как сделать подобную структуру прочитайте тут.

В результате получаем структуру, которая имеет несколько преимуществ:
1) Читаемость. У нас появляется столбик с версиями библиотек, который лучше читается из-за уменьшения количества текста.

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

3) Переиспользование версии в смежных зависимостях. Во всех проектах используются com.android.support библиотеки, которые должны иметь одинаковые версии. При таком подходе получаем возможность повышения версии в одном месте.

​​Конец недели, и вот вам новый топ статей из Medium.
#статьи #medium

1) Написание модульного приложения на Android. — (4 минуты)
В статье описан достаточно интересный принцип построения приложения на Android — модульный. После разбиения на модули получаем уменьшенное время сборки и повторное использование модулей. 

2) Рассматриваем KTX для Android. — (13 минут)
Недавно компания Google анонсировала набор расширений Kotlin для Android-разработки. Автор подробно рассматривает нововведения, подкрепляя примеры кодом. Теперь разработка на Kotlin еще удобнее!

3) Приложение не отвечает. Что же делать? — (5 минут)
Небольшая статья о состоянии, когда «приложение не отвечает», что затрудняет использование приложения. Автор описывает способы выяснения и борьбы с этим состоянием.

Сегодня продолжу тему #советы

Задача
Есть два источника одних и тех же объектов. Например, база данных и сервер.
Данные, получаются из кэша БД быстрее, чем с сервера. Но актуальная информация на сервере. Хотим показать пользователю данные с кэша, а потом после прихода информации с сервера показать их.

Решение
Одним из рабочих вариантов - создание PublishSubject, который подписывается на изменение данных, и в который попадает информация из каждого Observable.
Если не использовать Rx, то решение становится огромным куском кода.
В качестве альтернативы хочу предложить оператор Observable.concatEager(observables). Он принимает список Observable, который включает в себя получение данных из кэша и из сети. В результате получение будет запущенно параллельно, и вернутся данные из кэша, затем из сети. Важно помнить о порядке входящих источников.

Читайте подробнее об операторе и изучайте исходный код.

​​Multicursor в Android Studio
#разработка

Сегодня хочу поделиться с вами одним недооцененным инструментом в Android Studio, который увеличивает скорость написания кода и рефакторинга. Этот инструмент Multicursor.

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

Для вызова инструмента выделите часть строки и нажмите CTRL + G (ALT + J в Windows/Linux). После этого курсор дублируется к такой же строке кода.

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

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

​​Как отрефакторить ресурсы?
#статьи #разработка

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

При этом не всегда понятно, как правильно рефакторить, чтобы ничего не отломалось.

Рекомендую изучить статью, где автор говорит о рефакторинге ресурсов приложения.
Если вкратце, то:
• изменение colors.xml и dimens.xml;
• создание тем на основе этих файлов;
• создание стилей и их применение к проекту;
• переименование drawable.

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

Немного о перфекционизме
#статьи #дизайн

Сегодня прочитал статью про перфекционизм в дизайне. Задавали ли вы вопрос, почему появляется это явление?

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

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

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

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

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

Ну и последнее. Фильтруйте критику, которую получаете. Бывают люди, которые хотят показать свою правоту, доказать, что они лучше вас, но не указать на ошибки.

А вы перфекционист?