Так мы с Вами по сути об одном и том же) статья ровно об этом - качать только "техничку" (харды) тупиковый путь. Управление стрессом и работа с убеждениями - это и есть тот самый "код безопасности", без которого система падает в BSOD под нагрузкой. Хард-скилл просто интерфейс, а деньги держит бэкенд (психика).
Спасибо, вы очень точно сформулировали, статья именно про принципы проектирования системы, а не жесткий мануал. И ваш кейс с геймдевом - отличный пример, когда убираешь мусор (нелюбимые задачи, чужие установки..), сопротивление в цепи падает, а пропускная способность растет. Рад, что отозвалось)
Есть еще модель (по сути, закон сохранения энергии в психологии). Система всегда стремится к гомеостазу. Создал избыточный потенциал - прилетит "минус" для компенсации. Ну и личные конфиги решают. Вопрос внутренних прав доступа: разрешает ли вообще система себе быть богатым? Если в ядре прописано "деньги = опасность", то любой успех будет саботироваться изнутри. Причем успехи мозг часто считает "глюком" и забывает, а вот неудачи - старательно логирует, создавая устойчивый шаблон.
История - готовый сценарий для кино. Мое уважение.
Ваша биография через призму кода из статьи. Вы считаете, что "Злой рок" лишил вас сверхдоходов. Я вижу, что это идеально отработал алгоритм защиты, описанный в блоке class LimbicSystem. Давайте подставим ваши данные (90-е годы, развал страны) в переменные из статьи:
new_income (Сверхдоходы в 90-е) = Колоссальный Риск. В то время большие деньги шли в комплекте с реальной угрозой жизни (бандитизм, тюрьма).
Условие выполнилось (риск смерти > допустимого). И Система запустила метод: self.trigger_defense_mechanism(method="COLLAPSE_SCENARIO")
Возможно, система просто спасает предохранители от выгорания. Она держит вас в бедности (относительной), чтобы вы остались живы
В вашем случае фраза "чтобы вы остались живы" - не метафора, а буквальный факт. Ваша система выбрала Uptime (выживание и стабильность на 30 лет), пожертвовав пиковой мощностью. Ваша система (и ваш код!) пережила три государства. Ваша личная архитектура (МГУ + опыт) оказалась прочнее, чем архитектура стран, в которых вы жили. Это фантастический Uptime.
Вы очень точно сформулировали про "неочевидную ценность". Деньги платят именно за управление рисками, а это чистая нагрузка на нервную систему. По поводу "опасного упрощения" - принимается, но в инженерии это называется Изоляцией Переменных. Конечно, есть слой Environment (социальные лифты, удача, власть). Но мы зачастую не можем их пофиксить или переписать. Статья фокусируется на слое Hardware (внутренний ресурс). Потому что если "железо" не тянет нагрузку, то даже идеальный социальный лифт привезет не к успеху, а в кардиологию. Мы дебажим то, до чего можем дотянуться.
Это же чистый Chaos Engineering в быту! :) Вызов функции get_random_outfit() действительно потребляет минимум CPU. Если прод (окружающие) не падает при виде результата - значит, алгоритм валидный. Смело!
Аналогия тут про скрытую нагрузку. Я видел достаточно специалистов, которые получали желанный оффер x2 (вместе с новой должностью), а через полгода "отъезжали" с выгоранием или неврозом. Они получили деньги, но в комплекте шел вольтаж ответственности, который их текущая архитектура просто не вытянула. Это и называется - придавило нагрузкой.
Про ежиков и птиц - метафора огонь. Нюанс: процесс Update запускает сам еж. Снаружи такие патчи не встают, будет конфликт версий.
Краткий гайд по миграции (Migration Guide): 1. Синхронизация понятий. А что для меня "птица"? Это про свободу или про ответственность махать крыльями, когда нет сил? Готова ли система к такому Uptime? 2. Валидация Цели. Если цель ловить жучков и мышей в траве, крылья - это лишний вес. Архитектура должна биться с задачей. 3. Deprecation (снос легаси). Самое страшное. Иголки и рефлекс "свернуться в клубок" - это защитный контур. Чтобы взлететь, его придется выпилить из ядра. Система не тянет Dual Boot. Придется выбирать, какую версию себя стирать без бэкапа. 4. Настройка Среды. Очень важно залезть в кластер к птицам. Не просто смотреть, а парсить их протоколы: как они видят мир, когда он под ними, а не вокруг. Без валидной среды код не скомпилируется. 5. Выбор Модели. Абстрактная "птица" - это плохой класс. Нужно выбрать конкретную реализацию. Орел? Альбатрос? Главное, не пингвин - технически тоже птица, но с полетами там баг на проде :)
Про шаблон - точно подмечено. Я бы даже докрутил: пока система в "спящем режиме" (неосознанность), она тупо исполняет прописанный скрипт Персонажа. В этом состоянии всё реально детерминировано: и реакции, и доход, и тот самый потолок. Мы просто отыгрываем алгоритм. А Выход (ну, для чего собственно Матрица и была), по сути, момент получения Root-прав. Применительно к статье: мы упираемся в потолок, потому что пытаемся хакнуть реальность, оставаясь внутри старого скрипта (identity.yaml). А чтобы кратно расширить ёмкость, придется выйти из контекста Персонажа и начать переписывать архитектуру уже с позиции Администратора.
Пример с "Почтальоном" в яблочко! Но он как раз подтверждает теорию. Тот парень (генерал) изначально был с мощным потенциалом, просто работал на низкой нагрузке. Упали ограничения и его масштаб развернулся. Я лишь о том, что если внутренний генератор выдает 12 Вольт, то даже в идеальном постапокалипсисе Вожаком не станешь. Апгрейд самой системы всё-таки первичен.
Можно. Но это работа на износ оборудования. Если "железо" казенное, то не жалко. А если свое, родное - я бы поостерегся гонять его в красной зоне 24/7. Ремонт нынче дорогой
Отличная мысль. Я бы тогда рассмотрел интуицию как встроенную систему обнаружения аномалий. Наше подсознание обрабатывает миллионы сигналов в фоне и замечает "перегрев" или "мусорный трафик" раньше, чем это доходит до сознания (логики). Проблема в том, что мы часто отправляем эти алерты в спам, потому что "надо работать". А "трансформаторы" и "мини-блокировки" - это наши осознанные привычки и границы. И да, к сожалению, по дефолту они не предустановлены, их приходится кодить и деплоить вручную.
Ценю ваш сарказм :) Но тут ошибка в архитектуре. Если подать на бытовую розетку (уборщицу) напряжение от промышленной линии (директора), то будет пожар. Даже если мы демократично решим, что они равны. Статья не про то, что "не надо платить". Она про то, что сначала нужно менять проводку, а уже потом повышать вольтаж.
Так это оно и есть - ручное управление нагрузкой. Человек понял, что цена успеха (перегрев) выше, чем профит от денег, и перешел в энергосберегающий режим. Главное, чтобы этот выбор был осознанным, а не вынужденным из-за поломки.
Хорошая попытка записать меня в HR, но нет :) Я обеими руками "за" рост зарплат. Но статья про физиологию. Просто напоминаю, что вместе с чеком часто прилетает нагрузка, к которой психика не всегда готова. Хочется ведь быть богатым и здоровым, а не богатым и с нервным тиком.
Насчет теории - согласен, там споры идут. Но на практике усталость от бесконечного выбора чувствуется вполне реально, как это ни назови. Терапия - это для Critical Error, кто ж спорит. А вот униформа просто базовая гигиена, чтобы не тратить "мыслетопливо" на бытовуху. Не стоит вызывать реанимацию, чтобы выбрать цвет брюк :-)
Вот-вот НИОКР))) Если шопинг не приносит удовольствия, а надежный вендор и стабильная сборка найдены, зачем тратить ресурсы на новые тесты - просто обновляю версии
Так мы с Вами по сути об одном и том же) статья ровно об этом - качать только "техничку" (харды) тупиковый путь. Управление стрессом и работа с убеждениями - это и есть тот самый "код безопасности", без которого система падает в BSOD под нагрузкой. Хард-скилл просто интерфейс, а деньги держит бэкенд (психика).
Спасибо, вы очень точно сформулировали, статья именно про принципы проектирования системы, а не жесткий мануал. И ваш кейс с геймдевом - отличный пример, когда убираешь мусор (нелюбимые задачи, чужие установки..), сопротивление в цепи падает, а пропускная способность растет. Рад, что отозвалось)
Есть еще модель (по сути, закон сохранения энергии в психологии). Система всегда стремится к гомеостазу. Создал избыточный потенциал - прилетит "минус" для компенсации. Ну и личные конфиги решают. Вопрос внутренних прав доступа: разрешает ли вообще система себе быть богатым? Если в ядре прописано "деньги = опасность", то любой успех будет саботироваться изнутри. Причем успехи мозг часто считает "глюком" и забывает, а вот неудачи - старательно логирует, создавая устойчивый шаблон.
Вот это и есть тот самый хардкод в действии) кнопка "повторить" - лучшая фича эвер, ноль затрат цпу, а результат гарантирован
История - готовый сценарий для кино. Мое уважение.
Ваша биография через призму кода из статьи. Вы считаете, что "Злой рок" лишил вас сверхдоходов. Я вижу, что это идеально отработал алгоритм защиты, описанный в блоке
class LimbicSystem. Давайте подставим ваши данные (90-е годы, развал страны) в переменные из статьи:new_income(Сверхдоходы в 90-е) = Колоссальный Риск. В то время большие деньги шли в комплекте с реальной угрозой жизни (бандитизм, тюрьма).added_stress(Напряжение) = CRITICAL.Ваш внутренний DevOps (Мозг) просчитал уравнение:
if (current_load + added_stress) > self.CRITICAL_TEMP:Условие выполнилось (риск смерти > допустимого). И Система запустила метод:
self.trigger_defense_mechanism(method="COLLAPSE_SCENARIO")В вашем случае фраза "чтобы вы остались живы" - не метафора, а буквальный факт. Ваша система выбрала Uptime (выживание и стабильность на 30 лет), пожертвовав пиковой мощностью. Ваша система (и ваш код!) пережила три государства. Ваша личная архитектура (МГУ + опыт) оказалась прочнее, чем архитектура стран, в которых вы жили. Это фантастический Uptime.
Вы очень точно сформулировали про "неочевидную ценность". Деньги платят именно за управление рисками, а это чистая нагрузка на нервную систему. По поводу "опасного упрощения" - принимается, но в инженерии это называется Изоляцией Переменных. Конечно, есть слой
Environment(социальные лифты, удача, власть). Но мы зачастую не можем их пофиксить или переписать. Статья фокусируется на слоеHardware(внутренний ресурс). Потому что если "железо" не тянет нагрузку, то даже идеальный социальный лифт привезет не к успеху, а в кардиологию. Мы дебажим то, до чего можем дотянуться.Это же чистый Chaos Engineering в быту! :) Вызов функции
get_random_outfit()действительно потребляет минимум CPU. Если прод (окружающие) не падает при виде результата - значит, алгоритм валидный. Смело!Аналогия тут про скрытую нагрузку. Я видел достаточно специалистов, которые получали желанный оффер
x2(вместе с новой должностью), а через полгода "отъезжали" с выгоранием или неврозом. Они получили деньги, но в комплекте шел вольтаж ответственности, который их текущая архитектура просто не вытянула. Это и называется - придавило нагрузкой.Про ежиков и птиц - метафора огонь. Нюанс: процесс
Updateзапускает сам еж. Снаружи такие патчи не встают, будет конфликт версий.Краткий гайд по миграции (Migration Guide): 1. Синхронизация понятий. А что для меня "птица"? Это про свободу или про ответственность махать крыльями, когда нет сил? Готова ли система к такому
Uptime? 2. Валидация Цели. Если цель ловить жучков и мышей в траве, крылья - это лишний вес. Архитектура должна биться с задачей. 3. Deprecation (снос легаси). Самое страшное. Иголки и рефлекс "свернуться в клубок" - это защитный контур. Чтобы взлететь, его придется выпилить из ядра. Система не тянетDual Boot. Придется выбирать, какую версию себя стирать без бэкапа. 4. Настройка Среды. Очень важно залезть в кластер к птицам. Не просто смотреть, а парсить их протоколы: как они видят мир, когда он под ними, а не вокруг. Без валидной среды код не скомпилируется. 5. Выбор Модели. Абстрактная "птица" - это плохой класс. Нужно выбрать конкретную реализацию. Орел? Альбатрос? Главное, не пингвин - технически тоже птица, но с полетами там баг на проде :)Про шаблон - точно подмечено. Я бы даже докрутил: пока система в "спящем режиме" (неосознанность), она тупо исполняет прописанный скрипт Персонажа. В этом состоянии всё реально детерминировано: и реакции, и доход, и тот самый потолок. Мы просто отыгрываем алгоритм. А Выход (ну, для чего собственно Матрица и была), по сути, момент получения Root-прав. Применительно к статье: мы упираемся в потолок, потому что пытаемся хакнуть реальность, оставаясь внутри старого скрипта (
identity.yaml). А чтобы кратно расширить ёмкость, придется выйти из контекста Персонажа и начать переписывать архитектуру уже с позиции Администратора.Абсолютно. Модель - способ взаимодействовать с хаосом и не сойти с ума. Если обрабатывать каждый сигнал "как есть", никакого CPU не хватит
Пример с "Почтальоном" в яблочко! Но он как раз подтверждает теорию. Тот парень (генерал) изначально был с мощным потенциалом, просто работал на низкой нагрузке. Упали ограничения и его масштаб развернулся. Я лишь о том, что если внутренний генератор выдает 12 Вольт, то даже в идеальном постапокалипсисе Вожаком не станешь. Апгрейд самой системы всё-таки первичен.
Можно. Но это работа на износ оборудования. Если "железо" казенное, то не жалко. А если свое, родное - я бы поостерегся гонять его в красной зоне 24/7. Ремонт нынче дорогой
Коль перегрев грозит спалить твой чип, и кулер в голове давно охрип, не бойся, друг, что крыша потекла - то вентиляция для мощного ума!
Отличная мысль. Я бы тогда рассмотрел интуицию как встроенную систему обнаружения аномалий. Наше подсознание обрабатывает миллионы сигналов в фоне и замечает "перегрев" или "мусорный трафик" раньше, чем это доходит до сознания (логики). Проблема в том, что мы часто отправляем эти алерты в спам, потому что "надо работать". А "трансформаторы" и "мини-блокировки" - это наши осознанные привычки и границы. И да, к сожалению, по дефолту они не предустановлены, их приходится кодить и деплоить вручную.
Ценю ваш сарказм :) Но тут ошибка в архитектуре. Если подать на бытовую розетку (уборщицу) напряжение от промышленной линии (директора), то будет пожар. Даже если мы демократично решим, что они равны. Статья не про то, что "не надо платить". Она про то, что сначала нужно менять проводку, а уже потом повышать вольтаж.
Так это оно и есть - ручное управление нагрузкой. Человек понял, что цена успеха (перегрев) выше, чем профит от денег, и перешел в энергосберегающий режим. Главное, чтобы этот выбор был осознанным, а не вынужденным из-за поломки.
Хорошая попытка записать меня в HR, но нет :) Я обеими руками "за" рост зарплат. Но статья про физиологию. Просто напоминаю, что вместе с чеком часто прилетает нагрузка, к которой психика не всегда готова. Хочется ведь быть богатым и здоровым, а не богатым и с нервным тиком.
Насчет теории - согласен, там споры идут. Но на практике усталость от бесконечного выбора чувствуется вполне реально, как это ни назови. Терапия - это для
Critical Error, кто ж спорит. А вот униформа просто базовая гигиена, чтобы не тратить "мыслетопливо" на бытовуху. Не стоит вызывать реанимацию, чтобы выбрать цвет брюк :-)Вот-вот НИОКР))) Если шопинг не приносит удовольствия, а надежный вендор и стабильная сборка найдены, зачем тратить ресурсы на новые тесты - просто обновляю версии