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

Однако что слышат люди вокруг: "ооо, этот парень смешно психует про gradle, наверняка профи". Два рандомных человека пришли ко мне с консультацией по gradle, да вы чо блять? С одной стороны такая заметность приятна, с другой, я не прям мега гуру по gradle, чтобы решить любую проблему, так еще по gradle. Это буквально самая последняя вещь в программировании в которую я бы хотел погружаться. И самым крутым достижением при работе с gradle, я считаю тот факт, что еще не разбил свой рабочий ноут.

Есть такое понятие как когнитивное искажение – шаблонные отклонения в мышлении, которые возникают из-за особенности работы нашей психики. Самое ужасное в них тот факт, что знание этих искажений не спасает от негативного влияния.

Вот например, я знаю что не нужно оверинженирить в своих pet-проектах. Ведь в таких проектах счет идет на часы пока тебе интересно, и если ты не уложился – проиграл. И важно эти часы потратить на важные вещи. Я это осознаю, да я даже пост про это писал.

Однако решил я сделать бота для телеграма, который бы ходил в chat gpt и генерил тупые шутки и лютый кринж в чате друзей. Да, по сути делал бы то, что сейчас делаю я. Разумеется я начал делать его на python, ибо рот топтал возиться с системами сборки и компиляцией, на работе этой херни хватает.

Казалось бы, что могло пойти не так? А то, что вчера я потратил 2 часа на выбор самой лучшей либы для работы с конфигами. Чтобы все было красиво, можно было задавать конфиги как твоей душе угодно, и в дебаге было удобно. Прям по заветам 12 факторов приложения.

И знаете что, я либу так и не выбрал! А знаете сколько там конфигов внутри? Один! Только токен бота телеграмма. Казалось бы, просто задай через env и все, я это понимаю, но ничего не могу с собой поделать. Прям как главный герой из фильма прочь, вроде все вижу и понимаю, но ничего не могу с этим поделать…

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

Я снова начинаю учиться писать, кажется за два месяца скилл я знатно подрастерял. Пока я учусь, просто накидаю мысли не о чем. В конце концов у меня афторский проект и не обязательно выдавать годноту каждый раз. У меня включился какой-то дебильный перфекционизм. Формат телеграм канала подразумевает короткие заметки, тупо мысли без особой проработки. Да у меня и канал так называется easy notes. Однако я заметил за собой, что каждый раз когда возникает интересная идея, я ее откладываю в долгий ящик, ведь она недостаточно проработана и нужно над ней подумать еще пару лет. И в итоге вообще ничего не пишу.

Помимо этого, если говорить откровенно, то меня немного подустал android. Не то, чтобы я прям хочу свичнутся в другое направление, но и писать про мобилку становится, мягко говоря скучно. Я стараюсь руководствоваться аксиомой, что если про что-то скучно писать, то читать это будет еще скучнее. Это кстати совет для тех, кто хочет писать статьи. Если вы сильно прокрастинируете написание статьи, ваши читатели будут прокрастинировать с ее чтением. Проверял на себе.

Конечно завидую ребятам, которые не устают от одной платформы и могут делать контент годами, не уходя в сторону. У меня вероятно эдакая форма СДВГ, потому как у меня судя по всему так не получается. Поэтому еще один совет, если вдруг решите заводить авторский блог про разработку – не завязывайте название на одну конкретную платформу.

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

Сами подумайте, какого качества вы ожидаете от продукта, у которого логотип, это «зеленый слоник»?)

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

Удивительная вещь заключается вот в чем. Я и до этого пытался делать всякие open source либы, как мне казалось очень полезные. Писал чистый и аккуратный код, писал тесты, даже оформлял красивую доку весь набор перфекциониста. Как мы могли догадаться всем было похеру на мои решения. Тут же я вообще не запаривался и решение взлетело, не то чтобы сильно, но учитывая мои затраты (потратил на нее дней пять) вполне неплохо.

