Warning: mkdir(): No space left on device in /var/www/group-telegram/post.php on line 37

Warning: file_put_contents(aCache/aDaily/post/rareilly/--): Failed to open stream: No such file or directory in /var/www/group-telegram/post.php on line 50
Ra'Reilly - Заметки про Android и не только | Telegram Webview: rareilly/183 -
Telegram Group & Telegram Channel
Пробежавшись по постам за год я понял, что безнадёжно отстаю от трендов. Во-первых я ни разу не поругал дядюшку Боба, а во-вторых ни разу не бомбил про Gradle (предупреждение о сломанном релизе не в счёт). Негоже уходить в новый год с такими пробелами, поэтому буду исправляться. Хотя бы частично.

С дядюшкой Бобом и без меня неплохо справляются, я бы мог разве что на его стороне выступить, но это не модно. А про Gradle мне есть что сказать. Если у вас в этот момент возникла мысль "прочитаю лучше после праздников", подумайте, хотите ли вы начинать год с Gradle.

Существует много причин не любить Gradle, но меня больше всего раздражает его "хрупкость". Есть много способов сделать одно и то же, но только один из них правильный, а остальные приведут к замедлению конфигурации проекта, несовместимости с configuration cache или проект вообще перестанет собираться.

Речь, конечно, про lazy API. Это прям штука про которую нужно знать сразу, как только начинаешь делать в Gradle что-то сложнее чем объявление зависимостей. Но не стоит терять бдительность после прочтения документации. Допустим, ты знаешь, что нужно использовать tasks.named("javadoc") , а tasks.getByName("javadoc") в большинстве случаев не нужно, так как этот вызов создаёт запрошенный таск на месте вместо того чтобы возвращать ленивый провайдер. Но что если нужно сразу сконфигурировать этот таск? Вроде всё просто:
tasks.named("javadoc") { enabled = false }


А если хотим сконфигурировать все таски определённого типа? Можно написать так:
tasks.withType<Javadoc> { enabled = false }

И это будет ошибка. Если в withType передать лямбду, то под капотом вызывается withType<T>().all(configure), а all в моменте создаёт все таски в коллекции. Правильно будет делать так:
tasks.withType<Javadoc>()
.configureEach { enabled = false }


Хорошо, а если хотим выключать таски по какому-то условию? Например, по флажку в gradle.properties:
tasks.withType<Javadoc>().configureEach {
enabled = properties["tasks.javadoc"].toBoolean()
}

Ой-ой, опять ошибка! Нужно использовать findProperty("..."). Почему? Посмотрите документацию к getProperties... а, погодите, там ничего полезного не написано... тогда документацию к Project (скриншот снизу). Этот метод ищет "свойства" в более широком смысле — смотрит на поля convention'ов, Gradle-экстеншены, поля внутри Project, все таски, extras, причём не только для текущего проекта, но и для всех родительских. И все это собирается в одну большую Map'у. Привести это может к довольно неожиданным проблемам.

Так что в новом году желаю вам выбирать всегда правильные APIшки (и не только в Gradle). С Рождеством и Новым Годом :)

#gradle



group-telegram.com/rareilly/183
Create:
Last Update:

Пробежавшись по постам за год я понял, что безнадёжно отстаю от трендов. Во-первых я ни разу не поругал дядюшку Боба, а во-вторых ни разу не бомбил про Gradle (предупреждение о сломанном релизе не в счёт). Негоже уходить в новый год с такими пробелами, поэтому буду исправляться. Хотя бы частично.

С дядюшкой Бобом и без меня неплохо справляются, я бы мог разве что на его стороне выступить, но это не модно. А про Gradle мне есть что сказать. Если у вас в этот момент возникла мысль "прочитаю лучше после праздников", подумайте, хотите ли вы начинать год с Gradle.

Существует много причин не любить Gradle, но меня больше всего раздражает его "хрупкость". Есть много способов сделать одно и то же, но только один из них правильный, а остальные приведут к замедлению конфигурации проекта, несовместимости с configuration cache или проект вообще перестанет собираться.

Речь, конечно, про lazy API. Это прям штука про которую нужно знать сразу, как только начинаешь делать в Gradle что-то сложнее чем объявление зависимостей. Но не стоит терять бдительность после прочтения документации. Допустим, ты знаешь, что нужно использовать tasks.named("javadoc") , а tasks.getByName("javadoc") в большинстве случаев не нужно, так как этот вызов создаёт запрошенный таск на месте вместо того чтобы возвращать ленивый провайдер. Но что если нужно сразу сконфигурировать этот таск? Вроде всё просто:

tasks.named("javadoc") { enabled = false }


А если хотим сконфигурировать все таски определённого типа? Можно написать так:
tasks.withType<Javadoc> { enabled = false }

И это будет ошибка. Если в withType передать лямбду, то под капотом вызывается withType<T>().all(configure), а all в моменте создаёт все таски в коллекции. Правильно будет делать так:
tasks.withType<Javadoc>()
.configureEach { enabled = false }


Хорошо, а если хотим выключать таски по какому-то условию? Например, по флажку в gradle.properties:
tasks.withType<Javadoc>().configureEach {
enabled = properties["tasks.javadoc"].toBoolean()
}

Ой-ой, опять ошибка! Нужно использовать findProperty("..."). Почему? Посмотрите документацию к getProperties... а, погодите, там ничего полезного не написано... тогда документацию к Project (скриншот снизу). Этот метод ищет "свойства" в более широком смысле — смотрит на поля convention'ов, Gradle-экстеншены, поля внутри Project, все таски, extras, причём не только для текущего проекта, но и для всех родительских. И все это собирается в одну большую Map'у. Привести это может к довольно неожиданным проблемам.

Так что в новом году желаю вам выбирать всегда правильные APIшки (и не только в Gradle). С Рождеством и Новым Годом :)

#gradle

BY Ra'Reilly - Заметки про Android и не только




Share with your friend now:
group-telegram.com/rareilly/183

View MORE
Open in Telegram


Telegram | DID YOU KNOW?

Date: |

Ukrainian forces have since put up a strong resistance to the Russian troops amid the war that has left hundreds of Ukrainian civilians, including children, dead, according to the United Nations. Ukrainian and international officials have accused Russia of targeting civilian populations with shelling and bombardments. Telegram has gained a reputation as the “secure” communications app in the post-Soviet states, but whenever you make choices about your digital security, it’s important to start by asking yourself, “What exactly am I securing? And who am I securing it from?” These questions should inform your decisions about whether you are using the right tool or platform for your digital security needs. Telegram is certainly not the most secure messaging app on the market right now. Its security model requires users to place a great deal of trust in Telegram’s ability to protect user data. For some users, this may be good enough for now. For others, it may be wiser to move to a different platform for certain kinds of high-risk communications. The Russian invasion of Ukraine has been a driving force in markets for the past few weeks. The account, "War on Fakes," was created on February 24, the same day Russian President Vladimir Putin announced a "special military operation" and troops began invading Ukraine. The page is rife with disinformation, according to The Atlantic Council's Digital Forensic Research Lab, which studies digital extremism and published a report examining the channel. Right now the digital security needs of Russians and Ukrainians are very different, and they lead to very different caveats about how to mitigate the risks associated with using Telegram. For Ukrainians in Ukraine, whose physical safety is at risk because they are in a war zone, digital security is probably not their highest priority. They may value access to news and communication with their loved ones over making sure that all of their communications are encrypted in such a manner that they are indecipherable to Telegram, its employees, or governments with court orders.
from ua


Telegram Ra'Reilly - Заметки про Android и не только
FROM American