​​RxJava. Документация
#статьи #разработка 

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

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

Но все же есть более-менее распространенные операторы, которые используются чаще, чем другие. Документация Rx подробная, и только используя ее можно понять, что делает тот или иной оператор. А если вам нужно больше объяснения, кода и примеров (что особенно важно, когда вы новичок), то рекомендую почитать цикл статей об операторах Rx. Описано подробно, к каждому оператору прикреплен пример кода. Единственный недостаток — примеры применения в реальных приложений отсутствуют.

Как почувствовать грязный код? Часть 1.
#разработка #опрос

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

Одной из причин является недостаток опыта предыдущего разработчика. Мне кажется, что на начальном этапе необходимо делать так, чтобы код выполнял требуемые функции. Ведь ты не знаешь, что пишешь «грязный» код. Однако даже опытные разработчики не спрашивают себя: а что такое «грязный» код и не пишу ли я подобный код? Хочу поделиться несколькими признаками плохого и «грязный» кода. 

• отсутствие логирования ошибок. На мой взгляд, без обработок и логирования ошибок код является не завершенным. В будущем подобные косяки вызывают значительную потерю времени других разработчиков в случае реального возникновения ошибок. Кстати, рекомендую плагин для 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. Первая и вторая часть.

Как почувствовать грязный код? Часть 2
#разработка

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

Итак, еще немного размышлений о том, что такое «грязный» код и как его избегать.

• непроинициализированные переменные. Подобные переменные могут нести в себе много проблем. Например, в цикле подобная переменная может вызвать падение при попытке взять из списка неверный элемент. К счастью, 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. Главное не качество, а количество! Егор Бугаенко. Автор делился мыслями по организации работы разработчиков. По его словам, качество — не то, о чем должны заботиться программисты. Их главная задача — писать код быстро, а качеством должна заниматься выстроенная система контроля. Было много интересных тезисов и предложений, а также вопросов к слушателям. Очень понравился доклад, те размышления, которые были озвучены заставили задуматься об организации работы команд и разработчиков.

Конференция отличная. Большое спасибо организаторам. Обязательно буду делиться с вами еще многими вещами, которые узнал на конференции!

Уровни разработчиков
#мысли #опрос 

Сегодня размышлял о том, как понять, какого уровня разработчик. Общеизвестная шкала разработчиков: junior, middle и senior. Вроде понятно, что это ступени развития разработчика, однако порой не просто определить, на каком уровне находишься ты. 

Для себя вывел следующие характеристики каждой из групп:

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

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

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

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

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

А кем вы себя считаете?
🔴 — junior;
🔵 — middle;
⚫️ — senior.

​​Стремитесь не к качеству, а к скорости
#статьи #мысли #комментарии

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

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

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

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

Вот некоторые из возможных мер, которые сделают невозможным ухудшение качества проекта:
• автоматические билды при merge;
• ветка master в read-only;
• высокий уровень покрытия тестами;
• обязательный статический анализатор.

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

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

RxJava from-to
#разработка #статьи

В последнее время часто сталкивался с задачей перехода из различных классов Rx в другие. Приходилось каждый раз вводить в поисковик запросы типа «Observable to Completable» или «Observable to Single».

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

Кстати, это часть презентации Джейка Уортона о RxJava 2, когда она еще не была в релизе. Необычно просмотреть слайды о ней, когда уже применял ее на практике

Kotlin под капотом
#статьи #разработка

Сегодня попалась статья о просмотре декомпилированного в Java байткода Kotlin. Прочитал с начала до конца.

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

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

Playing APK Golf
#статьи #разработка

Вы когда-нибудь задавались вопросом, насколько можно сжать размер 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.

А на каком языке программирования вы пишете бОльшую часть времени?

Droidcon NYC 2018
#разработка #статьи #конференции

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

Сегодня хочу поделиться с вами плейлистом с конференции droidcon, которая проходила в Нью-Йорке. Кстати, не так часто организаторы конференции выкладывают доклады в публичный доступ, особенно так быстро. Глаза разбегаются от огромного количества полезного материала. Вот некоторые из тем: Flutter, MotionLayout, разное применение Kotlin, архитектура, безопасность.

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

