Коллега, даже если представить интуицию как прямой GET-запрос к "Облаку Вселенной", от троттлинга это не спасает. Вы только поймали поток, качаете гениальный инсайт на скорости 10 Гбит/с... и тут подходит менеджер: "А мы сегодня деплоимся?". Всё, Connection Reset. Пока вы заново сделаете TCP Handshake с астралом - полдня прошло. Нас убивает не сложность вычислений, а именно разрывы соединения.
Коллега, +1. Это уже не Chaos Engineering, а полноценный Red Teaming 24/7. У агентов типа Toddler есть sudo-права на уровне инстинктов. Любые софтовые методы они обходят через социальную инженерию за секунду. Работает только защита на Physical Layer (Уровень 1 OSI): шпингалет на двери и активный шумодав. Всё остальное как попытка писать код в горящей серверной. Держитесь!
Главное, начать строить дисциплину прямо сейчас, пока прёт. Потому что настраивать рутину когда "всплеск уйдет" это ад и х10 усилий (сам наступал). Проще "заскриптовать" привычки на этой инерции.
Вы по сути аппаратно отключили External Interrupts. В таком режиме КПД реально улетает в космос. Считайте просадку по деньгам временной инвестицией в R&D, сейчас оптимизируете ядро, а монетизация подтянется. А нет обратки? Часто бывает, что когда убираешь внешнего "погонщика", внутренний планировщик начинает сбоить и прокрастинировать. Или на своих проектах дофамин тащит сам?
Если переводить в глюкозу и АТФ, то немало. Мозг сервер дорогой, жрет 20% энергии тела даже в простое. Так что обсуждение это инвестиция, надеюсь ROI будет положительным)
Во, это ключевой момент. Если процесс (глажка) работает как медитация и разгрузка - значит, это уже не "рутина", а процедура восстановления, ресурс, такое трогать нельзя)
Но тут важный нюанс - мы хардкодим только то, что не приносит удовольствия. Если вам в кайф выбирать носки или готовить - супер, это ресурс, трогать нельзя. А вот если это нудная рутина, которая просто жрет батарейку, то её лучше в скрипт, чтобы силы остались на действительно важное (хоть на себя, хоть на семью), а не ушли в бытовой шум.
Так мы с Вами по сути об одном и том же) статья ровно об этом - качать только "техничку" (харды) тупиковый путь. Управление стрессом и работа с убеждениями - это и есть тот самый "код безопасности", без которого система падает в 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. Ремонт нынче дорогой
Коллега, даже если представить интуицию как прямой GET-запрос к "Облаку Вселенной", от троттлинга это не спасает. Вы только поймали поток, качаете гениальный инсайт на скорости 10 Гбит/с... и тут подходит менеджер: "А мы сегодня деплоимся?". Всё, Connection Reset. Пока вы заново сделаете TCP Handshake с астралом - полдня прошло. Нас убивает не сложность вычислений, а именно разрывы соединения.
Коллега, +1. Это уже не Chaos Engineering, а полноценный Red Teaming 24/7. У агентов типа Toddler есть sudo-права на уровне инстинктов. Любые софтовые методы они обходят через социальную инженерию за секунду. Работает только защита на Physical Layer (Уровень 1 OSI): шпингалет на двери и активный шумодав. Всё остальное как попытка писать код в горящей серверной. Держитесь!
Главное, начать строить дисциплину прямо сейчас, пока прёт. Потому что настраивать рутину когда "всплеск уйдет" это ад и х10 усилий (сам наступал). Проще "заскриптовать" привычки на этой инерции.
Вы по сути аппаратно отключили
External Interrupts. В таком режиме КПД реально улетает в космос. Считайте просадку по деньгам временной инвестицией в R&D, сейчас оптимизируете ядро, а монетизация подтянется. А нет обратки? Часто бывает, что когда убираешь внешнего "погонщика", внутренний планировщик начинает сбоить и прокрастинировать. Или на своих проектах дофамин тащит сам?Если переводить в глюкозу и АТФ, то немало. Мозг сервер дорогой, жрет 20% энергии тела даже в простое. Так что обсуждение это инвестиция, надеюсь ROI будет положительным)
Во, это ключевой момент. Если процесс (глажка) работает как медитация и разгрузка - значит, это уже не "рутина", а процедура восстановления, ресурс, такое трогать нельзя)
Нейминг переменных - это святое))
Но тут важный нюанс - мы хардкодим только то, что не приносит удовольствия. Если вам в кайф выбирать носки или готовить - супер, это ресурс, трогать нельзя. А вот если это нудная рутина, которая просто жрет батарейку, то её лучше в скрипт, чтобы силы остались на действительно важное (хоть на себя, хоть на семью), а не ушли в бытовой шум.
Так мы с Вами по сути об одном и том же) статья ровно об этом - качать только "техничку" (харды) тупиковый путь. Управление стрессом и работа с убеждениями - это и есть тот самый "код безопасности", без которого система падает в 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. Ремонт нынче дорогой