Поэтому просто наблюдение, что в этот раз я сделал по-другому:
👉Хорошее open source решение всегда вырастает из реального проекта, без исключений. Никогда не бывает хорошего open source когда вы сидите и думаете: "о а было бы прикольно сделать X". Хорошее решение это всегда произрастает из реального проекта, в котром нужна штука, которой нет на рынке. Вы делаете эту штуку для себя после чего, по доброте душевной делитесь с миром.

👉 Существует миф о том, что хорошее решение само себя продает, а вот нихуященьки. Поэтому после выполнения первого пункта нужно немного вложится в маркетинг. Что сделал я, тупо пошел в вопросы на stackoverlow и сделал пару ответов со ссылкой на мою либу.

Выполняете эти два пункта и у вашего open source решения будет успех. И ответ на главный вопрос: "А нахера эти звезды вообще нужны?". По факту они ни на что не влияют, потому как на интервью никто на github уже давно не заходит. Однако я слышал не одну историю когда разрабов завали в крутые места на работу, тупо по тому, что использовали их решения. Эдакая деверсификация личного бренда…

Я в одном из предыдущих постов писал про то, что в Gradle логирование сделано хреново. Однако вы вообще задумывались где оно сделано нормально? Вот смотрите что я имею в виду.

Возьмем уровни логирования, которые есть в каждой либе: debug, info, warning, error. Уровень debug, это какая-то отладочная информация, которая нужна разработчику помогающая понять, что произошло на устройстве, чтобы найти причину бага. Тут все понятно. Есть error, это буквально когда произошла прям критичная ошибка или приложение вообще упало. Опять-таки это информация для разработчика, чтобы он понял что конкретно нужно фиксить.

А вот warning это про что? Как бы произошла ошибка, но не критичная? Ну можно представить, что это момент когда мы не падаем, но отправляем в крашлитику событие, что у нас что-то пошло не так, допустим. А info это что за зверь? Это уже не уровень debug, но при этом и не ошибка. По названию это как будто бы инфа которую нужно показать пользователю и кстати в CLI программах так и делают, но как будто бы лог это не про показ информации пользователю, а исключительно отладочная инфа.

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

Я еще при этом не упоминал уровни вроде: trace, verbose, fatal, тут вообще пади разбери кто за что отвечает. При этом либы еще могут свои уровни добавлять. В Timber есть уровень логирования wtf. Это уровень, который ломает 4-ю стену, ты мысленно произносишь wtf когда его видишь.

Получается пытаясь решить проблему того, что либы срут кучу всякой лишней инфы в лог, мы пытаемся защититься уровнями логирования. Но это не работает, потому что ты все равно либо фильтруешь по error либо смотришь все логи. Потому как другой разраб мог сделать важный лог как info, так и warn. Да ты и сам каждый раз в растерянности: это warn, это info или это debug? Как будто тратим усилия на решение выдуманной задачи.

Пока я писал предыдущий пост я подумал вот о какой штуке. Смотрите, я говорил о том, что всякие либы придумывают свои уровни логирования и часто странные. Кто писал плагины для Gradle вы знаете, чтобы логи выводились в общую портянку которую генерит gradle, то для этого нужно использовать уровень логирования lifecycle. lifecycle – уровень который включен по умолчанию и выводится всегда, и выключить его можно только через флаг —quiet.

В чем суть, в Gradle смешали две фундаментально разные вещи. Логи это исключительно информация которая нужна в случае когда что-то идет не так. Вывод в консоль, когда мы говорим про CLI, это уже интерфейс программы. В программах с GUI такой путаницы не возникает, ведь в этом случае интерфейс это то, что мы рисуем, а логи сокрыты внутри.

В GUI прогах мы много времени тратим на то, чтобы сделать интерфейс минималистичным и удобным. Не показываем пользователю лишнюю инфу и не грузим его (китайские приложения не в счет). Когда же речь идет про CLI мы на это правило забиваем и фигачим в консоль все подряд и логи и результат.

