Git Immersion
#разработка #новичкам
Git — это мощная и сложная система для распределенного контроля версий. Кроме того, она является одной из самых распространенных систем для работы с кодом внутри команды разработчиков.
В начале пути программиста, могут возникнуть сложности с пониманием того, какие команды нужно изучить, как лучше использовать Git, как его правильно настроить. Я для себя открыл один качественный ресурс, который будет особенно полезен новичкам. Более опытным коллегам он поможет овладеть дополнительными командами при работе с Git, что откроет всем нам более эффективный путь в управлении исходным кодом.
Идея ресурса Git Immersion состоит в пошаговом применении команд во вновь созданном репозитории и постепенном понимании того, что там происходит. Курс достаточно обширный по количеству уроков, но они короткие и каждый касается одной или двух смежных команд.
#разработка #новичкам
Git — это мощная и сложная система для распределенного контроля версий. Кроме того, она является одной из самых распространенных систем для работы с кодом внутри команды разработчиков.
В начале пути программиста, могут возникнуть сложности с пониманием того, какие команды нужно изучить, как лучше использовать Git, как его правильно настроить. Я для себя открыл один качественный ресурс, который будет особенно полезен новичкам. Более опытным коллегам он поможет овладеть дополнительными командами при работе с Git, что откроет всем нам более эффективный путь в управлении исходным кодом.
Идея ресурса Git Immersion состоит в пошаговом применении команд во вновь созданном репозитории и постепенном понимании того, что там происходит. Курс достаточно обширный по количеству уроков, но они короткие и каждый касается одной или двух смежных команд.
👍1
Переработки в IT
#мысли #комментарии
Переработки — это печальная практика нашей индустрии. Большинство из нас перерабатывает, кто-то больше, кто-то меньше. И многие считают это уже не проблемой, а «особенностью» с которой просто надо смириться. Но так ли это?
Говоря о переработках можно выделить несколько ситуаций, с которыми может столкнуться каждый.
Например, есть задача выпустить релиз к определенному сроку, но постепенно приходит понимание, что выпустить релиз без переработок не удается. В этом случае, чтобы не подвести руководство и оправдать их ожидания или ожидания пользователей, разработчик вынужден перерабатывать. Подобные ситуации, на мой взгляд, не являются критическими, при условии их редкости. Если же руководство видит, что команда «справляется» с релизом в срок и начинает требовать такой же объем задач и дальше, то это уже проблема, которую стоит обсудить.
Вторая ситуация — это коллектив, который привык работать сверхурочно. И если ты привык работать как положено, то уходя вовремя ты попадаешь под неодобрительный взгляд коллег. В подобной ситуации также важны коммуникации. Если же руководство считает нормальным постоянную переработку, то это повод задуматься о смене работы.
Бываю и другие ситуации, которые могут возникнуть — это переработка ради опыта, денег или просто потому, что горишь проектом. Но все равно итог один — человек устает, теряет эффективность в своей работе и перегорает. Сверхурочная работа влияет и на физическое, и на психологическое здоровье. Даже если вы горите проектом и не чувствуете усталость сейчас, то все равно проблема вылезет позже. Поэтому, мой совет — отдыхайте, не перерабатывайте постоянно и восстанавливайтесь после краткосрочных переработок.
А как считаете вы? Насколько проблема переработок характерна для IT-сферы?
#мысли #комментарии
Переработки — это печальная практика нашей индустрии. Большинство из нас перерабатывает, кто-то больше, кто-то меньше. И многие считают это уже не проблемой, а «особенностью» с которой просто надо смириться. Но так ли это?
Говоря о переработках можно выделить несколько ситуаций, с которыми может столкнуться каждый.
Например, есть задача выпустить релиз к определенному сроку, но постепенно приходит понимание, что выпустить релиз без переработок не удается. В этом случае, чтобы не подвести руководство и оправдать их ожидания или ожидания пользователей, разработчик вынужден перерабатывать. Подобные ситуации, на мой взгляд, не являются критическими, при условии их редкости. Если же руководство видит, что команда «справляется» с релизом в срок и начинает требовать такой же объем задач и дальше, то это уже проблема, которую стоит обсудить.
Вторая ситуация — это коллектив, который привык работать сверхурочно. И если ты привык работать как положено, то уходя вовремя ты попадаешь под неодобрительный взгляд коллег. В подобной ситуации также важны коммуникации. Если же руководство считает нормальным постоянную переработку, то это повод задуматься о смене работы.
Бываю и другие ситуации, которые могут возникнуть — это переработка ради опыта, денег или просто потому, что горишь проектом. Но все равно итог один — человек устает, теряет эффективность в своей работе и перегорает. Сверхурочная работа влияет и на физическое, и на психологическое здоровье. Даже если вы горите проектом и не чувствуете усталость сейчас, то все равно проблема вылезет позже. Поэтому, мой совет — отдыхайте, не перерабатывайте постоянно и восстанавливайтесь после краткосрочных переработок.
А как считаете вы? Насколько проблема переработок характерна для IT-сферы?
👍1
Адаптируем RecyclerView
#разработка #библиотека
За последние несколько лет в Android поменялось много вещей. Но одна вещь остается неизменной: нам нужно отобразить пользователям данные в наиболее удобном для них виде. И если этих данных много, то мы используем список. Сегодня есть RecyclerView, которым мы отображаем списки уже несколько лет. Но так ли хорош RecyclerView или есть вещи, которые можно улучшить?
1) Adapter. Каждый RecyclerView для отображения данных использует адаптер. Если рассмотреть адаптер как паттерн, то это прослойка, которая позволяет интерфейсам уже созданных классов использоваться в других интерфейсах. Все адаптеры используют разные реализации ViewHolder, поэтому адаптер RecyclerView подходит под это определение. Но одной из наиболее известных ошибок, которая встречается в написании адаптеров является бизнес-логика внутри них. Надо помнить, что Adapter — это слой, который связывает логику отображения, и в нем нет места для бизнес-логики.
2) В любом адаптере надо переопределить много методов:
• установку данных в конструкторе или через сеттер;
• переопределить getItemCount();
• если есть несколько типов данных, то переопределить getItemViewType();
• переопределить onCreateViewHolder();
• ну и напоследок написать onBindViewHolder();
Если типов данных в списке много, то количество кода увеличивается. А с появлением нескольких адаптеров повторяющегося кода становится в разы больше.
3) DiffUtil — это класс, который решает проблему установки новых данных в адаптер, изменяя только те данные, которые нужно. Но недостаток в том же, что и во втором пункте: повторяющийся код. Для каждого Callback надо переопределить areItemsTheSame() и areContentsTheSame() и число этих методов растет в зависимости от числа типов элементов.
Этот список можно продолжать и дальше, ведь мы не касались обработки пустого списка, пагинации, выбора данных и прочих распространенных вещей.
Для решения этих и других проблему, рекомендую библиотеку OneAdapter, которая убирает большинство из этих недостатков. В ее основе лежит подход в создании модулей для биндинга ViewHolder, кликов, пагинации. Подробнее о библиотеке можно почитать в этой статье.
#разработка #библиотека
За последние несколько лет в Android поменялось много вещей. Но одна вещь остается неизменной: нам нужно отобразить пользователям данные в наиболее удобном для них виде. И если этих данных много, то мы используем список. Сегодня есть RecyclerView, которым мы отображаем списки уже несколько лет. Но так ли хорош RecyclerView или есть вещи, которые можно улучшить?
1) Adapter. Каждый RecyclerView для отображения данных использует адаптер. Если рассмотреть адаптер как паттерн, то это прослойка, которая позволяет интерфейсам уже созданных классов использоваться в других интерфейсах. Все адаптеры используют разные реализации ViewHolder, поэтому адаптер RecyclerView подходит под это определение. Но одной из наиболее известных ошибок, которая встречается в написании адаптеров является бизнес-логика внутри них. Надо помнить, что Adapter — это слой, который связывает логику отображения, и в нем нет места для бизнес-логики.
2) В любом адаптере надо переопределить много методов:
• установку данных в конструкторе или через сеттер;
• переопределить getItemCount();
• если есть несколько типов данных, то переопределить getItemViewType();
• переопределить onCreateViewHolder();
• ну и напоследок написать onBindViewHolder();
Если типов данных в списке много, то количество кода увеличивается. А с появлением нескольких адаптеров повторяющегося кода становится в разы больше.
3) DiffUtil — это класс, который решает проблему установки новых данных в адаптер, изменяя только те данные, которые нужно. Но недостаток в том же, что и во втором пункте: повторяющийся код. Для каждого Callback надо переопределить areItemsTheSame() и areContentsTheSame() и число этих методов растет в зависимости от числа типов элементов.
Этот список можно продолжать и дальше, ведь мы не касались обработки пустого списка, пагинации, выбора данных и прочих распространенных вещей.
Для решения этих и других проблему, рекомендую библиотеку OneAdapter, которая убирает большинство из этих недостатков. В ее основе лежит подход в создании модулей для биндинга ViewHolder, кликов, пагинации. Подробнее о библиотеке можно почитать в этой статье.
👍1
Android Lint в темной теме
#разработка #опрос #статьи
За последние пару лет мы увидели большое число приложений, которые обзавелись поддержкой темной темы.
Сегодня наличие темной темы является желательной для приложения, и многие пользователи с удовольствием устанавливают ее себе.
Но с появлением Android Q на большинстве устройств, всем нам придется сделать поддержку темной темы из-за того, что включение поддержки темного интерфейса вынесено теперь на системном уровне.
Есть несколько разных способов сделать темную тему в приложении, но самым первым шагом является удаление захардкоженных цветов из приложения.
Сегодня попалась статья, которая помогает в нахождении этих цветов при помощи Android Lint. Это здорово, что можно сэкономить время вместо того, чтобы тратить его на нахождение этих цветов вручную. Автор рекомендует установить эту проверку в CI, чтобы избежать появления новых цветов, которые не соответствуют правилам.
А у вас в приложении есть темная тема?
#разработка #опрос #статьи
За последние пару лет мы увидели большое число приложений, которые обзавелись поддержкой темной темы.
Сегодня наличие темной темы является желательной для приложения, и многие пользователи с удовольствием устанавливают ее себе.
Но с появлением Android Q на большинстве устройств, всем нам придется сделать поддержку темной темы из-за того, что включение поддержки темного интерфейса вынесено теперь на системном уровне.
Есть несколько разных способов сделать темную тему в приложении, но самым первым шагом является удаление захардкоженных цветов из приложения.
Сегодня попалась статья, которая помогает в нахождении этих цветов при помощи Android Lint. Это здорово, что можно сэкономить время вместо того, чтобы тратить его на нахождение этих цветов вручную. Автор рекомендует установить эту проверку в CI, чтобы избежать появления новых цветов, которые не соответствуют правилам.
А у вас в приложении есть темная тема?
👍1
Android Developer Roadmap
#разработка #статьи
Попалась любопытная схема — «дорожная карта» Android-разработчиков. Ведь в нашей довольно обширной области не всегда просто понять о каких вещах нужно знать, а какие стоит пропускать.
После изучения этой схемы, на мой взгляд, у вас не должно возникать ощущения того, что все это нужно знать, чтобы быть успешным разработчиком. Схема нужна больше для того, чтобы посмотреть, о каких вещах из нее вы слышали. Если же вы видите что-то совершенно новое, то стоит почитать пару статей об этой теме, чтобы иметь общее представление об этом.
Ссылка на roadmap тут.
#разработка #статьи
Попалась любопытная схема — «дорожная карта» Android-разработчиков. Ведь в нашей довольно обширной области не всегда просто понять о каких вещах нужно знать, а какие стоит пропускать.
После изучения этой схемы, на мой взгляд, у вас не должно возникать ощущения того, что все это нужно знать, чтобы быть успешным разработчиком. Схема нужна больше для того, чтобы посмотреть, о каких вещах из нее вы слышали. Если же вы видите что-то совершенно новое, то стоит почитать пару статей об этой теме, чтобы иметь общее представление об этом.
Ссылка на roadmap тут.
👍1
Java vs. Kotlin. Производительность
#статьи #комментарии
Сегодня приоритетным языком для программирования под Android, по мнению Google, является Kotlin.
Но спрашивали ли вы себя, какая производительность у этих двух языков?
В статье автор поставил себе задачу: сравнить производительность Java и Kotlin при выполнении одинаковых программ.
Для этого он воспользовался бенчмарком, где сравнивал версии нескольких программ на Java, сконвертированные версии с Java на Kotlin и Kotlin-idiomatic версии, которые использует все плюшки языка Kotlin.
В результате получилась любопытная диаграмма, в которой сравнивается время исполнения, использование памяти и нагрузка на CPU. Данных слишком много, поэтому удобнее посмотреть это в статье.
Любопытно, что в большинстве тестов победила Java: она обычно была лучше в управлении памятью и времени исполнения.
В моей практике я не наблюдал просадок производительности при использовании Kotlin.
Интересно, были ли у вас подобные случаи?
#статьи #комментарии
Сегодня приоритетным языком для программирования под Android, по мнению Google, является Kotlin.
Но спрашивали ли вы себя, какая производительность у этих двух языков?
В статье автор поставил себе задачу: сравнить производительность Java и Kotlin при выполнении одинаковых программ.
Для этого он воспользовался бенчмарком, где сравнивал версии нескольких программ на Java, сконвертированные версии с Java на Kotlin и Kotlin-idiomatic версии, которые использует все плюшки языка Kotlin.
В результате получилась любопытная диаграмма, в которой сравнивается время исполнения, использование памяти и нагрузка на CPU. Данных слишком много, поэтому удобнее посмотреть это в статье.
Любопытно, что в большинстве тестов победила Java: она обычно была лучше в управлении памятью и времени исполнения.
В моей практике я не наблюдал просадок производительности при использовании Kotlin.
Интересно, были ли у вас подобные случаи?
👍1
Как использовать Android Lint
#разработка #статьи
Одной из вещей, которую игнорируют Android-разработчики, является инструмент Android Lint. И причина этому то, что он для большинства он является раздражающим.
Даже при создании нового проекта и при его первой компиляции, можно увидеть несколько lint-warning, которые чаще всего игнорируются. Но Android Lint можно и нужно использовать как полезный инструмент, который помогает в написании качественного кода.
Я уже писал о том, как можно использовать свое правило для lint для нахождения «захардкоженных» цветов. Но вот небольшая инструкция о том, как настроить и использовать стандартные правила lint в своем проекте.
Для того, чтобы увидеть отчет по своему приложению, надо выполнить команду
Также можно настроить свои правила для lint. Хорошая статья об этом тут.
В свой проект я внес правила для показа ошибок при неиспользованных ресурсах и при отсутствующем переводе строк в приложении.
#разработка #статьи
Одной из вещей, которую игнорируют Android-разработчики, является инструмент Android Lint. И причина этому то, что он для большинства он является раздражающим.
Даже при создании нового проекта и при его первой компиляции, можно увидеть несколько lint-warning, которые чаще всего игнорируются. Но Android Lint можно и нужно использовать как полезный инструмент, который помогает в написании качественного кода.
Я уже писал о том, как можно использовать свое правило для lint для нахождения «захардкоженных» цветов. Но вот небольшая инструкция о том, как настроить и использовать стандартные правила lint в своем проекте.
Для того, чтобы увидеть отчет по своему приложению, надо выполнить команду
gradlew lint. В результате вы получите подробное описание всех потенциальных проблем в приложении. Большинство из них будут не критичные и связаны с «красивым» написанием кода. Также можно настроить свои правила для lint. Хорошая статья об этом тут.
В свой проект я внес правила для показа ошибок при неиспользованных ресурсах и при отсутствующем переводе строк в приложении.
👍1
Как удачно пройти собеседование на позицию Android developer
#статьи
В предыдущем посте я рекомендовал вам интересный канал, связанный с вопросами для подготовки к собеседованию.
А сегодня я предлагаю вам для просмотра полезную статью, в которой можно найти не только распространенные вопросы для проведения интервью, но и советы, как лучше запоминать эту информацию, как подготовиться, сколько времени нужно на подготовку.
Изучив представленные вопросы, поймал себя на мысли, что многие из них также задавали и мне на собеседованиях.
Ссылка на эту замечательную шпаргалку тут.
#статьи
В предыдущем посте я рекомендовал вам интересный канал, связанный с вопросами для подготовки к собеседованию.
А сегодня я предлагаю вам для просмотра полезную статью, в которой можно найти не только распространенные вопросы для проведения интервью, но и советы, как лучше запоминать эту информацию, как подготовиться, сколько времени нужно на подготовку.
Изучив представленные вопросы, поймал себя на мысли, что многие из них также задавали и мне на собеседованиях.
Ссылка на эту замечательную шпаргалку тут.
👍1
Статический анализ кода
#разработка #комментарии
Одной из последних задач, которую я решал на текущем проекте, была добавление статического анализа кода. Перед началом работы казалось, что задача тривиальная и не вызовет каких-то сложностей. Но для того, чтобы посмотреть все обилие существующих решений, попробовать их и понять, какое из них работает потребовалось большое количество времени.
• SpotBugs — достаточно распространенное решение, которое позволяет строить отчеты по текущей базе кода. Решение, которое не заработало у меня на проекте из-за наличия flavor.
• Infer — решение для статического анализа от Facebook, основано также на отчетах. Кроме того, позволяет строить отчеты для вновь добавленного кода. Не смог оценить решение из-за странных несовместимостей с последней версией JDK. Но выглядит интересно.
• Gnag — представляет из себя комбайн нескольких решений: checkstyle, pmd, findbugs, ktlint, detekt. Шикарное решение, которое работает сейчас на нашем проекте. Отдельной крутой фичей является анализ пулреквеста и добавление комментариев в нем, что позволяет встроить Gnag в CI.
• SonarQube — представляет из себя утилиту для детального отчета на сервере, показа текущего статуса приложения и количества критичных багов. Очень удачное решение, однако стартовая версия имеет ряд ограничений: анализ только master-ветки, отсутствие интеграции в CI, отсутствие интеграции с GitHub. Но получать отчет и анализировать его вы сможете и в ней.
После поиска, я пришел к выводу, что есть очень мало бесплатных и хорошо работающих решений. Некоторые из них работают плохо, другие невозможно подключить к проекту из-за непонятных несовместимостей с текущими библиотеками. И я уже не говорю про встраивание их в процесс CI. Остаются только платные решения, благо цена на них не слишком высока для коммерческих проектов, а для open-source чаще всего и вовсе отсутствует.
А что вы используете на своих проектах?
#разработка #комментарии
Одной из последних задач, которую я решал на текущем проекте, была добавление статического анализа кода. Перед началом работы казалось, что задача тривиальная и не вызовет каких-то сложностей. Но для того, чтобы посмотреть все обилие существующих решений, попробовать их и понять, какое из них работает потребовалось большое количество времени.
• SpotBugs — достаточно распространенное решение, которое позволяет строить отчеты по текущей базе кода. Решение, которое не заработало у меня на проекте из-за наличия flavor.
• Infer — решение для статического анализа от Facebook, основано также на отчетах. Кроме того, позволяет строить отчеты для вновь добавленного кода. Не смог оценить решение из-за странных несовместимостей с последней версией JDK. Но выглядит интересно.
• Gnag — представляет из себя комбайн нескольких решений: checkstyle, pmd, findbugs, ktlint, detekt. Шикарное решение, которое работает сейчас на нашем проекте. Отдельной крутой фичей является анализ пулреквеста и добавление комментариев в нем, что позволяет встроить Gnag в CI.
• SonarQube — представляет из себя утилиту для детального отчета на сервере, показа текущего статуса приложения и количества критичных багов. Очень удачное решение, однако стартовая версия имеет ряд ограничений: анализ только master-ветки, отсутствие интеграции в CI, отсутствие интеграции с GitHub. Но получать отчет и анализировать его вы сможете и в ней.
После поиска, я пришел к выводу, что есть очень мало бесплатных и хорошо работающих решений. Некоторые из них работают плохо, другие невозможно подключить к проекту из-за непонятных несовместимостей с текущими библиотеками. И я уже не говорю про встраивание их в процесс CI. Остаются только платные решения, благо цена на них не слишком высока для коммерческих проектов, а для open-source чаще всего и вовсе отсутствует.
А что вы используете на своих проектах?
👍1
AppsConf 2019. Список докладов
#конференции
Совсем скоро будет проходить конференция AppsConf 2019 в Санкт-Петербурге. Сегодня можно полностью посмотреть список докладов и выбрать для себя потенциально интересные. Для себя уже отметил несколько:
Например, в докладе «История одного pet-проекта» интересно будет послушать про то, как вывести свой проект на пассивный доход и какие качества нужны человеку, который хочет делать свой проект. Возможно, это будет хорошей мотивацией наконец начать писать собственное приложение.
В докладе «Хакатон или пишем приложение за ночь» любопытно послушать про хакатоны и их пользу мобильным разработчикам. Никогда не участвовал в них, поэтому будет полезно понять, нужно ли мне это.
Доклад «Android Insets - разбираемся со страхами и готовимся к Android Q» поможет побороть проблемы прозрачного статусбара и появления клавиатуры. Сам активно использую Insets в проектах, рекомендую изучить эту тему.
В докладе «New Android Project - The Most Important Decisions» любопытно послушать про то, как начинать новый проект и какими практиками пользоваться. Конечно, это тема очень субъективная и любой разработчик берет в новый проект уже зарекомендовавшие себя библиотеки и подходы, но, возможно, получится узнать что-то новое.
Следующий доклад поведает особенности работы в распределенной команде. Мне всегда интересны подобные доклады, так как сам работаю удаленно, и подобные практики можно применить в своей команде.
Докладов очень много, каждый сможет найти для себя интересное!
#конференции
Совсем скоро будет проходить конференция AppsConf 2019 в Санкт-Петербурге. Сегодня можно полностью посмотреть список докладов и выбрать для себя потенциально интересные. Для себя уже отметил несколько:
Например, в докладе «История одного pet-проекта» интересно будет послушать про то, как вывести свой проект на пассивный доход и какие качества нужны человеку, который хочет делать свой проект. Возможно, это будет хорошей мотивацией наконец начать писать собственное приложение.
В докладе «Хакатон или пишем приложение за ночь» любопытно послушать про хакатоны и их пользу мобильным разработчикам. Никогда не участвовал в них, поэтому будет полезно понять, нужно ли мне это.
Доклад «Android Insets - разбираемся со страхами и готовимся к Android Q» поможет побороть проблемы прозрачного статусбара и появления клавиатуры. Сам активно использую Insets в проектах, рекомендую изучить эту тему.
В докладе «New Android Project - The Most Important Decisions» любопытно послушать про то, как начинать новый проект и какими практиками пользоваться. Конечно, это тема очень субъективная и любой разработчик берет в новый проект уже зарекомендовавшие себя библиотеки и подходы, но, возможно, получится узнать что-то новое.
Следующий доклад поведает особенности работы в распределенной команде. Мне всегда интересны подобные доклады, так как сам работаю удаленно, и подобные практики можно применить в своей команде.
Докладов очень много, каждый сможет найти для себя интересное!
👍2
Android Chatroom With Firebase
#разработка #статьи
Сегодня попалась статья о создании своего небольшого приложения-чата, используя в качестве backend составляющей Firebase.
Все из нас так или иначе пользуются сервисами от Firebase. Но мало кто пользуется ими на всю мощь. Если разобраться и посмотреть на то обилие сервисов, которое предоставляет Firebase, то можно увидеть, что клиент-серверное взаимодействие можно выстроить и без наличия сервера. Например, тут есть и авторизация, и база данных, и облачное хранилище, ну и всем известные пуш-уведомления.
Ссылка на статью, где можно посмотреть использование всех этих инструментов тут.
#разработка #статьи
Сегодня попалась статья о создании своего небольшого приложения-чата, используя в качестве backend составляющей Firebase.
Все из нас так или иначе пользуются сервисами от Firebase. Но мало кто пользуется ими на всю мощь. Если разобраться и посмотреть на то обилие сервисов, которое предоставляет Firebase, то можно увидеть, что клиент-серверное взаимодействие можно выстроить и без наличия сервера. Например, тут есть и авторизация, и база данных, и облачное хранилище, ну и всем известные пуш-уведомления.
Ссылка на статью, где можно посмотреть использование всех этих инструментов тут.
👍1
Быть успешным и быть занятым — не одно и то же
#разработка #совет #комментарии
В современном мире, есть негласное понимание того, что постоянно занятые люди — это успешные люди. Я сам замечал то, что при разговоре с друзьями, которые отвечают тебе, что они постоянно заняты работой, ты относишься к этому с пониманием и уважением. Быть трудоголиком — это значит идти правильной дорогой.
Правда, не так давно я узнал о технике, которая называется "Неделя обдумывания". Это достаточно распространенный прием среди руководителей крупных компаний.
Например, его использовал Билл Гейтс в те периоды, когда он был главой Microsoft. Он использовал его не только для себя, но и для менеджеров компании. Это были двухнедельные паузы, которые не входили в состав отпуска, и цель которых была — ничего не делать. Интересно, что в подобные периоды нельзя было общаться с семьей и друзьями. Гейтс считал, что подобная практика позволяла найти идеи, которые служили успехом для Microsoft.
Но чтобы попробовать подобную практику, не обязательно отстранять от себя семью и друзей на полмесяца. Существует более легкая форма данной практики.
В какой-либо выходной, субботу или воскресенье, попробуйте не пользоваться своим смартфоном и компьютером.
Звучит это легче, чем сделать. Ведь уже "на автомате" мы тянемся к смартфону с самого утра, чтобы проверить уведомления и социальные сети и ложимся спать со смартфоном в руках. Для меня, как и для многих, смартфон также является кошельком, которым мы платим в магазинах и кафе.
Говорят, что даже благодаря одному дню такой практики, мозг может расслабиться и следующая рабочая неделя начнется куда более продуктивнее.
Пробовали ли вы такую практику? Делитесь своим опытом в комментариях
#разработка #совет #комментарии
В современном мире, есть негласное понимание того, что постоянно занятые люди — это успешные люди. Я сам замечал то, что при разговоре с друзьями, которые отвечают тебе, что они постоянно заняты работой, ты относишься к этому с пониманием и уважением. Быть трудоголиком — это значит идти правильной дорогой.
Правда, не так давно я узнал о технике, которая называется "Неделя обдумывания". Это достаточно распространенный прием среди руководителей крупных компаний.
Например, его использовал Билл Гейтс в те периоды, когда он был главой Microsoft. Он использовал его не только для себя, но и для менеджеров компании. Это были двухнедельные паузы, которые не входили в состав отпуска, и цель которых была — ничего не делать. Интересно, что в подобные периоды нельзя было общаться с семьей и друзьями. Гейтс считал, что подобная практика позволяла найти идеи, которые служили успехом для Microsoft.
Но чтобы попробовать подобную практику, не обязательно отстранять от себя семью и друзей на полмесяца. Существует более легкая форма данной практики.
В какой-либо выходной, субботу или воскресенье, попробуйте не пользоваться своим смартфоном и компьютером.
Звучит это легче, чем сделать. Ведь уже "на автомате" мы тянемся к смартфону с самого утра, чтобы проверить уведомления и социальные сети и ложимся спать со смартфоном в руках. Для меня, как и для многих, смартфон также является кошельком, которым мы платим в магазинах и кафе.
Говорят, что даже благодаря одному дню такой практики, мозг может расслабиться и следующая рабочая неделя начнется куда более продуктивнее.
Пробовали ли вы такую практику? Делитесь своим опытом в комментариях
👍1
Kaspresso
#разработка #статьи
Существует довольно много команд, которые при создании приложения, игнорируют написание UI-тестов.
Одни считают, что это не нужно, так как приложение развивается слишком быстро и поддержка тестов отнимает слишком много времени. Другие думают, что проще нанять больше тестировщиков в команду, и это будет эффективнее, чем написание UI-тестов. Третьи считают, что написание подобных тестов – это неудобно.
И в самом деле, написание UI-тестов на Android – не сама легкая задача, тем более если использовать только Espresso для этого. Ведь даже самый простой код заставляет потратить некоторое время для того, чтобы понять, что там происходит. При использовании фреимворка Kakao ситуация становится гораздо лучше, однако также имеет ряд недостатков.
И вот ребята с команды Касперского решили улучшить ситуацию в написании этого вида тестов, и создали фреимворк Kaspresso.
Вот только некоторые из фич: возможность обращения к adb-командам, работа с Android напрямую (отключение сети, эмуляция звонков, обрабока runtime-разрешений), создание скриншотов, простая конфигурация каждого из сценариев.
Больше информации о фреимворке можно найти тут. А все вопросы, которые возникнут во время пользования библиотеки, можете задать в чатике.
#разработка #статьи
Существует довольно много команд, которые при создании приложения, игнорируют написание UI-тестов.
Одни считают, что это не нужно, так как приложение развивается слишком быстро и поддержка тестов отнимает слишком много времени. Другие думают, что проще нанять больше тестировщиков в команду, и это будет эффективнее, чем написание UI-тестов. Третьи считают, что написание подобных тестов – это неудобно.
И в самом деле, написание UI-тестов на Android – не сама легкая задача, тем более если использовать только Espresso для этого. Ведь даже самый простой код заставляет потратить некоторое время для того, чтобы понять, что там происходит. При использовании фреимворка Kakao ситуация становится гораздо лучше, однако также имеет ряд недостатков.
И вот ребята с команды Касперского решили улучшить ситуацию в написании этого вида тестов, и создали фреимворк Kaspresso.
Вот только некоторые из фич: возможность обращения к adb-командам, работа с Android напрямую (отключение сети, эмуляция звонков, обрабока runtime-разрешений), создание скриншотов, простая конфигурация каждого из сценариев.
Больше информации о фреимворке можно найти тут. А все вопросы, которые возникнут во время пользования библиотеки, можете задать в чатике.
Шаблоны проектирования
#статьи #новичкам
Одним из важных инструментов в работе любого программиста являются паттерны проектирования. Эти шаблоны описывают типичные способы решения часто встречающихся проблем при разработке программ.
Но часто замечаю, что мы, как разработчики, знаем их недостаточно хорошо. Думаю, что проблема в том, что и без их знания также можно программировать. При этом, код может быть достаточно высокого уровня. Однако, зная паттерны вы получите еще один инструмент в свою копилку.
Второй причиной изучения шаблонов является сокращение времени на решение проблем. Ведь можно просто взять готовое решение из паттерна, которое будет проще объяснить коллеге, который также может прочитать описание того шаблона, который вы использовали. Важно помнить и другую крайность: после изучения паттернов, разработчик стремиться применить все эти знания там, где можно было обойтись кодом проще.
Ну и последняя причина для использования — это собеседования. Подобные вопросы часто всплывают при приеме на новое место работы, их знания увеличат ваши шансы на получение нового места.
Для себя я выделил два источника для изучения паттернов: сайт Refactoring Guru, а также вот эта статья. Ресурсы будут одинаково полезны как новичкам, так и более опытным коллегам.
#статьи #новичкам
Одним из важных инструментов в работе любого программиста являются паттерны проектирования. Эти шаблоны описывают типичные способы решения часто встречающихся проблем при разработке программ.
Но часто замечаю, что мы, как разработчики, знаем их недостаточно хорошо. Думаю, что проблема в том, что и без их знания также можно программировать. При этом, код может быть достаточно высокого уровня. Однако, зная паттерны вы получите еще один инструмент в свою копилку.
Второй причиной изучения шаблонов является сокращение времени на решение проблем. Ведь можно просто взять готовое решение из паттерна, которое будет проще объяснить коллеге, который также может прочитать описание того шаблона, который вы использовали. Важно помнить и другую крайность: после изучения паттернов, разработчик стремиться применить все эти знания там, где можно было обойтись кодом проще.
Ну и последняя причина для использования — это собеседования. Подобные вопросы часто всплывают при приеме на новое место работы, их знания увеличат ваши шансы на получение нового места.
Для себя я выделил два источника для изучения паттернов: сайт Refactoring Guru, а также вот эта статья. Ресурсы будут одинаково полезны как новичкам, так и более опытным коллегам.
Jetpack Compose
#разработка
На прошедшем Google IO мы увидели одну достаточно интересную вещь, которая, по мнению Google, поможет разработчикам поддерживать и создавать интерфейсы в Android-приложениях — Jetpack Compose.
Compose — это инструментарий реактивного пользовательского интерфейса, полностью разработанный на Kotlin и он похож, например, на фреимворк, который есть в Flutter.
Jetpack Compose дает возможность использовать набор компонентов, которые можно легко комбинировать между собой. Важно понимать, что эти компоненты — не обертки над существующими View, а абсолютно новые функции, которые рисуют на Canvas и все они являются простыми виджетами со своим набором правил.
Как только появился Jetpack Compose, то для того, чтобы попробовать его, нужно было самостоятельно компилировать свою собственную версию Android Studio. Но с 10 октября Google анонсировал первую дев-версию Jetpack Compose, которую можно подключить к проекту как обычную зависимость.
Важно: не используйте этот инструмент для ваших прод-проектов, так как инструмент находится в начальной стадии разработки. Но это отличная возможность попробовать его, дать фидбек о тех недостатках которые вы заметили и повлиять на разработку такого крутого инструмента.
В этой статье найдете описание тех зависимостей, которые есть у Jetpack Compose, а тут — побольше информации о некоторых виджетах и примеры кода для старта.
Как вам новый инструмент от Google?
#разработка
На прошедшем Google IO мы увидели одну достаточно интересную вещь, которая, по мнению Google, поможет разработчикам поддерживать и создавать интерфейсы в Android-приложениях — Jetpack Compose.
Compose — это инструментарий реактивного пользовательского интерфейса, полностью разработанный на Kotlin и он похож, например, на фреимворк, который есть в Flutter.
Jetpack Compose дает возможность использовать набор компонентов, которые можно легко комбинировать между собой. Важно понимать, что эти компоненты — не обертки над существующими View, а абсолютно новые функции, которые рисуют на Canvas и все они являются простыми виджетами со своим набором правил.
Как только появился Jetpack Compose, то для того, чтобы попробовать его, нужно было самостоятельно компилировать свою собственную версию Android Studio. Но с 10 октября Google анонсировал первую дев-версию Jetpack Compose, которую можно подключить к проекту как обычную зависимость.
Важно: не используйте этот инструмент для ваших прод-проектов, так как инструмент находится в начальной стадии разработки. Но это отличная возможность попробовать его, дать фидбек о тех недостатках которые вы заметили и повлиять на разработку такого крутого инструмента.
В этой статье найдете описание тех зависимостей, которые есть у Jetpack Compose, а тут — побольше информации о некоторых виджетах и примеры кода для старта.
Как вам новый инструмент от Google?
AppsConf 2019. Утвержденные доклады
#конференции
Уже на следующей неделе в Санкт-Петербурге пройдет конференция для мобильных разработчиков — AppsConf. Полное расписание и список утвержденных докладов. А вот и список докладов, которые я обязательно посещу.
Например, доклад Евгения Идзиковского «Повышение своей эффективности. Гайд» расскажет о том, как получить прирост в своей производительности, как быть эффективным и как бороться с прокрастинацией. На первый взгляд, достаточно «заезженная» тема, но тем не менее интересно получить ответы на все эти вопросы от человека, которые имеет опыт.
Доклад «Из разработчика в стартаперы» расскажет о пути, который нужно было пройти автору, чтобы начать свой стартап. Послушать о подводных камнях подобных проектов всегда интересно.
В докладе «Keep it scrollin’: боремся с RecyclerView за каждый кадр» можно послушать про достаточно старый и распространенный компонент в любом Android-приложении — RecyclerView. Надеюсь узнать некоторые дополнительные приемы, которые можно применить для сложных списков.
Доклад «Animations in 2k19» расскажет о подходах к выбору построения анимаций, а также о таких современных и нужных компонентах, как MotionLayout и CoordinatorLayout.
Ну и для новичков во Flutter будет полезным доклад «Flutter. Опыт в продакшн-разработке». Будет много всего о том, как ведет себя Flutter в проде, как устроен CI/CD при работе с ним, ну и ответ на всех волнующий вопрос: возможно ли сейчас применять Flutter в проде?
Докладов очень много, каждый, как и я, сможет найти для себя интересное!
#конференции
Уже на следующей неделе в Санкт-Петербурге пройдет конференция для мобильных разработчиков — AppsConf. Полное расписание и список утвержденных докладов. А вот и список докладов, которые я обязательно посещу.
Например, доклад Евгения Идзиковского «Повышение своей эффективности. Гайд» расскажет о том, как получить прирост в своей производительности, как быть эффективным и как бороться с прокрастинацией. На первый взгляд, достаточно «заезженная» тема, но тем не менее интересно получить ответы на все эти вопросы от человека, которые имеет опыт.
Доклад «Из разработчика в стартаперы» расскажет о пути, который нужно было пройти автору, чтобы начать свой стартап. Послушать о подводных камнях подобных проектов всегда интересно.
В докладе «Keep it scrollin’: боремся с RecyclerView за каждый кадр» можно послушать про достаточно старый и распространенный компонент в любом Android-приложении — RecyclerView. Надеюсь узнать некоторые дополнительные приемы, которые можно применить для сложных списков.
Доклад «Animations in 2k19» расскажет о подходах к выбору построения анимаций, а также о таких современных и нужных компонентах, как MotionLayout и CoordinatorLayout.
Ну и для новичков во Flutter будет полезным доклад «Flutter. Опыт в продакшн-разработке». Будет много всего о том, как ведет себя Flutter в проде, как устроен CI/CD при работе с ним, ну и ответ на всех волнующий вопрос: возможно ли сейчас применять Flutter в проде?
Докладов очень много, каждый, как и я, сможет найти для себя интересное!
Одна из моих любимых рубрик на канале — это #интервью с разработчиком.
Сегодня у нас свежее интервью с командой Surf. Оно получилось достаточно объемным, но очень интересным, так как ребята, Евгений Сатуров и Максим Туев, ответили подробно на много вопросов.
Прочитать интервью вы можете тут.
Сегодня у нас свежее интервью с командой Surf. Оно получилось достаточно объемным, но очень интересным, так как ребята, Евгений Сатуров и Максим Туев, ответили подробно на много вопросов.
Прочитать интервью вы можете тут.
Teletype
Интервью с разработчиками. Студия Surf
Сегодня хочу представить вам не одного разработчика, а сразу нескольких.
Еще немного Jetpack Compose
#разработка
На прошлой неделе, я рассказывал о новом компоненте от Google — Jetpack Compose. Хотелось бы немного дополнить пост.
Я писал о том, что для работы теперь необходимо просто добавить компонент как обычную зависимость. Но для полноценной работы этого компонента все еще нужно иметь кастомную Android Studio и компиляторный плагин. По словам разработчиков, тот момент, что все заработало на обычной Android Studio — это случайность🤷♂️.
Уже совсем скоро состоится DevSummit, на котором будет немного больше подробностей о том, как все будет работать и больше новостей об этом компоненте.
Хотите еще больше информации о Jetpack Compose, то читайте ее в этой статье. Также, там можно ознакомиться с комментариями разработчика этого компонента, если вам интересны шаги развития этого инструмента.
И спасибо подписчику, указал мне на эту неточность в посте!
#разработка
На прошлой неделе, я рассказывал о новом компоненте от Google — Jetpack Compose. Хотелось бы немного дополнить пост.
Я писал о том, что для работы теперь необходимо просто добавить компонент как обычную зависимость. Но для полноценной работы этого компонента все еще нужно иметь кастомную Android Studio и компиляторный плагин. По словам разработчиков, тот момент, что все заработало на обычной Android Studio — это случайность🤷♂️.
Уже совсем скоро состоится DevSummit, на котором будет немного больше подробностей о том, как все будет работать и больше новостей об этом компоненте.
Хотите еще больше информации о Jetpack Compose, то читайте ее в этой статье. Также, там можно ознакомиться с комментариями разработчика этого компонента, если вам интересны шаги развития этого инструмента.
И спасибо подписчику, указал мне на эту неточность в посте!
ViewModels и LiveData: паттерны и антипаттерны
#разработка #статьи
В своем последнем проекте активно использую компоненты из Jetpack. К ним относятся ViewModels и LiveData.
ViewModel это класс, который создан для хранения и управления данными, связанными с пользовательским интерфейсом, учитывая жизненный цикл. Вместе с LiveData можно легко, не боясь утечек памяти, подписываться на изменения ViewModel.
При работе с ним возникают вопросы, связанные с его правильным использованием. На некоторые из них, нашел ответы в этой статье, которая рассматривает основные вопросы, связанные с ее применением.
Например, мне было интересно прочитать про правильное взаимодействие ViewModel с репозиториями, как избежать огромных ViewModel, а также как связаны состояния Activity и ViewModel.
#разработка #статьи
В своем последнем проекте активно использую компоненты из Jetpack. К ним относятся ViewModels и LiveData.
ViewModel это класс, который создан для хранения и управления данными, связанными с пользовательским интерфейсом, учитывая жизненный цикл. Вместе с LiveData можно легко, не боясь утечек памяти, подписываться на изменения ViewModel.
При работе с ним возникают вопросы, связанные с его правильным использованием. На некоторые из них, нашел ответы в этой статье, которая рассматривает основные вопросы, связанные с ее применением.
Например, мне было интересно прочитать про правильное взаимодействие ViewModel с репозиториями, как избежать огромных ViewModel, а также как связаны состояния Activity и ViewModel.
Самый короткий код с Dagger 2
#разработка #опрос #статьи
Когда впервые видишь Dagger, то ловишь себя на мысли, что не понимаешь, как это все работает. Видишь «волшебную» аннотацию Inject, которая без создания объекта отдает тебе его.
Конечно, при большем изучении этой библиотеки все становится яснее. И сейчас очень много статей, примеров и докладов, которые расскажут, наверное, о всех аспектах и фичах.
Но есть один пример, который призван показать «здесь и сейчас» как работает Dagger. Он не призван показать все, а только самую суть. Некий «hello world!»
Подробнее о примере, а также ссылку на GitHub, можно найти тут.
Как вам пример?
#разработка #опрос #статьи
Когда впервые видишь Dagger, то ловишь себя на мысли, что не понимаешь, как это все работает. Видишь «волшебную» аннотацию Inject, которая без создания объекта отдает тебе его.
Конечно, при большем изучении этой библиотеки все становится яснее. И сейчас очень много статей, примеров и докладов, которые расскажут, наверное, о всех аспектах и фичах.
Но есть один пример, который призван показать «здесь и сейчас» как работает Dagger. Он не призван показать все, а только самую суть. Некий «hello world!»
main(args: Array<String>) {
println(MainClass().info.text)
}
class MainClass {
@Inject lateinit var info : Info
init {
DaggerMagicBox.create().poke(this)
}
}
class Info @Inject constructor() {
val text = "Hello Dagger 2"
}
@Component interface MagicBox {
fun poke(mainClass: MainClass)
}Подробнее о примере, а также ссылку на GitHub, можно найти тут.
Как вам пример?
Binds vs Provides в Dagger 2
#разработка
Какая разница между Binds и Provides в Dagger 2? Это один из самых частых вопросов на собеседованиях, связанных с Dagger 2. И мне бы хотелось попробовать дать вам более-менее полное объяснение, которое я нашел и использую при ответе.
Первое отличие заключается в том, каким образом каждая из них «предоставляет» зависимости.
Provides может содержать в своем методе больше, чем один параметр, и возвращает реализацию того элемента, который нам нужен.
Binds же может принимать только один параметр, причем этот параметр — реализация того класса, который нам нужен, а возвращаемым параметром является интерфейс данного класса.
Кроме того, можно добавить, что с Provides используется обычный метод, а с Binds — абстрактный.
Вторым отличием является количество генерируемого кода в проекте.
Если посмотреть на то, что генерируется при добавлении этой аннотации, то видно добавление
Подробнее про сравнение этих двух аннотаций можно почитать в этой статье.
Есть ли еще какие-то отличия?
Будет здорово, если вы добавите их в комментариях.
#разработка
Какая разница между Binds и Provides в Dagger 2? Это один из самых частых вопросов на собеседованиях, связанных с Dagger 2. И мне бы хотелось попробовать дать вам более-менее полное объяснение, которое я нашел и использую при ответе.
Первое отличие заключается в том, каким образом каждая из них «предоставляет» зависимости.
Provides может содержать в своем методе больше, чем один параметр, и возвращает реализацию того элемента, который нам нужен.
Binds же может принимать только один параметр, причем этот параметр — реализация того класса, который нам нужен, а возвращаемым параметром является интерфейс данного класса.
Кроме того, можно добавить, что с Provides используется обычный метод, а с Binds — абстрактный.
Вторым отличием является количество генерируемого кода в проекте.
Если посмотреть на то, что генерируется при добавлении этой аннотации, то видно добавление
MyModule_GetInjectClassFactory , которой нет при использовании Binds, но есть при добавлении Provides.Подробнее про сравнение этих двух аннотаций можно почитать в этой статье.
Есть ли еще какие-то отличия?
Будет здорово, если вы добавите их в комментариях.