RxJava: subscribeOn vs observeOn
#разработка
Эти два оператора помогают использовать один из важнейших аспектов RxJava — планирование работы в нужном потоке. Кажется, что нельзя допустить ошибок в использовании этих операторов. Однако, есть несколько нюансов, которые необходимо знать.
Оператор observeOn меняет поток для всех операторов, которые будут идти после него. Многие ошибочно полагают, что его действие распространяется также на впереди стоящих операторов.
Оператор subscribeOn меняет поток, который используется Observable при подписке. Мы подписываемся в самом конце цепочки операторов, поэтому не имеет значения, где расположить этот оператор.
Что будет, если расположить в цепочке несколько операторов? Если с observeOn понятно, то что поток будет изменяться каждый раз, когда мы пишем его, то с subscribeOn не все так однозначно.
Распространенным мнением является то, что учитывается только первый оператор. Однако недавно мне попалась статья о том, что несколько операторов subscribeOn могут влиять на цепочку. Подробно и с примерами кода ее можно прочитать тут
На мой взгляд, использовать несколько операторов в одной цепочке — это чаще всего неочевидно и излишне. Но вопрос: «Что будет, если расположить подряд несколько операторов observeOn\ subscribeOn?» очень распространен в различных квестах, викторинах и на собеседованиях. Теперь вы точно знаете ответ на этот вопрос!
#разработка
Эти два оператора помогают использовать один из важнейших аспектов RxJava — планирование работы в нужном потоке. Кажется, что нельзя допустить ошибок в использовании этих операторов. Однако, есть несколько нюансов, которые необходимо знать.
Оператор observeOn меняет поток для всех операторов, которые будут идти после него. Многие ошибочно полагают, что его действие распространяется также на впереди стоящих операторов.
Оператор subscribeOn меняет поток, который используется Observable при подписке. Мы подписываемся в самом конце цепочки операторов, поэтому не имеет значения, где расположить этот оператор.
Что будет, если расположить в цепочке несколько операторов? Если с observeOn понятно, то что поток будет изменяться каждый раз, когда мы пишем его, то с subscribeOn не все так однозначно.
Распространенным мнением является то, что учитывается только первый оператор. Однако недавно мне попалась статья о том, что несколько операторов subscribeOn могут влиять на цепочку. Подробно и с примерами кода ее можно прочитать тут
На мой взгляд, использовать несколько операторов в одной цепочке — это чаще всего неочевидно и излишне. Но вопрос: «Что будет, если расположить подряд несколько операторов observeOn\ subscribeOn?» очень распространен в различных квестах, викторинах и на собеседованиях. Теперь вы точно знаете ответ на этот вопрос!
AppsConf
Продолжаю свой рассказ о предстоящих конференциях мобильных разработчиков. Сегодня я расскажу о конференции AppsConf. Она пройдет с 8 по 9 октября.
Я еще не посещал эту конференцию, однако после ознакомления со списком докладов и спикеров это желание возникло.
Например, заинтересовал доклад «Автор, пиши меньше. Котлин для разработки в iOS и Android» Николая Иготти. Возможно, кто-то слышал о том, что общую бизнес-логику следует писать сразу на Android и iOS. При этом возникают вопросы. Какие инструменты использовать для правильной организации архитектуры? На каком языке писать общие компоненты? Не будет ли уменьшения в производительности? Автор будет делиться своим опытом написания под Kotlin Native, что позволит не дублировать общий код под каждую платформу.
Еще один доклад «Как ускорить интернет, или Оптимизация приложений в мобильных сетях» Александра Тоболя. Основная масса приложения на смартфонах использует Интернет. Большинство разработчиков считает, что Интернет постоянно высокоскоростной и безлимитный. Если приложение загружает небольшие объемы данных, то все работает быстро. Но если в приложении нужен стриминг видео или загрузка изображений в высоком разрешении, то на слабом Интернете все становится грустно. Автор расскажет, на примере приложения OKLive, про отмену и варианты загрузки данных в мобильном приложении.
Доклад «Как переписать приложение с нуля и не потерпеть фиаско»
Михаила Емельянова расскажет о правильном переписывании приложения. Уже писал пост о том, что текущий код лучше того, что может быть написан в будущем. И полностью переписывать приложение может быть губительно для бизнеса. Автор поделится своим опытом переписания приложения, о том, какие подводные камни появляются при использовании чистой архитектуры.
Список докладов еще пополняется. Полный список докладчиков тут. Кстати, у конференции есть подкаст, который называется Run Loop.
Продолжаю свой рассказ о предстоящих конференциях мобильных разработчиков. Сегодня я расскажу о конференции AppsConf. Она пройдет с 8 по 9 октября.
Я еще не посещал эту конференцию, однако после ознакомления со списком докладов и спикеров это желание возникло.
Например, заинтересовал доклад «Автор, пиши меньше. Котлин для разработки в iOS и Android» Николая Иготти. Возможно, кто-то слышал о том, что общую бизнес-логику следует писать сразу на Android и iOS. При этом возникают вопросы. Какие инструменты использовать для правильной организации архитектуры? На каком языке писать общие компоненты? Не будет ли уменьшения в производительности? Автор будет делиться своим опытом написания под Kotlin Native, что позволит не дублировать общий код под каждую платформу.
Еще один доклад «Как ускорить интернет, или Оптимизация приложений в мобильных сетях» Александра Тоболя. Основная масса приложения на смартфонах использует Интернет. Большинство разработчиков считает, что Интернет постоянно высокоскоростной и безлимитный. Если приложение загружает небольшие объемы данных, то все работает быстро. Но если в приложении нужен стриминг видео или загрузка изображений в высоком разрешении, то на слабом Интернете все становится грустно. Автор расскажет, на примере приложения OKLive, про отмену и варианты загрузки данных в мобильном приложении.
Доклад «Как переписать приложение с нуля и не потерпеть фиаско»
Михаила Емельянова расскажет о правильном переписывании приложения. Уже писал пост о том, что текущий код лучше того, что может быть написан в будущем. И полностью переписывать приложение может быть губительно для бизнеса. Автор поделится своим опытом переписания приложения, о том, какие подводные камни появляются при использовании чистой архитектуры.
Список докладов еще пополняется. Полный список докладчиков тут. Кстати, у конференции есть подкаст, который называется Run Loop.
Многомодульность
#разработка
Сегодня большинство мобильных приложений представляет из себя не простое приложение, а огромный «комбайн» с различными функциональностями. Достаточно часто можно слышать то, что приложения на мобильные устройства сейчас на первом месте.
Я часто пишу тут про архитектуру, про некоторые подходы при разработке. Это огромная тема, которую постоянно нужно изучать, и всегда будешь открывать для себя что-то новое.
Недавно попалась статья про многомодульность. Автор делится своим опытом перехода от монолитного проекта к многомодульному, а также рассказывает о трудностях, с которыми ему пришлось столкнуться при переходе.
Сегодня о многомодульных проектах говорят многие. О переходе на них начинаешь задумываться, когда необходимо переиспользовать код в другом приложении или когда время сборки проекта становится невыносимо долгим. Советую также задуматься о разбиении на модули в тот момент, когда начинаете писать новое приложение. Это сэкономит много времени и сил в будущем.
#разработка
Сегодня большинство мобильных приложений представляет из себя не простое приложение, а огромный «комбайн» с различными функциональностями. Достаточно часто можно слышать то, что приложения на мобильные устройства сейчас на первом месте.
Я часто пишу тут про архитектуру, про некоторые подходы при разработке. Это огромная тема, которую постоянно нужно изучать, и всегда будешь открывать для себя что-то новое.
Недавно попалась статья про многомодульность. Автор делится своим опытом перехода от монолитного проекта к многомодульному, а также рассказывает о трудностях, с которыми ему пришлось столкнуться при переходе.
Сегодня о многомодульных проектах говорят многие. О переходе на них начинаешь задумываться, когда необходимо переиспользовать код в другом приложении или когда время сборки проекта становится невыносимо долгим. Советую также задуматься о разбиении на модули в тот момент, когда начинаете писать новое приложение. Это сэкономит много времени и сил в будущем.
Движение FIRE
#мысли #статьи #опрос
На прошедшей неделе мне попалась статья о тенденции, которая становится популярной в мире разработчиков на западе.
Есть разработчик, который работает в среднестатистической компании, но при это получает достаточно большие деньги для комфортного проживания. Но вместо комфортного жилья, дорогой одежды и вкусной еды, наш герой откладывает 80% своего ежемесячного дохода. Он снимает комнату в общежитии, ест одну и ту же еду каждый день и спит на надувном матрасе. Для чего же откладывать столько средств?
Цель такой экстримальной экономии — закончить работу к 30-35 годам. Накопленных средств хватит для того, чтобы жить на проценты. После этого можно посвятить жизнь тому, что хочешь. Такие люди считают, что работа — рабство для того, чтобы заработать деньги. И единственным способом выйти из него — накопить достаточно денег для жизни. Эта тенденция получила название FIRE (financial independence, retire early, финансовая независимость и ранняя пенсия).
Не уверен, что подобная тенденция будет распространена в России, однако это повод задуматься о некоторых вещах. Например, о перегорании на работе. Сторонники FIRE считают, что работа приносит много стресса, и люди часто перерабатывают напрасно. Также стоит задуматься о том, куда ты тратишь свои деньги. Возможно, стоит отладывать часть средств на какие-то важные вещи или сделать себе подушку безопасности, а не прожигать все деньги за месяц или на покупку ненужных вещей.
Возможно, вы знаете людей, которые следуют этой тенденции. Всегда рад ответить на ваши сообщения тут.
А что вы думаете о FIRE?
#мысли #статьи #опрос
На прошедшей неделе мне попалась статья о тенденции, которая становится популярной в мире разработчиков на западе.
Есть разработчик, который работает в среднестатистической компании, но при это получает достаточно большие деньги для комфортного проживания. Но вместо комфортного жилья, дорогой одежды и вкусной еды, наш герой откладывает 80% своего ежемесячного дохода. Он снимает комнату в общежитии, ест одну и ту же еду каждый день и спит на надувном матрасе. Для чего же откладывать столько средств?
Цель такой экстримальной экономии — закончить работу к 30-35 годам. Накопленных средств хватит для того, чтобы жить на проценты. После этого можно посвятить жизнь тому, что хочешь. Такие люди считают, что работа — рабство для того, чтобы заработать деньги. И единственным способом выйти из него — накопить достаточно денег для жизни. Эта тенденция получила название FIRE (financial independence, retire early, финансовая независимость и ранняя пенсия).
Не уверен, что подобная тенденция будет распространена в России, однако это повод задуматься о некоторых вещах. Например, о перегорании на работе. Сторонники FIRE считают, что работа приносит много стресса, и люди часто перерабатывают напрасно. Также стоит задуматься о том, куда ты тратишь свои деньги. Возможно, стоит отладывать часть средств на какие-то важные вещи или сделать себе подушку безопасности, а не прожигать все деньги за месяц или на покупку ненужных вещей.
Возможно, вы знаете людей, которые следуют этой тенденции. Всегда рад ответить на ваши сообщения тут.
А что вы думаете о FIRE?
A/B тестирование
#разработка
Если открыть Google Play, то мы найдем там миллионы различных приложений. Но очень маленький процент из них имеет большое количество пользователей, а также хорошее качество. Из-за большой конкуренции важно, чтобы пользователям нравилось приложение.
Но, например, как понять, какой дизайн больше нравится пользователям? Или не раздражает ли их новая функциональность? А что сделать, чтобы текущая функциональность была заметнее? Ответы на эти вопросы может дать A/B-тестирование.
Если упрощенно, то A/B-тест позволяет распространить разные версии одного и того же приложения и в реальном времени определить, какая из версий является «лидером». Лидер определяется по определенным параметрам, которые задаются при создании A\B-теста.
Распространенным инструментом для создания A/B-тестов является Firebase Remote Config. Сейчас он в стадии beta. Судя по моему опыту, не зря. Config иногда не приходит, а Activation event не срабатывает. Поэтому, будьте внимательны при его использовании, проверяйте каждый тест внимательно.
Хорошая статья о настройке и раздачи тестов тут.
#разработка
Если открыть Google Play, то мы найдем там миллионы различных приложений. Но очень маленький процент из них имеет большое количество пользователей, а также хорошее качество. Из-за большой конкуренции важно, чтобы пользователям нравилось приложение.
Но, например, как понять, какой дизайн больше нравится пользователям? Или не раздражает ли их новая функциональность? А что сделать, чтобы текущая функциональность была заметнее? Ответы на эти вопросы может дать A/B-тестирование.
Если упрощенно, то A/B-тест позволяет распространить разные версии одного и того же приложения и в реальном времени определить, какая из версий является «лидером». Лидер определяется по определенным параметрам, которые задаются при создании A\B-теста.
Распространенным инструментом для создания A/B-тестов является Firebase Remote Config. Сейчас он в стадии beta. Судя по моему опыту, не зря. Config иногда не приходит, а Activation event не срабатывает. Поэтому, будьте внимательны при его использовании, проверяйте каждый тест внимательно.
Хорошая статья о настройке и раздачи тестов тут.
Не так давно писал вам о конференции AppsConf.
Прошло немного времени, а список докладов дополнился и расписание теперь известно полностью. Удобно то, что доклады поделены по уровням сложности. Сам можешь решить, что для тебя приоритетнее. Ведь если не касался определенной темы, то на хардкорном уровне будет сложно.
Кстати, на этой конференции появился новый формат докладов, который называется митап. Судя по описанию, формат ориентирован на живое общение, где участники могут задать вопросы спикеру. Спикер получает в распоряжение аудиторию, час времени и доску с проектором. Мне кажется, что это интересный формат, потому что часто не хватает времени на живое общение.
Больше информации тут. Спешите купить билет по более низкой цене!
Прошло немного времени, а список докладов дополнился и расписание теперь известно полностью. Удобно то, что доклады поделены по уровням сложности. Сам можешь решить, что для тебя приоритетнее. Ведь если не касался определенной темы, то на хардкорном уровне будет сложно.
Кстати, на этой конференции появился новый формат докладов, который называется митап. Судя по описанию, формат ориентирован на живое общение, где участники могут задать вопросы спикеру. Спикер получает в распоряжение аудиторию, час времени и доску с проектором. Мне кажется, что это интересный формат, потому что часто не хватает времени на живое общение.
Больше информации тут. Спешите купить билет по более низкой цене!
EditText и inputType
#разработка #статьи
Во время работы с EditText у разработчика есть отличная возможность облегчить ввод данных пользователя, используя свойство inputType.
Однако часто разработчики забывают устанавливать необходимое значение для вводимых строк. Наиболее распространенным применением, на мой взгляд, является скрытие пароля. Но стоит смотреть на характер вводимой информации и устанавливать корректный inputType. Это говорит о внимательности к деталям при разработке.
Существует много значений. Рекомендую ознакомиться со статьей, где перечислены необходимые значения этого параметра в зависимости от вводимой информации.
#разработка #статьи
Во время работы с EditText у разработчика есть отличная возможность облегчить ввод данных пользователя, используя свойство inputType.
Однако часто разработчики забывают устанавливать необходимое значение для вводимых строк. Наиболее распространенным применением, на мой взгляд, является скрытие пароля. Но стоит смотреть на характер вводимой информации и устанавливать корректный inputType. Это говорит о внимательности к деталям при разработке.
Существует много значений. Рекомендую ознакомиться со статьей, где перечислены необходимые значения этого параметра в зависимости от вводимой информации.
RxJava. Документация
#статьи #разработка
На мой взгляд, сегодня RxJava одна из популярных библиотек среди Android-разработчиков. При этом, почти уверен, что нет ни одного разработчика, который бы знал большую часть операторов этой библиотеки.
Как я думаю, в этом нет ничего плохого. Некоторое время назад, пытался учить доступные в RxJava операторы. Открывал документацию, читал примеры, писал код, чтобы разобраться. Однако вскоре большинство операторов, которые выучил подобным образом, забылись. Это связано с тем, что я не применял знания на практике.
Но все же есть более-менее распространенные операторы, которые используются чаще, чем другие. Документация Rx подробная, и только используя ее можно понять, что делает тот или иной оператор. А если вам нужно больше объяснения, кода и примеров (что особенно важно, когда вы новичок), то рекомендую почитать цикл статей об операторах Rx. Описано подробно, к каждому оператору прикреплен пример кода. Единственный недостаток — примеры применения в реальных приложений отсутствуют.
#статьи #разработка
На мой взгляд, сегодня RxJava одна из популярных библиотек среди Android-разработчиков. При этом, почти уверен, что нет ни одного разработчика, который бы знал большую часть операторов этой библиотеки.
Как я думаю, в этом нет ничего плохого. Некоторое время назад, пытался учить доступные в RxJava операторы. Открывал документацию, читал примеры, писал код, чтобы разобраться. Однако вскоре большинство операторов, которые выучил подобным образом, забылись. Это связано с тем, что я не применял знания на практике.
Но все же есть более-менее распространенные операторы, которые используются чаще, чем другие. Документация Rx подробная, и только используя ее можно понять, что делает тот или иной оператор. А если вам нужно больше объяснения, кода и примеров (что особенно важно, когда вы новичок), то рекомендую почитать цикл статей об операторах Rx. Описано подробно, к каждому оператору прикреплен пример кода. Единственный недостаток — примеры применения в реальных приложений отсутствуют.
Как почувствовать грязный код? Часть 1.
#разработка #опрос
При написании проекта, особенно когда пишешь его с нуля, стараешься поддерживать код в чистом виде. При этом каждый разработчик хоть раз ковырялся в старом проекте и разгребал легаси-код. Откуда же появляется этот код, если все стараются писать код чистым?
Одной из причин является недостаток опыта предыдущего разработчика. Мне кажется, что на начальном этапе необходимо делать так, чтобы код выполнял требуемые функции. Ведь ты не знаешь, что пишешь «грязный» код. Однако даже опытные разработчики не спрашивают себя: а что такое «грязный» код и не пишу ли я подобный код? Хочу поделиться несколькими признаками плохого и «грязный» кода.
• отсутствие логирования ошибок. На мой взгляд, без обработок и логирования ошибок код является не завершенным. В будущем подобные косяки вызывают значительную потерю времени других разработчиков в случае реального возникновения ошибок. Кстати, рекомендую плагин для RxJava, который подсвечивает незалогированные ошибки.
• memory leaks. Чтобы предотвратить подобные ошибки рекомендую использовать плагин LeakCanary.
• неправильное именование функций и переменных. Этим часто грешат начинающие разработчики. Чаще всего стоит использовать camelCase. Также стоит использовать понятные названия функций, и не думать о красивом и коротком названии. Например, название
• гигантские классы. Иногда тяжело разбивать участок кода на несколько кусков. Однако чаще большие классы возникают от нежелания программиста разбивать его на более мелкие. Необходимо стремиться к такому классу, который отвечает только за определенную функциональность.
• функции делают слишком много. Такое бывает и у опытных разработчиков. Часто встречаю в проектах функцию типа
Это далеко не все признаки грязного кода. Вскоре напишу еще сигналы, которые помогут делать наш код чище. А какие признаки грязного кода знаете вы? Пишите мне, обязательно опубликую в следующей части.
Находили подобный код в проектах?
#разработка #опрос
При написании проекта, особенно когда пишешь его с нуля, стараешься поддерживать код в чистом виде. При этом каждый разработчик хоть раз ковырялся в старом проекте и разгребал легаси-код. Откуда же появляется этот код, если все стараются писать код чистым?
Одной из причин является недостаток опыта предыдущего разработчика. Мне кажется, что на начальном этапе необходимо делать так, чтобы код выполнял требуемые функции. Ведь ты не знаешь, что пишешь «грязный» код. Однако даже опытные разработчики не спрашивают себя: а что такое «грязный» код и не пишу ли я подобный код? Хочу поделиться несколькими признаками плохого и «грязный» кода.
• отсутствие логирования ошибок. На мой взгляд, без обработок и логирования ошибок код является не завершенным. В будущем подобные косяки вызывают значительную потерю времени других разработчиков в случае реального возникновения ошибок. Кстати, рекомендую плагин для RxJava, который подсвечивает незалогированные ошибки.
• memory leaks. Чтобы предотвратить подобные ошибки рекомендую использовать плагин LeakCanary.
• неправильное именование функций и переменных. Этим часто грешат начинающие разработчики. Чаще всего стоит использовать camelCase. Также стоит использовать понятные названия функций, и не думать о красивом и коротком названии. Например, название
getFullName() несет больше смысла, чем name().• гигантские классы. Иногда тяжело разбивать участок кода на несколько кусков. Однако чаще большие классы возникают от нежелания программиста разбивать его на более мелкие. Необходимо стремиться к такому классу, который отвечает только за определенную функциональность.
• функции делают слишком много. Такое бывает и у опытных разработчиков. Часто встречаю в проектах функцию типа
init(), где огромная мешанина из условий, переменных и вызовов других функций. Стремитесь, чтобы таких методов было как можно меньше. Кстати, слышал, что в некоторых компаниях есть ограничения на длину функции. Если она больше определенного числа строк, то это повод разбить ее на несколько и без этого разбиения нельзя сделать коммит.Это далеко не все признаки грязного кода. Вскоре напишу еще сигналы, которые помогут делать наш код чище. А какие признаки грязного кода знаете вы? Пишите мне, обязательно опубликую в следующей части.
Находили подобный код в проектах?
Уже давно не публиковал подборку статей из Medium.
#статьи #medium
1) London Tube Status App. — (5 минут)
Подробный цикл статей о последовательном написании мобильного приложения. Подобный гайд поможет новичкам начать писать свое собственное приложение. Опытные разработчики также могут найти для себя некоторые мысли. Например, мне было интересно изучить опыт миграции с Dagger2 на Koin.
2) Keeping track of staged rollouts with Android Bot — (5 минут)
При публикации приложения в Google Play есть фишка — поэтапное развертывание приложения. Можно зарелизить приложение на 20% пользователей и посмотреть, как ведет себя приложение, не появились ли новые проблемы или баги и перед публикацией полной версии приложения исправить их. Нашел статью о написании бота, который помогает получать информацию о поэтапном релизе приложения.
3) UberCarAnimation: A try to make animation of cars on map — (10 минут)
Иногда ловлю себя на мысли, что при использовании некоторых приложений с необычными анимациями спрашиваешь себя, как эти анимации были сделаны. Нашел статьи о том, как создать анимацию движения автомобиля по карте из приложения Uber. Первая и вторая часть.
#статьи #medium
1) London Tube Status App. — (5 минут)
Подробный цикл статей о последовательном написании мобильного приложения. Подобный гайд поможет новичкам начать писать свое собственное приложение. Опытные разработчики также могут найти для себя некоторые мысли. Например, мне было интересно изучить опыт миграции с Dagger2 на Koin.
2) Keeping track of staged rollouts with Android Bot — (5 минут)
При публикации приложения в Google Play есть фишка — поэтапное развертывание приложения. Можно зарелизить приложение на 20% пользователей и посмотреть, как ведет себя приложение, не появились ли новые проблемы или баги и перед публикацией полной версии приложения исправить их. Нашел статью о написании бота, который помогает получать информацию о поэтапном релизе приложения.
3) UberCarAnimation: A try to make animation of cars on map — (10 минут)
Иногда ловлю себя на мысли, что при использовании некоторых приложений с необычными анимациями спрашиваешь себя, как эти анимации были сделаны. Нашел статьи о том, как создать анимацию движения автомобиля по карте из приложения Uber. Первая и вторая часть.
Как почувствовать грязный код? Часть 2
#разработка
Для тех, кто пропустил первую часть. Спасибо подписчикам, которые поделились мнением о посте. Это приятно.
Итак, еще немного размышлений о том, что такое «грязный» код и как его избегать.
• непроинициализированные переменные. Подобные переменные могут нести в себе много проблем. Например, в цикле подобная переменная может вызвать падение при попытке взять из списка неверный элемент. К счастью, Android Studio подсвечивает подобные переменные, говоря о том, что они не были проициализированы. К этому же пункту относятся неиспользуемые переменные, которые остаются после рефакторинга. Они вызывают меньше проблем, однако захламляют код.
• большой список параметров. Подобные ошибки вызывают сложность в использовании функции. Особую сложность представляют собой функции, которые принимают параметры одинакового типа. Стоит только ошибиться в порядке передачи этих параметров и функция будет работать некорректно.
• огромное количество комментариев. Кажется, что комментарии помогают в использовании кода. Но некоторые разработчики увлекаются написанием комментариев и пишут их для очевидных функций. Стремитесь к тому, чтобы по названию функции можно было понять, что делает эта функция. Однако, не ленитесь писать комментарий, где используете «костыль» или делаете неочевидное действие. К этому же пункту отнесу автосгенерированные студией комментарии для классов и функций. Чаще всего они излишни.
• неиспользование раннего выхода. Иногда разработчики забывают о такой полезной вещи как ранний выход из функции. Если параметры или условия не удовлетворяют требования для продолжения работы функции, то ее можно тут же завершить при помощи
• злоупотребление наследованием. Наследование — полезные инструмент. Но когда цепочка наследников становится слишком большой, то это также ухудшает читаемость кода и приводит к проблемам и багам. Большинство подобных проблем лечатся при помощи делегирования.
Уверен, что есть еще огромное множество сигналов о «грязном» коде, но некоторыми из них поделился с вами. Применяйте эти знания для написания чистого кода.
#разработка
Для тех, кто пропустил первую часть. Спасибо подписчикам, которые поделились мнением о посте. Это приятно.
Итак, еще немного размышлений о том, что такое «грязный» код и как его избегать.
• непроинициализированные переменные. Подобные переменные могут нести в себе много проблем. Например, в цикле подобная переменная может вызвать падение при попытке взять из списка неверный элемент. К счастью, Android Studio подсвечивает подобные переменные, говоря о том, что они не были проициализированы. К этому же пункту относятся неиспользуемые переменные, которые остаются после рефакторинга. Они вызывают меньше проблем, однако захламляют код.
• большой список параметров. Подобные ошибки вызывают сложность в использовании функции. Особую сложность представляют собой функции, которые принимают параметры одинакового типа. Стоит только ошибиться в порядке передачи этих параметров и функция будет работать некорректно.
• огромное количество комментариев. Кажется, что комментарии помогают в использовании кода. Но некоторые разработчики увлекаются написанием комментариев и пишут их для очевидных функций. Стремитесь к тому, чтобы по названию функции можно было понять, что делает эта функция. Однако, не ленитесь писать комментарий, где используете «костыль» или делаете неочевидное действие. К этому же пункту отнесу автосгенерированные студией комментарии для классов и функций. Чаще всего они излишни.
• неиспользование раннего выхода. Иногда разработчики забывают о такой полезной вещи как ранний выход из функции. Если параметры или условия не удовлетворяют требования для продолжения работы функции, то ее можно тут же завершить при помощи
return. Если не делать это, то получаем большой набор вложенных операторов if else, который в будущем тяжело читать и понимать происходящее.• злоупотребление наследованием. Наследование — полезные инструмент. Но когда цепочка наследников становится слишком большой, то это также ухудшает читаемость кода и приводит к проблемам и багам. Большинство подобных проблем лечатся при помощи делегирования.
Уверен, что есть еще огромное множество сигналов о «грязном» коде, но некоторыми из них поделился с вами. Применяйте эти знания для написания чистого кода.
AppsConf 2018. Доклады
На прошедшей неделе посетил конференцию мобильных разработчиков AppsConf 2018. Было много докладов, хочу рассказать о некоторых из тех, которые посетил и понравились.
1. Machine Learning + Mobile: настоящее и будущее Андрей Володин. Автор делился опытом разработки приложения Prisma, а также применением AI к своему приложению. К сожалению, сейчас не так много приложений используют AI, хотя это перспективная технология и не такая сложная, как кажется на первый взгляд. Также автор сравнивал Android и iOS в области применения алгоритмов искусственного интеллекта.
2. Считать пиксели и не сдаваться, или Строим поверх View и ViewGroup Алексей Милеев. На основе приложения App in the Air, автор поделился методами написания своих собственных View и ViewGroup. Порой написание кастомных элементов дает возможность большей оптимизации UI, вследствие чего приложение работает быстрее. Однако, всегда необходимо тестировать ViewGroup и сравнивать со стандартными. Например, текущий ConstraintLayout хорошо оптимизирован. Часто не получить большой производительности при написании своего layout.
3. Автор, пиши меньше. Котлин для разработки в iOS и Android Николай Иготти. Доклад связан с написанием общей бизнес-логики на Kotlin Native для Android и iOS. Интересный доклад, применив который в проекте можно сэкономить время при написании кода.
4. Смешные и грустные истории про разработку компьютерных игр Вадим Башуров. В конце первого дня был отличный доклад об опыте разработчика игр. Автор делился написанием и продвижением различных игр, в которые играло тысячи людей. Помимо современных Android и iOS платформ автор рассказал про написание и заработок на играх в прошлом: на Symbian и MS-DOS.
5. Мифы и легенды удалённой работы Артур Бадретдинов. Автор поделился своим опытом работы удаленным сотрудником. Было интересно со стороны послушать плюсы и минусы удаленной работы и сравнить со своим видением.
6. It's time to up your test game Xavier F. Gouchet. Доклад связан с написанием тестов. Все разработчики понимают, что писать тесты важно и хорошо, однако очень мало делают это. Автор приводил аргументы, связанные с написанием тестов, а также делился опытом того, как устроено написание тестов в его приложении. Кстати, многие разработчики не знают как правильно писать тесты. Основным посылом было то, что нужно просто начинать писать их. В начале не важно, насколько качественными они будут. Со временем придет понимание правильного построения и написания тестов.
7. Как ускорить интернет, или Оптимизация приложений в мобильных сетях Александр Тоболь. Доклад связан с текущими протоколами для передачи данных. Мне кажется, что не много разработчиков задумываются о том, как верно передавать данные с устройства на сервер. Однако если есть большой объем передаваемых данных, то этот вопрос является ключевым. Узнал много нового о текущих протоколах и о том как можно ускорить работу многих приложений.
8. Создаём голосовое приложение на примере Google Assistant Павел Гвай. Удивлен, что на конференции не было много докладов, посвященных голосовым приложениям и помощникам. Тем не менее этот доклад интересен теоретическими основами написания голосовых приложений. Оказывается, писать голосовые приложения не так сложно как кажется, однако есть много нюансов. Было интересно послушать о правильном тестировании таких приложений.
9. Главное не качество, а количество! Егор Бугаенко. Автор делился мыслями по организации работы разработчиков. По его словам, качество — не то, о чем должны заботиться программисты. Их главная задача — писать код быстро, а качеством должна заниматься выстроенная система контроля. Было много интересных тезисов и предложений, а также вопросов к слушателям. Очень понравился доклад, те размышления, которые были озвучены заставили задуматься об организации работы команд и разработчиков.
Конференция отличная. Большое спасибо организаторам. Обязательно буду делиться с вами еще многими вещами, которые узнал на конференции!
На прошедшей неделе посетил конференцию мобильных разработчиков AppsConf 2018. Было много докладов, хочу рассказать о некоторых из тех, которые посетил и понравились.
1. Machine Learning + Mobile: настоящее и будущее Андрей Володин. Автор делился опытом разработки приложения Prisma, а также применением AI к своему приложению. К сожалению, сейчас не так много приложений используют AI, хотя это перспективная технология и не такая сложная, как кажется на первый взгляд. Также автор сравнивал Android и iOS в области применения алгоритмов искусственного интеллекта.
2. Считать пиксели и не сдаваться, или Строим поверх View и ViewGroup Алексей Милеев. На основе приложения App in the Air, автор поделился методами написания своих собственных View и ViewGroup. Порой написание кастомных элементов дает возможность большей оптимизации UI, вследствие чего приложение работает быстрее. Однако, всегда необходимо тестировать ViewGroup и сравнивать со стандартными. Например, текущий ConstraintLayout хорошо оптимизирован. Часто не получить большой производительности при написании своего layout.
3. Автор, пиши меньше. Котлин для разработки в iOS и Android Николай Иготти. Доклад связан с написанием общей бизнес-логики на Kotlin Native для Android и iOS. Интересный доклад, применив который в проекте можно сэкономить время при написании кода.
4. Смешные и грустные истории про разработку компьютерных игр Вадим Башуров. В конце первого дня был отличный доклад об опыте разработчика игр. Автор делился написанием и продвижением различных игр, в которые играло тысячи людей. Помимо современных Android и iOS платформ автор рассказал про написание и заработок на играх в прошлом: на Symbian и MS-DOS.
5. Мифы и легенды удалённой работы Артур Бадретдинов. Автор поделился своим опытом работы удаленным сотрудником. Было интересно со стороны послушать плюсы и минусы удаленной работы и сравнить со своим видением.
6. It's time to up your test game Xavier F. Gouchet. Доклад связан с написанием тестов. Все разработчики понимают, что писать тесты важно и хорошо, однако очень мало делают это. Автор приводил аргументы, связанные с написанием тестов, а также делился опытом того, как устроено написание тестов в его приложении. Кстати, многие разработчики не знают как правильно писать тесты. Основным посылом было то, что нужно просто начинать писать их. В начале не важно, насколько качественными они будут. Со временем придет понимание правильного построения и написания тестов.
7. Как ускорить интернет, или Оптимизация приложений в мобильных сетях Александр Тоболь. Доклад связан с текущими протоколами для передачи данных. Мне кажется, что не много разработчиков задумываются о том, как верно передавать данные с устройства на сервер. Однако если есть большой объем передаваемых данных, то этот вопрос является ключевым. Узнал много нового о текущих протоколах и о том как можно ускорить работу многих приложений.
8. Создаём голосовое приложение на примере Google Assistant Павел Гвай. Удивлен, что на конференции не было много докладов, посвященных голосовым приложениям и помощникам. Тем не менее этот доклад интересен теоретическими основами написания голосовых приложений. Оказывается, писать голосовые приложения не так сложно как кажется, однако есть много нюансов. Было интересно послушать о правильном тестировании таких приложений.
9. Главное не качество, а количество! Егор Бугаенко. Автор делился мыслями по организации работы разработчиков. По его словам, качество — не то, о чем должны заботиться программисты. Их главная задача — писать код быстро, а качеством должна заниматься выстроенная система контроля. Было много интересных тезисов и предложений, а также вопросов к слушателям. Очень понравился доклад, те размышления, которые были озвучены заставили задуматься об организации работы команд и разработчиков.
Конференция отличная. Большое спасибо организаторам. Обязательно буду делиться с вами еще многими вещами, которые узнал на конференции!
Уровни разработчиков
#мысли #опрос
Сегодня размышлял о том, как понять, какого уровня разработчик. Общеизвестная шкала разработчиков: junior, middle и senior. Вроде понятно, что это ступени развития разработчика, однако порой не просто определить, на каком уровне находишься ты.
Для себя вывел следующие характеристики каждой из групп:
• junior разработчик знает как решить некоторые не сложные задачи, причем знает только распространенное, часто не лучшее решение. Сложные задачи могут оказаться не по плечу. Код часто не лучший и требует правок. На мой взгляд, на этом шаге самым важным качеством является способность и желание учиться.
• middle уже самостоятельный разработчик, который способен решить большинство задач. Кстати, на этом шаге программист может оценивать задачи, а также выполнять их по ТЗ. Он понимает, что работает в команде, и его код является частью большого приложения. Думаю, что тут главным качество является способность воспринимать критику.
• senior разработчик имеет большой опыт практического написания кода. Знает, что как работает, в каких компонентах есть недостатки. Этот человек способен с нуля писать архитектурно правильные приложения, а также умеет доказать свою точку зрения, основанную опыта. Часто занимает руководящие должности и имеет в подчинении сотрудников. На данном шаге важно делиться своими идеями, а также не останавливаться на этом уровне.
Кстати, бывает так, что уровень может снизиться. Это может зависеть от смены работы. Переход в компанию с более высококлассными разработчиками несколько снижает уровень, однако через некоторое время он становится только выше.
Хотя эти границы условны, но порой стоит задавать себе вопрос, на каком этапе я нахожусь и не останавливаться в развитии.
А кем вы себя считаете?
🔴 — junior;
🔵 — middle;
⚫️ — senior.
#мысли #опрос
Сегодня размышлял о том, как понять, какого уровня разработчик. Общеизвестная шкала разработчиков: junior, middle и senior. Вроде понятно, что это ступени развития разработчика, однако порой не просто определить, на каком уровне находишься ты.
Для себя вывел следующие характеристики каждой из групп:
• junior разработчик знает как решить некоторые не сложные задачи, причем знает только распространенное, часто не лучшее решение. Сложные задачи могут оказаться не по плечу. Код часто не лучший и требует правок. На мой взгляд, на этом шаге самым важным качеством является способность и желание учиться.
• middle уже самостоятельный разработчик, который способен решить большинство задач. Кстати, на этом шаге программист может оценивать задачи, а также выполнять их по ТЗ. Он понимает, что работает в команде, и его код является частью большого приложения. Думаю, что тут главным качество является способность воспринимать критику.
• senior разработчик имеет большой опыт практического написания кода. Знает, что как работает, в каких компонентах есть недостатки. Этот человек способен с нуля писать архитектурно правильные приложения, а также умеет доказать свою точку зрения, основанную опыта. Часто занимает руководящие должности и имеет в подчинении сотрудников. На данном шаге важно делиться своими идеями, а также не останавливаться на этом уровне.
Кстати, бывает так, что уровень может снизиться. Это может зависеть от смены работы. Переход в компанию с более высококлассными разработчиками несколько снижает уровень, однако через некоторое время он становится только выше.
Хотя эти границы условны, но порой стоит задавать себе вопрос, на каком этапе я нахожусь и не останавливаться в развитии.
А кем вы себя считаете?
🔴 — junior;
🔵 — middle;
⚫️ — senior.
Стремитесь не к качеству, а к скорости
#статьи #мысли #комментарии
Кажется, что очевидной и правильной вещью в разработке является качественный код. На канале также были посты про то, как увидеть некачественный код и избавиться от него. Однако недавно нашел статью, где автор пишет о том, что главное, что должен обеспечить программист — скорость разработки, а не качество кода.
Кажется, что это звучит абсурдно, так как если писать не качественный код, то большой проект со временем станет невозможно поддерживать. Но только в том случае, если проект сам не будет беспокоиться о своем качестве.
Идея состоит в том, что между программистами и проектом должен быть постоянный конфликт:
1) Проект сконфигурирован так, чтобы отбраковать все, что понижает качество этого проекта.
2) Разработчики заинтересованы в том, чтобы делать изменения в проекте.
Появляется ситуация, где разработчики заинтересованы в быстром создании фич, а проект заинтересован в поддержке качества.
Вот некоторые из возможных мер, которые сделают невозможным ухудшение качества проекта:
• автоматические билды при merge;
• ветка master в read-only;
• высокий уровень покрытия тестами;
• обязательный статический анализатор.
Мне понравилась идея этой статьи, однако на практике большинство проектов нацелены на то, чтобы разработчики сами думали о качестве кода. Но люди не совершенны, и на любом проекте может проявляться человеческий фактор. Уверен, что у каждого в проекте были глупые ситуации, когда разработчик допускал нелепые ошибки, опечатки или нехотя ломал текущую функциональность.
А что вы думаете об этом подходе?
Есть ли у кого-то в компании такой подход?
Хочу попробовать новую для этого канала возможность - оставлять комментарии. Делитесь размышлениями ниже.
#статьи #мысли #комментарии
Кажется, что очевидной и правильной вещью в разработке является качественный код. На канале также были посты про то, как увидеть некачественный код и избавиться от него. Однако недавно нашел статью, где автор пишет о том, что главное, что должен обеспечить программист — скорость разработки, а не качество кода.
Кажется, что это звучит абсурдно, так как если писать не качественный код, то большой проект со временем станет невозможно поддерживать. Но только в том случае, если проект сам не будет беспокоиться о своем качестве.
Идея состоит в том, что между программистами и проектом должен быть постоянный конфликт:
1) Проект сконфигурирован так, чтобы отбраковать все, что понижает качество этого проекта.
2) Разработчики заинтересованы в том, чтобы делать изменения в проекте.
Появляется ситуация, где разработчики заинтересованы в быстром создании фич, а проект заинтересован в поддержке качества.
Вот некоторые из возможных мер, которые сделают невозможным ухудшение качества проекта:
• автоматические билды при merge;
• ветка master в read-only;
• высокий уровень покрытия тестами;
• обязательный статический анализатор.
Мне понравилась идея этой статьи, однако на практике большинство проектов нацелены на то, чтобы разработчики сами думали о качестве кода. Но люди не совершенны, и на любом проекте может проявляться человеческий фактор. Уверен, что у каждого в проекте были глупые ситуации, когда разработчик допускал нелепые ошибки, опечатки или нехотя ломал текущую функциональность.
А что вы думаете об этом подходе?
Есть ли у кого-то в компании такой подход?
Хочу попробовать новую для этого канала возможность - оставлять комментарии. Делитесь размышлениями ниже.
Android Live 🤖 pinned «Здравствуйте! Разрабатываю мобильные приложения для Android. Через меня проходит большое количество новостей из мира технологий, которым хочется делиться и высказывать мнение. Канал будет интересен тем, кто работает в области IT и мобильных технологий, а…»
RxJava from-to
#разработка #статьи
В последнее время часто сталкивался с задачей перехода из различных классов Rx в другие. Приходилось каждый раз вводить в поисковик запросы типа «Observable to Completable» или «Observable to Single».
В своих поисках нашел таблицу, которая в разы упрощает поиск необходимого оператора. Спешу поделиться ей с вами.
Кстати, это часть презентации Джейка Уортона о RxJava 2, когда она еще не была в релизе. Необычно просмотреть слайды о ней, когда уже применял ее на практике
#разработка #статьи
В последнее время часто сталкивался с задачей перехода из различных классов Rx в другие. Приходилось каждый раз вводить в поисковик запросы типа «Observable to Completable» или «Observable to Single».
В своих поисках нашел таблицу, которая в разы упрощает поиск необходимого оператора. Спешу поделиться ей с вами.
Кстати, это часть презентации Джейка Уортона о RxJava 2, когда она еще не была в релизе. Необычно просмотреть слайды о ней, когда уже применял ее на практике
Kotlin под капотом
#статьи #разработка
Сегодня попалась статья о просмотре декомпилированного в Java байткода Kotlin. Прочитал с начала до конца.
Думаю, что она будет интересна большинству разработчиков, как новичкам, так и опытным.
Порой чтение байткода помогает понимать, как какие-то части языка влияют на производительность и что из себя представляет какой-либо элемент языка.
#статьи #разработка
Сегодня попалась статья о просмотре декомпилированного в Java байткода Kotlin. Прочитал с начала до конца.
Думаю, что она будет интересна большинству разработчиков, как новичкам, так и опытным.
Порой чтение байткода помогает понимать, как какие-то части языка влияют на производительность и что из себя представляет какой-либо элемент языка.
Playing APK Golf
#статьи #разработка
Вы когда-нибудь задавались вопросом, насколько можно сжать размер APK?
Попалась статья, где автор задался целью максимально уменьшить размер apk «Hello World». Первоначально размер файла был 1.5mb. После определенных действий размер стал 1757 байт. Не слабая оптимизация, верно?
К сожалению, сжать apk файл обычного приложения не так просто, да и врядли получится сжать его в 3-5 раз. Но убрать пару лишних мегабайт реально. Вот несколько советов, которые помогут в этом.
1) Удалите неискользуемые ресурсы. Сделать это достаточно просто. Стоит запустить в Android Studio
2) Проанализируйте итоговый apk. Для этого надо воспользоваться командой
3) Переведите png в webp.
4) Удалите неиспользуемые языки. Я уже упоминал этот пункт. В этом посте. Лично я был удивлен, как много могут весить строковые ресурсы.
5) Примените App Bundle. Также это уменьшит размер файла приложения для пользователя. Упоминал об этом тут.
6) Удалите неиспользуемые библиотеки. Обязательно стоит время от времени анализировать текущий список зависимостей в проекте. Некоторые разработчики ради одного класса тянут целую зависимость. Еще часто после рефакторинга библиотека вообще не используется в проекте, но при этом остается в зависимостях. Также много «веса» добавляют нативные библиотеки. Анализируйте и их.
Может быть, вы знаете еще способы уменьшения размеров apk? Буду рад почитать их в комментариях.
#статьи #разработка
Вы когда-нибудь задавались вопросом, насколько можно сжать размер APK?
Попалась статья, где автор задался целью максимально уменьшить размер apk «Hello World». Первоначально размер файла был 1.5mb. После определенных действий размер стал 1757 байт. Не слабая оптимизация, верно?
К сожалению, сжать apk файл обычного приложения не так просто, да и врядли получится сжать его в 3-5 раз. Но убрать пару лишних мегабайт реально. Вот несколько советов, которые помогут в этом.
1) Удалите неискользуемые ресурсы. Сделать это достаточно просто. Стоит запустить в Android Studio
Refactor -> Remove unused resources. После этого обязательно проверьте, что не удалилось чего-то лишнего. Хотя бы запустите приложение и проверьте, что оно запускается.2) Проанализируйте итоговый apk. Для этого надо воспользоваться командой
Build -> Analyze APK. Посмотрите, какая категория имеет наибольший размер. Чаще всего этой категорией будет — ресурсы. 3) Переведите png в webp.
4) Удалите неиспользуемые языки. Я уже упоминал этот пункт. В этом посте. Лично я был удивлен, как много могут весить строковые ресурсы.
5) Примените App Bundle. Также это уменьшит размер файла приложения для пользователя. Упоминал об этом тут.
6) Удалите неиспользуемые библиотеки. Обязательно стоит время от времени анализировать текущий список зависимостей в проекте. Некоторые разработчики ради одного класса тянут целую зависимость. Еще часто после рефакторинга библиотека вообще не используется в проекте, но при этом остается в зависимостях. Также много «веса» добавляют нативные библиотеки. Анализируйте и их.
Может быть, вы знаете еще способы уменьшения размеров apk? Буду рад почитать их в комментариях.
Миграция на Kotlin
#статьи #разработка #опрос
Сегодня уже огромное количество проектов, которые написаны на Kotlin. Уже не раз упоминал на канале о том, что новый проект стоит начинать только на Kotlin.
Однако как быть с текущими проектами? На деле решиться перейти на Kotlin не просто. Ведь для бизнеса чаще без разницы, как вы пишите проект: на каком языке, какая архитектура, какие подходы вы используете. Основная задача — создание «фич» вовремя.
Но что можно сказать о разработчиках? Уверен, что большинство желает пробовать новые технологии, языки программирования, библиотеки. Однако очень дорого испытывать это на рабочем приложении. Ведь если что-то пойдет не так, то исправить это будет не просто из-за недостатка опыта в конкретной сфере.
Так бывает и с переходом на Kotlin. Одной из негативных мыслей, которая может появиться, является недостаточное знание языка. Не всегда просто писать те вещи, которые ты долгое время писал на Java, а теперь должен чуть по-другому писать на Kotlin.
Наткнулся на полезную статью, где автор описывает этапы перехода на Kotlin. Он рассматривает некоторые типичные шаблоны в Android-разработке и описывает их переход на Kotlin. Мне кажется, что подобная статья полезна всем, кто переписывает свой проект на Kotlin.
А на каком языке программирования вы пишете бОльшую часть времени?
#статьи #разработка #опрос
Сегодня уже огромное количество проектов, которые написаны на Kotlin. Уже не раз упоминал на канале о том, что новый проект стоит начинать только на Kotlin.
Однако как быть с текущими проектами? На деле решиться перейти на Kotlin не просто. Ведь для бизнеса чаще без разницы, как вы пишите проект: на каком языке, какая архитектура, какие подходы вы используете. Основная задача — создание «фич» вовремя.
Но что можно сказать о разработчиках? Уверен, что большинство желает пробовать новые технологии, языки программирования, библиотеки. Однако очень дорого испытывать это на рабочем приложении. Ведь если что-то пойдет не так, то исправить это будет не просто из-за недостатка опыта в конкретной сфере.
Так бывает и с переходом на Kotlin. Одной из негативных мыслей, которая может появиться, является недостаточное знание языка. Не всегда просто писать те вещи, которые ты долгое время писал на Java, а теперь должен чуть по-другому писать на Kotlin.
Наткнулся на полезную статью, где автор описывает этапы перехода на Kotlin. Он рассматривает некоторые типичные шаблоны в Android-разработке и описывает их переход на Kotlin. Мне кажется, что подобная статья полезна всем, кто переписывает свой проект на Kotlin.
А на каком языке программирования вы пишете бОльшую часть времени?
Droidcon NYC 2018
#разработка #статьи #конференции
Я часто на канале описываю различные конференции, связанные с мобильной разработкой. Считаю, что если ты взял с конференции хотя бы одну идею и применил ее, то это уже была полезная конференция. Ну а в личном посещении главным плюсом является общение с коллегами из других компаний. Ведь доклады посмотреть можно и онлайн чуть позже, но задать свои вопросы, возможно, уже не получится.
Сегодня хочу поделиться с вами плейлистом с конференции droidcon, которая проходила в Нью-Йорке. Кстати, не так часто организаторы конференции выкладывают доклады в публичный доступ, особенно так быстро. Глаза разбегаются от огромного количества полезного материала. Вот некоторые из тем: Flutter, MotionLayout, разное применение Kotlin, архитектура, безопасность.
Для себя отметил Flutter. Возможно, наконец-то дойдут руки до того, чтобы попробовать написать на нем простое приложение. Ну и вы выбирайте и изучайте понравившуюся тему.
#разработка #статьи #конференции
Я часто на канале описываю различные конференции, связанные с мобильной разработкой. Считаю, что если ты взял с конференции хотя бы одну идею и применил ее, то это уже была полезная конференция. Ну а в личном посещении главным плюсом является общение с коллегами из других компаний. Ведь доклады посмотреть можно и онлайн чуть позже, но задать свои вопросы, возможно, уже не получится.
Сегодня хочу поделиться с вами плейлистом с конференции droidcon, которая проходила в Нью-Йорке. Кстати, не так часто организаторы конференции выкладывают доклады в публичный доступ, особенно так быстро. Глаза разбегаются от огромного количества полезного материала. Вот некоторые из тем: Flutter, MotionLayout, разное применение Kotlin, архитектура, безопасность.
Для себя отметил Flutter. Возможно, наконец-то дойдут руки до того, чтобы попробовать написать на нем простое приложение. Ну и вы выбирайте и изучайте понравившуюся тему.
AI для решения проблем с кожей
#статьи #мысли
Недавно прочитал статью о достаточно необычном применении искусственного интеллекта. В ней говорится о нескольких приложениях для борьбы с проблемами кожи на лице.
На старте необходимо ответить на несколько вопросов, связанных со с проблемами кожи, как кожа реагирует на средства для ухода, что употребляет пользователь из еды.
Но помимо этого, пользователь должен загрузить селфи. Приложение проанализирует полученную фотографию при помощи искусственного интеллекта и предложит комплекс мер для ухода. Также представляется возможность делать снимки время от времени и следить за своим прогрессом.
Успех подобных приложений в том, что они решают проблему конкретного пользователя. Существует огромное количество ресурсов, связанных с медициной, где любой пользователь может узнать нужную информацию. Однако, персонализация — это то, что отличило это приложение. Здорово, что сегодня AI помогает делать сервисы более полезными при помощи персонализации.
#статьи #мысли
Недавно прочитал статью о достаточно необычном применении искусственного интеллекта. В ней говорится о нескольких приложениях для борьбы с проблемами кожи на лице.
На старте необходимо ответить на несколько вопросов, связанных со с проблемами кожи, как кожа реагирует на средства для ухода, что употребляет пользователь из еды.
Но помимо этого, пользователь должен загрузить селфи. Приложение проанализирует полученную фотографию при помощи искусственного интеллекта и предложит комплекс мер для ухода. Также представляется возможность делать снимки время от времени и следить за своим прогрессом.
Успех подобных приложений в том, что они решают проблему конкретного пользователя. Существует огромное количество ресурсов, связанных с медициной, где любой пользователь может узнать нужную информацию. Однако, персонализация — это то, что отличило это приложение. Здорово, что сегодня AI помогает делать сервисы более полезными при помощи персонализации.