Вот например когда Gradle ничего не делает, он все равно выдает портянку того, какие этапы он там проходит. С одной стороны хорошо, сразу все видно, но с другой стороны да всем похеру на то, что он там выводит, нас интересует только конечный результат. Мы смотрим в список задач только если что-то пошло не так или мы хотим оптимизировать сборку, да и для этого мы тоже забиваем на консоль и запускаем scan.

По-хорошему, хотелось бы, чтобы если Gradle нечего делать, он бы так и выдавал одну строку: "No task to do". Я пока писал этот пост, думал найти больше примеров CLI программ, в которых эти ошибки допущены, но прикол в том, что большинство популярных прог как раз таки имеют грамотный интерфейс и не выводят лишней инфы. Проблемы возникают только с системами сборки вроде Gradle и Maven, а также во внутренних тулзах которые делаются на коленке.

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

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

Мне кажется причина тут та же, по которой Германия делает самые крутые машины, а в России лучший финтех. Одна из причин почему Германия делает лучшие машины, потому что она была отсталой. Среди крупных европейских стран Германия (на тот момент по сути Прусия) последняя страна где началась промышленная революция. И когда она там началась, они внедряли решения, поглядывая на проебы других стран. Если интересно вот документалка в которой про все это подробно рассказывается.

Аналогичная история и с финтехом в России, он самый крутой, потому что был отсталый. Когда в России только начали всех пересаживать на сайты, в США они уже давно были. По этой же причине VK на заре популярности был в тысячу раз удобнее facebook. Также и pytorch считается более крутой либой для ML по сравнению с tensorflow – мнение не мое, а знакомых MLшиков с которыми общался. Поэтому telegram круче watsapp и этот список можно продолжать бесконечно. Когда ты делаешь решение, похожее на то, которое уже есть, ты сразу можешь двигаться в правильном направлении, изучая ошибки тех, кто был до тебя.

И что же разработкой под мобилку? Среди других индустрий она по сути тоже отсталая, тупо потому что молодая. Ну по факту, мобильная разработка именно в том виде, в котором она есть сейчас появилась с выходом первого айфона. В мобилке все используют решения, которые на фронте появились более 10 лет назад. Мы вот MVI лет 5 назад продвигали как очень крутой, новый подход для архитектуры. А MVI по сути своей базируется на идеях, которые заложены в языке Elm для фронта, который появился в 2012 году. Поэтому в плане холиваров мобильная разработка скучная, мы интегрировали хорошие решения с дескротопов и фронта, а лишнюю фигню не затаскивали (по крайней мере прям трэшовую) и надеюсь это так и останется.

Вот это одна из причин, почему не каждый готов регулярно вести свой блог. Однако меня это пиздец как забавляет. Я пишу: "в мобилке не так много дичи, потому что она появилась позже всех". В пример аналогии привожу автопром Германии, финтех в России, либы для ML. В посте можно доебаться практически до всего, но разумеется я получаю: "Ты че пес, схерали в России лучший финтех?" и срач про регулятов.

Ладно, хорошо, давайте так, дабы снизить температуру ваших кресел я перефразирую: "В России один из лучших финтехов". Разумеется я не пробовал финтех всех стран и это лишь мое мнение. Однако у меня есть приложения 2-х Казахских банков, Американского брокера, Грузинского банка. Помимо этого я видел интерфейсы нескольких Германских банков и честно сказать, ребятам пока еще есть над чем работать. Но пост то про другое!

Касательно того, что во фронте все делают кто как хочет, а вот в мобилках есть вендор и все такое. А ничего что любой фронт выполняется в браузере, который по сути своей та же экосистема? Да этих браузеров больше чем операционок, но все они также закручивают гайки, и ты уже там не сделаешь как раньше все что тебе вздумается. Другими словами, то что на фронте куча вариантов сделать хрень, а в мобилке меньше, никак не опровергает то, что я написал. Потому как вполне возможно (я лишь предполагаю), что те кто стоял у истоков мобильной разработки как раз таки сразу смекнули, что не нужно идти по пути вэба и поэтому у нас есть вот эти гайдлайны, один UI фреймворк вместо огромной кучи и т.д.

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

