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

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

Давно уже подумывал слегка поменять имя канала и лого, чтобы лучше отражало что я тут делаю. Не переживайте контент про 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.

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

Ладно а теперь на чистоту, вы мне много чего накидали за воротник по поводу koin. Многие пишут, что вот у нас 100 экранов и вообще никаких проблем мы не испытываем. Хорошо, допустим, вам все нравится, в прописывании кучи get, поиском ответа на вопрос, а откуда же мне тут приходит зависимость и прописывании изолированных контекстов вы не видите ничего плохого.

При этом вы точно уверены, что у вас достаточно большой проект сейчас? Я сейчас работаю на проекте, где 40+ Android разрабов, более 1000 gradle модулей, а количество экранов я даже посчитать не смогу, кажется уже бесконечность. В проекте такого уровня использовать Koin это страшное преступление.

Каждый разраб сошел бы с ума нахер, пытаясь найти что, где откуда берется и как мне сейчас прописыванием очередного single c параметром ничего не сломать. Я уже молчу про перформанс, он с треском проигрывает любому другому DI на базе кодогенерации.

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

Итак, вершина инженерной мысли, 9 симфония в мире Java Backend, покровитель всего интерпрайза – Spring.

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

В мобилке мы используем кодогенерацию для ускорения инициализации графа, ведь это влияет на запуск приложения. Ну или забиваем и используем либу из прошлого поста. На беке же, грубо говоря, поебать на скорость запуска. Ты хоть 5 минут можешь граф инициализировать, главное чтобы все не тормозило в процессе. Поэтому в Spring практически все работает на базе рефлексии. Да медленно, зато удобно, а готовые плагины показывают откуда, берутся зависимости (отсоси Koin!)

Component. Как отдельного класса его нет. Тут можно представить что создается компонент на каждый класс, в котором ты используешь DI. Поставил аннотацию @Component и все, теперь внутри класса можешь инжектить все что тебе вдумается и главное как тебе вдумается. Spring умеет инжектить и через конструктор, и через приватное поле, и через setter и даже через твою ма…

Module. Реализуются похожим на Dagger подходом. Делаем класс, реализуем методы для создания зависимостей, проставляем каждому методу аннотацию @Bean (не спрашивайте почему Bean, интерпрайзные приколы). Далее классу проставляем аннотацию @Configuration и все. На практике такие модули создают редко и только для всяких конфигураций. Всякие Repository и Interactor у нас являются @Component, поэтому их Spring за тебя сам создаст и запихает куда нужно.

Scope. Опять-таки аннотация @Scope. Можно сделать чтобы зависимость жила пока не умрет все приложение, можно сделать чтобы зависимость жила пока живет сессия или вообще сделать scope на уровне запроса. Ну и также этой же аннотацией мы проставляем Singleton или Prototype.

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

P.S для матерых бекендеров. Да я знаю что есть еще @Service и @Repository которые работают слегка по другому, но давайте не усложнять сейчас)