Друзья, наша рубрика «Интервью с разработчиком» продолжается. Следующий респондент — Евгений Мацюк. Евгений — тимлид Android-команды в Лаборатории Касперского и опытный разработчик.

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

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

В этом месяце был создан канал, и сейчас на нем больше 250 человек! Это очень много. Я счастлив, что вы меня читаете. Чувствую больше ответственности за те посты, которые даю Вам. Спасибо за то, что даете обратную связь.

Хочу пожелать вам успехов в профессиональном плане: интересных проектов, понимающих заказчиков, меньше непредсказуемых багов и крутую команду, где вы будете расти постоянно. Я в вас верю, и все у вас получится!
А в жизни желаю вам побольше здоровья, осознанности и удовлетворенности жизнью. Пусть каждый день будет счастливым! 💥

​​Книги по программированию
#книги #мысли

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

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

Сейчас, когда хожу по книжному магазину, и на глаза попадается книга по Android-программированию, то у меня есть два критерия-минитеста в переводе и проверка на качество и профессионализм этой книги:
1) Activity переведено как Активность.
2) Intent переведено как Намерение.

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

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

​​Нативная или кроссплатформенная разработка?
#разработка #мысли #вопрос

Представьте: вы работаете в команде, где создаются мобильные приложения. Поступает задача — создать новый экран на iOS и Android. Начинается работа:
- сделать дизайн;
- согласовать дизайн и внести коррективы;
- отдать в разработку программисту iOS и Android;
- отдать в тестирование две платформы;
- исправить баги;
- зарелизить.

Иногда бывают ситуации, что релиз нужно сделать одновременно.

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

Мое знакомство с кроссплатформенной разработкой произошло пару лет назад, когда планировался достаточно большой проект. Посмотрели в сторону Xamarin, который позволял создавать приложения для Android, iOS и Windows Phone. Почитав документацию и начав разработку, выяснилось, что продолжать создание этого проекта невозможно: появляются краши, которые непонятно как исправить из-за небольшого сообщества разработчиков; многие вещи по-прежнему нужно писать на три платформы в отдельности, экономия по времени небольшая.

Не так давно я увидел Flutter. Это SDK от Google, который позволяет создавать одновременно приложения на Android и iOS. В основе лежит язык Dart. Пока этот проект в alpha-режиме, поэтому страшно использовать его для коммерческих и больших проектов. Хотя уже сейчас есть несколько опубликованных проектов в Google Play и Apple Store.

Мое отношение к кроссплатформенной разработке сейчас такое же, как на картинке: если требуется создать что-то сложное и постоянно дорабатываемое, то без нативной разработки не обойтись. Сейчас нативная разработка позволяет сделать все, учитывая особенности операционной системы. Если же нужно создать что-то простое, типа «вывести список с сайта», то стоит смотреть в сторону кроссплатформенности для удешевления разработки.

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

Видели альтернативный Telegram для Android?

Судя по всему, это и есть Telegram X для Android. Меня дико радуют новые очень плавные анимации. Судя по отзывам, есть недочеты, нет некоторых функций и русского языка, но работа проведена огромная, да и пофиксят их вскоре. Он действительно быстрее.

Прям вдохновился внедрять больше красивых, плавных анимаций в свои проекты. Как вам клиент?

​​Выступления для программистов

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

- выступайте только тогда, когда хотите выложиться полностью, когда четко понимаете, о чем говорите;
- хороший доклад — это стендап, научно-популярное шоу, кино и Колизей (вопросы могут быть крайне неожиданными, и на них надо быть готовым ответить);
- не дублируйте то, что написано на слайде. При этом, на слайде должно быть написано мало. Хороший пример — манга и комиксы. Узнал про редактора Ольминского;
- стимулируйте фидбек, который можете получить до выступления и после;
- всегда перепроверяйте и перестрахуйте все моменты, связанные с техникой. То, что может сломаться, и даже не может, обязательно сломается в самый важный момент, за минуту до выступления!

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

