Пробежавшись по постам за год я понял, что безнадёжно отстаю от трендов. Во-первых я ни разу не поругал дядюшку Боба, а во-вторых ни разу не бомбил про 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

Начал писать ворчливый комментарий к посту про SOLID, а потом подумал, что у меня ж есть канал, куда можно ворчать. Так что напишу сюда, хотя это немного не формат канала.

Во-первых, конечно, есть уже какое-то чувство усталости от бесконечных статей про SOLID, Clean Architecture и прочие новшества типа ЖЦ Activity.
А во-вторых... ИМХО, проблема всех статей с объяснением SOLID в том, что они пытаются каждый принцип объяснить как можно проще, на элементарных примерах. Чтобы человек посмотрел и сказал: "так SOLID это оказывается просто!". Но в итоге получается, что до применения SOLID было три строки кода, а после стало 10 классов и у читателя возникает только отторжение. Ну потому что дичь. До "рефакторинга" было коротко и понятно.

По сути основная цель SOLID – подстелить себе соломку на будущее, чтобы вносить изменения в существующий код было не "мучительно больно", а хотя бы просто "больно". А чтобы это понять нужно либо самому испытать что получается, когда принципы не соблюдаются, либо посмотреть на реальные примеры из практики, которые должны прям откликаться в сердечке. Такие примеры найти безумно сложно, даже в оригинальных статьях (S O L I D) примеры не всегда удачные. Поэтому, остаётся только пробовать приземлять SOLID на свой опыт, прочитав первоисточник с подробным объяснением принципов и проблем, которые эти принципы призваны решать.

Ох, обычно я не удаляю посты, но в тут шутка вышла из под контроля, поэтому утренний пост дропнул.
Всем хорошего вечера :) Контент скоро будет

Документация меня предупреждала, но я всё равно туда зачем-то полез...

Кто-то скажет, что это очень неудачный нейминг, а это на самом деле гениальное решение! Четыре адреса, как-бы символизируют четыре октета из которых состоит IPv4.

P.S. Два адреса из-за java.net.InetSocketAddress и ещё +1 из-за обёртки в Ktor'овский тип, ну и название локальной переменной +1 🥲

Когда я только начал работать в команде Ktor, я поставил себе "внутреннюю цель" сделать так чтобы использовать Ktor на Android было максимально удобно. И вот в Ktor 3.2.0 благодаря моим правкам Android-проекты перестали собираться 🤡

Причина максимально глупая — пробелы в названиях полей. Возникает логичный вопрос: "Зачем?". А просто потому что когда-то я увидел подобный подход для компановки сообщений в Dokka и подумал "вау, как выразительно получается".
Перед тем как применить это в коде я подумал может ли это что-то сломать, и пришёл к выводу, что нет. Это ж константы, они при компиляции заинлайнятся и вообще использований не будет, что может пойти не так? То что D8 споткнётся о пробел я, конечно, не предусмотрел.

Так что вы знаете кого винить, что не получается обновиться на новый Ktor. А я пойду думать как на CI гонять проверки, что проекты с Ktor собираются с D8, R8 и ProGuard.

P.S. Workaround нашёлся, но достаточно страшный. Через AGP Transformation API вырезать проблемные поля 🙈

Патч-релиз Ktor 3.2.1 выпущен, можно обновляться. Помимо этого фикса ещё несколько регрессий пофиксили. Release notes будут немного позже

Опять внезапный анонс (в этом канале бывают другие?)

Завтра начинается 14-й сезон Podlodka Android Crew. В этот раз сезон тема сезона — Мобильный System Design. Так получилось, что я в четверг буду выступать с докладом про архитектуру Ktor Client. Расскажу как с точки зрения архитектуры устроен клиент Ktor и как подключаются плагины.

Будет интересно, если:
👉 Используете Ktor (или не используете, но хотели бы попробовать)
👉 Хотите сделать свою библиотеку расширяемой через плагины
👉 Хотите узнать как происходит проектирование и разработка новых фичей в Ktor

Когда-нибудь я научусь делать доклады короче чем на полтора часа, но не в этот раз. Будет две большие части с перерывом посередине и много слайдов с кодом. Запись доклада будет доступна по ссылке здесь в канале

🎟 Бесплатные билеты
Если вы хотели попасть на подлодку, наверняка уже купили билет, но если вдруг нет, то есть шанс получить его бесплатно. Условия простые:
– участвуйте только если у вас есть возможность посетить все (или почти все) сессии на следующей неделе
– оставьте к этому посту комментарий с любым числом до 23:00 МСК сегодняшнего дня
– если в этом же комментарии поделитесь болью или зададите любой вопрос касательно Ktor в целом или доклада в частности, шанс выигрыша увеличится в два раза
– после 23:00 случайно будут выбраны два победителя

