Нужено купить всю технику за пару месяцев до принятия закона и больше не покупать технику в России.
Хотят они чтобы местный ритейл окончательно сдох и налоги больше не платил, туда ему и дорога. А большие техно покупки теперь буду совмещать с отпусками в забугорные страны
Все ваши аргументы в пользу того, что распад в одночасье не случится. Ну так он и не должен - это долгий затяжной процесс.
США возвращает свои заводы на территорию - это не происходит одномоментно (нужны десятилетия) и это очень сложно (потому что не очень рентабельно и есть сопротивление) - но идёт. Гига фабрики строят у себя, заводы чипмейкеров тащат.
Про нехватку людей все верно - не хватит, по этому в первую очередь выносить будут то - по чему больнее всего бить. Чипы (Китай уже много лет инвестирует в свои, США кидает гранты в интел, Самсунг поддерживает свои наработки), авиация, автопром, системы связи.
Отдельные страны уже не имеют значения.
Так было раньше, пока сюзерены делали свои поборы небольшими, но пандемия показала, что так жить нельзя, завися от кого-то настолько - что он может показать тебе умереть за него.
Возможно, это потому, что вы смотрите на то, кто что заявляет, а я на реально происходящее в экономике?
Я старался каждый тезис подкреплять примером . От вас примеров только про электронику, и он весьма специфичен. Про ширпотреб - вы кстати зря - уже часто можно из кучи разных стран ширпотреб получить, не только из Китая.
Так что может вы и правы, но предпосылок вашей правоте я не вижу.
Распад единого глобального рынка на сектора - это как раз движение в обратную глобализации сторону.
Раньше страны могли себе позволить быть зависимыми от глобального рынка, веря в правила ВТО, безопасность государственных активов, доступность торговли. Сейчас всем понемногу становится ясно - что деньги хранящиеся в других странах могут украсть в одночасье (потому Индия, Сербия, Германия, Италия - активно возвращают золотые активы домой), что от торговли могут пытаться отключить (Китай выкатывает свой аналог Свифта), ВТО мертва (тарифы Трампа уже даже не скрываются под оправданием гос. безопасности).
Так что США стремятся вернуть заводы домой, БРИКС перейти на взаиморасчёты в домашних валютах, а Китай - пересесть но свой авиапарк. Каждая страна будет развивать внутреннее производство вытесняя внешнее, даже если это менее выгодно т.к. теперь это вопрос стратегической безопасности и жизнеспособности страны.
Благодаря аддитивным технологиям это становится более реальным (раньше окупить завод штучных деталей для самолётов можно было только продавая их всему миру, сейчас 1 3д принтер может штамповать всю их номенклатуру, наоборот не масштабируясь от количества)
Может этот этап пройдет, но пока явно виден распад глобализма.
Заменим эффективные, износостойкие и дешевые колёса, на неэффективные и сложные и дорогие ноги, потом проделаем тот-же трюк заменив одну телескопическую клешню на пару рук, добавим ненужную голову с глазами.
И вот - у нас уже робот, который в 60 раз менее надёжен, в 8 раз дороже (в лучшем случае), в 10 раз медленнее, и требует дополнительного оборудования (типо лестниц для высоких полок, колясок для габаритных грузов).
Думаю тут эффект масштаба и перепрофилируемости не поможет.
Вариант 1 - менеджеры оказались не эффективны - и инвестировали в машины, у которых срок окупаемости и цена дюйм в дюйм совпадает со стоимостью работников на этом интервале.
Тогда да - мы получили 960 работников, которые теперь могут решать новые задачи и приносить пользу государству.
Вариант 2 - реалистичный.
Машины обходятся дешевле людей. Тогда завод получает больше прибыли с каждой детали, а значит (неожиданно) - платить больше налог на прибыль, а остальное делит между инвесторами. 960 человек теперь работают в других местах - где продолжают за них платить пенсионные отчисления, что значит, что даже гос бюджет в выигрыше. А если станки куплены в стране и обслуживаются местными мастерами - то это ещё и поддержка местного производства, а там тоже налоги и рабочие места. В выигрыше по итогу все.
Фактически - для общества в целом - оптимизация труда - это всегда благо. Хотя для конкретного индивида - это может быть трагедией.
Глобализация подразумевает более менее равноправие, а для больших игроков это недопустимо т.к. их права "ровнее".
То что до этого продвигали как глобализацию - оказалось вассализацией - когда есть сюзерен имеющий монополию в производстве какого-то товара, и манипулирующий вассалами зависимыми от этого товара как ему угодно.
Первое - это точно не стартовый и не главный экран мессенджера. Не сейчас, и скорее всего никогда. Лишний клик для перехода к списку из виджетов сразу убъет весь интерес. Открывая мессенджер - я намерен действовать - писать сообщение конкретному пользователю/читать сообщение от конкретного пользователя - в девяносто десяти % случаев. Это не новостная лента, куда можно зайти посмотреть.
Второе - виджеты должны полностью генерироваться без участия пользователя (а это значит что все чаты будут отправляться в llm - сейчас, когда все топят за приватность, это будет тяжело протащить), но с возможность редактирования.
Если заметки надо будет писать самому и встречи надо будет трекать самому - удобнее завести приложение под каждую из этих целей отдельно. Причина тут проста - клик на запуск мессенджера мы тоже учитываем и если мне нужны заметки - я быстрее запущу заметки, чем мессенджер -> заметки.
В целом - как аналог google now но для мессенджера, который автоматически распознает в тексте маркеры и формирует виджеты - прикольно. Т.е. - это скорее экран тематического поиска (где обсуждаемые события, пароли, действия - вынесены). В таком виде - перспективно, даже подумалось реализовать поверх телеги, но блин - как представлю сколько мощностей llm это будет потреблять - становится страшно
Вы не договариваете. Никаких аргументов Сейчас. А вот когда они появятся, а рано или поздно они появятся - добро пожаловать в ад. Тем более что на деле как раз репозитории имеют свойство получать в аргументы dao, cacheProvider-ы, а в последствии и мапреры.
сам Spring использует этот термин (@Scope("singleton") ).
Singleton в di задаётся в рамках scope и это в любой момент можно поменять в модуле (я могу поменять singletone на factory заменив 1 слово в коде, сколько вам потребуется поменять, чтобы заменить singletone на factory при прямом обращении? И с di у вас может быть два инстанса singletone в разных скоупах - а это уже не тот сингтон, который невозможно поменять, не пройдя каждое вхождение.
надо сразу статические методы вызывать DataProvider.doSomething()
Мои старания тщетны, раз вы не понимаете почему такой код плохой. А он очень плох в долгосрочной поддержке. Сегодня ваш dataProvider работает без кэша, а завтра надо добавить кэш, а послезавтра сделать чтобы половина была с кэшем а половина нет, а через месяц - брать данные из разных источников, а через год - хранить кэши раздельно для разных провайдеров.
И вот - вместо четырёх объектов каждый из которых ограничен своей логикой и выбран в di, получаем метод, с кучей параметров, обросший ифами снаружи, который нужно конфигурировать в каждой точке использования.
Хорошо если у вас все функции чистые - тогда вам и объекты не нужны, и di у вас по сути будет по умолчанию (нет объектов - нет зависимостей). Но когда появляются объекты - всё, di нужен.
Моё утверждение остаётся таким-же. Di практически бесплатен в разработке если вы ознакомились с тем как его писать. Его внедрение и использование в проекте не делает код сложнее или дороже - но он может решить кучу проблем, по этому не считая скриптов, однострочных сервисов, и кода на выброс - его повсеместное внедрение разумно.
Это как бесплатная страховка без дополнительных условий - отказываться нет смысла.
Последний раз 5ого июня, всё без проблем. Не думаю что все могло с тех пор измениться.
Слышал проблемы бывают у тех, кто только зарегистрировал аккаунт, у тех, у кого большой процент возврата, и у тех, от кого уже был проблемный возврат. Их проверяют вручную.
У меня практически все возвраты проходили автоматически. Т.е. заполняю данные, жму - сделать возврат, и через 10 секунд получаю код возврата и предложение сдать товар в пункте выдачи.
Принцип Парето, 20% процентов работы, которые дали впечатляющий результат - сделаны ещё в 2014, до полноценного автопилота без проблем будем ехать ещё долго.
Если это пункт в договоре - антимонопольщики за такой легко могут взгреть что мама не горюй, они у нас кто бы что не говорил - лютейшие. Если это косвенный намек - тогда решается просто, model B. На маркетплейсе вы продаёте один товар, а у себя на сайте другой. Да, выглядит так-же, но на маркетплейсе model A и дорого, а у себя более совершенный model B и по дешеше.
Но вообще, если вы не супер большой бренд с миллиардными продажами - то никто и не узнает. Или как вы себе это представляете - при размещении магазина на маркете модераторам даётся задание - проверить что товары не продаются нигде дешевле, и отказать если продаются? - да если такое есть - человек с такой в переписке может хорошо шантажировать маркетплейс (не думаю что дэюро можно отказать в услуге размещения на основе того, что кто-то дешевле продаёт), слить её тем-же антимонопольным, и как минимум - уже выкатить анонимное интервью на какой нибудь youtube канал)
Если такие есть но я пропустил - пишите где смотреть, очень интересно)
30 возвратов на озон, проблемный был только 1, с заказом из за рубежа. Кросовки, мониторы, даже стулья после месяца использования (Сидушки трещинами пошли) - вернулись спокойно.
Не сомневаюсь что проблемы могут возникнуть (особенно на первом этапе, если продавец упрется, но в таком случа поддержка самого озона практически всегда на стороне покупателя, и возврат будет)
Во первых в своей статье вы критикует DI как подход, а не использование библиотек - это контрастирует с утверждением
Поэтому в JS, мне кажется, DI проще делать вручную - это элементарно, соответственно библиотеки DI - не очень понятно что - типа сахара для массового внедрения
Не важно каким инструментом вы делаете di - если вы его делаете (адекватно) - то это хорошо, а если нет, могут быть проблемы.
Я прекрасно ознакомлен с js, и понимаю о чем вы говорите. Ваши утверждения скорее показывают что вы не работали с проектом где di есть и построен верно. Да, в js можно хаотично импортировать что угодно куда угодно, но это не решает проблем которые решает di. Наоборот - динамическая типизация их усугубляет - когда у вас класс инстанцируется di в одном месте (как правило модуле), чтобы заменить его поведение (набор аргументов) - нужно поменять это в одном месте. Когда у вас класс инстанцируется там где применяется - чтобы поменять его аргументы - нужно найти все вхождения и заменить аргументы (и в js, если вы забыли в одном месте, то в отличии от компилируемых языков - ваша ошибка в рантайме), а если у вас вместо класса структура, создаваемая инлайн - можно вешаться - тут даже поиск и замена по проекту не помогут, и всесто новой реализации вы можете откуда-нибудь подтянуть старую, которая несовместима.
Если вы не используете модули как источник объектов - то код имеет свойство превращаться в матрёшки A(B(C(Q(Z), Q(Z)), Z, Q(Z))
Ну и синглтон - антирпетрн, так что прямой экспорт объекта может кончится глобальным супер рефакторингом.
В целом когда ваш код выглядит как UserStory(dataProvider), а не UserStory { let dataProvider = DataProvider }
То вы получаете гибкость - заменить dataProvider за 5 секунд.
Это делает эту статью очень ценой - как наглядный социальный эксперемент.
Отлично показывает - что когда читающий уже предвзят, и недостаточно квалифицирован в области материала - то легко примет за чистую монету то, что на деле только похоже на аргументы.
Андроид разработчик сразу видит по статье, что это не разбор а скорее хейт, но таких 14. А какой нибудь веб разработчик видит правдоподобные аргументы, и ставит плюс за "интересные подробности".
Буду демонстрировать её чтобы показать - что даже информацию про чиновника укравшего миллионы, или представителя закона в сговоре с бандитами - надо воспринимать критически
Во первых - вы декомпилировали телерамм из плейстора? Он там точно не обфусцирован? Я не смотрел, но другие проекты с открытым исходным кодом таковые видел. Не удивлюсь если и телега такая.
А во вторых - если вы прочитаете официальную документацию к какому нибудь materialIcon3 прям с сайта документации Гугла для андроид разработчиков - там черным по белому написано - что они строго рекомендуют использовать r8 чтобы он вырезал неиспользуемые иконки.
Нет ни одной адекватной причины не использовать r8 в релизной сборке. Это примерно как отказаться от бесплатного лотерейного билета - ты ничего не теряешь включив r8, но можешь много выиграть.
Вот я с этим тезисом почти не согласен. И люди которые не знали зачем нужен di конечно плохо что не изучили, но все равно хорошо что использовали (если хотя бы правильно).
Di - это как ремень безопасности в машине - пристегнуть быстро, есть куча ситуаций когда он спасет тебе жизнь, и очень исключительные случаи когда может помешать (я согласен что в скрипте каком нибудь он не нужен).
Внедрение di (в новый проект) - обычно занимает меньше одного дня, поддержка не стоит почти ничего, и даже если он не начнет давать плюсов - не много потеряно. Зато если начнет - вы будете очень счастливы что он у вас есть.
Хотя я не смотрел его js - может там нет простых решений, хотя учитывая гибкость js - они напрашиваются
С товарищем играли в факторио - я строил первые заводы простые, не масштабируемые но быстро, а он фундаментальные, закладывался на рост и масштабирование - в итоге пока он масштабировался в Т1, я уже выходил в Т2, и опять строил наброски - как итог, игру я прошел быстрее.
Так что носить воду или строить водопровод - это все от ситуации зависит. Возможно вода сейчас позволить построить водопровод быстрее за счёт вырученных ресурсов, чем водопровод сразу. Или вообще понять, что он не нужен.
Нужено купить всю технику за пару месяцев до принятия закона и больше не покупать технику в России.
Хотят они чтобы местный ритейл окончательно сдох и налоги больше не платил, туда ему и дорога. А большие техно покупки теперь буду совмещать с отпусками в забугорные страны
Все ваши аргументы в пользу того, что распад в одночасье не случится. Ну так он и не должен - это долгий затяжной процесс.
США возвращает свои заводы на территорию - это не происходит одномоментно (нужны десятилетия) и это очень сложно (потому что не очень рентабельно и есть сопротивление) - но идёт. Гига фабрики строят у себя, заводы чипмейкеров тащат.
Про нехватку людей все верно - не хватит, по этому в первую очередь выносить будут то - по чему больнее всего бить. Чипы (Китай уже много лет инвестирует в свои, США кидает гранты в интел, Самсунг поддерживает свои наработки), авиация, автопром, системы связи.
Так было раньше, пока сюзерены делали свои поборы небольшими, но пандемия показала, что так жить нельзя, завися от кого-то настолько - что он может показать тебе умереть за него.
Я старался каждый тезис подкреплять примером . От вас примеров только про электронику, и он весьма специфичен. Про ширпотреб - вы кстати зря - уже часто можно из кучи разных стран ширпотреб получить, не только из Китая.
Так что может вы и правы, но предпосылок вашей правоте я не вижу.
Распад единого глобального рынка на сектора - это как раз движение в обратную глобализации сторону.
Раньше страны могли себе позволить быть зависимыми от глобального рынка, веря в правила ВТО, безопасность государственных активов, доступность торговли. Сейчас всем понемногу становится ясно - что деньги хранящиеся в других странах могут украсть в одночасье (потому Индия, Сербия, Германия, Италия - активно возвращают золотые активы домой), что от торговли могут пытаться отключить (Китай выкатывает свой аналог Свифта), ВТО мертва (тарифы Трампа уже даже не скрываются под оправданием гос. безопасности).
Так что США стремятся вернуть заводы домой, БРИКС перейти на взаиморасчёты в домашних валютах, а Китай - пересесть но свой авиапарк. Каждая страна будет развивать внутреннее производство вытесняя внешнее, даже если это менее выгодно т.к. теперь это вопрос стратегической безопасности и жизнеспособности страны.
Благодаря аддитивным технологиям это становится более реальным (раньше окупить завод штучных деталей для самолётов можно было только продавая их всему миру, сейчас 1 3д принтер может штамповать всю их номенклатуру, наоборот не масштабируясь от количества)
Может этот этап пройдет, но пока явно виден распад глобализма.
Заменим эффективные, износостойкие и дешевые колёса, на неэффективные и сложные и дорогие ноги, потом проделаем тот-же трюк заменив одну телескопическую клешню на пару рук, добавим ненужную голову с глазами.
И вот - у нас уже робот, который в 60 раз менее надёжен, в 8 раз дороже (в лучшем случае), в 10 раз медленнее, и требует дополнительного оборудования (типо лестниц для высоких полок, колясок для габаритных грузов).
Думаю тут эффект масштаба и перепрофилируемости не поможет.
Вариант 1 - менеджеры оказались не эффективны - и инвестировали в машины, у которых срок окупаемости и цена дюйм в дюйм совпадает со стоимостью работников на этом интервале.
Тогда да - мы получили 960 работников, которые теперь могут решать новые задачи и приносить пользу государству.
Вариант 2 - реалистичный.
Машины обходятся дешевле людей. Тогда завод получает больше прибыли с каждой детали, а значит (неожиданно) - платить больше налог на прибыль, а остальное делит между инвесторами. 960 человек теперь работают в других местах - где продолжают за них платить пенсионные отчисления, что значит, что даже гос бюджет в выигрыше. А если станки куплены в стране и обслуживаются местными мастерами - то это ещё и поддержка местного производства, а там тоже налоги и рабочие места. В выигрыше по итогу все.
Фактически - для общества в целом - оптимизация труда - это всегда благо. Хотя для конкретного индивида - это может быть трагедией.
Глобализация подразумевает более менее равноправие, а для больших игроков это недопустимо т.к. их права "ровнее".
То что до этого продвигали как глобализацию - оказалось вассализацией - когда есть сюзерен имеющий монополию в производстве какого-то товара, и манипулирующий вассалами зависимыми от этого товара как ему угодно.
Первое - это точно не стартовый и не главный экран мессенджера. Не сейчас, и скорее всего никогда. Лишний клик для перехода к списку из виджетов сразу убъет весь интерес. Открывая мессенджер - я намерен действовать - писать сообщение конкретному пользователю/читать сообщение от конкретного пользователя - в девяносто десяти % случаев. Это не новостная лента, куда можно зайти посмотреть.
Второе - виджеты должны полностью генерироваться без участия пользователя (а это значит что все чаты будут отправляться в llm - сейчас, когда все топят за приватность, это будет тяжело протащить), но с возможность редактирования.
Если заметки надо будет писать самому и встречи надо будет трекать самому - удобнее завести приложение под каждую из этих целей отдельно. Причина тут проста - клик на запуск мессенджера мы тоже учитываем и если мне нужны заметки - я быстрее запущу заметки, чем мессенджер -> заметки.
В целом - как аналог google now но для мессенджера, который автоматически распознает в тексте маркеры и формирует виджеты - прикольно. Т.е. - это скорее экран тематического поиска (где обсуждаемые события, пароли, действия - вынесены). В таком виде - перспективно, даже подумалось реализовать поверх телеги, но блин - как представлю сколько мощностей llm это будет потреблять - становится страшно
Вы не договариваете. Никаких аргументов Сейчас. А вот когда они появятся, а рано или поздно они появятся - добро пожаловать в ад. Тем более что на деле как раз репозитории имеют свойство получать в аргументы dao, cacheProvider-ы, а в последствии и мапреры.
Singleton в di задаётся в рамках scope и это в любой момент можно поменять в модуле (я могу поменять singletone на factory заменив 1 слово в коде, сколько вам потребуется поменять, чтобы заменить singletone на factory при прямом обращении? И с di у вас может быть два инстанса singletone в разных скоупах - а это уже не тот сингтон, который невозможно поменять, не пройдя каждое вхождение.
Мои старания тщетны, раз вы не понимаете почему такой код плохой. А он очень плох в долгосрочной поддержке. Сегодня ваш dataProvider работает без кэша, а завтра надо добавить кэш, а послезавтра сделать чтобы половина была с кэшем а половина нет, а через месяц - брать данные из разных источников, а через год - хранить кэши раздельно для разных провайдеров.
И вот - вместо четырёх объектов каждый из которых ограничен своей логикой и выбран в di, получаем метод, с кучей параметров, обросший ифами снаружи, который нужно конфигурировать в каждой точке использования.
Хорошо если у вас все функции чистые - тогда вам и объекты не нужны, и di у вас по сути будет по умолчанию (нет объектов - нет зависимостей). Но когда появляются объекты - всё, di нужен.
Моё утверждение остаётся таким-же. Di практически бесплатен в разработке если вы ознакомились с тем как его писать. Его внедрение и использование в проекте не делает код сложнее или дороже - но он может решить кучу проблем, по этому не считая скриптов, однострочных сервисов, и кода на выброс - его повсеместное внедрение разумно.
Это как бесплатная страховка без дополнительных условий - отказываться нет смысла.
Последний раз 5ого июня, всё без проблем. Не думаю что все могло с тех пор измениться.
Слышал проблемы бывают у тех, кто только зарегистрировал аккаунт, у тех, у кого большой процент возврата, и у тех, от кого уже был проблемный возврат. Их проверяют вручную.
У меня практически все возвраты проходили автоматически. Т.е. заполняю данные, жму - сделать возврат, и через 10 секунд получаю код возврата и предложение сдать товар в пункте выдачи.
А зачем эта штука вообще нужна? Может кто-то есть, кто применяет гугловское решение например, и есть примеры использования?
Принцип Парето, 20% процентов работы, которые дали впечатляющий результат - сделаны ещё в 2014, до полноценного автопилота без проблем будем ехать ещё долго.
Если это пункт в договоре - антимонопольщики за такой легко могут взгреть что мама не горюй, они у нас кто бы что не говорил - лютейшие. Если это косвенный намек - тогда решается просто, model B. На маркетплейсе вы продаёте один товар, а у себя на сайте другой. Да, выглядит так-же, но на маркетплейсе model A и дорого, а у себя более совершенный model B и по дешеше.
Но вообще, если вы не супер большой бренд с миллиардными продажами - то никто и не узнает. Или как вы себе это представляете - при размещении магазина на маркете модераторам даётся задание - проверить что товары не продаются нигде дешевле, и отказать если продаются? - да если такое есть - человек с такой в переписке может хорошо шантажировать маркетплейс (не думаю что дэюро можно отказать в услуге размещения на основе того, что кто-то дешевле продаёт), слить её тем-же антимонопольным, и как минимум - уже выкатить анонимное интервью на какой нибудь youtube канал)
Если такие есть но я пропустил - пишите где смотреть, очень интересно)
30 возвратов на озон, проблемный был только 1, с заказом из за рубежа. Кросовки, мониторы, даже стулья после месяца использования (Сидушки трещинами пошли) - вернулись спокойно.
Не сомневаюсь что проблемы могут возникнуть (особенно на первом этапе, если продавец упрется, но в таком случа поддержка самого озона практически всегда на стороне покупателя, и возврат будет)
Я у тому, что люди которые скупают биток рискуют оказаться с ними в одной лодке с такой же аргументацией)
Во первых в своей статье вы критикует DI как подход, а не использование библиотек - это контрастирует с утверждением
Не важно каким инструментом вы делаете di - если вы его делаете (адекватно) - то это хорошо, а если нет, могут быть проблемы.
Я прекрасно ознакомлен с js, и понимаю о чем вы говорите. Ваши утверждения скорее показывают что вы не работали с проектом где di есть и построен верно. Да, в js можно хаотично импортировать что угодно куда угодно, но это не решает проблем которые решает di. Наоборот - динамическая типизация их усугубляет - когда у вас класс инстанцируется di в одном месте (как правило модуле), чтобы заменить его поведение (набор аргументов) - нужно поменять это в одном месте. Когда у вас класс инстанцируется там где применяется - чтобы поменять его аргументы - нужно найти все вхождения и заменить аргументы (и в js, если вы забыли в одном месте, то в отличии от компилируемых языков - ваша ошибка в рантайме), а если у вас вместо класса структура, создаваемая инлайн - можно вешаться - тут даже поиск и замена по проекту не помогут, и всесто новой реализации вы можете откуда-нибудь подтянуть старую, которая несовместима.
Если вы не используете модули как источник объектов - то код имеет свойство превращаться в матрёшки A(B(C(Q(Z), Q(Z)), Z, Q(Z))
Ну и синглтон - антирпетрн, так что прямой экспорт объекта может кончится глобальным супер рефакторингом.
В целом когда ваш код выглядит как UserStory(dataProvider), а не UserStory { let dataProvider = DataProvider }
То вы получаете гибкость - заменить dataProvider за 5 секунд.
Это делает эту статью очень ценой - как наглядный социальный эксперемент.
Отлично показывает - что когда читающий уже предвзят, и недостаточно квалифицирован в области материала - то легко примет за чистую монету то, что на деле только похоже на аргументы.
Андроид разработчик сразу видит по статье, что это не разбор а скорее хейт, но таких 14. А какой нибудь веб разработчик видит правдоподобные аргументы, и ставит плюс за "интересные подробности".
Буду демонстрировать её чтобы показать - что даже информацию про чиновника укравшего миллионы, или представителя закона в сговоре с бандитами - надо воспринимать критически
Не спорю. Но опять же - оставить поведение по умолчанию - это никак не тянет на
Это как сказать, что пользователь, который использует динамический ip выданый оператором "намеренно и тотально скрывает свою личность в интернете".
Нет, он просто за статический платить не захотел)
Нет, не добавляет.
Во первых - вы декомпилировали телерамм из плейстора? Он там точно не обфусцирован? Я не смотрел, но другие проекты с открытым исходным кодом таковые видел. Не удивлюсь если и телега такая.
А во вторых - если вы прочитаете официальную документацию к какому нибудь materialIcon3 прям с сайта документации Гугла для андроид разработчиков - там черным по белому написано - что они строго рекомендуют использовать r8 чтобы он вырезал неиспользуемые иконки.
Нет ни одной адекватной причины не использовать r8 в релизной сборке. Это примерно как отказаться от бесплатного лотерейного билета - ты ничего не теряешь включив r8, но можешь много выиграть.
Вот я с этим тезисом почти не согласен. И люди которые не знали зачем нужен di конечно плохо что не изучили, но все равно хорошо что использовали (если хотя бы правильно).
Di - это как ремень безопасности в машине - пристегнуть быстро, есть куча ситуаций когда он спасет тебе жизнь, и очень исключительные случаи когда может помешать (я согласен что в скрипте каком нибудь он не нужен).
Внедрение di (в новый проект) - обычно занимает меньше одного дня, поддержка не стоит почти ничего, и даже если он не начнет давать плюсов - не много потеряно. Зато если начнет - вы будете очень счастливы что он у вас есть.
Хотя я не смотрел его js - может там нет простых решений, хотя учитывая гибкость js - они напрашиваются
С товарищем играли в факторио - я строил первые заводы простые, не масштабируемые но быстро, а он фундаментальные, закладывался на рост и масштабирование - в итоге пока он масштабировался в Т1, я уже выходил в Т2, и опять строил наброски - как итог, игру я прошел быстрее.
Так что носить воду или строить водопровод - это все от ситуации зависит. Возможно вода сейчас позволить построить водопровод быстрее за счёт вырученных ресурсов, чем водопровод сразу. Или вообще понять, что он не нужен.