Прокачивайте себя не только в кодинге!

Рад, что вы проявляете активность и пишите свои мысли. Делюсь мнением, которое прислал подписчик по поводу кроссплатформенной разработки.

«Как раз недавно изучал тему кроссплатформы. Смотрел на React Native. Он позволяет с помощью одного кода создавать нативный UI под разные платформы (в отличие от PhoneGap, Ionic и т.д., которые создают UI через html). React Native используется в Facebook, Instagram, AirBnB, Skype. У них есть блоги где расписано, как его используют, но по сути у всех это несколько экранов в основном приложении. Кроме того, есть Kotlin Native, но пока он позволяет шарить между платформами только бизнес-логику, о UI речь не идет. Выводы примерно такие же — если нужно быстро сделать небольшой проект, то да. Если что-то посерьезнее — лучше native пока ничего нет.»

​​Топ статей из Medium
#статьи #medium

1) Безопасность Android-приложения. — (10 минут)
Автор делится своими мыслями о безопасности приложения. Написано очень подробно, плюс к этому основан на собственном опыте разработки. Куча советов о том, как проверить безопасность своего приложения и как лучше его защитить.
https://medium.com/@yonatanvlevin/bang-bang-you-have-been-hacked-df82db3f2001

2) Как настроить структуру gradle? — (4 минуты)
Статья о том, как лучше организовать структуру gradle файлов.
https://medium.com/mobiwise-blog/let-me-tell-you-how-you-should-build-your-gradle-structure-f13e368e00a4

3) Дизайн адаптивных иконок. — (6 минут)
Рассказ о том, как создавать и применять адаптивные иконки приложений. Почерпнул для себя несколько полезных ресурсов, где можно быстро потестировать свои иконки.
https://medium.com/google-design/designing-adaptive-icons-515af294c783

60 fps повсюду
#библиотека

Каждый разработчик хочет, чтобы интерфейс его приложения выглядел максимально плавным.
Одним из показателей плавности интерфейса является показатель 60 fps.

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

Для меня отличным решением стала библиотека Tiny Dancer. Очень простая в установке библиотека, добавляет на экран числовую и цветовую метрику, которая показывает текущий fps. Кроме того удобна в тестировании и ее можно отключать в runtime, если в подсчете нет нужды.

​​Material Cue
#разработка #приложение

Уверен, каждый из Android-разработчиков знаком с Material Design. Для того, чтобы понять, следует экран отступам и размерам, которые прописаны в Material, есть отличное приложение — Material Cue.

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

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

​​Где лучше работать?
#мысли #вопрос 

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

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

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

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

В маленькой компании или стартапе, человек ощущает себя свободнее.
В самом начале карьеры, я работал в небольшой компании, где было 4 Android-разработчика. Сначала я верстал небольшие view, потом правил не критичные баги. Со временем, под контролем лида я получал значимые задачи, а вскоре было полное доверие. Мне кажется, что в огромной компании я бы не получил подобного роста, причем настолько быстро.

При этом, вероятность умереть у стартапа выше, чем у большой компании. Я работал в стартапе. Было очень интересно, команда и проект были отличные. Но вскоре начались финансовые проблемы...

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

Друзья, представляю вам следующее #интервью из нашей рубрики. Сегодня у нас на интервью Евгений Мацюк — тимлид Android-разработки в «Лаборатории Касперского».

Пообщались про архитектуру, поговорили про новые архитектурные компоненты от Google, о кроссплатформенной разработке и многом другом.
http://telegra.ph/Intervyu-s-razrabotchikom-Evgenij-Macyuk-Laboratoriya-Kasperskogo-01-10

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

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

Он создал библиотеку, которая имела полезный функционал, но при этом отправляла данные с форм на сайте: пароли, номера карт, имена пользователей. При этом, зловред имел две особенности:
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, если бы такие подходы применялись к мобильной разработке?