Архив недели @ashumidub
Понедельник
Большой летний 😎привет всем любителям мобильной разработки 📱
С вами Артём Шумидуб (@ashumidub) - андроидер из @tradingView
План такой:
ПН: Знакомство и мой путь в IT 👟
ВТ: А/В тесты
СР: Локализация
ЧТ: Брак
ПТ: Сложность восприятия кода 🤯
Выходные: Импакт 💪, радикальная откровенность и свободное общение
Как видно, есть и технические и софтовые темы, да и просто про жизнь.
Поехали ! 🚀
Мой путь в разработку был не особо прямой, хоть с детства я и тянулся к компам, занималка патчингом телефонных прошивок в 16-ричной системе и т.д.
В момент выбора своего жизненного пути я не доверился своим увлечениям, так как считал, что много компьютерные инженеры не получают😄
Зато "слышал" про роскошную жизнь судей 👨⚖️ и юристов.
Такая вот каша была у меня в голове )
Поэтому учился на юриста, потом работал в юр. фирме.
Так как я интроверт, то в принципе, пока работал с созданием исковых, договоров купли-продажи и иных документов, погружался в изучение буквы закона - то было в целом норм.
А когда начал ходить по судебным заседаниям - понял, что общение с людьми мне уже не так нравится.
Особенно в такой конфликтной сфере🤜🤛
Я по характеру стараюсь избегать конфронтации, поэтому первое свое судебное дело, которое до меня длилось уже года полтора, я довел до мирового соглашения. От чего даже судья была в шоке 😲
Далее я, не раз я встречался с не совсем адекватными представителями власти.
Кто-то просто не понимал очевидных норм права, кто-то сидел на пайке у застройщиков.
С этим можно было работать, но в целом крутиться в этой сфере становилось все неприятнее.
Интровертной работы становилось все меньше, т.е. меньше того, чем мне вообще нравилось заниматься, где я могу входить в поток и не испытывать стресса.
Тогда начали посещать мысли, что с профессией я прогадал 🤔
И что нужно искать другое, более приятное для души занятие 🏄♂️
И тогда я прошел курсы по фотографии, купил камеру и начал снимать 📸
Работать с камерой с студийным светом мне нравилось. Немного работ, которые нашел с тех времен 😏
Кстати, будет много общей теории.
Поэтому интересно будет и для iOS и для Android 👆
И еще немного 📸
Работая на себя я кайфовал:
- не нужно носить туфли и рубашку 👔
- мог не брится сколько хочу 🧔
- вставать во сколько хочу
Уже тогда, когда я встречал знакомых юристов на улице, по одежде и их виду - я понимал, насколько я стал свободнее.
И я ценил это🤗
Иду по улице на расслабоне, заросший, в цветастых бриджах 🩳 или не давящих спортивных штанах, шлепках🩴или кросах, не измучанный как белка в колесе
Встречаю бывших коллег, затянутых галстуками и ремнями 👞👔💼
Правда с потоком клиентов для фотографии иногда были сложности.
Потом уже случайно увлекся питоном и втянулся.
Мне прям понравилось писать код и потом обнаруживать, что он работает🧑💻😃
Я легко вхожу в поток и есть какое-то творческое начало во всем этом.
@ruxeg @nikalaikina 📷 Был фотографом 🖱️ Много времени тратил на ренейминг и сортировку фоток 🔰 Прошел быстрый курс по питону и написал py script для автомазации 🤟 Понял что творить через код круто, мне понравилось 👟 Пошел в IT 💠 Сначала QA, автоматизатор, CD/CI 📳 Потом ANDROID developer
Я решил погрузиться в эту сферу.
И начал искать возможности войти в IT
twitter.com/ashumidub/stat…
Работал в нескольких местах.
Сначала пошел мобильным QA.
За это время я смог присмотреться как к iOS так и к Android разработке.
Понял что Android мне больше по душе, пересел поближе к разрабам.
Начал писать тесты, получил доступ к git, стал настраивать в Bamboo разные CD/CI приколюхи.
Делал все чтобы быть ближе к разработке
В Bamboo почти успел настроить планы сборки с разными проверками пулл реквестов (линтеры, юнит тесты, ui тесты). И почти успел настроить автопубликацию приложений в Google Play
Так как был доступ к git, то я изучал код, смотрел архитектуру и какие библиотеки используются.
Читал что-то новое по firebase, разным библиотекам и подходам, старался предлагать свои решения.
Далее мобильное направление в фирме прикрылось
Но кроме новых знания и опыта, которые я оттуда вынес, я был также сильно благодарен тому, что у нас старались делать какие-то хорошие практики по процессам
У меня в голове многое разложилось по полочкам относительно того, что делать полезно и правильно, а что нет.
Это помогло мне, когда я устроился на новое место уже в роли разработчика.
Пары недель хватило, чтобы понять, что это место гиблое.
Руководство не понимает как должны быть устроены процессы в IT, в глазах тех лида читалась усталость от попыток продолбить стену непонимания.
Через две недели я оттуда убежал.
К тому же они не выполнили обещания, относительно того, что было главной причиной, почему я пришел к ним (о чем я говорил им на собесе)
Кстати по поводу собеседований и отказов.
Я всегда придерживался правила - честно все рассказывать (и в случае моего отказа в приглашении)
Как мне кажется - это помогает проверить и адекватность второй стороны и сохранить хорошие отношения в любой ситуации.
А если в результате честного общения что-то не срастается, возможно просто вторая сторона не очень адекватна, и хорошо, что не срастается 😁
Одни сильно обиделись, что я к ним не пошел. Сказали, мол я упускаю возможность играть в "Высшей лиге" 😂
Звучало это смешно. Ведь это была далеко не высшая лига, и других "преимуществ" у них вообще не было.
Я надеялся на стабильность (после того как прошлая фирма закрылась я не хотел ввязываться во что-то не стабильное), но после их посещения, понял что у них не про стабильность
Какое-то время спустя я устроился в @tradingView.
Чему очень рад 🥳🕺
Меня приняли в офисе в Ростове-на-Дону.
Офис разработки есть еще в Питере.
Остальные офисы в Москве, Нью-Йорке, Лондоне и еще где-то по миру.
На тот момент сайт TV входил в топ-500 по миру (сейчас в топ-170)
Попал в TradingView (далее TV) почти случайно, так как до этого я более месяца проходил много этапов собеседований в другое место (в НИИ с уклоном на реверс-инжиринг и безопасность).
Все собесы наконец-то закончились и я туда должен был выйти уже завтра - послезавтра.
Про TV я знал давно, и в моем топе привлекательности оно было выше того места, куда меня брали (TOP 1).
Я ничего не знал про уровень ЗП, зато мне нравился свободный молодежный дух.
Свое представление я выстроил по отзывам и просмотрам записей митапов, проходящих в TV
Но к сожалению, на мой отклик мне не отвечали достаточно долго и я перестал думать о TV (TradingView).
И кстати на большинстве собеседований я прямо рассказывал, что у меня есть рейтинг мест по привлекательности, рассказывал по каким критериям я решил прийти именно сюда, по каким признакам я вижу плюсы, по каким минусы.
И вот, я практически принят в НИИ после череды долгих собесов, должен выходить послезавтра, как мне ответили из TradingView.
После собеса, ейчар сказал что в течении недели свяжется со мной.
Но я просил связаться раньше по возможности, так как мне у них понравилось, но я завтра должен выйти уже в другом месте.
Мне пошли на встречу и ответ сообщили вроде бы в тот же день вечером.
Я отписался в телеграм в НИИ своему почти будущему начальнику, что согласился на другое приглашение.
Меня спросили, почему я больше заинтересовался другим местом.
Я ответил что мне нравятся процессы и свободный молодежный дух.
При этом назавать куда ухожу я не стал.
Мне ответили, что они в команде сделали ставки по этому вопросу. И побеждает версия с TradingView.
Ранее я писал про честность на собесах, что это помогает сохранить хорошие отношения и проверить на адекватность.
Вот это был пример когда сохранились хорошие отношения. Хоть и было потрачено много сил и времени с обоих сторон.
В целом я рад и тому что перешел в IT, и тому что попал в TradingView.
В IT другая культура.
К вам относятся к человеку, помогают расти и делать все, чтобы вы были довольны
И платят тоже хорошо.
В других сферах все это менее распространено.
Я рад что ушел с юридической стези.
Было много стресса, меньше свободы, ЗП не такая заоблачная, как я себе воображал.
Когда встречаю бывших одногруппников, мы делимся, что нового у каждого произошло.
Все не из IT.
Если заходит речь про ЗП, мне потом говорят, что я их расстроил
Поэтому будьте довольны, сейчас IT на подъеме и здесь лучше, чем во многих других местах.
Кстати интересно, как другие относятся к IT 🤔
Считаете ли это супер местом и цените ли его также как и я?
Или в целом думаете - что нет ничего особого? И нет такого ощущения, что в основном в большинстве сфер все не так хорошо?
А пока двинемся дальше.
Мы пришли к тому что я в TradingView.
Мне здесь настолько нравится, что я пытаюсь убедить и своих IT знакомых тоже прийти сюда.
Мне нравится обстановка здесь, нравится что многие вопросы решаются командой, и относительно продукта в том числе.
И возможность влиять на продукт мне нравится прям очень сильно.
Круто быть вовлеченным и наблюдать как продукт растет.
Я успел прийти еще до первого релиза в стор, а сейчас в одном Android более миллиона инсталлов.
Вместе с iOS месячная аудитория более 1.8 миллиона.
Хочется верить, что хоть какая-то малая заслуга в этом есть и моя 🙂
Кстати, до самоизоляции у нас ежемесячно проводились разные митапы.
Это хороший способ как отдохнуть, так и провести некий тимбилдинг на уровне компании, послушать доклады, узнать новое, посмотреть на интересных спикеров и привлечь новых сотрудников.
Было весело.
Чаще всего это были открытые митапы, куда мог прийти любой желающий и оценить обстановку 🥳🍸🕺
И да, бар у нас прям на кухне 🙂
Кажется @_bravit тоже был у нас доволен )
Да и в качестве спикера тоже был замечен 🕵️
Вторник
Кстати интересно, как другие относятся к IT 🤔 Считаете ли это супер местом и цените ли его также как и я? Или в целом думаете - что нет ничего особого? И нет такого ощущения, что в основном в большинстве сфер все не так хорошо?
Большинство согласно с тем, что IT это круто 🤟.
Так держать 💪
twitter.com/mobileunderhoo…
Ок, вчерашний speech был про мой путь 👟 в IT и отношение к нему 🙂
А сегодня поговорим про А/B тесты 📊
А/B тесты - это важная часть работы над продуктом.
Тест позволяют сравнить несколько версий продукта и определить, как изменения влияют на целевые показатели, конверсию📏📉
Это эффективный способ проверки гипотез.
A/B тесты помогают принимать решения, основываясь на собранных данных и цифрах, используя мощь статистической теории, в противовес принятию решений, основанных на интуиции, домыслах
Помогают поставить точку, в случае наличия нескольких мнений, когда каждый продвигает свою точку зрения.
Они помогают измерять реальное поведение аудитории вашего продукта.
Защищают от того, чтобы выкатить в прод ухудщающие изменения
Кроме того, могут тестироваться не только гипотезы по улучшающим изменениям, но и просто гипотезы важности того или иного аспекта для продукта.
Речь идет про ухудшающие эксперименты😱😁
Например, ухудшение performance и замер результатов через эксперимент - быстрый способ проверить насколько performance важен для вашей аудитории.
Еще ухудшающие эксперименты помогают отделить чувствительные метрики от не чувствительных
На чем же строится достоверность выводов экспериментов ?
Во-первых одновременность замера версии с изменениями и без. Нужно как можно сильнее исключить сторонние факторы.
Ведь если делать замер версии с изменениями и без в разное время - то есть много дополнительных факторов, которые могут влиять - влияние дня недели, количество праздников и выходных, политические, экономические новости, курс валюты и т.д.
Когда мы делаем замер одновременно, мы расчитываем, что единственное изменение - это то, которое мы заложили в эксперимент.
Вторая причина, из-за которой мы можем рассчитывать на достоверность вывода, сделанного по итогу эксперимента - статистическая теория проверки гипотез.
В общем, статистика предоставляет нам следующий порядок рассуждений для проверки гипотез 👇:
Определяем нашу генеральную совокупность (ГС)
Выбираем контрольную группу (выборка А) без изменений и группу с изменениями (выборка В)
Выдвигаем нашу нулевую гипотезу (H0): "выборка А и В принадлежат одной ГС, между ними нет разницы".
Альтернативная гипотеза (H1) состоит в том, что между выборками есть статистически значимые различия (т.е. они не принадлежат одной генеральной совокупности)
По умолчанию считаем достоверной гипотезу H0.
Применяем относительно H0 правило: "Отклоняем тихо, оставляем громко".
Т.е. нулевая гипотеза верна, пока нет достаточных оснований ее опровергнуть.
Выбираем порог отклонения нулевой гипотезы (p-value).
Часто применяют порог 0,05 или 0,1.
Читается это так - если p-value ниже 0,05 порога то можно с 95 %-ной вероятностью утверждать, что есть статистически значимые отличия между выборками.
Для 0.1 это соответственно 90%.
Где-нибудь в физике и других сферах, где важна супер уверенность, могут применять и более точный порог, например 0,01.
В тоже время бывают варианты и с меньшей степенью вероятности, например 0,2.
Иногда готовые системы аналитики и a/b тестирования предлагают такие.
Более низкий порог дает большую уверенность, но требует и большую статистическую мощность. Более высокий порог - меньшую уверенность.
Статистическая мощность зависит от размера выборок и силе различий между ними
Проводим тест и проверяем статистическую значимость.
Разница называется статистически значимой, когда достигнутая разница между выборками маловероятна, если предположить, что обе выборки принадлежат одной генеральной совокупности (т.е. верна H0).
Для оценки маловероятности полученного отклонения, как раз и используется порог, который мы определили выше.
Можно либо напрямую рассчитать p-value, либо построить доверительный интервал.
Доверительные интервалы - это то, что чаще всего можно увидеть в готовых сервисах для проведения экспериментов.
Взглянув на два интервала - достаточно понять включает ли в себя один интервал среднее значение другого. Если не включает - то можно отклонять нулевую гипотезу (H0)
Но стоит отдельно отметить, что статистическая значимость говорит только о вероятности получения различий между выборками, при условии, что H0 верна, но ничего не говорит о величине разницы между выборками
Просто вероятность разницы
Насколько большая разница - не говорит ❕
Также стоит отметить, что приведенный алгоритм, не единственный шаблон проверки гипотез. Скорее просто хороший базис, чтобы начать понимать основы статистической проверки.
А так бывают еще разные виды экспериментов, поправки к данным, есть байесовский метод и т.д.
Что же делать, если мы не получили стат. значимость ?
А ничего - просто мы не смогли подтвердить H1
Большинство экспериментов не показывают результат, это нормально
Нужно настроиться на это заранее и не расстраиваться потом😀
Чтобы уменьшить количество таких результатов - можно более осмысленно подходить к выбору изменений для замера экспериментом.
Не тестировать все подряд, а только реальные гипотезы, которые как-то логически обоснованно могут повлиять на целевые метрики.
Не проводить тест там, где маленькая выборка, изменение будет незначительно или тест может затянуться надолго
Получится ли набрать необходимую статистическую мощность - лучше считать заранее.
Напомню, что на нее влияет как размер выборки, так и чувствительность целевой метрики.
Ищите более чувствительную метрику и как можно точнее отбирайте сегмент.
Если эксперимент нацелен только на проверку поведения не зарегистрированных пользователей или только платящих, то и в сегмент отбирайте только их, а не всех подряд.
Для нормального распределения значений можно сказать, что важно не только среднее значение выборки, но и размах значений. Выбирая более точно сегмент, мы уменьшаем размах
В целом нужно настроиться на то, что эксперименты требуют больше сил и времени, и увеличивают длительность релизного цикла фичи. Зато дают дополнительную уверенность
Может потребоваться провести разные статистические проверки - проверить на выбросы (сильно отклоняющиеся значения), проверить на характер распределения, выполнить некоторые поправки 😁
Проведение многофакторного эксперимента (сразу несколько изменений влияют на целевой показатель) или многовариантного (А/B/C/D/….) усложняет подсчет статистической значимости. По хорошему нужно проверять корреляции признаков и делать статистические поправки
Но хорошая новость в том, что есть готовые инструменты проведения экспериментов, которые сами все считают за нас 😁
Но при работе с ними, держите в голове идею про простой дизайн эксперимента (однофакторный А/В - одно изменение один вариант с изменением) - ибо эти инструменты вряд ли делают поправки на более сложный дизайн.
Обращайте внимание и на используемое значение p-value
Готовые инструменты тестирования хороши, чтобы начать, особенно для экспериментов с простым дизайном. Но все равно иногда лучше включать здравый смысл и здоровое недоверие.
Часто если тест определяет победителя довольно быстро - то просто подождите еще) Он еще может поменяться
Для более точных рассчетов, большой уверенности и покрытия разных ситуаций - большие компании заводят in-house аналитику, систему сплита пользователей для эксперимента и доставки фиче тогглов.
Вообщем A/B тесты довольно хороший инструмент, если правильно им пользоваться)
До недавнего времени у нас их еще не было.
Поразмыслив с @tereznikof (наш продакт), решили что пора начинать что-то пробовать
Самое простое и очевидное - Firebase A/B Testing.
С него и начали.
К тому же Firebase одна из аналитик, которой мы пользуемся. Уже настроена куча ивентов, по которым можно мерять конверсию и User Property, по которым можно сегментировать пользователей.
Среда
Cегодня поговорим про локализацию 🇷🇺🇺🇸🇮🇹
Будет немного про стандарты и локализацию в общем, про flow локализации у нас, и потом некоторые детали для Android.
Чем полезна локализация для продукта - понятно.
Она помогает выйти на новые рынки и увеличивать удержание существующих пользователей, если общение с ними ранее было не на родном для них языке.
Конечно в каждой ситуации нужно отдельно оценивать необходимость локализации.
Однако часто - если вы делаете мировой продукт и у вас уже есть не мало пользователей из разных стран, с помощью локализации можно достигнуть еще большего роста активной аудитории
Если для вашего only english продукта у вас уже много пользователей, например из России, Германии, Китая и т.д. - это повод обратить внимание на эти регионы.
ASO оптимизация c локализацией (переводы текстов, скриншоты, ключевые слова) тоже хороший способ увеличить установки.
А иногда для проверки потенциала роста, достаточно начать с локализации страницы самого приложения.
И если заметен рост - то заняться и самим приложением.
Можно найти и другие стратегии выбора региона для локализации :
- где плохо знают английский.
- где хорошо платят.
- где мало локализованных конкурентов и т.д.
Localization иногда пишут сокращенно как l10n.
10 - количество символов между l и n.
L10n - это не просто перевод, форматы даты, времени, валют и т.д.
L10n - это еще и понимание менталитета и культурных особенностей регионов.
Это могу быть другие цвета или другие способы трактовать информацию, другие формы обращения к человеку.
Хорошим примером является локализация для Китая, ибо с ней можно выделить сразу несколько нюансов.
Например в Китае любят красный цвет.
У них он символизирует счастье и богатство.
И когда у всего мира зеленый цвет котировок означает рост, а красный падение, у Китая все наоборот :
- красный - рост
- зеленый - падение
Скидки для Китая тоже нужно указывать по другому. Нужно писать не размер скидки, а размер остатка после скидки.
Для китайской локали есть два скрипта:
- Традиционный (Traditional)
- Упрощенный (Simplified)
Каждый из китайских регионов использует один из них.
Не нужно использовать китайские локали без указания скрипта, просто как язык и регион (например zh-TW) 🙅
Используйте:
- zh-Hans (Simplified script) для регионов CN, HK, SG)
- zh_Hant (Traditional script) для TW, HK, MO).
Иначе иногда можно обидеть китайских пользователей, так как у них есть свои территориальные тёрки
Еще есть термин Internationalization (i18n).
К i18n относятся различные приемы, которые помогают строить продукты, гибко адаптируемые под любой регион.
Т.е. это не адаптация под конкретный регион, а скорее общие техники создания международного продукта.
Что это за практики могут быть?
Во-первых, банальное - хранить строки в отдельных ресурсах, а не хардкодить в коде. Это позволит гибко выбирать вариант текста с учетом локали.
@mobileunderhood i18n тогда что?) просьба раскрыть подробнее тему l10n vs i18n
Сегодня вопросы задают довольно быстро) 💪
twitter.com/stephenseliuk/…
Еще есть термин Internationalization (i18n). К i18n относятся различные приемы, которые помогают строить продукты, гибко адаптируемые под любой регион. Т.е. это не адаптация под конкретный регион, а скорее общие техники создания международного продукта.
Только начал писать про i18n 👇
twitter.com/mobileunderhoo…
При этом полезно помнить, что знаки пунктуации тоже могут использоваться по разному.
Или слова вообще могут менять свой порядок.
Поэтому плейсхолдеры лучше использовать нумерованные и позволить переводчикам самим решить вопрос их расположения
Во вторых - не хардкодить паттерны даты, а пользоваться форматтерами, которые работают учитывая локали.
Например порядок цифр может отличаться даже между en локалями в зависимости от региона.
С другими локалями может быть еще больше отличий.
В-третьих - при дизайне учитывать, что в разных языках разная длина слов.
Некоторые языки занимают больше места, некоторые меньше (особенно иероглифы).
Если решить этот вопрос в дизайне не удается - то просим переводчиков подобрать более короткий перевод.
Соответственно визуальные элементы с текстом должны выглядеть органично, не слишком большими относительно малого количества текста, но в тоже время и чтобы текст не обрезался.
Даже если вы пока не поддерживаете RTL, можно сразу с ориентиром на будущее использовать возможности гибкого задания верстки, в зависимости от направления. Например, использовать атрибуты start, end, вместо left, right
В-четвертых, плюралы.
Кроме отдельного хранения строк, не забывайте и про плюралы (формы множественного числа).
Учтите, что одна и та же плюральная форма имеет разное употребление в разных локалях
Например, для en локали плюральная форма one - это только 1.
Для ru локали - это 1,21,31,101 и т.д., т.е все что при делении на 10 дает остаток 1, но кроме 11-дцати.
Не забудь в дефолтной локали для переводчиков указать варианты для всех плюралов, даже если именно в этом языке какая-то форма не используется.
И для one лучше тоже использовать вариант с указанием плейсхолдера. Даже если в дефолтном языке one - это только 1 (как для en)
Иначе переводчики могут ошибиться при переводе. Вспомните что в русском плюрал one используется и для 21,31...
Здесь пользователю вместо "Посмотреть 21 комментарий" покажем "Посмотреть комментарий" 😁
Кстати, выше писал про то, что нужно использовать нумерованные плейсхолдеры, вместо замены плейсхолдеров при форматировании строки просто по порядку.
Как раз нашел пример того, что может быть если не следовать этому правилу 😅
Полезный сайт в плане просмотра стандартов - это cайт консорциума Unicode - cldr.unicode.org
Основное назначение проекта - это распространять языковые настройки для софта в формате xml.
Однако можно его использовать и для себя - там много полезной информации.
Конечно сайт не самый user friendly и experience такой себе.
Иногда они еще временно ломают полезные ссылки.
И приходится смотреть в либо веб архиве, либо выкачивать их репозиторий.
Хорошо, что сейчас они добавили просмотр и через GitHub Pages.
Вот здесь например можно посмотреть информацию по плюралам
unicode-org.github.io/cldr-staging/c…
Еще интересный момент - стандарты бывают не совсем стабильными и могут меняться.
Например, в стандарте буквенного кодирования языков ISO-639 менялись коды некоторых языков.
В некоторых языках программирования при создании локали с указанием кода языка, код языка может подменяться на старый, с целью обратной совместимости.
Например, в Java коды языков "he", "yi", "id" подменяются на "iw", "ji", "in"
Такая она, обратная совместимость.
Из-за подмены кодов я несколько раз натыкался на некоторые баги.
Коды в стандарте поменяли аж в 1989 году (да, до выхода Java), страдаем до сих пор🤷♂️
Далее расскажу про наш флоу работы с переводами.
В качестве сервиса, в который выгружаем переводы и где с ними уже работают переводчики, используем Webtranslateit.
С Webtranslateit можно работать через api напрямую, или через командную строку с помощью их CLI.
У нас там есть разные проекты - для веба, для Android, для iOS. Есть и общая часть.
Сервис может принимать и отдавать *.po файлики.
Это формат для переводов со специальной структурой. Содержит информацию о языке, id строки, оригинале строки, переводе, комментарии, плюралы.
Этот формат используется в библиотеке для интернационализации gettext.
Для того чтобы из исходников приложения собирать строки в po файл и потом обратно из po файла собирать ресурсы с переводами - можно воспользоваться какой-нибудь дополнительной тулзой.
Например: github.com/miracle2k/andr…
У нас есть специальная ветка для переводов.
В CI есть scheduled job, которая проверяет, что появились новые строки для переводов, далее собирает их в po файл и отпаравляет в WebtranslateIt.
И также есть job, которая наоборот выгружает и распаковывает переводы в эту ветку.
Ветка потом мержится в develop.
При этом, так как мы тянем переводы из нескольких проектов, и имеем несколько *.po файлов для одной локали - нам их нужно смержить в один файл. Это умеет делать msgcat тулза.
Если в наших строковых ресурсах оставлять комментарии - то они дойдут до переводчиков.
Там часто указываем описание контекста.
Но есть способ и скрыть от переводчиков комментарии, если они нужны чисто разработчикам.
Тег <eat-comment /> работает )
Ключи стараемся давать точные, чтобы был понятен контекст.
Конвенция такая - уровень_тип_назначение
И для одного и того же слова/текста на дефолтном языке, но с разным контекстом используем разные ключи
Это помогает исключить ситуации, когда один текст используется для разных ситуаций и на каком-то языке перевод может не подходить под другой контекст
Здесь первое на русском можно использовать как "Подписки", а второе "Вы подписаны"
Иначе будет кнопка с текстом "Подписки", вместо "Вы подписаны" 😀
Еще у нас есть способ быстро пройтись в UI тестах по основным экранам с разными локалями, собрать скриншоты и записать видео.
В случае необходимости можно проверить, что языки корректно переключаются, верстка не едет и еще для переводчиков собрать скриншоты
Кстати, с помощью схемы, подсмотренной у Kaspresso,
и своего DSL получилось удобно из кода тестов запрашивать выполнение команд для ADB и терминала
github.com/KasperskyLab/A…
Если и дальше углубляться в детали l10n конкретно под Android, то следует упомянуть, что начиная с 24 API - обновить конфигурацию (которая содержит информацию о локале) на ресурсах больше нельзя, нужно рестартовать Activity и получать новые Resources с новым Context
Особенно это касается ситуации, когда вы не просто отлавливаете изменение конфигурации при смене ее в системе, но и когда у вас есть собственный экран настроек с поддержкой смены языка.
Не забывайте при смене языка в приложении также менять и локаль для текущего инстанса JVM через Locale.setDefaults. Это много где используется в библиотеках и системе.
Locale.default дизайн мне не очень нравится, ибо это синглтон который может быть изменен откуда угодно и кем угодно. Но Java вынуждает нас с этим жить
При смене языка на смартфоне не забудьте решить - как будет вести себя приложение - переключать язык вместе с системным, или оставлять тот который выбран.
При этом опять не забудьте про Locale.default
Есть системный язык не поддерживается в приложении - то просто проставится дефолтный язык из ресурсов. Но Locale.default перепишется на тот неподдерживаемый язык, и библиотеки использующие его для форматирования будут вести себя не корректно 😱
Для форматирования времени и даты можно использовать DateTimeFormatter. Он использует информацию из локали и форматирует с учетом их особенностей. Единственный минус - локаль нельзя передать параметром, он как раз один из тех, кто использует Locale.default
С методами toUpperCase, toLowerCase и c аттрибутом AllCaps тоже следует быть аккуратнее.
Без передачи локали в параметры этих методов - изменение регистра может пройти с ошибкой для языка.
Например, если у вас стоит Турецкий язык, а username пользователя бывает только английский
Четверг
А сегодня поговорим про вступление в брак 👫 и что нужно делать, чтобы все было хорошо 🙂
Вопрос серьезный, и подходить к нему нужно осознанно ❗️
В России уровень разводов превышает 50%.
По миру уровень разводов тоже постоянно растет.
Я не социолог, не психолог и в этом вопросе не спец.
Поэтому могу ошибаться. Просто говорю свое мнение.
Причины разводов конечно разные.
Но помимо прочих, я бы выделил особо ситуации, когда трудности проявляются изначально из-за несовместимости
Обычно видна зависимость от уровня экономическоего развития по странам, группам населения.
Чем он больше - тем реже сохраняется брак из-за финансовой зависимости
Чем больше защищаются права женщины и чем больше у нее есть возможностей самой работать и обеспечивать себя - тем тоже больше расторжений брака
Лично мое мнение - дело в том, что когда есть какие-то сдерживающие факторы, то люди сохраняют брак.
Но при этом остаются очень несчастливы вместе.
Поэтому если есть возможность быть независимым от супруга и расторгнуть брак, это даже лучше, чем сохранять и страдать
Просто статистика разводов не отвечает на более важный вопрос. Нужно больше фокусироваться именно на том, насколько счастливы пары вместе, а не сколько остается сохраненных браков.
Само по себе сохранение брака не может рассцениваться как однозначно позитивная метрика
Иначе потом можно терпеть годам, обзавестись 10-ю детьми и потом развестись в глубоком возврасте. Страдать будут и дети и бывшие супруги, ибо лучшие и молодые годы жизни уже отданы.
Соответственно, нужно как-то влиять на уровень счастья в браке.
Как же это сделать? 🤔
Для начала нужно готовиться к браку, совместной жизни заранее, как можно лучше узнать друг друга.
Это означает, что не нужно пускать все на самотек, жить только на основании влюбленности и эмоциях.
К ранней стадии отношений можно подойти как к вопросу тестирования продуктовой гипотезы или как к вопросу о стоимости обнаружения ошибки в продукте. Чем раньше ошибка была найдена, тем стоимость ниже. Чем позднее - тем стоимость выше.
А значит, нужно хорошо готовиться, прежде чем принимать важные, влияющие на всю жизнь решения; нужно повысить уровень осознанности
Ослепленность влюбленностью по началу может создавать видимость счастливых и крепких отношений, но также и мешает сразу определить проблемы, которые эти отношения потом разрушат
Как же готовиться?
Нужно подумать о том, что каждому важно в жизни, насколько в этом вы будете помогать друг другу и насколько мешать.
Против чего каждый категорически против.
Насколько совпадают жизненные ценности.
Насколько общие интересы и насколько общим может быть путь.
Например, если один супруг укоренелый спортсмен, а другой ярый домосед, который не только не будет поддерживать спортивные начинания, но и вообще будет против поездок по соревнованиям, вместо сидения дома - то это почва для конфликтов и неудовлетворенности обоих
Один увлеченный предприниматель и путешествиенник, любит риск и еще и экстрим. Другой спокойный домосед, против рисков, любит стабильность и родной город. Здесь не то что нет поддержки друг друга, но и каждый тянет одеяло в свою сторону.
Один любит побыть с друзьями, попить пивка.
Другой ярый противник алкоголя, полностью за ЗОЖ.
Для одного дело всей жизни - различные открытия в математике или физике. Другой не относится к этому серьезно, топит за то, чтобы идти работать менеджером и строить нормальную карьеру
Иногда и насчет отпуска может быть тяжело договориться. Одному хочется в шикарные отели заграницей и со спа. Другому хардкорные походы по горам, ночевки в палатке, рыбалка. Что одному отдых и новые впечатления, другому страдания. Отдыхать порознь тоже не вариант.
Конечно не каждые различия в интересах стоит рассматривать как серьезное препятствие.
Нужно отталкиваться от того, насколько та или иная конкретная вещь важна для счастья в жизни каждого.
А иногда бывают и ситуации, когда люди с разными взглядами хорошо уравновешивают друг друга.
Поэтому этот совет тоже нужно применять с умом.
Совет скорее про то, что нужно понять - насколько сильно вы готовы идти вместе по пути совместного счастья, насколько у вас общие интересы.
Если они в чем-то не общие, то насколько сильно вы будете мешать друг другу быть счастливыми.
Само собой на 100 % совпадающего по интересам партнера найти маовероятно. Важно просто провести для себя границу - что для каждого критически важно, а в чем готовы будете проявлять гибкость и идти на компромисы.
Полезно также составить список важных и волнующих вопросов и обсудить их.
Убедиться что нет критических противоречий
Вопросы
- о детях, когда их заводить, как воспитывать
- о родственниках
- о финансах и работе
- о сексе
- о здоровье и болезнях
- об обязанностях
- как видите роль жены и роль мужа
- о планах планах на будущее
- что ждете от брака
- религии
- политике
- отношении к закону
- алкоголе и азартных играх
- времяпрепровождении с друзьями
- сколько свободного личного времени каждому нужно
- как разрешать конфликты
- как вместе проходить трудности
- в одном ли направлении будете двигаться по жизни
- в чем вы похожи, в чем различаетесь
- что устраивает, что не устраивает и вы ожидаете изменений от партнера
- насколько готовы видеть друг в друге не только хорошее, но и принимать плохое и где граница принятия
- насколько каждый готов работать над отношениями и меняться
Попробуйте состоватить важные вопросы от себя
Цель максимально узнать друг друга и показать себя партнеру, обнаружить проблемы как можно раньше и заранее разобраться со всеми спорными и тяжелыми вопросами
В переди их будет еще досточно, но подготовка лишней не будет)
@mobileunderhood Если настолько математически подходить к отношениям, то теряется вся их суть. Все эти(и другие важные) вопросы прекрасно решаются длительными отношениями и проживанием вместе, а не марафонным забегом в ЗАГС после пары месяцев обжиманий в кинотеатре
Воу, я вижу что эта тема вызвала оживленный интерес, и меня это очень радует 😊
Чтобы подтреты не потерялись - добавлю их сюда
twitter.com/xd720p/status/…
Это верно гарантий нет
twitter.com/Nocchka/status…
Вот лучше бы про программирование писал... twitter.com/mobileunderhoo…
@mobileunderhood Есть еще вариант забыть старые форматы, и просто получать удовольствие от отношений пока это получается, без лишней бюрократии и обманчивых надежд.
@mobileunderhood В любом случае почти все отношения заканчиваются (со штампом и без), собсно мысль была в том, чтобы это принять и не тешить себя иллюзиями и не подписывать ничего, о чем пожалеешь в итоге. Интересно ваше мнение, в чем вообще смысл регистрировать отношения?
Когда-нибудь через @mobileunderhood я узнаю откуда берутся дети.
Просто веселый твит )
twitter.com/aarexer/status…
@mobileunderhood Я отнесся несерьёзно и вот уже 6 год вместе официально. Боюсь читать теперь, вдруг передумаю
Это здорово 🥳
Я вообще тоже не относся серьезно 😜
И тоже уже 6,5 лет вместе (в браке чуть меньше) и все отлично ) 💪
Жаль, что некоторым везет меньше - вокруг меня полно примеров, кому бы такие советы не помешали в начале 😞
twitter.com/abbath0767/sta…
Чтож двинемся дальше 😁
Также важно понять, насколько вы готовы выстраивать здоровые отношения двух самодостаточных людей, вместо токсичных, невротичных и зависимых отношений.
Токсичные отношения можно перетерпеть или найти способ избавиться от них, например на работе или при обращении в гос. органы или в другом месте.
Но брак это надолго и лучшее заранее с этим разобраться
Невротичные отношения - это любые отношения, которые заставляют человека страдать и переживать. Они строятся на внутренних проблемах, которые испытывает один или оба из партнеров.
Вероятнее всего, если один невротик, а у другого здоровая психика, то второй быстрой уйдет.
Конечно всякие сдерживающие факторы, на подобии финансовой зависимости, сложности раздела имущества сыграют свою сдерживающую роль, но такое себе
Если невротики оба, то страдать вместе и поддерживать не здоровые отношения могут долго. Но нельзя идти на поводу невротичных отношений, приносить боль и страдания друг другу (а потом и детям)
Унижения и манипуляции, эмоциональный шантаж, постояные капризы, чувство жалости к себе, излишняя зависимость от партнера, постоянные скандалы и выяснения отношений, претензии и обиды и т.д.
Лучший способ работы с этим - это обратисься к психотерапевту.
При этом невротик должен сам понимать проблему и желать ее исправить, конечно при поддержке друг друга.
Что еще ?
Приготовьтесь с одной стороны быть более гибким и меняться. Многие привычки и взгляды на жизнь придется пересмотреть, взять на себя новую отвественность и постоянно работать над собой и отношениями.
С другой стороны - не нужно пытаться перевоспитывать друг друга )
Подытожим опросом 😀
А вы как считаете, нужно ли думать перед вступлением в брак о том, как можно попробовать предупредить будущие проблемы ?
Хорошо поговорить друг с другом, обсудить важные вопросы, подготовиться ? 🫂
Пятница
Ух, вчера были жаркие обсуждения ♨️
А сегодня у нас пятница, а значит по плану снова IT-шная тема 🥳 😁
Будем говорить про сложность восприятия кода.
Для начала стоит сказать, что работа с кодом - это не только написание кода, но еще и чтение и попытки его понять. Причем читаем мы в разы больше.
Когда мы пишем код, нам кажется что все понятно и не нужно принимать дополнительных усилий, чтобы обеспесить его читаемость.
На самом деле это ловушка.
Пишем код мы кусками, каждый раз сохраняя фокус на конкретном маленьком участке логики. Отсюда и высокое понимание это участка.
Как только проходит немного времени и мы забываем контекст - то когнитивная лекость понимания проходит. Нам уже нужно больше усилий, чтобы разобраться.
К тому же читать код приходится в гораздо больших количествах, чем писать. Программы растут в размерах. И читать нужно много.
Уже нет постепенного фокуса на маленьком участке логики, нужно сразу охватывать большие части, связывать между собой различные куски программы
Если смотреть на небольшой пример кода, в котором не побеспокоились об уменьшении сложности его восприятия, то потратится лишь немного больше времени на его понимание. Это будет даже не заметно.
Когда речь идет о большой программе - то это выливается уже в более заметные масштабы
Когда я добавляю новую логику, или дебажу какую-то ошибку, чтобы разобраться с логикой работы программы - нужно много читать своего и чужого кода
Но дело даже не только в скорости восприятия кода. Чем более легко воспринимается код при чтении и чем меньше допускает возможностей трактовать логику по разному, чем меньше вводит в заблуждение - тем меньше вероятность совершить ошибку.
В целом читаемость и сложность кода сильно влияет на качество и скорость поддержки.
Поэтому важно не только быстро выполнить таск, но и обеспечить простой уровень поддержки, масштабирования логики, развития.
Конечно для каждого продукта свой баланс скорость vs поддерживаемость
Можно написать логически верную программу, которая будет работать правильно, но будет совершенно не поддерживаемая.
Все потому, что мы не машины и подвержены различным когнитивным искажениям и ошибкам при восприятии информации.
Нужно помнить, что пишем не только инструкции для машины, но и описываем логику для человека
Машине все равно как записан код если он корректен. Но человек скорее всего не станет долго поддерживать и развивать проект с обфусцированными исходниками.
В целом можно и с таким кодом разобраться, но времени это будет занимать гораздо больше. И следует вспомнить, что прочитать нужно много кода. Это большая часть нашей работы по времени.
Говоря об отличия восприятия человеком информации от машины, прежде всего хочется упомянуть про кошелек Миллера
Американский ученый-психолог Джордж Миллер выявил закономерность, согласно которой кратковременная человеческая память, обычно не может удержать более чем 7 ± 2 элементов
Фишка в том, что "положить в кошелек" больше чем 7 ± 2 элементов нельзя, но можно ложить элементы разного уровня абстрагирования, разного веса
Так например, для начинаюзего джуна, для которого всё в новинку, такие элементы будут достаточно мелкими - какие-то элементарные правила синтаксиса и т.д.
С большим опытом мозг привыкает оперировать такими конструкциями и начинает делать это на автомате, а значит может подняться на уровень выше и оперировать например паттернами или сложным объектами как одним элементом, который он может положить в кошелек.
Соответственно он уже может удержать в голове больше логики работы программы за счет повышения уровня абстракции.
В целом можно это заметить, когда пытаешься разобраться с логикой работы программы на языке, с которым редко работаешь.
Разобраться можно, но это занимает чуть дольше времени и уровень понимания чуть хуже.
По аналогии с разным синтаксисом языков, в таком же принципе состоит и одна из полезностей использования код стайла.
Даже на одном языке можно по разному писать код, использовать по разному переносы, скобки, отступы
Часто важно не то, какой именно код стайл, а то чтобы он просто был.
Когда используются одни и те же паттерны в структуре кода, то мозг к ним привыкает и это помогает снизить когнитивную сложность восприятия, экономит время при прочтении
Поэтому код стайл, а вместе с ним всякие линтеры и анализаторы кода - наши помощники.
Они помогают нам следить, чтобы мы не передавали слишком много параметров в метод.
Они помогают нам не писать слишком длинные строки, ведь чем правее информация, тем больше шансов что-то упустить при прочтении. Мозг лучше подребляет информацию в начале строки, так как глаза больше проходят ближе к левому краю текста.
Большие методы и классы тоже могу отрицательно влиять на легкость восприятия.
Много вложенных if-else и т.д.
Цикломатичная сложность - тоже одна из важных метрик оценки когнитивной сложности восприятия кода. Линтеры частично помогают ее снижать.
Можно также использовать различные плагинчики для замера сложности в IDE или в CI
Подведем итоги)
Большинство согласны, что стоит относиться серьезнее к вопросу, стараться узнать человека лучше, обсудить важные вопросы и не полагаться просто на чувства ❤️ перед вступление в брак
В этом и был основной point🙂
Но были и другие интересные мнения в комментах)
Кстати, это, пожалуй, основной аргумент, почему не желательно жениться раньше лет так 25-ти, на мой взгляд. К этому возрасту, как правило, начинает складываться система СОБСТВЕННЫХ убеждений и ценностей. Один и тот же человек в 20 и в 30+ - это практически два разных человека...
Вот тоже интересная мысль.
Согласен, что человек от 18 до 30 скорее всего изменится гораздо сильнее, чем например от 30 до 40 или даже от 30 до 50. И тогда 25+ возможно будет более подходящим возврастом, чем 18, хоть у всех может быть и по разномуtwitter.com/Alisa_Livi/sta…
К сожалению, не все удается переложить в руки автоматических помощников, анализаторов. Собственная осознанность в этом вопросе тоже важна.
Такие вопросы как правильное именование переменных, методов, оставление комментариев, тоже имеет прямое влияние на восприятие кода.
Хорошая практика, называть переменные так, чтобы название точно отвечало на вопрос - что это?
Когда я говорю точно, я имею ввиду, назвать так, чтобы нельзя было трактовать смысл названия более широко, или более узко или не правильно.
Например переменаня locale может быть не достаточно точной
Что это за локаль ?
systemLocale, appLocale, savedLocale ... ?
allLocales -> supportedLocales
items -> itemsOnPage и т.д.
Правила точной трактовки относится и к методам.
Если метод предназначен для проверки того, что установлена например локаль с английским языком и GB регионом (соответствует UK локале), то я ожидаю что метод будет называться isUKLocale, а не isEnglishLang.
Хоть и что-то похожее, но суть разная. Последее имеет больее широкий смысл.
А не точное отражение смысла ведет к ошибкам при применении этого метода потом в другом месте, при прочтении логики или при рефакторинге
Хотя когда вы пишите этот метод и смотрите на него целиком, вместе с телом метода, которое простое в одну строчку - может показаться, что все легко и ошибки нет.
Вы же видите прям сейчас как это реализовано и понимаете суть метода.
Для избавления от такого - нужно всегда думать о том, на сколько верно будет читаться логика программы в месте использования функции, там где видна только сигнатура метода, но не видна реализация.
Ввводить в заблуждение или допускать разночтения название точно не должно.
Простое правило - если какое-то название может быть трактовано по разному, оно будет трактовано по разному.
А значит и применено будет не правильно
Я не за то, чтобы никогда не изучать реализацию функций, а за то чтобы тратить на это меньше времени и код допускал меньше возможностей для совершения ошибок из-за неправильно понимания.
При этом точность именнования иногда может приводить к очень длинным названиям, но это тоже не желательно, важно сохранять баланс.
А лучше применять другие способы для сохранения информации, которую мы хотели уложить в название.
Можно разбить метод на несколько с более короткими названиями. Особенно часто подходит для булевых методов с несколькими проверками
Можно вынести набор переменных в отдельный класс, который часть информации забирет себе в имя и название переменной сделает короче.
Если говорить еще не именно про проблему разбиения длинных названий, а просто про то, куда можно выности какую-то информацию, то можно использовать также JavaDoc в коде, документация не в коде, commit message и PR message в git.
Это дополнительные способы сохранения информации.
Они менее приоритетны, ибо либо требуют поддержки, либо могут затеряться.
Но в целом, когда я не могу понять причины те или иных измений, это будут места куда я тоже полезу и попробую разобраться
Не пренебрегайте ими, особенного вариантами с git.
Не ленитесь писать понятные сообщения по схеме - "что было сделано и зачем".
Часто сам код не способен ответить на эти вопросы.
Иначе при рефакторинге есть риск, что сделанный фикс, информацию по которому нигде не оставили - сломается или будет выкошен
В целом сегодня просто хотел сказать, что важно как пользоваться тулзами, которые помогают нам писать читаемый код, так и иметь собственную осознанность
Чем больше удается отдать в руки анализатора - тем лучше.
В идеале, чтобы весь код стайл проверялся автоматически.
Тогда во время ревью можно сосредоточиться больше на логике
Ну и не забывайте про старое правило 😁
В есть ли такая либа или тулза, чтобы можно было настраивать крутой Voice Over в мобильном приложении, но при этом и писать UI-тесты?🤔 А то часто UI-тесты вытесняют нормальный Accessibility для людей с особенностями. Или где про это почитать?
А кто-что подскажет по iOS ?)
twitter.com/pavbox/status/…
Суббота
@mobileunderhood Все ваши рассуждения и графики ломаются на том факте, которым козыряет Доктор Хаус. Все врут. Семейные планы, разговоры... А один думает: "вот не совсем сходимся, но такие сиськи", а она думает: "о, какой обеспеченный". Ну, или наоборот )))
Вот тоже интересный момент - людям свойственно обманывать.
Я бы даже добавил, что обманывать и других и самих себя.
twitter.com/Nocchka/status…
Я думал, можно ли с этим что-то делать.
Попалось на глаза видео, которое мне кажется достойно упоминания.
youtu.be/haUZiledg3Y?t=…
Во многом идеи пересекаются с идеями в этом треде.
Но также есть совет прислушиваться к семье и знакомым, особенно если у вас есть честные прямолинейные друзья. Возможно со стороны им виднее, что за человек рядом с вами, и глаз не замылен чувствами
Это тоже конечно же не абсолютная гаранития, но если у вас есть семья и друзья, которым вы доверяете, или трое из ваших друзей говорят одно и тоже - вполне себе повод задуматься
Сегодня у нас другая интересная тема для обсуждения - импакт, вовлеченность и драйф от того что делаешь.
Недавдо был разбор крутого 😎💪 доклада @parahall
Вот запись разбора
youtu.be/KoKKiwPqwRk
Мое видение вопроса:
Когда ты можешь не только получать хорошую зп, но и драйвить 🚀от того что ты делаешь и приносить пользу - то это очень круто ))
Можно совмещать и одно и другое 😃
Мой драйф состоит в том, чтобы не только писать код, но и думать о том, какую реальную задачу он должен решать, смотреть по сторонам и влиять на продукт
Когда думаешь о проблеме целиком, знаешь свой домен и своих пользователей - можно выбрать другой способ закодить, продумать дизайн решения.
Возможно увидеть слепые, не продуманные зоны и вообще предложить альтернативное решение. Возможно найти баги не в коде, а в доменной логике
Делаю ли я правильные вещи, или возможно таск просто создавался давно, с тех времен произошли какие-то изменения в продукте, платформе или мире и нужно внести какие-то изменения. Не упускаем ли мы ничего ?
Само собой, в первую очередь нужно улучшать процессы, которые не допускают ошибочные, не нужные, не актуальные или не точные требования в тасках
Разаработчик в первую очередь должен делать свою работу и делать ее хорошо.
Но я не считаю нормальным и уход в другую крайность - когда ты готов сотворить какую-то дичь, только потому, что до тебя уже все должны были продумать, а ты просто исполнитель и пишешь код, и это не твоя забота думать об остальном.
Тут я вспомнаю такой пример.
В 1983 году на пульт КП «Серпухов-15» поступило сообщение о запуске нескольких американских ракет.
Однако дежуривший в должности инженера-аналитика подполковник Станислав Петров смог спасти мир от глобальной ядерной войны
Он усомнился, что в случае начала войны американцы бы использовали не весь свой арсенал, а только пару ракет с одной базы.
Новейшее оборудование обнаружения было поставлено на вооружение за пару месяцев до этого.
Вроде были и протоколы и процессы настроены.
И они указывали, что необходимо принять другое решение.
Но неравнодушие человека, вместо простого исполнения инструкций, спасло мир.
Конечно пример может и преувеличен относительно наших тасков )
Зато хорошо иллюстрирует - что хоть немного знать свой домен и пользователей, и если что-то настораживает - лишний раз переспросить, уточнить - не будет лишним.
При разных инициативах важно и наоборот не верить слепо в верность всего что делаешь, если ты в этом не профи.
Например, продакт знает, что не каждая гипотеза подтверждается. А ты еще не столкнувшись с этим можешь настойчиво топить за новую идею, веря что она точно верная
Вообще нужно не переусердствовать и ничего не сломать 😁
Лучше согласовать что-то с теми кто разбирается в вопросе
Круто если в компании есть налаженные процессы по работе с разными инициативами 💪
Иногда важно обсудить идею и просто чтобы не тратить время на ненужные вещи
Также понятно, что такой подход больше матчится на продуктовую компанию и будет зависить от подходов в ней, применимости таких начинаний в конкретной команде и т.д.
Нормально просто любить писать код, а если ты способен еще не заваливать сроки, делать таски быстро, пусть и не задавая лишних вопросов - то много где и такие люди нужны и будут приносить пользу.
Есть как разные люди, которым нравится по разному делать свое дело, так и разные компании и команды которым нужны разные люди.
А возможно ты такой же как и я.
Принося пользу как можешь, зажигаешься своим делом и нет ощущения, что ты просто отрабатываешь с 9 до 18.
Наоборот - вкладываешься и драйвишься этим.
Если так - то можно просто стараться попасть в места, где такой подход приветствуется
Важно иногда и давать себе отдых, чтоб не перегореть, но пока мне кажется, что я быстрее потеряю интерес к делу от того что я не понимаю какую пользу приношу и делаю никому не нужные вещи, чем перегорю от импакта.
Лично для меня очень круто наблюдать - как продукт растет вместе с тобой. Хочется верить и что какая-то твоя небольшая заслуга в этом есть.
Это просто приятно когда получается что-то задумать , согласовать, реализовать и потом увидеть результат.
К тому же импактить можно не только с ближайшим ориентиром на продукт.
Есть много способов сделать это и по другому, технически, инфраструктурно, с процессами в команде и т.д.
Например улучшить стабильность ui тестов или найти способ уменьшить время сборки и вообще удариться в инфраструктуру
Организовать мини-митапы, делать дайджест новостей, совместный разбор книг.
Тема с разбором книг и мини выступлениями хорошо помогает развиваться
Когда я начал как qa, не прошло и недели, как я начал изучать фреймворки для автотестов - хоть тогда меня об этом еще никто и не просил.
Позднее я поговорил об этом с нашим тех. директором и скоректировал мое направление
Мой стимул был верным, но я ушел немного в сторону, он мне посоветовал смотреть чисто нативные Espresso и XCTest.
Потом я немного начал делать деплой, автопубликацию, разные штуки в Bamboo и т.д.
Если ты болеешь за то, что делаешь, способен давать больше, чем от тебя ждут и приносить пользу, это круто, какой бы это не был способ.
А способов повлиять много.
Будьте проактивны и ищите компанию подходящую вам.
А от импакта в компании, продукте плавно перейдем к импакту в сообществе.
Есть много способов принести пользу - open source, статьи, конференции, подкасты и информационные каналы.
Лично я особенно очень рад, что есть разные подкасты и каналы.
Мне это помогает оставаться на плаву, быть в курсе последних новостей, понимать куда движется разработка.
Экономит кучу времени, по сравнению с тем, если бы я сам искал много разных источников и статей
Их авторы как по мне вносят огромный вклад в сообщество 💪
Но я не представляю, как много энергии, сил и времени нужно чтобы организовать такое и поддерживать. Отбор материалов, подготовка сценария, вопросов, работа со звуком, видео и т.д.
От глаз скрыто много работы, но для нас для всех это очень полезно
При том, что еще поддерживается и какая-то регулярность. При том, что у них есть и основная работа и много других автивностей
В последнее время я так проникся, что оформил подписки для поддержки некоторых проектов.
В частности @PodlodkaPodcast и @andro_broadcast
Podlodka интересна темами обо всем в общем.
AndroidBroadcast - про Андроид (но есть и другие темы)
Оба подкаста радуют частотой выходов 💪
Я думаю такая поддержка как просто помогает купить лучше технику и софт для обработки материала, так и сильно мотивирует авторов вкладываться больше и приносить еще больше пользы
Начать помогать не сложно - каждый день я трачу на питание больше, чем на обе эти подписки в месяц😀
По ощущению степени полезности для себя, я бы еще отметил Android Dev Podcast.
Была бы у них подписка, я бы тоже офоромил.
А для того, что писал выше, можно найти инфу здесь
patreon.com/podlodka
boosty.to/androidbroadca…
Воскресенье
А сегодня у нас свободный день, можно поговорить на любые темы, если у кого-то есть вопросы то вперед 😀
А пока вы думаете, я еще немного напишу про радикальную откровенность и потом вспомним, что интересного было за неделю и о моих впечатлениях от ведения аккаунта 😃
Про радикальную откровенность я впервые услышал из доклада @jbaruch
Эта тема меня сразу заинтересновала, я стал всё чаще замечать как за собой, так и за другимим, что мы можем затеять какой-то не констуктивный холивар, агрессивную критику при обсуждении какого-то вопроса.
Однако зная про разные способы критики, такое поведение стало очень просто замечать и переходить на рельсы констуктивного общения с честной, откровенной, но доброжелательной критикой, без перехода на личности
Есть разные способы донести свою критику
Обычно определенной нации свойственно то или иное поведение в большей степени.
Русские - это Вызывающая агрессия.
Американцы - это Губительное сочувствие.
А оптимальное - это Радикальная откровенность.
Был пример с собакой, когда хозяин стоит возле перехода через дорогу и с трудом удерживает поводок, собака хочет вырваться и бежать.
Реакция через Губительное сочувствие - это "Ты молодец, не переживай, многим тяжело справиться с эмоциями собаки"
Реакция через Вызывающую агрессию - это "Да как таким людям вообще животное доверил, им нужно самим руки попереломать, завели монстра и теперь справиться не могут"
А оптимальный вариант через Радикальную откровенность это 👇
"Послушай, я знаю, ты любишь своего питомца. Но если ты не научишь его слушаться - рано или поздно он вырвется и попадет под машину. Ты можешь его тренировать таким образом - властно командуй Сидеть - и при этом садись сам, чтоб показать пример. Нужно повторить много раз"
Вообщем Радикальная откровенность - это лучший конструктивный способ что-то изменить, улучшить, донести свою мысль.
Вызывающая агрессия может только настроить другого человека против тебя и не внести никакого конструктива.
Иногда кажется, что кто-то другой делает что-то не так, и тебе кажется, что нельзя быть настолько упоротым. С этой реакцией нужно работать и лучше пробовать конструктивно спокойно объяснять - что не так, что нужно сделать, чтобы улучшить ситуацию. Объяснять заботливо и открыто
Каждый живет немного в своем контексте, со своими мыслями, опытом, и то что понятно одному, не факт что понятно другому. Если ты не объясняешь это спокойно и конструктивно, то ты все равно не делаешь ничего полезного, только портишь.
Правило радикальной откровенности и конструктивного общения полезно применять в любом устном/письменном взаимодействии, код ревью, общении в команде и между командами и т.д.
Помогайте, а не осуждайте
Будьте откровенны и заботливы
Сначала старайтесь понять
Не переходите на личности, обсуждайте поступки, действия и как предотвратить нежелательное поведение в будущем
Первоисточник темы - книга «Радикальная Откровенность» от @kimballscott
Книга про собственный опыт руководства, модели поведения руководителей и создание для команды пространства, свободное от всевозможного отвратительства, в котором люди ценят свою работу и друг друга
Я думаю тема достаточно полезная и интересная, чтобы использовать ее не только при руководстве, а вообще при любом общении.
В первую очередь, я стал больше замечать за самим собой различные проявления отступления от радикальной откровенности и начал присекать это
Итак, давайте вспомним, что интересного было за неделю 😀
После, я опишу свои впечатления от ведения аккаунта 😃
Cегодня поговорим про локализацию 🇷🇺🇺🇸🇮🇹 Будет немного про стандарты и локализацию в общем, про flow локализации у нас, и потом некоторые детали для Android.
Вот основные треды 👇:
Мой путь 👟 в IT, любовь к IT и к TradingView
twitter.com/mobileunderhoo…
А/В тесты 📊
twitter.com/mobileunderhoo…
Локализация 🇷🇺🇺🇸🇮🇹
twitter.com/mobileunderhoo…
А сегодня у нас свободный день, можно поговорить на любые темы, если у кого-то есть вопросы то вперед 😀 А пока вы думаете, я еще немного напишу про радикальную откровенность и потом вспомним, что интересного было за неделю и о моих впечатлениях от ведения аккаунта 😃
Узнай человека перед вступлением в брак👫
twitter.com/mobileunderhoo…
Сложность восприятия кода 🧠
twitter.com/mobileunderhoo…
Импакт, вовлеченность, драйв 🚀💪😎🤟
twitter.com/mobileunderhoo…
Радикальная откровенность, конструктивное общение 🫂
twitter.com/mobileunderhoo…
Итак, давайте вспомним, что интересного было за неделю 😀 После, я опишу свои впечатления от ведения аккаунта 😃
Вот и пролетела неделя 😮
Подводим итоги 😀
twitter.com/mobileunderhoo…
У кого еще остались вопросы, смело пишите мне, найти меня можно здесь 👇
Telegram: ttttt.me/artem_shumidub
Linkedin: linkedin.com/in/shumidub
VK: vk.com/artemshumidub
В понедельник я писал про свой путь в IT, и что мне нравится ❤️ и IT и то место в котором я работаю.
Кстати Ростов/Питер, кому интересно узнать больше про TradingView - можете мне писать, спрашивать (welcome 🙂)
Кстати интересно, как другие относятся к IT 🤔 Считаете ли это супер местом и цените ли его также как и я? Или в целом думаете - что нет ничего особого? И нет такого ощущения, что в основном в большинстве сфер все не так хорошо?
Эту тему мы закреплили опросом, большинству тоже нравится быть в IT 🤟😎🔥
twitter.com/mobileunderhoo…
Тортовый ведущий на этой неделе twitter.com/mobileunderhoo…
В Среду писал про l10n и i18n.
На мое удивление, тема вызвала больший интерес и отклик, чем я думал. Это круто, вы молодцы 👍
twitter.com/robert_egorov/…
По крайней мере, если сравнивать например с темой вторника - А/B тесты.
Лично для меня тема А/B тестов кажется интереснее, но лайков, вопросов, реакции было меньше, поэтому я не стал расписывать дальше некоторые пункты, решил не заваливать сильно твиттами.
Но если вдруг кто-то хочет еще что-то по ним спросить - как про А/B тесты в общем, так и конкретно про Firebase A/B тестинг или Firebase Remote Config - контакты я оставил выше 👆 )
В четверг у нас было самое вкусненькое
Тема хоть и не IT-шная, но учень важная, ведь IT-шники тоже люди
Про многие другие важные не-IT темы я могу услышать в разных подкастах или на конференциях - про здоровье, финансы, тревелинг, психотерапию и т.д.
Но про брак я еще не слышал
И хоть мы не нашли никакой волшебной пилюли, но просто призыв быть осознаннее кажется уже многого стоит.
Мне кажется, что уделяя время такой теме я принес больше пользы, чем если бы рассказывал про UI тесты или проблемы работы с WebView в Андроид
С одной стороны основной point прост и понятен, с ним большинство согласны. С другой, мне кажется что в жизни все равно чаще все происходит наоборот)
Было много и других мнений и это хорошо, что многие решили высказаться 🙂 В споре рождается истина или по крайней мере просто понимается многомерность и сложность вопроса.
Я думал, можно ли с этим что-то делать. Попалось на глаза видео, которое мне кажется достойно упоминания. youtu.be/haUZiledg3Y?t=…
Уже после четверга, мне на глаза попалось интересное видео, в духе треда, которое я потом добавил, но боюсь оно могло затеряться в море твиттов. Кому интересно - смотрите 🙂
twitter.com/mobileunderhoo…
В пятницу я рассказал про когнитивную сложность восприятия кода
На самом деле - большинство мыслей довольно известны и капитанские, в умных книжках это не раз уже повторялось. Но все равно сплошь и рядом я вижу не применение таких советов
Да и например, когда не просто читал про совет, но и в голове отложилась информация про тот же кошелек Миллера - должно быть лучше понимание вопроса.
В выходные рассказал про импакт и драйф от вовлеченности и роста продукта
Писал про то, что можно найти разные способы приносить пользу 🙂
Также напомнил про то, что есть много ребят, которые вносят как по мне просто супер вклад в сообщество, и приносят огромную пользу и было бы не плохо их лишний раз за это поблагодарить и поддержать 🙏
И немного рассказал про радикальную откровенность и конструктивное общение
В целом мне очень понравилось вести аккаунт, это оказалось даже интереснее, чем я думал 💪🔥🤟
Хоть я прочувствовал тяжелое наследие этого аккаунта)
Люди "удивляются" тому, что в этом аккаунте говорим про темы разработки, также как удивляются и тому, что присутствует темы не про разработку 😁
Но поддержки было все равно еще больше, просто море благодарностей и позитивного отклика.
Вы все молодцы ❤️, делайте то то что считаете правильным, и все будет круто 💪
