Можно, но какой в этом смысл, если локальный flake8 умеет все ровно тоже самое?
По моему опыту, единственное, ради чего стоит использовать сонар - так это для отображения покрытия кода тестами, если этого не умеет CI/CD. Например, GitlabCI умеет отображать его только в рамках MR, и только для измененных файлов, а если нужно просто посмотреть на текущее покрытие пофайлово, то увы.
Никогда не добавляйте код, меняющий настройки логирования, в ту часть, что выполняется при импорте. По крайней мере в библиотеках. Иначе потом будет подгорать в попытке понять, почему изменение настроек логгера перестает работать при появлении зависимости, в которой автор что-то натворил с логированием
Численные методы решения задачи N тел дают решения подходящей точности на тысячи и десятки тысяч лет, но на масштабах миллиардов лет все становится очень слабо предсказуемым. Особенно с учётом того, что сложность растет как квадрат от числа тел, а в начале формирования солнечной системы было не десяток планет, а десятки тысяч платенезималей, сливавшихся в более крупные или наоборот, дробившиеся на более мелкие.
Плюс крупные возмущения часто возникали как на заре формирования солнечной системы, так могли и после - мы только недавно узнали, что какие-то 70 тысяч лет назад звезда Шольца проходила где-то в районе облака Оорта, а это по космическим меркам это всего 5 минут назад.
Также, основная теория возникновения Луны - это столкновение прото-Земли с планетой размером с Марс. Этому есть множество подтверждений, от расчета орбиты луны на миллиарды лет назад, до близости состава обоих тел. Почему это может быть теорией, а столкновение других тел солнечной системы с другими протопланетами - это что-то притянутое за уши?
Ну так и на хосте, без контейнеров, можно запустить разные версии приложений с разными версиями либ под капотом. Но почему-то никто не называет это оверхедом, это просто следствие использования разных версий приложений одновременно. Если файлы разные, то кэшироваться они будут независимо друг от друга.
А вот если запускать несколько контейнеров из одного образа, где версии приложений/либ совпадают, то по сути все контейнеры ссылаются на один и тот же файл внутри образа, поэтому он загружается в память только один раз. Дисковый кэш находится уровнем ниже разделения на namespace, поэтому для него не важно, запустили приложение на хосте, в контейнере или в нескольких.
Если речь не идёт о Docker Desktop, а о нативных контейнерах (Linux), то оверхеда нет ни по памяти, ни по CPU, потому что это всего лишь механизм изоляции процессов на уровне ядра, а не виртуалка или эмуляция. А вот по сети оверхед есть
У меня пару раз было, что если заходить под VPN из, к примеру, Нидерландов, то на любое действие (лайк, открытие комментов и т.п.) отображалось сообщение, что в целях защиты сообщества (точную формулировку не помню) действие было заблокировано, и лайк/коммент просто не добавлялись. Но стоило зайти через VPN из США, то все прекрасно работало.
Также стоит включить на уровне настроек репозитория или push хуков проверку на то, что в репозиторий не залили секрет в открытом виде. Например, с помощью https://github.com/Yelp/detect-secrets
Новый 3-way merge интерфейс просто за гранью зла, а теперь ещё и дефолтный
Можно, но какой в этом смысл, если локальный flake8 умеет все ровно тоже самое?
По моему опыту, единственное, ради чего стоит использовать сонар - так это для отображения покрытия кода тестами, если этого не умеет CI/CD. Например, GitlabCI умеет отображать его только в рамках MR, и только для измененных файлов, а если нужно просто посмотреть на текущее покрытие пофайлово, то увы.
У сонара очень мало встроенных проверок для Python. Flake8 с плагинами позволяет найти гораздо больше code smells и ошибок
Никогда не добавляйте код, меняющий настройки логирования, в ту часть, что выполняется при импорте. По крайней мере в библиотеках. Иначе потом будет подгорать в попытке понять, почему изменение настроек логгера перестает работать при появлении зависимости, в которой автор что-то натворил с логированием
А что ещё остаётся?
Численные методы решения задачи N тел дают решения подходящей точности на тысячи и десятки тысяч лет, но на масштабах миллиардов лет все становится очень слабо предсказуемым. Особенно с учётом того, что сложность растет как квадрат от числа тел, а в начале формирования солнечной системы было не десяток планет, а десятки тысяч платенезималей, сливавшихся в более крупные или наоборот, дробившиеся на более мелкие.
Плюс крупные возмущения часто возникали как на заре формирования солнечной системы, так могли и после - мы только недавно узнали, что какие-то 70 тысяч лет назад звезда Шольца проходила где-то в районе облака Оорта, а это по космическим меркам это всего 5 минут назад.
Также, основная теория возникновения Луны - это столкновение прото-Земли с планетой размером с Марс. Этому есть множество подтверждений, от расчета орбиты луны на миллиарды лет назад, до близости состава обоих тел. Почему это может быть теорией, а столкновение других тел солнечной системы с другими протопланетами - это что-то притянутое за уши?
Для этого достаточно установить uBlacklist, и подписаться на список клонов StackOverflow
nodemon -L разве не это делает?
Как насчёт в примерах давать нормальные имена типам вместо _O, R, D?
Отвергая любую критику, вы выставляете себя далеко не в лучшем свете
Гугл же не мгновенно индексирует страницы
Это если ПО развернуто в единственном экземпляре. А у каждого заказчика собственная копия, то все становится не так радужно
Теорию Ксанфомалити мало кто воспринимает всерьез, и этому есть куча причин:
Разве скорость swap не зависит целиком и полностью от дисковой подсистемы?
Ну так и на хосте, без контейнеров, можно запустить разные версии приложений с разными версиями либ под капотом. Но почему-то никто не называет это оверхедом, это просто следствие использования разных версий приложений одновременно. Если файлы разные, то кэшироваться они будут независимо друг от друга.
А вот если запускать несколько контейнеров из одного образа, где версии приложений/либ совпадают, то по сути все контейнеры ссылаются на один и тот же файл внутри образа, поэтому он загружается в память только один раз. Дисковый кэш находится уровнем ниже разделения на namespace, поэтому для него не важно, запустили приложение на хосте, в контейнере или в нескольких.
Более подробно можно почитать здесь: https://biriukov.dev/docs/page-cache/7-how-much-memory-my-program-uses-or-the-tale-of-working-set-size/
И да, не userspace, а namespace. Причем это не один namespace на контейнер, а несколько - изолируется файловая система, процессы, сеть и т.п.:
https://habr.com/ru/company/ruvds/blog/592057/
https://habr.com/ru/company/ruvds/blog/593335/
Если речь не идёт о Docker Desktop, а о нативных контейнерах (Linux), то оверхеда нет ни по памяти, ни по CPU, потому что это всего лишь механизм изоляции процессов на уровне ядра, а не виртуалка или эмуляция. А вот по сети оверхед есть
А можно скрин? У меня в Play Market нигде нет трёх точек
У меня пару раз было, что если заходить под VPN из, к примеру, Нидерландов, то на любое действие (лайк, открытие комментов и т.п.) отображалось сообщение, что в целях защиты сообщества (точную формулировку не помню) действие было заблокировано, и лайк/коммент просто не добавлялись. Но стоило зайти через VPN из США, то все прекрасно работало.
И как абсолютно точно делать не надо
Также стоит включить на уровне настроек репозитория или push хуков проверку на то, что в репозиторий не залили секрет в открытом виде. Например, с помощью https://github.com/Yelp/detect-secrets
Я пробовал пользоваться им с пульта, не вышло. Но это было давно, может с тех пор стало лучше