Без шуток, жду с нетерпением)

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

Вот например история одного разраба, который пилил свой open source и никого не трогал. По стечению обстоятельств, он в своей тулзе по умолчанию указал свой приватный бакет в S3. Если вдруг не знаете что такое, S3 – то можно представить что это огромных размеров директория, куда можно складывать файлы через API. Когда его программа начала пользоваться популярностью, все клиенты дружно начали стучаться в этот закрытый бакет. Оказывается AWS вполне непрочь, взять за тебя бабки, даже за неавторизованный доступ.

Еще раз, бакет закрытый, доступ есть только у конкретного пользователя, однако если в этот бакет кто-то начинает ломиться, Amazon все равно списывает за такие запросы бабки. В итоге чуваку выставили счет 1500$. Справедливости ради, AWS решили пофиксить эту проблему, а то теоретически узнав бакет конкурентов, можно задешево скушать их бюджет.

Вот другая история, в которой гугл случайно удалил облако целой блять компании, вместе со всеми бэкапами. Благо разрабы компании оказались достаточно умны, чтобы не доверять гуглу и хранили бэкапы в другой системе, благодаря чему быстро восстановились. Там еще ответ гугла был в стиле: "Мы дичайше просим прощения, это повторится!" Представьте если бы разрабы доверяли гуглу полностью? Это же все, это конец бизнеса!

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

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

Может у вас есть истории когда ваша ошибка на мобилке привела к финансовым потерям?

Под прошлым постом много кто описал как можно обосраться с мобилкой, чтобы компании финансово было больно. Не сказать, что примеры сильно пугают, однако я давно не делал полезных постов, поэтому… Разбираем инженерные практики как сделать так, чтоб если даже вы повторили путь разбов AGP (сделали на релизе полную херню) минимизировать риски и не обанкротить компанию.

Когда пользователей становится очень много (что такое много зависит от приложения) всегда нужно делать несколько уровней защиты от нелепых изменений.
Разумеется мы исходим из того, что у вас уже есть какой-то минимальный мониторинг из комбинации крашлитики и аналитики, чтобы вы могли сразу отслеживать, что что-то идет не так.

1️⃣ уровень – фича тоглы.  Подход заключается в том, что новые фичи или какие-то изменения мы закрываем флагом, например тупо boolean.  Этот флаг у нас периодически обновляется через API. Далее через бэк мы можем открыть функциональность, когда в ней уверены. Прикол в том, что мы можем открыть не у всех пользователей, а только у части и посмотреть как пойдет. Идет криво – быстро ее закрываем и фиксим, идет нормально – увеличиваем процент пользователей. Однако есть изменения, которые не закроешь флагом. Например, какой-то глобальный рефакторинг. Тогда на сцену выходит:

2️⃣ уровень – канареечные релизы 🐤. Суть омерзительно проста, мы не раскатываем новую версию приложения сразу на 100% пользователей, а используем подход фича тоглов. Раскатили на 5%, подождали, посмотрели как пошло, затем на 30%, ну далее до 100%. Если происходит какая-то херня, мы вероятнее всего ее успеем отловить на первых 10%. И даже если там что-то невероятно критичное, это заденет лишь малую часть пользователей. Да больно, но что хуже отрубить палец или голову?

3️⃣ Если же, мы совсем боимся, то добавляем третий уровень – бета. В основном этот способ используют медиа приложения, но теоретически подходит всем. Тут прикол в том, что мы сначала раскатываем приложение на ограниченную группу пользователей, которые сами захотели в этом поучаствовать. Они берут на себя риски того, что у них все может вылетать и баговать, но получают новый функционал раньше. Мы же получаем возможность протестить функционал на реальных пользователях еще до релиза. Сложность в том, что если у нас например банковское приложение и мы как-то задели бабки путь даже и пользователей беты. Регулятору будет похер и придется отвечать, поэтому с этим тоже аккуратнее.

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

