А чем предлагается заменить buildSrc для плагинов, которые нигде не шерятся?
В плане? Не особо понял проблему. По факту же buildSrc это тот же includeBuild просто добавленный в classpath со старта и везде. Причем Gradle в итоге откажутся рано или поздно от buildSrc совсем и превратят его уже в явный includedBuild
includeBuild разве не страдает теми же инвалидациями build classpath?
Да, но не совсем, ничто не мешает распихать по разным includedBuild
Version Catalog кстати хорош тем, что можно явно иметь зависимости между композитными билдами и кодом основного проекта. Но да, возможно в Groovy все не так хорошо, работал с ним только в Kotlin DSL
Хранить зависимости в buildSrc это ж кошмарная идея. Как и использовать buildSrc в 2к22 в целом. Любое изменение buildSrc инвалидирует кэши. Поменяли версию зависимости и вот сидите, огребаете.
Если у вас вопросы "решаются быстрее в офисе", то поздравляю - у вас отвратительные и неналаженные процессы.
Каким образом вообще наличие человека в офисе ускоряет работу? Вы берете задачи не по приоритету, а по принципу кто первый до разраба ножками пришел? У вас нет оплаченного зума, чтоб можно было быстро организовать встречу и был этот самый "постоянный контакт"? У вас нет нормальной документации, что всем постоянный контакт нужен?
Узнал о компании Мой Офис - оказывается удаленки нормальной нет, фичи делаются под копирку "как в Microsoft" даже если это кусок говна и можно сделать лучше.
Самое странное интервью в моей жизни: рекрутёр и HR директор собеседования ни по hard ни по soft скилам не умеют проводить вообще, либо не готовились :)
Задали 2-3 вопроса и основной поинт собеседования это "ну что рассказать, задавайте свои вопросы"
------
Никакой обратной связи, конечно же.
------
Пожалуй, самое неприятное интервью, которое у меня было. А было их за мой опыт достаточно.
Обе HR не спешили расположить к себе или как-то построить беседу, рассказать о корпоративной жизни или хоть что-то об условиях и компании (по их логике, всё есть на HH.ru и сайте).
------
Дают тестовое задание(естественно не оплачиваемое, объем задания 1-2 полных рабочих дня) по их продукту(актуальной версии)
Итого: я узнал, что Мой Офис это компания, которая прямо врет в собственном описании на ХедХантере и не имеет нормальной удаленки. HR и рекрутеры не умеют давать обратную связь, при этом на собесах иногда дают тестовые по продукту, что само по себе зашквар.
Вот скажите, а мне точно надо было что-то искать про вашу компанию? Что бы что? Чтоб я узнал про ваши косяки? Не лучше было бы вам шоб я пришел к вам на собес, а вы мне имели возможность продать вакансию и дозированно рассказать только то, что вы хотите чтоб я знал о вашей компании?
Что за дичь? Миллион? Во многих компаниях посредственные разработчики получают больше в виде годовой премии
И при этом за один лям нужно делать бизнес на 200 млн? Серьезно? Если у меня есть такой стартап или хотя бы рабочая идея, то уж проще на обедах сэкономить и как-нибудь без вас, мы ж тут про IT говорим все таки.
Спасибо, поставил на свой андроидофон RTX3070 и тени действительно стали гораздо лучше! Правда пришлось ставить еще систему охлаждения и теперь 3кг аккумулятор немного карман оттягивает, может еще с этой проблемой решение предложите?
if (view is TextView) {
(view as TextView).setTextColor(
if (darkMode) R.color.blue else R.color.black
)
} else if (view is TabLayout) {
(view as TabLayout).doAnything()
}
Я не очень понял зачем упарываться рантайм перекраской. Да, «моргания» действительно нет, но смена темы это сравнительно редкое явление, которым можно пренебречь, а вот обмазывать каждую вью для перекраса рантаймом это очень дорого в разработке.
Но не лучше ли спрашивать про конкретную платформу? Про конкретный язык, на котором кандидату придется работать? Неужели абстрактные алгоритмы спрашивать лучше, чем практические знания?
Ты написал что «опенсорс это хорошо». Где тут конкретная явная позиция по данному вопросу? Или у вас только позиция по поводу того что «опенсорс это хорошо, а nginx это хороший продукт» есть? Так это и без вас знаем, конкретной поддержкой nginx тут и не пахнет вовсе.
Иногда лучше ничего не писать, чем писать воду вокруг да около хайпа.
Ну после такой истории лично у меня Рамблер будет в блэклисте вместе с банком Тинькофф, чисто из-за неадекватной деятельности руководства.
Зачем было так позориться — непонятно.
7) Судя по исходникам Modifier кажется довольно объемным решением, можете хоть Padding виджет не удалять, потому что как видно из слака того же — все разделились на 2 лагеря, кому-то удобно через модифаер, кому-то через виджет. Кажется, правильно оставить и поддержать оба варианта.
10) Сейчас если в поле @Model класса есть ArrayList например, то изменение этого листа не влечет за собой изменение UI, нужно присваивать новый ArrayList, что неудобно. Планируется ли как-то улучшить этот процесс, особенно в свете того, что для Compose как раз будут писать свой RecyclerView аналог?
11) А зачем, похоже, что самый удобный способ — это все тот же инстанс @Model внутри ViewModel/Presenter через который и будут производиться изменения. Да и насколько я понимаю с текущей реализацией стейта в Compose LiveData становится ненужной практически.
А сами паттерны это столько не про формализацию, сколько про типичное решение типичных проблем, что очень нужно знать джуну, но синьор и так напишет то же самое, даже не помня про конкретный паттерн.
Да никто не будет писать массово серьезные приложения на QT потому что это прошлый век, еще на COBOL или ALGOL предложи писать.
Уже выстроилась экосистема, тысячи библиотек, понятные всем языки и тд - никто не поменяет это на переусложненные кривые плюсы и недружелюбную IDE
Это точно про Яндекс? :D
В плане? Не особо понял проблему. По факту же buildSrc это тот же includeBuild просто добавленный в classpath со старта и везде. Причем Gradle в итоге откажутся рано или поздно от buildSrc совсем и превратят его уже в явный includedBuild
Да, но не совсем, ничто не мешает распихать по разным includedBuild
Version Catalog кстати хорош тем, что можно явно иметь зависимости между композитными билдами и кодом основного проекта. Но да, возможно в Groovy все не так хорошо, работал с ним только в Kotlin DSL
Хранить зависимости в buildSrc это ж кошмарная идея. Как и использовать buildSrc в 2к22 в целом. Любое изменение buildSrc инвалидирует кэши. Поменяли версию зависимости и вот сидите, огребаете.
Для зависимостей вообще-то есть Version Catalog
Если уж ТАК хочется хранить зависимости в коде можно использовать Composite builds
Если у вас вопросы "решаются быстрее в офисе", то поздравляю - у вас отвратительные и неналаженные процессы.
Каким образом вообще наличие человека в офисе ускоряет работу? Вы берете задачи не по приоритету, а по принципу кто первый до разраба ножками пришел? У вас нет оплаченного зума, чтоб можно было быстро организовать встречу и был этот самый "постоянный контакт"? У вас нет нормальной документации, что всем постоянный контакт нужен?![]()
Зашел на https://career.habr.com/companies/myoffice/scores/2021
Узнал о компании Мой Офис - оказывается удаленки нормальной нет, фичи делаются под копирку "как в Microsoft" даже если это кусок говна и можно сделать лучше.
Зашел на https://hh.ru/employer/213397
Одни баззворды, читаю такое в каждом первом описании компании.
Зашел на https://pravda-sotrudnikov.ru/company/moy-ofis
И тут вообще клоунада
Итого: я узнал, что Мой Офис это компания, которая прямо врет в собственном описании на ХедХантере и не имеет нормальной удаленки. HR и рекрутеры не умеют давать обратную связь, при этом на собесах иногда дают тестовые по продукту, что само по себе зашквар.
Вот скажите, а мне точно надо было что-то искать про вашу компанию? Что бы что? Чтоб я узнал про ваши косяки? Не лучше было бы вам шоб я пришел к вам на собес, а вы мне имели возможность продать вакансию и дозированно рассказать только то, что вы хотите чтоб я знал о вашей компании?
Что за дичь? Миллион? Во многих компаниях посредственные разработчики получают больше в виде годовой премии
И при этом за один лям нужно делать бизнес на 200 млн? Серьезно? Если у меня есть такой стартап или хотя бы рабочая идея, то уж проще на обедах сэкономить и как-нибудь без вас, мы ж тут про IT говорим все таки.
Спасибо, поставил на свой андроидофон RTX3070 и тени действительно стали гораздо лучше! Правда пришлось ставить еще систему охлаждения и теперь 3кг аккумулятор немного карман оттягивает, может еще с этой проблемой решение предложите?
После is не нужен явный каст же
А надо было их запускать в обязательном порядке на CI, локально никто ничего запускать не будет точно.
Иногда лучше ничего не писать, чем писать воду вокруг да около хайпа.
Зачем было так позориться — непонятно.
BTW — спасибо за ответы)
10) Сейчас если в поле @Model класса есть ArrayList например, то изменение этого листа не влечет за собой изменение UI, нужно присваивать новый ArrayList, что неудобно. Планируется ли как-то улучшить этот процесс, особенно в свете того, что для Compose как раз будут писать свой RecyclerView аналог?
11) А зачем, похоже, что самый удобный способ — это все тот же инстанс @Model внутри ViewModel/Presenter через который и будут производиться изменения. Да и насколько я понимаю с текущей реализацией стейта в Compose LiveData становится ненужной практически.
А сами паттерны это столько не про формализацию, сколько про типичное решение типичных проблем, что очень нужно знать джуну, но синьор и так напишет то же самое, даже не помня про конкретный паттерн.