По-явански

Приятно видеть, что плагин востребован и набирает обороты. Сложность в том, что фичи придумываются быстрее, чем я успеваю их реализовывать. По самым грубым подсчётам у меня 20 фич, почти все можно улучшить, ещё с десяток хочется сделать. Поэтому есть два предложения: 1. Тем, кто хочет вкатиться в плагиностроение, предлагаю парное программирование. Тебе — бесценный опыт, всем нам — улучшения плагина, мне — потенциальные пуллреквесты в будущем. 2. А если вдруг здесь есть люди с опытом плагиностроения (преимущественно инспекций), то я хотел бы заполучить кусочек вашего опыта, можно даже не бесплатно. Пишите в личку, кому интересно.

На просторах интернета обнаружилось нечто похожее: готовая система плагинов с горячей загрузкой для андроида.

Кстати, у всем известного нам @Harmonizr вышел апдейт его IDE плагина, который в текущей версии обладает крайне важной и нужной функцией, а именно чистит ваши SVG от всякого лишнего мусора. Установить плагин можно по ссылке - https://plugins.jetbrains.com/plugin/12690-mike-s-idea-extensions/versions/stable/148933

Скоро начнём!

Всем привет! Мы вместе с Алексеем Гладковым (YouTube-канал Mobile Developer) проводим онлайн-дискуссию про то, как выбрать идеальный SDK для Android-приложений и существует ли он, какие SDK — must-have для Android, а когда лучше обойтись без интеграции внешних библиотек. В ходе беседы соберём мнения тех, кто широко использует SDK для себя, кто разрабатывает их для других и кто предпочитает использовать только свои решения. 30 ноября в 17:00, регистрация здесь: https://qonversion.io/sdk-meetup Приходите!

Всем привет! Мы вместе с Алексеем Гладковым (YouTube-канал Mobile Developer) проводим онлайн-дискуссию про то, как выбрать идеальный SDK для Android-приложений и существует ли он, какие SDK — must-have для Android, а когда лучше обойтись без интеграции внешних библиотек. В ходе беседы соберём мнения тех, кто кто широко использует SDK для себя, кто разрабатывает их для других, и кто предпочитает использовать только свои решения. 30 ноября в 17:00, регистрация здесь: https://qonversion.io/sdk-meetup Приходите!

Дополнил ❤️

Решают ли DI-фреймворки больше проблем, чем создают? В моём канале с мемами много шуток про то, что в спорах между Dagger 2 и Koin на самом деле побеждают фабрики. Так вот, это не шутки. Я считаю что DI-фреймворки в android – это подражание спрингерам, дань моде, следствие хронического ООП-клинкода головного мозга и просто переоценённое излишество. Жёсткий наброс вкинут, погнали подкреплять его аргументами. Что вообще решают DI-фреймворки? DI фреймворки в основном решают очень простую проблему – как написать код, который собирает объект из зависимостей. Это очень простой код, который легко написать и потом читать и дебажить. Есть ли в этом вообще проблема? Ну да, кажется, что это "бойлерплейт". Слишком скучно и неинтересно. Но когда скучный код был проблемой? Проблемой обычно бывает как раз "интересный" код. Его надо прочесть, понять, переспать с ним, вдуматься, ошибиться в нём пару раз. Со скучными фабриками проблемы нет. Я готов их писать каждый день. Что если вы не такой устойчивый к рутине? Ладно, допустим, рутина написания фабрик для вас – это проблема. Настолько большая, что вы не представляете, что можете отказаться от DI-фреймворка и начать писать всё руками. Но вы пробовали? В Kotlin, благодаря интерфейс- и проперти-делегатам неплохо получается писать код фабрик кратко. И при этом вам и вашим джунам не придётся учить доменный язык Koin или язык аннотаций Dagger. Серьёзно, я помню джуновскую дрожь в коленках от словосочетания Inherited subcomponent multibindings в документации Dagger. Я честно говоря до сих пор не понимаю, какие задачи стоят перед теми кто в такое упарывается. Да и в простых случаях помню как смотрел как баран на новые ворота и пытался понять, а какой магией зависимости прилетают ко мне в конструктор? Почему иногда я вешаю @Inject надо конструктором и всё работает, а иногда мне выплёвывают портянку красного кода где ни слова о том, что мне просто нужно поставить ещё одну такую же аннотацию и всё снова будет работать? Ух, аж передёрнуло от волны флешбеков. Koin я начал изучать на более сознательном этапе карьеры, но всё равно надо было посидеть поразбираться, чем их модули и компоненты отличаются от Dagger и Ninject. А так был бы только Kotlin, только хардкор прагматичный подход. Какие проблемы не решают DI-фреймворки? При этом мы расплачиваемся более высоким порогом входа только за решение тривиальной задачи "собери из спичек домик". На более сложные, смежные с DI вопросы типа навигации иили передачи данных из одного скоупа в другой, восстановления графа зависимостей, жизненного цикла зависимостей, кооперативного очищения скоупов зачастую во фреймворке готового ответа нет или ответы в лучшем случае medium rare. Эти проблемы приходится решать самому, и тут есть 100500 решений и в каждом проекте будет немного по-другому. А это задача сложная, из тех что на подумать. Хорошо если у вас в команде будет условный Владимир Тагаков, который всё вам настроит и будет бить по рукам за неправильное использование и срезание углов. Но в современной разработке мы часто слишком мало думаем, у нас нет возможности лечь в гамак как Рич Хикки и думать о наилучшем способе показать пользователю промку с акцией на чёрную пятницу. Сложная проблема + сложный инструмент + ограниченные ресурсы = неоптимальные решения, которые стрельнут через пару лет, треснув под грузом нового кода как плохо залитый фундамент.

