Ошибку с неправильным написанием ловил, но исправлял. Действовал согласно вашим статьям. Но у меня сборка ругалась в итоге не на подключение в settings.gradle.kts. А в build.gradle.kts проекта. Когда надо добавить свой плагин в сборку: id("base.plugin")
Мне стало лень разбираться дальше с этим и откатился на buildSrc, так как понял что уже несколько часов занимаюсь обновлением конфигов сборки ))
Что-то вы путаете. Как ни крути, но конструктор класс по прежнему возвращает instance этого класса. А вот уже сам instance можно вызвать после этого с другими параметрами.
Помню как занимался таким до появления VersionCatalogs. Но сейчас используя зависимости в одном toml-файлике и conventions-плагины, могу получить такие gradle-конфиги:
конфиг feature-модуля
А у него под капотом спрятана вся логика по настройке такого библиотечного модуля вместе с нужными зависимостями. И мне в конфиге остается только указать индивидуальные зависимости именно этого модуля. Здесь зависимости прокидываются в модуль не явно, в отличии от вашего подхода. Но меня это полностью устраивает, так как всегда могу провалиться внутрь и вспромнить что там есть.
Спасибо за статьи! Convention-плагин подключить не получилось, а вот затащить это в buildSrc удалось. Наконец избавился от дублирования некоторых значений и хранения в разных местах констант. Пробовал как-то и сам extension-функции написать для упрощения конфигурирования модулей приложения и библиотек, но не смог ))). Да и gradle далеко не та штука в которой хочется долго ковыряться, так как код самого приложения важнее.
Уже нет смысла использовать имутабельные коллекции. Теперь можно указать Compose через настройку какие классы будут стабильными, про чем глобально для всего проекта. то есть указывать аннотацию @Stable для всех моделек уже можно не надо
В статье описана обычная Scara - та самая промышленная робо-рука, которую можно увидеть на всяких демострациях и выставках; и Morgan-scara. При этом в morgan объединили и morgan и 5bar (на скрине как раз она). А морган хоть и параллельная, но имеет одно отличие от 5 bar, у нее основания плеч имеют общую ось вращения (по сути улучшенная обычная scara). Почему решили мучиться с Marlin? На мой скромный взгляд худший выбор из-за ее архитектуры. Та же smoothieware куда приятнее в обращении и уже имеет ее поддержку (с нее я начал когда строил свой 3d-printer на scara), еще есть RepRapFirmware, в которой поддержка скары еще лучше, чем в смузи и марлине. Почему-то у вас Prusa имеет лучшую точность, повторяемость и скорость, чем кубик. Из-за подвижного стола (из-за этого его и зовут дрыгостолом) он имеет меньшую скорость в сравнении с кубиком.
А линейные дельты не такой уж и большой объем для печати предоставляют для печати в сравнении с размером. Они очень высокие, и область печати имеет цилиндрическую форму.
Скорее не лямбду для какой-то extension-функции, а обработку в едином for-цикле. Такой код явно не будет очень удобным для чтения и выглядить будет так себе, но интересно именно какой оверхед несут extension-функции для списков. Все же каждая такая функция создает новый список и более сложные преобразования. Таким вопросом давно задаюсь, но сам так и не проверил. Но даже не смотря на результаты переставать пользоваться этими удобными функциями не перестану, с ними код чище и более читаем.
Жаль что нет сравнения с ручным преобразованием списком, без удобных операторов котлина. Был бы значительный прирост в производительности, если не было лишних созданий списков?
На php не все так ужасно, как на том же python. После kotlin/java думал что на php будет совсем боль из-за типизации, но оказалось, что все не так уж и плохо, даже захотелось в kotlin возможность вернуть из функции два разных типа данных aka string|bool. А возможности phpstorm просто невероятно помогают разобраться в чужом и своем коде, после vscode, который ощущался просто текстовым редактором с подсветкой.
Спасибо за статью. Так как я и сам уже писал плагин для idea, мне интересно где вы черпали информацию? В оф. доках весьма мало информации, и в интернете найти что-то сложно.
Подозреваю, главная причина в том что человеку нужна IDE, но не текстовый редактор с подсветкой.
До просто
pluginя сокращал не помогло, а до простоbaseдаже не пробовал ))Если вдруг решу снова ковыряться в
gradle, то попробую так сделать...Никто и не пишет, что это страшно. Это странно выглядит и пример привел, если неучитывать все эти DI, а их не все используют.
А чем метод
invokeне нравится? Он же и так есть по умолчанию, как оператор, но вызывать явно можно.Что имеется в виду? Не понятно...
Согласен, что выглядит странно, особенно если так написать )):
SomeUseCase(someRepository)(someId)Но можно же и явно вызвать метод
invokeБоюсь с этим мало что можно сделать, современные тенденции, они такие )
Вы лукавите же? Вы разве не об этом вели речь в статье упоминая про toml-файл с зависимостями?
Ошибку с неправильным написанием ловил, но исправлял. Действовал согласно вашим статьям. Но у меня сборка ругалась в итоге не на подключение в settings.gradle.kts. А в build.gradle.kts проекта. Когда надо добавить свой плагин в сборку:
id("base.plugin")Мне стало лень разбираться дальше с этим и откатился на buildSrc, так как понял что уже несколько часов занимаюсь обновлением конфигов сборки ))
Что-то вы путаете. Как ни крути, но конструктор класс по прежнему возвращает instance этого класса. А вот уже сам instance можно вызвать после этого с другими параметрами.
Помню как занимался таким до появления VersionCatalogs. Но сейчас используя зависимости в одном toml-файлике и conventions-плагины, могу получить такие gradle-конфиги:
А у него под капотом спрятана вся логика по настройке такого библиотечного модуля вместе с нужными зависимостями. И мне в конфиге остается только указать индивидуальные зависимости именно этого модуля.
Здесь зависимости прокидываются в модуль не явно, в отличии от вашего подхода. Но меня это полностью устраивает, так как всегда могу провалиться внутрь и вспромнить что там есть.
Спасибо за статьи! Convention-плагин подключить не получилось, а вот затащить это в buildSrc удалось. Наконец избавился от дублирования некоторых значений и хранения в разных местах констант. Пробовал как-то и сам extension-функции написать для упрощения конфигурирования модулей приложения и библиотек, но не смог ))). Да и gradle далеко не та штука в которой хочется долго ковыряться, так как код самого приложения важнее.
Вы не написали про 3 способ как избежать проблем со стабильностью:
Прописать нужные типы в конфигурационом файле (ссылка).
Уже нет смысла использовать имутабельные коллекции. Теперь можно указать Compose через настройку какие классы будут стабильными, про чем глобально для всего проекта. то есть указывать аннотацию
@Stableдля всех моделек уже можно не надоВ статье описана обычная Scara - та самая промышленная робо-рука, которую можно увидеть на всяких демострациях и выставках; и Morgan-scara. При этом в morgan объединили и morgan и 5bar (на скрине как раз она). А морган хоть и параллельная, но имеет одно отличие от 5 bar, у нее основания плеч имеют общую ось вращения (по сути улучшенная обычная scara).
Почему решили мучиться с Marlin? На мой скромный взгляд худший выбор из-за ее архитектуры. Та же smoothieware куда приятнее в обращении и уже имеет ее поддержку (с нее я начал когда строил свой 3d-printer на scara), еще есть RepRapFirmware, в которой поддержка скары еще лучше, чем в смузи и марлине.
Почему-то у вас Prusa имеет лучшую точность, повторяемость и скорость, чем кубик. Из-за подвижного стола (из-за этого его и зовут дрыгостолом) он имеет меньшую скорость в сравнении с кубиком.
А линейные дельты не такой уж и большой объем для печати предоставляют для печати в сравнении с размером. Они очень высокие, и область печати имеет цилиндрическую форму.
Или напиши в несколько разных преобразований, а ide пишет тебе, мол что ты делаешь, можно сократить парочку extensions в один )
Скорее не лямбду для какой-то extension-функции, а обработку в едином for-цикле. Такой код явно не будет очень удобным для чтения и выглядить будет так себе, но интересно именно какой оверхед несут extension-функции для списков. Все же каждая такая функция создает новый список и более сложные преобразования. Таким вопросом давно задаюсь, но сам так и не проверил.
Но даже не смотря на результаты переставать пользоваться этими удобными функциями не перестану, с ними код чище и более читаем.
Классная статья! Очень познавательно.
Жаль что нет сравнения с ручным преобразованием списком, без удобных операторов котлина. Был бы значительный прирост в производительности, если не было лишних созданий списков?
На php не все так ужасно, как на том же python. После kotlin/java думал что на php будет совсем боль из-за типизации, но оказалось, что все не так уж и плохо, даже захотелось в kotlin возможность вернуть из функции два разных типа данных aka string|bool. А возможности phpstorm просто невероятно помогают разобраться в чужом и своем коде, после vscode, который ощущался просто текстовым редактором с подсветкой.
Спасибо за статью. Так как я и сам уже писал плагин для idea, мне интересно где вы черпали информацию? В оф. доках весьма мало информации, и в интернете найти что-то сложно.
Спасибо! Не думал, что все настолько банально.