Для старта покатит. Но в Maven Central публикация получается качественней как раз из-за того что Maven Central требует, чтобы были: - исходники - JavaDoc - подпись - данные о библиотеке и о разработчике в pom.xml
Ради интереса прогнал assembleDebug --scan на проекте сначала с использованием buildSrc, потом с included build. Проект небольшой, состоит из трёх модулей: app, ui-kit и ещё один модуль-библиотека.
Получил такие результаты:
# Замер без кэшей для сравнения (--rerun-tasks --no-build-cache)
No cache: 3m 9.846s, 0 avoided tasks
# buildSrc (127 tasks)
No changes: 2.185s, 89 avoided tasks
Dependency version (non-ABI change): 3m 4.044s, 14 avoided tasks
Add dependency (ABI change): 3m 21.682s, 14 avoided tasks
# included build (115 tasks)
No changes: 4.928s, with 87 avoided tasks
Dependency version (non-ABI change): 3m 44.495s, 13 avoided tasks
Add dependency (ABI change): 3m 38.804s, 13 avoided tasks
no changes — cначала прогонял несколько раз таск без каких либо изменений. Чтобы посмотреть сколько времени проект собирается когда есть все кэши. dependency version — менял версию зависимости. Пересобирал проект три раза, каждый раз менял версию у разных зависимостей. add dependency — добавлял новую константу с зависимостью. Прогонял сборку так же три раза, добавляя каждый раз новую константу.
По build-scan'ам не заметил особой разницы, разве что с buildSrc по какой-то причине чуть быстрее проходит "холостой" билд без внесения изменений (всегда около 2 сек, против 4-5 сек с included build) при том что тасок становится немного больше.
По времени есть небольшой разброс, но это не бенчмарк и замеров слишком мало поэтому скорее стоит ориентироваться на avoided tasks. При внесении любого изменения в buildSrc или included build все модули пересобирались.
Может неправильная методика замеров? Или стоит смотреть разницу на проектах с бОльшим количеством модулей?
Спасибо за статью!
Есть только одно дополнение про этот абзац.
любое изменение в buildSrc будет инвалидировать весь кэш сборки, что может быть несущественно для средних и маленьких проектов, но выливаться в серьезные проблемы для больших команд.
Чтобы поставить себе i3, нужно сначала обкатать шелл с плюшками? Мне это всё как-то странно.
Зависимость не прямая, но у меня примерно так и было
не очень понятно, зачем нужны плюшки. Больше похоже, что всё это чисто дело вкуса.
Чтобы знать об их существовании и использовать если понадобится :) Вы уже нашли комфортное для себя окружение, а плюшки могут быть полезны тем кто его только ищет.
bash и zsh отличные шеллы, но для статьи между вариантами "поставьте fish" и "поставьте zsh и oh-my-zsh, потом поставьте плагин zsh-autosuggestions, настройте вот это и вон то" я выбрал первый.
Fish можно попробовать "бесплатно" — не тратя время на настройку. Не зашло — выкинул, настроил другой шелл. Если не настраивал, то и выкидывать не жалко.
Главное, чтобы читатель увидел какие фичи вообще бывают и тогда он при желании сможет настроить их и для других оболочек.
Ничего не имею против zsh + ohmyzsh, но отвечу для тех кто тоже столкнётся с проблемой совместимость fish и bash.
Если использовать fish только как интерактивную оболочку, боль от отсутствия обратной совместимости минимизируется.
Иногда возникаю проблемы, что копипаста со stackowerflow или какой-то скрипт не работает (потому что в нём нет shebang), но тут есть варианты как это исправить.
Если команда простая, её можно адаптировать под синтаксис fish.
Всегда остаётся вариант выполнить команду через bash:
$ bash script.sh # Запускаем скрипт в bash
$ bash -c 'your command here' # А теперь команду
Если учитывать решения с плагинами, можно попробовать fish.reply
1) настройка «под себя» это первый гвоздь в гроб пользователя, это отчасти работает если кроме пары настроенных ПК вы ничем не пользуетесь, а когда у вас например 600 стандартных ПК, то у вас есть только та консоль, что уже установлена
Зависит от задачи. Не каждый работает с таким количеством компов, поэтому смею предположить, что для большинства пользователей настройка под себя приемлема.
2) если умирает какой-то проект на который вы подсели, то будет ломка, я не хочу ломки
Хороший аргумент. Можно снизить шансы, что это произойдёт если выбирать популярные опенсорсные утилиты. Вероятность, что они умрут меньше, потому что сообщество может взять поддержку утилиты на себя. С другой стороны проект может умереть и вы этого даже не заметите если утилита работала и работает исправно.
3) консоль требует очень-очень хорошей памяти, которой например у меня нет и я быстрее всё сделаю «стрелочками» в FAR/NC чем вспоминая команды и их формат в консоли.
Наверное я не до конца понял. Вы имеете в виду только работу с файлами в этом пункте? Если так, то это не противоречит статье. Возможно, стоит добавить ещё один спойлер с файловыми менеджерами :)
Согласен, будет неприятно, но лучше чем если человек вовсе не знаком с консолью.
Я хочу заинтересовать людей, которые не хотят пользоваться консолью из-за того, что им некомфортно. Тут ведь как. Вошёл во вкус и вот сам не заметил как поставил себе i3 и пишешь скрипт на каждый блок в статусной строке :)
Стоит еще упомянуть, что при асинхронном обновлении, адаптер не подписывается на изменения дочерних групп, а значит при вызове `notify*` из этих групп он не узнает о том, что что-то изменилось и как следствие, например, разворачивание/сворачивание `ExpandableGroup` не будет работать. Объясняется отсутствие подписки тем, что с ней были утечки памяти.
Кстати, Groupie, начиная с 2.2 поддерживает androidx (что сделало невозможным использование её на проектах, которые еще не настолько стильные и молодёжные) и предоставляет метод asyncUpdate для просчитывания DiffUtil в бэкграунде.
Для старта покатит. Но в Maven Central публикация получается качественней как раз из-за того что Maven Central требует, чтобы были:
- исходники
- JavaDoc
- подпись
- данные о библиотеке и о разработчике в pom.xml
Хотя сам процесс публикации не удобный, это да.
У других решений есть "фатальный недостаток" :)
Ради интереса прогнал
assembleDebug --scanна проекте сначала с использованием buildSrc, потом с included build. Проект небольшой, состоит из трёх модулей:app,ui-kitи ещё один модуль-библиотека.Получил такие результаты:
no changes — cначала прогонял несколько раз таск без каких либо изменений. Чтобы посмотреть сколько времени проект собирается когда есть все кэши.
dependency version — менял версию зависимости. Пересобирал проект три раза, каждый раз менял версию у разных зависимостей.
add dependency — добавлял новую константу с зависимостью. Прогонял сборку так же три раза, добавляя каждый раз новую константу.
По build-scan'ам не заметил особой разницы, разве что с buildSrc по какой-то причине чуть быстрее проходит "холостой" билд без внесения изменений (всегда около 2 сек, против 4-5 сек с included build) при том что тасок становится немного больше.
По времени есть небольшой разброс, но это не бенчмарк и замеров слишком мало поэтому скорее стоит ориентироваться на avoided tasks. При внесении любого изменения в buildSrc или included build все модули пересобирались.
Может неправильная методика замеров? Или стоит смотреть разницу на проектах с бОльшим количеством модулей?
Хм, и правда. Невнимательно прочитал change log, там действительно только про инвалидацию конфигурации, но не про кэши.
Спасибо за статью!
Есть только одно дополнение про этот абзац.
Эту проблему поправили в Gradle 6.8
Зависимость не прямая, но у меня примерно так и было
Чтобы знать об их существовании и использовать если понадобится :) Вы уже нашли комфортное для себя окружение, а плюшки могут быть полезны тем кто его только ищет.
bash и zsh отличные шеллы, но для статьи между вариантами "поставьте fish" и "поставьте zsh и oh-my-zsh, потом поставьте плагин zsh-autosuggestions, настройте вот это и вон то" я выбрал первый.
Fish можно попробовать "бесплатно" — не тратя время на настройку. Не зашло — выкинул, настроил другой шелл. Если не настраивал, то и выкидывать не жалко.
Главное, чтобы читатель увидел какие фичи вообще бывают и тогда он при желании сможет настроить их и для других оболочек.
Ничего не имею против zsh + ohmyzsh, но отвечу для тех кто тоже столкнётся с проблемой совместимость fish и bash.
Если использовать fish только как интерактивную оболочку, боль от отсутствия обратной совместимости минимизируется.
Иногда возникаю проблемы, что копипаста со stackowerflow или какой-то скрипт не работает (потому что в нём нет shebang), но тут есть варианты как это исправить.
Спасибо за комментарий. Попробую ответить.
Зависит от задачи. Не каждый работает с таким количеством компов, поэтому смею предположить, что для большинства пользователей настройка под себя приемлема.
Хороший аргумент. Можно снизить шансы, что это произойдёт если выбирать популярные опенсорсные утилиты. Вероятность, что они умрут меньше, потому что сообщество может взять поддержку утилиты на себя. С другой стороны проект может умереть и вы этого даже не заметите если утилита работала и работает исправно.
Наверное я не до конца понял. Вы имеете в виду только работу с файлами в этом пункте? Если так, то это не противоречит статье. Возможно, стоит добавить ещё один спойлер с файловыми менеджерами :)
Согласен, будет неприятно, но лучше чем если человек вовсе не знаком с консолью.
Я хочу заинтересовать людей, которые не хотят пользоваться консолью из-за того, что им некомфортно. Тут ведь как. Вошёл во вкус и вот сам не заметил как поставил себе i3 и пишешь скрипт на каждый блок в статусной строке :)
К сожалению, клавиша
zв top на macOS ничего не делает, да и в целом в этой версии топа довольно мало функцийА вот если linux, то действительно можно добавить цветов.
P.S Не знал, что для say можно ещё и голос выбрать, спасибо за ссылку
Кстати, Groupie, начиная с 2.2 поддерживает androidx (что сделало невозможным использование её на проектах, которые еще не настолько стильные и молодёжные) и предоставляет метод
asyncUpdateдля просчитывания DiffUtil в бэкграунде.