AI для решения проблем с кожей
#статьи #мысли

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

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

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

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

Conference call между эмуляторами
#разработка 

Большинство разработчиков знает о возможности звонка в эмуляторе Android. Сделать это просто: нажмите на меню эмулятора -> Phone -> Call Device.

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

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

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

​​Android P: Priority Buckets
#разработка #статьи

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

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

Поэтому, теперь приложение попадает в одну из групп:
• active — приложение, которое сейчас запущено пользователем. Интересно то, что если приложение не имеет launcher activity, то оно никогда не попадет в эту группу.
• working set  — приложение, которое не запущено, но используется часто в течении дня. Например, наши любимые соц.сети.
• frequent — приложение, которое не запущено, но используется иногда в течении недели. Возможно, приложение для тренировок или такси.
• rare — приложение, которое редко используется на устройстве. Например, специальное приложение, которое вы использовали только в отпуске.
• never — приложение, которое никогда не запускалось.

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

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

Уверен, что среди вас есть много крутых спецов в серверной части. Возможно, среди них есть люди, которые хотели бы:
• работать удаленно. У нас нет привязки ни к месту, ни ко времени работы;
• работать в международной команде. На данный момент наша команда из США, Индии и России;
• каждый день прокачивать свой английский. Кроме постоянного общения с командой, можно воспользоваться курсами английского, которые оплачивает компания.

Требования:
• уверенные знания NodeJS, Express и MongoDB;
• знания React;
• опыт развертки серверов в Google Cloud (App Engine и Compute Engine);
• знание разговорного английского языка.

Если нужны подробности, то пишите мне. Расскажу все о бонусах, о ЗП и о компании.

​​Производительность ConstraintLayout
#разработка #статьи 

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

Автор протестировал его с другими в зависимости от располагаемых объектов. 

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

При расположении View в центре наилучший результат показал FrameLayout. Был удивлен, что LinearLayout показал почти такой же результат. ConstraintLayout проиграл с большим отрывом. 

Как ни странно, при создании сложных View, ConstraintLayout показывал себя как наиболее медленный. 

Уверен, что в простых случаях лучше не использовать ConstraintLayout. Если достаточно LinearLayout или FrameLayout — это будет быстрее. Однако, если ваш layout сильно усложнится, то в итоге все равно придется переделать на ConstraintLayout.

Я сам уже долгое время использую ConstraintLayout для создания View, значительно снизив использование других layout. Также не замечал снижения производительности при его использовании, поэтому некоторые результаты тестов показались странными.

​​Android launchMode
#разработка

На прошлой неделе в своей работе столкнулся с проблемой разворота приложения из активных. Ответ крылся в достаточно простой вещи: неправильно настроенным launchMode для второй Activity.

Это важная вещь, и думаю, что все разработчики должны знать, как она работает.  Многие используют singleTask, чтобы предотвратить создание дубликатов, но забывают про остальные модификаторы.

В понимании работы launchMode мне помогла статья с иллюстрациями работы каждого из типа: singleTop, singleTask, singleInstance, standard. Можно добавить в закладки и обращаться к ней в момент изменения launchMode.

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

7 декабря, 18:00 — Android-митап :: e-Legion, Revolut, JetBrains

Место: конференц-холл дата-центра Selectel, ул.Цветочная, 19

Спикеры:

— Николай Иготти, JetBrains: Kotlin/Native: технология и средства разработки;

— Роман Яцына, Revolut: Архитектура приложения, основанная на списках и RecyclerView. Реактивный поток данных от сети и БД до RecyclerView;

— Никита Цыганов, e-Legion: Как мы создавали виджет для одного из самых крупных мобильных операторов России: Firebase Job Dispatcher & Channels Coroutine.

Формат: доклады, вопросы и подарки, дискуссия за пиццей 🙌

Вход свободный, регистрируйся сегодня, количество мест ограничено: https://elegion.timepad.ru/event/864117/

​​Про удаленную работу
#мысли #вопрос #опрос

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

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

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

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

И я бы хотел спросить у вас: интересно ли вам было бы услышать ответы на ваши вопросы от меня, касаемо удаленной работы?