Можно ли при таком подходе проебаться? Разумеется да, проебаться можно во всем, уж поверьте мне, я в этом профи! Однако вероятность этого снижается настолько, насколько это возможно.

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

Тадааам, старый лого испариился.

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

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

У меня были периоды сильного перфекционизма, когда я думал, что документация нужна прям на все. Были периоды, когда я думал, что любая документация обречена на старение. Далеко не у всех есть интерес ее поддерживать и вообще зачем она нужна если можно код посмотреть?

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

И вот это у меня и начало происходить, толи это реально старость, толи из-за количества разных проектов помнить нужно дохера. Так или иначе прихожу к выводу, что документация все таки экономит время. Помимо этого очень часто бывают ситуации, когда меня что-то спрашивают, типо как сделать X. И первые раза 3 ты отвечаешь сам и это не напряжно, но потом это заебывает не на шутку и охото иметь возможность просто скинуть ссылку и чтобы от тебя уже отъебались.

Касательно доки, всегда есть два основных вопроса: когда нужно ее делать и как ее делать правильно?

По поводу того, когда нужно делать доку

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

Поэтому если ответит кратко, то необходимость определяем на глазок. Нужно держать в голове, что документация это инвестиция, и ее нужно делать тогда, когда в этого будет виден явный профит. Если на проекте вас 3 человека, то вероятнее всего, вам будет тупо быстрее созвонится, чем страдать графоманством. Однако если вас на проекте уже человек 30, все время приходят новенькие, тут уже без доки вы сойдете с ума.

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

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

Фанаты Apple, сколько это сочетание слов вызывает у меня эмоций, вы бы знали. Я в работе уже давно использую mac, и я по-прежнему уверен, что именно для работы нет ничего более крутого.

При этом, у меня довольно много критики касательно того, как Apple относится к разработчикам. Я уже молчу про XCode после которого не расхуярить mac это то еще испытание. Вот банальный пример, когда ты начинаешь настраивать новый mac (или после обновления) при попытке обратится к git всплывает вот такая херня:

«You have not agreed to the Xcode license agreements, please run 'sudo xcodebuild -license' from within a Terminal window to review and agree to the Xcode license agreements.»

И я раньше об этом не задумывался, но… Каким хером вообще связаны xcode license и git, которую Apple блять не писали? Другими словами, я должен спросить у Apple разрешения пользоваться программой, которая им даже не принадлежит? Ладно бы я Xcode использовал, но это же git, он же опенсорсный. Возможно у вас тут тянутся руки написать: "Ну установи через brew и все". Однако этот самый brew под капотом и использует git, на использование которого нужно получить лицензию, сука…

Разумеется я начинаю об этом жаловаться, на что мне прилетает весьма токсичное: ну и не пользуйся mac тогда! Довольно часто люди слишком близко к сердцу принимают критику продукта которым они пользуются. Стоит пожаловать на проблему с лицензиями, так тебе сразу предлагают получить лицензию мудака.

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

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

При этом, сейчас, несмотря на то, что я давно уже не трогал dagger, я смогу не заглядывая в доку, рассказать про то, как он работает. Все кто читает меня давно знают, что я в своем канале продвигаю одну мысль: основные концепции в разработке практически не меняются. Меняются только API и всякие разные тонкости.

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

В любом DI есть четыре основные сущности, которые нужно запомнить:

👉 Module – класс или функция в которой зависимости генерятся
👉 Component – интерфейс, который позволяет получить нужные зависимости
👉 Dependencies – зависимости которые будут использоваться в Module, получаемые извне, например из другого модуля
👉 Scope – опциональная штука, суть которой определить время жизни зависимостей. Причем не нужно тут завязывать на то, что Scope обязательно привязан с Activity и т.д вы при желании можете сделать его тупо по таймеру, что например он живет 5 минут.

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

Продолжение тут