Архив недели
Понедельник
Всем привет! На этой неделе с вами буду я, Александр Горшков.
Пишу под Android последние 5 лет.
Сейчас работаю в компании EkoNiva Android-разработчиком, а также веду канал в Telegram — Android Live🤖.
Долго думал по поводу плана на неделю, и пока в голове он таков:
• понедельник — расскажу о своём пути в Android-разработку;
• вторник — поговорим о том, как это вести Telegram-канал про Android, и что мне это даёт;
• среда — обсудим, какие плюсы и минусы работы разработчику в неайтишной компании;
• четверг — поговорим о темах, стилях и ресурсах в Android;
• пятница и выходные — пока не придумал, но точно что-то найдётся ✌️
Надеюсь, что будет интересно.
Обычно пишу в Telegram, а посты в Twitter — совершенно новый опыт, так что посмотрим, что из этого выйдет.
О, придумал тему на пятницу.
Расскажу об опыте ведения сообщества GDG в довольно небольшом городе
Думаю, свой более осознанный путь в разработку я начал с университета.
До этого было обучение в техникуме, однако каких-то глубоких или практических знаний о разработке он мне, почти не дал.
Правда, именно там я попробовал делать программы в Delphi, верстать сайты и неплохо работать в Word😁.
Именно мобильной разработки у нас в университете на момент моего обучения не было, и своё первое приложение под Android написал в виде дипломной работы.
Тогда мобильные приложения в дипломах были редкостью, вместо стандартного эмулятора нужно было использовать Genymotion, ведь стандартный толком не работал, а чтобы продемонстировать приложение, мне пришлось одолжить планшет на Android 4 у своего товарища.
Универ дал довольно хорошую базу, ведь алгоритмы, базы данных, ООП — это распространённая вещь в большинстве областей программирования.
Также отличный предмет — теория принятия решений, хотя после универа я распробовал его больше 😁.
Этой базы хватило, чтобы устроиться Junior-разработчиком в местную компанию, где делали приложение телепрограмму. Безумно рад, что устроился именно сюда, потому что именно тут я хорошо прокачал навыки Android-разработки. Менторство очень помогает, особенно на начальных этапах.
На мой взгляд, новичкам лучше всего искать именно офисную работу в небольших компаниях. Будет круто, если ещё и проект будет интересный. Мне кажется, что именно там вы прокачаетесь лучше всего.
Мобильную разработку выбрал по причине того, что мне нравилось видеть результат своей работы на каком-то другом устройстве и наличие пользователей, которые используют твоё приложение.
После нескольких лет работы в этой компании, я сменил место работы в гораздо большей и масштабной компании, где количество разработчиков было в десятки раз выше.
Там я поработал почти 2 года, где дорос до тимлида Android-команды и оценил все плюсы и минусы работы над огромным проектом.
Следующий этап работы — это работа в американском стартапе удалённо. Именно тут пришлось качать свой английский, учиться планировать время и учитывать особенности менталитета разных людей.
Отличный опыт и время, ведь именно тогда я понял прелести удалёнки: ты сам планируешь свой день и можешь работать откуда угодно.
Для меня самым большим минусом удалённой работы является отсутствие общения с другими людьми. На удалёнке не так просто обсудить прошедший Google IO или другую конференцию, пообщаться о свежих новостях или поесть пиццу с коллегами.
Скучаете по живому общению на удалённой работе?
Хотя с другой стороны, ты сильнее ценишь живое общение с близкими и друзьями.
Сейчас я работаю также удалённо в совсем неайтишной компании — EkoNiva, где мы улучшаем жизнь наших агрономов при помощи Android-приложения. Но об этом в другой день 😉.
Вторник
Итак, сегодня вторник, а значит я расскажу о своём опыте ведения Telegram-канала — Android Live.
На нём уже больше 5500 подписчиков, сложно сказать, мало это или много для канала с темой Android-разработки.
Всё началось в конце 2017 года, когда идея ведения своего Telegram-канала про Android-разработку превратилась в созданный канал.
Основных причин по которым я начал его вести две:
Навести порядок в своей голове. Действовал по принципу «научи другого, чтобы научиться самому». По сути, когда ты начнёшь объяснять какую-то область знаний, где ты что-то понимаешь, то сразу поймешь, где у тебя самого пробелы.
Желание делиться знаниями и опытом. У меня всегда была привычка читать с утра какие-то статьи про разработку. Из них часто получалось взять полезные знания, и я частенько скидывал их своим коллегам. Если им это интересно, то может быть интересно и другим людям — решил я.
Да и сам я сталкивался на практике с разными задачами. Так почему бы не рассказать об этом другим, чтобы они избегали твоих ошибок.
В то время Telegram был (да и остаётся) платформой, где сидит много разработчиков, а тот формат, который есть в этом мессенджере позволяет читать информацию быстрым и удобным способом.
Если вы давно думали, стоит ли делиться своим опытом с другими — обязательно пробуйте. Своей попыткой вы сделаете гораздо больше, чем те, кто не хочет ничего создавать или только думает о своём блоге.
Самой большой ошибкой, которую я сделал — это начало ведения блога анонимно, не рассказывая о себе. Не повторяйте её, и указывайте себя как автора.
Ну и обязательно рассказывайте о своём блоге другим людям, особенно друзьям-разработчикам, которые могут дать полезную обратную связь.
Теперь давайте поговорим о том, что мне дал и даёт Telegram-канал.
Во-первых, это прокачка навыка написания постов и своих мыслей.
Эта область, в которой сложно достичь совершенства, ведь всегда можно что-то улучшить в своей правильности изложения того, что у тебя в голове.
Если вы тоже хотите усовершенствовать этот навык, рекомендую две книги:
«Пиши, сокращай. Как создавать сильный текст» Ильяхова.
«Как писать хорошо» Зинсера.
Во-вторых — это общение и знакомства с другими разработчиками.
В этом мне особенно помогла рубрика «Интервью с разработчиком», где я задавал вопросы подписчиков другим разработчикам.
Сейчас эта рубрика немного расширилась, и теперь я спрашиваю о том, как живётся в других странах нашим коллегам.
На канале есть интервью с разработчиком из Израиля и огромный пост про жизнь там.
Если в обычном случае вы можете постесняться написать им, то от имени канала это сделать проще.
Во время интервью и общения я понял, насколько у нас работают крутые и открытые ребята.
Так что канал — это ещё и способ наладить социальные связи.
В-третьих, это плюсик для резюме и личный бренд.
Обязательно надо указывать, что ведёте свой блог о разработке в своём резюме, во многих компаниях на это обращают внимание.
Был забавный случай, когда я собеседовался в англоязычную команду, и тимлид сказал мне: «Вижу у тебя есть канал, жаль, что я ничего не могу там прочитать, но ты молодец, что делишься знаниями».
В-четвёртых — это возможность получить «плюшки».
Например, есть такая штука как «инфорпартнёрство», где твой канал рассказывает о каком-то продукте, а взамен получает что-то от создателей этого продукта.
В большинстве случаев, это конференции, где можно получить билет для себя и подписчиков.
Хотя иногда это бывают книги или мерч.
Мне кажется, что изначально неправильным будет создавать канал с целью получить из него прямую выгоду или косвенную в виде плюшек.
Начните с желания делиться своим опытом и контентом, а «плюшки» придут со временем.
Кстати, я всегда рад делать посты об opensource проектах, бесплатных мероприятиях или конференциях.
Это хороший вклад в сообщество разработчиков.
Отдельно следует упомянуть, что важно сохранять регулярность постов на канал.
Мало кто из подписчиков читает посты несколько раз, и поэтому вы должны быть всегда наверху его ленты.
В среднем на написание одного поста уходит от 30-50 минут. Это при условии, если берёшь какую-то мысль из «бэклога» и делаешь из неё полноценный пост.
Ну и как итог (который прослеживается по всей цепочки твитов) — не бойтесь начать, и если у вас давно была мысль ведения своего блога — обязательно начните, пишите регулярно и у вас всё получится🤟!
Если у вас возникнут вопросы про канал (свой или мой), то пишите мне в Telegram: al_gorshkov
Среда
Итак, сегодня среда, и я расскажу вам о том, какие плюсы и минусы есть в работе разработчиком в неайтишной компании.
Сейчас я работаю в компани EkoNiva. Это довольно крупная компания, основной деятельностью которой является производство молочной продукции.
Кроме этого компания владеет сотнями тысяч гектар полей, где выращивает разные сельскохозяйственные культуры🌾.
Вообще сфера сельского хозяйства сейчас активно заполняется всякими штуками с IT.
Приведу два примера.
Возможно, вы читали статью от компании Cognitive Pilot, где они роботизируют процесс уборки полей при помощи комбайнов.
В своей статье они описывают, хоть и без технических деталей, то, как работает их решение и нейронные сети.
Выглядит впечатляюще, как по мне.
Второй пример — это компания OneSoil, где ребята анализируют спутниковые снимки, опознают на них поля и строют специальные карты для этих полей.
Мы же начали делать приложение, которые позволяет навести порядок всех процессов в компании, которые происходят на полях: сев культур, их уборка, обработка удобрениями, осмотры полей и т.д.
Для начала это позволит просто учесть то, что было вложено в поля, чуть позже — рассчитать зарплату агрономам и механизаторам, а ещё в планах — спрогнозировать урожайность, нашествия вредителей и болезней.
Теперь перейдём к основной теме цепочки и рассмотрим преимущества работы.
Во-первых — интересно. Это новое и нестандартное направление, где ты можешь быть первым, и получить опыт в совершенно другой области, которая не связана с IT.
Во-вторых — влияние на продукт. Тут ты всегда можешь предложить свою идею, особенно если она основана на предыдущем опыте, и ты понимаешь, что «вот так» будет лучше.
В-третьих — перспективность. Хотя сейчас и есть довольно большое количество стартапов, работающих в сельском хозяйстве, остаётся много областей, которые можно улучшить.
Сельское хозяйство — та область, которая ещё долго не умрёт.
Теперь давайте поговорим об особенностях работы. Не могу назвать их недостатками, потому что конкретно они не мешают работе, а просто являются вещами, которые нужно учесть.
Начнём с того, что компания не связана с IT, и приходится часто рассказывать о том, что в IT компаниях знают и без тебя. Например, насколько важен QA-отдел или как правильно завести баг и задачу.
Сюда я бы отнёс и отношение наших агрономов к продукту. Дело в том, что некоторые из них считают, что мы добавляем их лишних проблем, пытаясь заставить делать дополнительную работу.
Из-за этого у них сложно получить обратную связь.
Ну и последнее — это непонимание некоторых процессов.
Например, если вы пишите Интернет-магазин, то примерно представляете себя в виде пользователя и можете оценить удобство использования.
В нашем случае нужно много обратной связи, чтобы сделать всё хорошо.
Как итог скажу одно: если вам попадётся вакансия с нестандартной областью знаний, то попробуйте себя в ней. Это крутой опыт и неплохой пунктик для резюме😉.
Отвечу на ваши вопросы.
Ну и с удовольствием почитал бы о ваших нестандартных местах работы.
Четверг
Итак, сегодня четверг. Поговорим про тему Android-разработки, которая у меня сейчас «болит», хотя многие разработчики её недооценивают — это стили, темы и ресурсы в приложении🎨.
Начнём, пожалуй, с самой простой вещи — это наименование строк.
Существует так называемая практика <HOW>_<DESCRIPTION>. Это практика, где первым словом вы указываете то, как использовать ресурс в проекте, а вторым — что означает данный ресурс. Например, label_home или hint_user_name.
Но даже её не придерживаются многие разработчики.
У меня на практике был забавный случай, когда неверный нейминг ресурса привёл к неправильному переводу.
В одном приложении мы писали игру «21». До этого был экран, где был небольшой список, и кнопка «Ещё», чтобы посмотреть полный список.
Не долго думая, разработчик заиспользовал эту строку «Ещё», которая имела незамысловатое название ресурса «more».
Отдел переводчиков попросил скриншот, и перевёл строку «Ещё» для кнопки как "More", что совершенно правильно и корректно.
Кто же знал, что в английской версии «21» действие «Ещё» — это не "More", а "Hit".
По ошибке, это была одна и та же строка, и в итоге кнопка в приложении превратилась в "Hit".
Хорошо, что мы быстро заметили ошибку, а то бы пользователям приходилось «пинать» список, чтобы он показался полностью.
Теперь снова вернёмся к технике <HOW>_<DESCRIPTION>.
В своих проектах я немного расширил эту технику до <HOW><WHERE><DESCRIPTION>. В этом случае where — это экран или модуль, где используется ресурс. Например, title_registration_pass. Если ресурс используется в нескольких местах, то параметр where опускается.
Для себя также обозначил следующие how:
• title — заголовки;
• hint — подсказки в edittext;
• msg — сообщения или обычные текста на экранах;
• error — сообщения об ошибках;
• action — кнопки или какие-то действия.
Вы не поверите, какой порядок позволило навести подобное правило в проекте.
Теперь не обязательно придумывать названия для строк, ведь по большей части они формируются сами.
Кроме того, не возникает недопонимания, где они используются.
Ещё сюда можно добавить группировку строк в файле ресурсов, чтобы было наглядное понимание, сколько строк используется для конкретного экрана.
Вторая проблема — это наименование цветов.
Когда вы начинаете проект, то можете начать с наивного нейминга, типа "green", "red", "white".
Но потом приходит дизайнер, который просит внести ещё парочку оттенков зелёного, для начала темнее и светлее.
Вроде ничего страшного, и вы называете их "green_dark" и "green_light".
Через какое-то время появляется ещё один цвет, который не совсем темный, но уже и не просто зелёный. Тогда могут появляться названия, типа "green_darker" или "green_2".
В общем, начинается неразбериха.
На самом деле, наименование цветов — не самая простая задача. Но помочь нам в ней помогает один ресурс, который придумывает для всех цветов название.
chir.ag/projects/name-…
Теперь цвета всегда имеют эти названия, и в проекте появляются "green_fern", "green_sea" или "red_roman".
Возможно, не самое лучшее решение, однако это лучше варианта с более-менее светлыми цветами.
Со временем ты привыкаешь к тем цветам, которые есть в проекте.
Возможно, у вас есть более интересные подходы к неймингу, будет интересно о них узнать.
Давайте про стили и темы я расскажу в субботу, а то цепочка получится слишком большой.
Там есть о чём рассказать.
Да и лишняя тема дня — это тоже неплохо😉.
Пятница
Итак, вечер пятницы, и самое время поговорить о ведении сообщества в довольно небольшом городе🏙.
Сейчас я живу в городе Брянск, где проживает около 400 тысяч.
На самом деле, сложно сказать, насколько много в нашем городе людей, которые профессионально занимаются IT.
Если посмотреть на количество компаний, то вроде появляется немаленькая цифра.
Но как такового сообщества в городе не было.
В том году у нас проводилась конференция для IT в одном из университетов, куда, к моему удивлению, собралось достаточно много людей.
Конечно, стоит отсечь студентов, которые пришли туда ради плюшки от преподавателя, но всё равно😁.
И после этой конференции у меня возникла в голове совсем крохотная идея сделать сообщество. Но совсем не было понимания, как лучше это организовать.
И на одной из конференций в Москве, уже не помню на какой, был стенд GDG, где я впервые узнал об этом сообществе.
По сути, GDG, или Google Developers Group — это группа людей, которые интересуются технологиями Google.
Сейчас такое сообщество есть больше, чем в 30 городах России.
В ноябре я решил написать координатору, и уже через несколько недель, после организационного интервью, я получил возможность быть организатором GDG у себя в городе.
Проверьте свой город на сайте, и, возможно, мы увидимся снова в рядах организаторов:
developers.google.com/community/gdg
После этого начался период организации первого митапа.
Во время подготовки получилось познакомиться с большим числом классных ребят у себя в городе: это менеджеры, владельцы компаний, тимлиды команд.
Мне кажется, что самым сложным пунктом был поиск подходящего помещения. Если в крупных городах нет проблем с пространствами, то в небольших — или очень дорого, или ужасно выглядит.
К удивлению, поиск спикеров — не самая сложная задача. Вспомнил интересных авторов с конференций, подумал о компаниях в своём городе, а также компаниях, которые готовы направлять своих сотрудиков выступать — и всё.
Были спикеры, которым было интересно приехать выступить именно в регионе, так как в Брянск не поедешь как турист, но если тебя туда приглашают — то почему бы и нет.
Такой вот плюс жизни в регионе.
Кроме этого, есть крутые ребята — GDE (Google Developers Experts). Обычно это состоявшиеся разработчики в своей области, которые получили такой аппрув от Google.
И они тоже с радостью соглашаются приезжать с выступлением.
В результате первый митап прошёл очень круто: пришло около 50 человек, доклады были шикарными, а вопросов от спикеров — много✌️.
Второй запланированный митап, к сожалению, не состоялся из-за всем нам известной ситуации в мире. Зато было несколько онлайн мероприятий, что было тоже интересно организовывать.
Правда, живое общение с разработчиками твоего города — это совсем другие ощущения.
Кроме знакомств с местными разработчиками, локальное сообщество — это крутая возможность прокачать навык организации, а также принадлежность к глобальному сообществу GDG.
Уже несколько было постов с призывами что-то делать... И вот ещё один: попробуйте организовать сообщество у себя, если живёте в регионе, где ситуация с мероприятиями и конференциями тяжёлая.
Пробуйте даже если у вас совсем небольшой город, где живёт меньше 100 тысяч жителей. Уверен, что и среди них найдутся заинтересованные люди.
И как всегда я на связи в Telegram: al_gorshkov.
Будут вопросы по GDG — не стесняйтесь и пишите😉.
Суббота
Сегодня суббота, и давайте поговорим про стили и темы в Android🎨.
Наверное, начать стоит с того, в чём разница между стилем и темой.
По сути, стиль — это некоторый набор атрибутов для конкретной View. Лучше делать этот набор уникальным для каждого типа View, потому что набор атрибутов отличается.
Можно представить, что стиль — это Map<view attribute, resource>.
Тема - это набор именованных ресурсов, на которые позже можно будет ссылаться с помощью стилей, макетов и т.д.
Тема — это Map<theme attribute, resource>.
И набор этих атрибутов не применяется для конкретной View, а имеет более общий характер.
Чуть больше информации об этой разнице можно почитать тут:
medium.com/androiddevelop…
Начиная новый проект, нет причин не наследоваться от других тем, кроме как MaterialComponents.
Взамен мы получаем поддержу новых виджетов, которые работают только в material theme, несколько новых атрибутов для цветов и классный сайт, который описывает всё, что связано с Material
Теперь давайте поговорим про нейминг тем.
Для начала стоит сделать базовую тему для приложения, называя её: Theme.AppName.Base
В ней стоит переопределить все параметры, которые не относятся к конкретным цветам приложения.
Это могут быть дефолтные стили для виджетов или textAppearance для текстов.
Я бы сюда включил два цвета: это цвет navigationBar и statusBar. Лучше сделать их прозначными, чтобы корректно поддерживать отступы при помощи insets.
Следующая тема, которую уже стоит прописать в манифесте — это Theme.AppName, которая наследуется от нашей базовой темы.
Здесь уже важно переопределить основные атрибуты цветов, чтобы во всех View использовать описанные атрибуты.
Очень важно не использовать прямые ссылки на цвета в стилях для View или напрямую в xml. Если вы так делаете, то лишаете себя возможности настройки темы, а также поддержи нескольких тем в приложении.
Конечно, есть исключения: например, если необходимо использовать цвет бренда во всех View, который никогда не поменяется (хотя я бы тут лучше сделал кастомный атрибут) или же вы делаете View, цвет которой используется только для неё.
Теперь давайте поговорим о стилях, и как лучше всего применить их.
Начните с того, что определите дефолтные стили для некоторых из виджетов, например для EditText, Button, Toolbar.
Пропишите их в Theme.AppName.Base, и этим действием вы сэкономите себе время в будущем.
Для стилей тоже важно сохранять нейминг.
Здесь всё просто: именуйте их в том стиле, в каком именуется её родитель.
Если вы наследуетесь от Widget.AppCompat.EditText, то назовите ваш стиль как Widget.AppName.EditText.
Следует также упомянуть про такую ведь как textAppearance. Они содержат в себе атрибуты, которые применимы только для текстовых View: цвет текста, шрифт, размер и т.д.
В Material Components сделали встроенную поддержку 13 стилей для текста, и к ним можно обратиться через атрибуты
Подробнее о них можно почитать тут:
material.io/develop/androi…
textAppearance очень крутая штука, которая позволит, практически, избавиться от стилей для текстовых View. В своих проектах я не указываю размеры для текста напрямую в xml, это всегда делается через textAppearance.
В будущем, если ваше приложение захочет использовать другой шрифт — вам нужно будет просто переопределить стили textAppearance.
Важно помнить, что textAppearance поддерживает не все атрибуты, которые вы можете прописать в стиле. Проверьте, что поддерживает textAppearance перед добавлением своего свойства.
На самом деле, виден большой шаг в сторону дизайна в Android, важно немного разобраться в этом и использовать все преимущества🤟.
А что вы делаете в своём проекте, чтобы все визуальные элементы выглядели едиными?