Чёт все новости — про Компоуз, Хилт или компайл-тайм рефлекшен в Котлине. 30 октября в 10:00 Мск будет бесплатная онлайн-конфа. В кубернетесах я ничего не понимаю, а вот про Loom, Graal Native Image и Java 17 послушаю с интересом.

Дано: проект с Gson и смешанным кодом на Java и Kotlin. Задача: пилить фичи, добавлять эндпоинты. Хотелки: 1. Не иметь геттеров. Из существующего джавового кода они выглядят многословно. 2. Поля должны быть финальными. Не хочу нежданчиков в виде случайных присваиваний. 3. Нужны фоллбэки. Если опциональное поле не приходит, пусть у него будет удобное значение — emptyList() или "". Вариант описывать данные на котлине с @JvmField я отмёл: многословно. За что боролись, об то и навернулись. Вместе с @SerializedName может и в строчку не уместиться. Остаётся джава, поля объявил в таком виде: @SerializedName("user_name") public final String userName = ""; Проблема первая: для такой конструкции у поля генерируется ConstantValue и инлайнится в места использования. В итоге Gson успешно переписывает финальные поля, но их уже никто не читает. Случай описан выше. Выход — таки унести присвоения в конструктор, как в B и C. Проблема вторая: опциональное поле может прийти null. Тогда я хочу оставить фоллбэк. Есть GsonBuilder#serializeNulls(), но мне нужно наоборот: не десериализовать нуллы. Настройки такой нет, конский ReflectiveTypeAdapterFactory копипастить ради одного ифа не хочется. В итоге написал JsonReader, который эти нуллы пропускает.

Фишка в том, что я в детстве невнимательно читал JLS. Поле считается константным, если оно финальное и инициализировано константным выражением в месте объявления. Про static здесь ни слова. В итоге класс А после декомпиляции выглядит так, как показано на картинке. B и C (E, F) этому правилу не подчиняются, поэтому все поля честно используются. D тоже «нормальный» — котлин решил не повторять «странностей» джавы, потому что сейчас уже ясно, что такая конструкция может использоваться для десериализации.

Какие классы ведут себя эквивалентно, а какие принципиально отличаются? Только не надо говорить, что у них имена разные и у Kotlin-версий есть метадата, речь про практическую разницу ;)

Раскопал занятный баг внутри GradientDrawable (<shape>) в андроиде. Костыль прилагается.

А я вот чего подумал. %username%, ты считаешь, что факториал — хороший пример на рекурсию и генераторы? Бро, нет. Определение n! = n * (n-1)! не только рекурсивно, оно ещё и рекуррентно, то есть следующий член легко вычисляется на основании предыдущего. Итераторы-генераторы в целом подходят, но очень быстро наступит переполнение, т. к. 21! уже не влезает в Long/ULong. Тестировать такой генератор скучно, а всерьёз использовать — больно. В итоге я остановился на табличном методе: сразу вычисляем аж все 20 факториалов, которые вмещаются в Long, и хватит. Никакой рекурсии, никаких вспомогательных объектов, очень просто и «в лоб». Но громоздко, да.

Идея самой компактной версии принадлежит @ivanovn.

fun factorial(n: Int): Long =
    (2..n).fold(1L, Long::times)

Задача: реализовать функцию factorial(n) -> long. Какое решение самое простое? Компактное? Эффективное? Зрелищное?

Присоединяйтесь - https://www.youtube.com/watch?v=8XBjQZ5dLMs

GDG Live: Верстка виджетов и библиотека FiftyShades 🎙28 июля (ср) в 19:00 будем обсуждать разработку и верстку виджетов с Александром Невьянцевым, а также устроим сессию вопросов и ответов по библиотеке теней FiftyShades от Михаила Горюнова. В первой части митапа Михаил сделает демо библиотеки, которая делает нормальную тень в андроиде и затем ответит на вопросы, если таковые появятся. Михаил написал библиотеку, которая рисует произвольные тени https://github.com/Miha-x64/FiftyShades - готовьте свои вопросы, чтобы задать спикеру на сессии. Во второй части вас ждет доклад о виджетах от Александра Невьянцева. Александр покажет основные проблемные точки в разработке виджетов, откуда они появляются и возможные решения. Подробности тут: https://www.meetup.com/gdgspb/events/279490422/

В продолжение темы графики в андроиде. Запилил пару топиков для Hyperskill. * Drawables overview * Graphics overview. Implementing a Drawable

Бесплатный онлайн-митап для Java-разработчиков и тех, кто занимается DevOps – Luxoft TechFest #4 Когда: 3 июня, 18:00 (GMT+3) Участие: бесплатно Формат: онлайн Организаторы: Luxoft и JUG Ru Group В программе доклад Евгения Мандрикова, ведущего разработчика JaCoCo – «Scala, Kotlin, Java и Code Coverage: показать все, что скрыто». Знаете ли вы, что Scala-компилятор помещает внутрь ваших class-файлов? А чем отличается байт-код, производимый Scala-компилятором, от байт-кода, производимого Java и Kotlin компиляторами? А готовы поспорить? 😏 Смотрите всю программу на https://bit.ly/3hS0U0Z 🔥 А еще мы разыграем сертификаты на онлайн-курсы от Luxoft Training, и все участники мипата получат 10% скидку на любой курс. Подключайтесь, задавайте вопросы и общайтесь со спикерами в дискуссионных зонах. Участие бесплатное, нужно только зарегистрироваться.