Вовсе нет, это просто деталь реализации, если бы в шарпе в ArrayPool.Shared все бакеты под все размеры прединициализировались, то память бы сжиралась еще при запуске приложения.
Попробуйте немного в разработку реального софта и выяснится,
Хех, вот вы попробовали, и что, у вас получается дебажить контейнеры в Райдере? Если у вас действительно есть какой-то опыт разработки реального софта, то уже давно бы поняли, что если при решении задачи возникает техническая проблема толщиной в несколько бетонных стен, то не стоит разбегаться и биться головой об них (даже если вы супермен), и по пробитии кричать во всю глотку "Я это сделал!"; а стоит просто спокойно обойти, ибо эстимейты уже проставлены. А за использование всего подряд, что есть под рукой обычно голосят еще зеленые в индустрии люди (мидл минус и ниже).
Отладка с аттачем к процессу это необходимость лишь тогда, когда реализованная фича достаточно сложна и тонка, что разраб, где-то что-то не формализовал и конкретно зафакапил; при этом совершенно ничего не логируется (что в наши дни моветон).
А зачем дебажить приложение запущенное в 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+ лет ходить учиться лишь бы учиться нету. Рабочая лошадка трудоспособного возраста сама должна ставить для себя задачи и цели (большие и малые) и ВЫДАВАТЬ результаты. Прямо как Джейсон Борн). Мое имхо.
Ну холивар о том что лучше - монолиты или микросервисы - и правда давно прошел. Однако эти три пункта о чем думает индустрия сейчас - модули/репы/артефакты - полный баян. Индустрия всегда думала о таких вещах, это просто дизайн и архитектура проектов и физическая/логическая организация кода. Все это всегда имело место с тех пор, как зародилась разработка ПО как индустрия.
Зачем быть коробочным программистом?
Не, проще зайти в музей в Лондоне и вылить супчик на творение бедняги Ван Гога.
Вовсе нет, это просто деталь реализации, если бы в шарпе в ArrayPool.Shared все бакеты под все размеры прединициализировались, то память бы сжиралась еще при запуске приложения.
Лучше уж и не писать совсем, чем писать такое. Новостей навалом, ищешь, переводишь и кидаешь эту какаху на хабр. Вот и вся ценность такого - ничего.
Это минус, дроны сразу поймут, куда лететь. )) А зачем проверять антидрон-системы в продакшене?
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
Ну холивар о том что лучше - монолиты или микросервисы - и правда давно прошел. Однако эти три пункта о чем думает индустрия сейчас - модули/репы/артефакты - полный баян. Индустрия всегда думала о таких вещах, это просто дизайн и архитектура проектов и физическая/логическая организация кода. Все это всегда имело место с тех пор, как зародилась разработка ПО как индустрия.
Сотрудники раз в году в отпуск за границу с флешками летать будут.