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

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

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

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

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

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

Ничто не бодрит так с утра, как чашечка, вылетевшая из коленного сустава. Зайдя сегодня в idea, обнаружил, что у меня слетел сертификат для docker образа, который мне нужен. Причем я его не обновлял, но докеру похер.

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

Ребята, немного офтоп. А у меня из подписчиков есть кто-нибудь из Сыктывкара? Я просто не верю что такой город существует)

Я правильно понимаю, что я стараюсь, публикую посты про DI, про доку и на каждый полезный пост от меня отписывается человек по 5?

При этом стоит вбросить какую-то дичь с пьяну про Сыктывкар, на меня подписалось 15 человек. Бля, я кажется до сих пор не понимаю правил этой игры….

Как-то в разнобой посты делаю, однако хотел закончить серию про доку. В частности как правильно ее делать?

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

И вот очередная мудрость от меня, как писать крутую доку. Топ 3 фишки, которые вам помогут.
👉 После написания, представляете что вы обделены разумом (в моем случае это представить очень легко) и по свой доке пытаетесь что-то сделать, не отходя от того, что вы написали. Получилось? Если да, то вы либо себя наебали, либо с первого раза сделали крутую доку. Если не получилось, дописываете и повторяете процедуру.

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

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

Видели такое?

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

В целом я даже могу предвидеть какую причину они укажут для этой эксгумации. Теперь вы можете свой легаси проект перевести на multiplatform еще быстрее, ведь Async Task теперь можно использовать и в iOS.

Возникает вопрос, что это за проекты такие, которые в 24 году еще используют Async Task? Если же такие еще есть, и за все это время у них не хватило ресурсов перевести это легаси на новые подходы, как вы думаете насколько приоритетной задачей для них будет перевести все на KMP?

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

Погнали, продолжим разгонять тему про то, как понимать любой DI. Возьмем несколько DI либ с разными подходами:

👉 Dagger 2
👉 Spring
👉 Koin

Первый это база для Android разработки, второй используется только на бэке, а Koin он, ну вы знаете, Koin… Ну и ручной DI тоже рассмотрим.

Я постараюсь показать как, именно каждый из этих DI кладется на модель, которую я предложил.

Первый у нас это Dagger, он прям идеально кладется на модель:

Module – в нем указываем как именно нам создавать наши зависимости. Можно делать вручную, можно через bind, тут не особо важно.

Component – интерфейс, чтобы получать зависимости из Module. У Dagger Component есть возможность указать в какой класс нам нужно все заинжектить и Dagger сам все сделает, без необходимости доставать все вручную. Однако при желании, можно вручную ходить в Component и вытаскивать что нам нужно.

Dependencies – удивительно, но не все знают что при описании Component вы можете указать класс интерфейса, откуда брать внешние зависимости. Причем вы указываете просто интерфейс. Этим интерфейсом может быть как и другой Component Dagger, так и просто обычный класс, который вы руками реализовали. Далее этот класс (или Component) можно подсунуть при создании Component где вы указали Dependencies.

Что по scope у Dagger? В рамках компонента все понятно, есть Provider, есть Singleton. Можно конечно еще создать свою аннотацию, которая по сути будет Singleton, но об этом в другой раз.

Касательно Scope для компонента, все довольно просто. Вы его контролируете ручками. Создали компонент и сохранили его в Application, все он будет жить пока не умрет приложение. Создали компонент и сохранили его в Activity, он будет жить пока не умрет Activity (т.е даже при повороте экрана).

Далее koin. Когда в детстве разработчиков Koin подкидывали и забыли ловить… ладно объясню нормально.

Module. В нем создаем зависимости, аналогично Dagger. Далее эти модули нужно указать в инициализаторе Koin.

Component. Он так и называется KoinComponent, позволяет использовать функции для получения зависимостей. Ну на самом деле он просто ищет глобальный контекст Koin и через него уже получает доступ ко всем загруженным модулям. Помимо этого в модуле для Android уже реализованы расширения для использования inject и get во всех стандартных компонентах.

Dependencies. А вот с этим в Koin все довольно забавно. Эта собака же сама все хранит в глобальном контексте. Поэтому работает это так. Вот в app модуле приложения вы прописали какие модули Koin нужно загрузить т.е сразу все. И так как контекст то у Koin один, что значит все теперь все модули доступны везде. Что означает, вы в фиче модуле, в модуле Koin можете сразу использовать зависимости, которые вы например определили в app модуле. Минус в том, что вы можете случайно получить зависимость с другого фича модуля и отслеживать это придется вручную.

Хотелось бы чтобы это было явно. В целом это можно решить тем, что вы делаете интерфейс зависимостей и затем пытаетесь в модулях, которые прописаны в фиче, получать зависимости не через koin, а инстанс этого интерфейса, который вы реализовали в app. Да запутанно, поэтому не используйте koin, если у вас проект чуть больше чем 5 экранов.

Scope. В Koin можно прям явно указать что объекты создаются на время работы конкретного экрана, т.е они привязаны в Activity или фрагменту и уничтожаются при выходе с этого экрана. Тут все более явно чем в Dagger.