Попробуйте немного в разработку реального софта и выяснится,
Хех, вот вы попробовали, и что, у вас получается дебажить контейнеры в Райдере? Если у вас действительно есть какой-то опыт разработки реального софта, то уже давно бы поняли, что если при решении задачи возникает техническая проблема толщиной в несколько бетонных стен, то не стоит разбегаться и биться головой об них (даже если вы супермен), и по пробитии кричать во всю глотку "Я это сделал!"; а стоит просто спокойно обойти, ибо эстимейты уже проставлены. А за использование всего подряд, что есть под рукой обычно голосят еще зеленые в индустрии люди (мидл минус и ниже).
Отладка с аттачем к процессу это необходимость лишь тогда, когда реализованная фича достаточно сложна и тонка, что разраб, где-то что-то не формализовал и конкретно зафакапил; при этом совершенно ничего не логируется (что в наши дни моветон).
А зачем дебажить приложение запущенное в Docker-е? Нельзя запустить локально инстанс и натравить конфу остальных контейнеров на него? Конечно если пытаться впихать невпихуемое, то будут сложности. Можно сидеть на табуретке с 4-мя ножками, одна из которых сломана, и вместо сломанной подставить собственную коленку. Однако будет очень неудобно.
Эту локаль можно поставить позже, ставим en_US UTF8. Дальше уже после установки заходим в файлик с локалями, раскомментируем правильные строки с ru_RU и вызываем locale-gen. Не всегда проблему надо решать сразу в момент установки.
Видимо, имелась в виду способность ThreadPool-а планировать свою загрузку, работа этого самого HillClimbing-а. У Дэвида Фаулера есть гайдлайн по async/await, где упоминается, что запускать таску с опцией TaskCreationOptions.LongRunning как бы бессмысленно, посколько при первом неблокирующем ожидании IO-операции этот самый поток, на создание которого было потрачено относительно много усилий, будет отпущен.
В итоге в любом случае приходим к тому, что любой современный асинхронный код - это замысловатое переплетение коротких (и длинных) CPU-bound с IO-bound операциями. Что как бы отлично ложится на работу HillClimbing-а.
Выдавать сразу качественную кодовую базу, минимизируя объем работы для QA, не? Представьте, как классно будет если ревьюверами будут условные 5 педантичных senior-маньяков с чувством перфекционизма и большим опытом чтения кода.
Если вы уже в IT и получили системное мышление, (или тем более вышку в самом начале ИТ-шную получили), то смысла в 40+ лет ходить учиться лишь бы учиться нету. Рабочая лошадка трудоспособного возраста сама должна ставить для себя задачи и цели (большие и малые) и ВЫДАВАТЬ результаты. Прямо как Джейсон Борн). Мое имхо.
Ну холивар о том что лучше - монолиты или микросервисы - и правда давно прошел. Однако эти три пункта о чем думает индустрия сейчас - модули/репы/артефакты - полный баян. Индустрия всегда думала о таких вещах, это просто дизайн и архитектура проектов и физическая/логическая организация кода. Все это всегда имело место с тех пор, как зародилась разработка ПО как индустрия.
Да, тоже на языке крутилось. Запуск внешнего процесса конечно можно назвать интеграцией, однако подход, как говорится "в лоб", часто является самым неэффективным из всех возможных.
Не занимайтесь ерундой, занимайтесь разработкой ПО.
Вы не понимаете, это все часть разработки ПО. Не недооценивайте системы контроля версий в индустрии, где появились микросервисы и микрофронтенды, где есть спеки OpenAPI, OpenTracing, OpenTelemetry и прочее.
Это минус, дроны сразу поймут, куда лететь. )) А зачем проверять антидрон-системы в продакшене?
Security through obscurity.
Хех, вот вы попробовали, и что, у вас получается дебажить контейнеры в Райдере? Если у вас действительно есть какой-то опыт разработки реального софта, то уже давно бы поняли, что если при решении задачи возникает техническая проблема толщиной в несколько бетонных стен, то не стоит разбегаться и биться головой об них (даже если вы супермен), и по пробитии кричать во всю глотку "Я это сделал!"; а стоит просто спокойно обойти, ибо эстимейты уже проставлены. А за использование всего подряд, что есть под рукой обычно голосят еще зеленые в индустрии люди (мидл минус и ниже).
Отладка с аттачем к процессу это необходимость лишь тогда, когда реализованная фича достаточно сложна и тонка, что разраб, где-то что-то не формализовал и конкретно зафакапил; при этом совершенно ничего не логируется (что в наши дни моветон).
А зачем дебажить приложение запущенное в Docker-е? Нельзя запустить локально инстанс и натравить конфу остальных контейнеров на него? Конечно если пытаться впихать невпихуемое, то будут сложности.
Можно сидеть на табуретке с 4-мя ножками, одна из которых сломана, и вместо сломанной подставить собственную коленку.
Однако будет очень неудобно.
Gentoo users don't brag - they have no time for that :)
Gentoo users don't brag - they have no time for that :)
Эту локаль можно поставить позже, ставим en_US UTF8. Дальше уже после установки заходим в файлик с локалями, раскомментируем правильные строки с ru_RU и вызываем locale-gen. Не всегда проблему надо решать сразу в момент установки.
Для этого надо выйти на улочку, повисеть на турнике минут так тридцать (чтобы выпрямить руки) и обратно зайти - все начнет поддерживаться.
Having python-based archinstall script builtin with live cd
Видимо, имелась в виду способность ThreadPool-а планировать свою загрузку, работа этого самого HillClimbing-а. У Дэвида Фаулера есть гайдлайн по async/await, где упоминается, что запускать таску с опцией TaskCreationOptions.LongRunning как бы бессмысленно, посколько при первом неблокирующем ожидании IO-операции этот самый поток, на создание которого было потрачено относительно много усилий, будет отпущен.
В итоге в любом случае приходим к тому, что любой современный асинхронный код - это замысловатое переплетение коротких (и длинных) CPU-bound с IO-bound операциями. Что как бы отлично ложится на работу HillClimbing-а.
Выдавать сразу качественную кодовую базу, минимизируя объем работы для QA, не? Представьте, как классно будет если ревьюверами будут условные 5 педантичных senior-маньяков с чувством перфекционизма и большим опытом чтения кода.
Даа, полностью поддерживаю, во взрослом возрасте вполне себе можно самостоятельно обучаться.
Если вы уже в IT и получили системное мышление, (или тем более вышку в самом начале ИТ-шную получили), то смысла в 40+ лет ходить учиться лишь бы учиться нету. Рабочая лошадка трудоспособного возраста сама должна ставить для себя задачи и цели (большие и малые) и ВЫДАВАТЬ результаты. Прямо как Джейсон Борн). Мое имхо.
Хех, а я увидел воду. Как говорится, красота в глазах смотрящего.
removed
Ну холивар о том что лучше - монолиты или микросервисы - и правда давно прошел. Однако эти три пункта о чем думает индустрия сейчас - модули/репы/артефакты - полный баян. Индустрия всегда думала о таких вещах, это просто дизайн и архитектура проектов и физическая/логическая организация кода. Все это всегда имело место с тех пор, как зародилась разработка ПО как индустрия.
Сотрудники раз в году в отпуск за границу с флешками летать будут.
Да, тоже на языке крутилось. Запуск внешнего процесса конечно можно назвать интеграцией, однако подход, как говорится "в лоб", часто является самым неэффективным из всех возможных.
Вы не понимаете, это все часть разработки ПО. Не недооценивайте системы контроля версий в индустрии, где появились микросервисы и микрофронтенды, где есть спеки OpenAPI, OpenTracing, OpenTelemetry и прочее.
POV:
Ultimate guide: на гит уделяйте 12 дней.
Me: изучаю git c 2017 года и до сих пор не все знаю.
Неплохо, но в Германии, говорят, скучно; если ехать, то только с женой и детьми.