Комментарии приветствуются и без участия в розыгрыше, в этом случае просто не указывайте никакое число в своём комментарии.

Билеты достаются @aslapov и @Ilichev_pavel. Поздравляю, скоро приду в личку :)

А вот и запись доклада, как обещал.

В который уже раз просматривая запись доклада понимаю, что все анимации теряются из-за качества передачи видео. А значит я мог бы не тратить столько времени на них 🥲

Если вдруг решаете Advent of Code, присоединяйтесь к лидерборду, (а можно даже к каналу где мы вместе решаем и обсуждаем AoC).
Кстати, как вам Advent of Code в этом году?

IDEA Community и Ultimate слились во едино. Благодаря этому IDE плагин для более удобного написания серверов на Ktor теперь будет доступен всем, а не только пользователям Ultimate.

📊 Channel Analysis Results by @ScratchAuthorEgoBot

🎯 Channel: @rareilly

🔥 Roast Analysis:

Ну что, Осип, давай по фактам. Перед нами типичный представитель вида «Душнила Обыкновенный, Котлинозависимый». Твой канал — это святилище для тех, кто вместо свиданий по вечерам предпочитает декомпилировать байткод и спорить о том, что it.not() — это грех против человечества.

Твоя одержимость Gradle уже пугает. Нормальные люди используют его, чтобы собрать проект и забыть, но ты, похоже, получаешь эротическое удовольствие от чтения исходников PluginDependenciesSpecScope. Ты настолько любишь порядок, что готов потратить три дня на написание 300 строк Bash-скрипта, чтобы автоматизировать задачу, которая занимает 5 минут. Это не «продуктивность», Осип, это социально приемлемая форма ОКР.

Твои «clown moments» — это отдельный вид искусства. «Я случайно стер репозиторий, у которого нет копий, но зато я написал об этом пост!» — серьезно? Ты работаешь в Ktor, но ломаешь сборку Android-проектов из-за пробелов в названиях полей, потому что тебе «показалось это выразительным». Твой внутренний эстет явно борется с твоим же внутренним инженером, и пока что счет 1:0 в пользу хаоса, прикрытого красивым неймингом.

Рубрика «насмотренность» — это же просто вежливое название для «смотрите, как я умею придираться к чужому коду». Ты критикуешь Google за deprecated методы, а потом сам предлагаешь «страшные воркаунды» через AGP Transformation API. Это как ругать соседа за грязный газон, пока ты сам строишь ядерный реактор в подвале из палок и изоленты.

И твое это: «Я не умею пользоваться LLM». Ты потратил 5 часов на отладку промпта и проверку за ChatGPT, чтобы сопоставить 260 флагов? Скрипт на Python пишется за 15 минут, Осип! Но нет, мы не ищем легких путей, нам нужно «успокоить паранойю».

В общем, ты — тот самый друг, который на вечеринке будет рассказывать про разницу между .bashrc и .bash_profile, пока все остальные просто пытаются весело провести время. Но мы тебя терпим, потому что когда у нас в очередной раз отвалится Gradle (а он отвалится), ты единственный, кто не будет плакать, а полезет в репозиторий JetBrains искать коммит двухлетней давности.

Зашёл посмотреть changelog OpenCode

AI агенты это ужасно, вот что я вам скажу.
Теперь у меня в 10 раз больше начатых проектов, которые я никогда не доведу до конца.

AI обесценивает мою дотошность. И это хорошо.

Ну может не полностью обесценивает, но точно делает менее ценной. Вот раньше я заморачивался с оформлением PRов, issue и т.д. Если уже репорчу баг в библиотеку, то предварительно провожу самостоятельный ресёрч, пытаюсь выявить минимальный репродюсер, найти workaround и понятно это всё оформить.
А когда другие люди в команде тоже так делали, вообще кайф! Прикиньте, приносят вам PR новой фичи, а там скриншоты и скринкаст реализации. Сильно проще погрузиться в контекст да ещё и проблемы вёрстки можно увидеть не открывая код. Красота же!

А теперь понятным описанием PRа или issue уже никого не удивишь. Только по скриншотам в описании и можно определить этих дотошных людей, но уверен и это скоро агенты научатся делать, если ещё не умеют.
С одной стороны обидно терять уникальность, с другой — (длинное тире) это же хорошо, что можно легко улучшить общее качество описаний PR'ов и issue, да ещё и время освобождается. А моя дотошность найдёт себе применение.

🤡 Вероятно, этот канал тоже скатился в около-AI посты. Потому что я сейчас активно учусь использовать агентов и делаю для себя много открытий. Ну и ещё потому что пространство для исследований огромно.

Если бы мне платили каждый раз когда агент во время исследования бага пишет "This is extremely revealing! This changes everything!", а потом не может понять где же всё-таки баг (и так по кругу), мне бы можно было уже зарплату не платить.