Представьте себе что все эти 3Гб это программа, которая пишет другую программу, которая пишет другую и так много "слоёв".
Причем все, или некоторые из этих слоёв могут присутствовать одновременно и влиять друг на друга.
И каждая такая программа ещё и саму себя может модифицировать.
И вот из всех этих слоёв и их взаимодействий, какой-то небольшой процент транслируется в юелковую биохимию и получается муха.
Это очень упрощённый и совершенно неправильный пример, но он даёт некоторое представление о сложности процесса.
Поиск причин появления того или иного синдрома, особенно в случае не острого проявления, это та ещё чёрная магия.
В моём случае периодическую сухость глаза пока победить не удалось, хотя причина вроде понятна, аллергический конъюнктивит, триггер не нашли.
Немного добавлю про мышечные зажимы.
Дисклеймер: я не врач и не физиотерапевт, прикладная биомеханика это моё давнишнее хобби.
По поводу профилактики мышечных зажимов, есть один "универсальный" но сложный в реальной жизни рецепт — иметь несколько разнообразных активных двигательных моделей.
Это работает когда нет явных патологий.
Причём модели должны быть действительно разными.
Возьмём сферического хабровчанина в вакууме (СХВ).
У СХВ будет только одна активная двигательная модель — условно "сидячий образ жизни европейца"
Характерные мышечные зажимы — укорочение мышц голени, напряжённая шея, слабые мышцы кора, и т. д.
Как СХВ может разнообразить свой набор двигательных моделей так чтобы это не требовало приложения силы воли.
Выбросит европейскую мебель и обставит свой дом в японском стиле: татами, футоны, столы высотой в 15 сантиметров.
Увеличится гибкость таза и голеностопа.
Купит велосипед и начнёт ездить на работу.
Улучшится гибкость и немного усилится кор.
Наконец начнет делать то о чем твердит его семейный врач, 10000 и более шагов каждый день.
Удлиннится "ахиллес" (на самом деле неправда, удлинняются мышцы голени). Накачаются мышцы стабилизаторы позвоночника.
Переедет в дом с дровяной печью и участком;
посадит сад, огород, клумбы с цветами; построит теплицу и курятник.
Тут кстати ничего сильно не улучшится, зато улучшения будут сразу во многих областях.
Начнет заниматься спортом (физкультурой). В зависимости от вида спорта улучшаться будет состояние разных групп связок и мышц.
Наиболее перспективными кажутся кроссфит, пауэрлифтинг/бодибилдинг, единоборства, скалолазание.
Начнет заниматься йогой, фельденкразом, контактной имповизацией, небоевыми видами ушу.
Ну тут понятно. Повышается осознание своего тела и прививается "правильный" стереотип движений.
Заведёт себе хобби связанное с физическим трудом. Разовьётся конкурирующий с основным стереотип двигательных шаблонов. Чем таких стереотипов больше тем лучше.
А ещё можно почитать "Анатомические поезда" Томаса Маерса и "Соматика" Томаса Ханна.
Тема соматики довольно спорная, как я понимаю.
Но примеры упражнений из этих книг вполне работают.
Для тех кто постоянно пользуется есть встроенные в маску/очки оправы под оптику.
Искать по словам RX goggles insert
В принципе там цены начинают покусывать но есть варианты.
Себе так баллистические нашел.
Если я правильно понял те статьи что читал, то поддержания для генетического разнообразия и стабильного роста популяции требуется что-то вроде 10К человек.
А на поддержание цивилизации на близком к текущему уровню 100-200К минимум.
И это в стабильных условиях, без катастроф.
Любой такой анализ это в той или иной степени спекуляция, о чем авторы обычно пишут.
Проблему с малой популяцией можно частично решить банком генов и активным применением генной инженерии, правда генной инженерии такого уровня у нас ещё нет.
Для решения проблемы с поддержанием и дальнейшим развитием уровня цивилизации требуется серьёзный технологический скачок.
Вариантов решения много. Некоторые даже не чрезмерно фантастические.
На мой взгляд наименее инвазивным может стать вариант с универсальным репликатором совмещённым с машиной Фон-Неймана.
А вот сколько требуется человек и какого рода потребуются технологии для поддержания и развития культурного и научного потенциала я не представляю.
Статей на тему я не находил.
Так что имея такого порядка технологии и решения проблем можно относительно безболезненно колонизировать вселенную.
Вот только как ставить эксперименты и делать симуляции всего этого?
На мой взгляд для описанной системы введение определения «символ» избыточно.
Достаточно было только действий.
Символы могут потребоваться если будет использоваться «отложенная память» например.
Других вариантов пока не придумал.
Добавь на тот же гитхаб ансибль который сможет настроить сервер. И пайплайн с деплоем настрой. При падении метеорита нужно будет приобрести новую VDS и сменить IP хоста в ансибле. После пуша поставится и настроится само.
Вот не знаю где их брать когда интервью делал то обычно мрак и ужас. Редко кто попадался с правильно настроенной головой.
Из личного опыта.
Мне повезло поддерживать R&D почти на всех работах и было просто любопытно что там разрабы пилят.
Пришлось освоить несколько языков на базовом уровне.
Тоесть программировать нормально я не умею, скилл и налёт часов нужен но в логике программы разберусь.
В предпоследней команде половина DevOps были выходцами из системщиков.
Так perl, python, Java вообще никого не пугали.
Не говоря уже о bash.
Хорошим тоном было найти место в коде, которое падало с ошибкой и если проблема маленькая и тривиальная то можно было к разрабу с пулл-реквестом прийти.
Но это редко было.
Разработчики в разы лучше ориентируются в коде.
В одном из мест где я работал кроме стенда, использовался изолированный кластер из прода.
Обычная схема была — в каждом гео сегменте несколько кластеров (3-6). И в сегменте по дизайну потеря одного из кластеров не приводит к насыщению больше 80% при пиковой нагрузке.
Это позволяло делать деплой кластера целиком, а также забирать один из них для стресс-тестов.
Для обстрела используется реплей запросов пользователей. Файлы по 5-10GB и з них случайно выбираются запросы.
Так что возможность делать стрессы относительно безболезненно можно учесть ещё при дизайне системы.
Поверьте, удалял, и восстанавливал.
В телефонах это немного не так как в Windows работает, даже в ext[2,3,4] не говоря уже об остальных файловых системаз в Linux восстановление становится нетривиальным.
В телефонах при подключении после шифрования и сброса к заводским настройкам восстановить данные достаточно сложно на мой взгляд.
Сисадмины как и программисты бывают разные.
Для неплохого сисадмина прочитать и понять, а иногда и поправить, код на большинстве мейнстрим языков — не проблема.
При переходе такого в DevOps акценты просто смещаются в сторону большего количества кода и меньшего ковыряния в операционке/железе.
Ключевые качества прагматичного DevOps-а:
Усидчивость — без вопростов
Внимание к деталям — без вопростов.
Но главное не зарываться и знать когда остановиться.
Чрезмерный перфекционизм не всегда полезен.
Аналитическое мышление — в формулировке в приведенной в статье — не соглашусь.
Противопоставлять примеры и тех. доки — зачем? У них цели разные.
Если есть готовое решение, и оно подходит, я не буду чего-то искать.
Если подходит не полностью — склонирую и допилю напильником.
Многозадачность — нафиг, нафиг, и ещё миллиард раз нафиг!
Так никакие проекты не будут продвигаться.
В нормальной команде будет on-call дежурство, так вот именно on-call будет чинить то, что сломалось.
В это время свободные от дежурства спокойно делают запланированные таски и о факапах узнают на post-mortem.
Если вам «повезло» быть единственным DevOps на проекте, то во первых — мои соболезнования, во вторых — заставляйте всех открывать тикеты, даже для misson critical, начинайте чинить сразу, но чтоб тикет был.
Ну или сами открывайте ставя нужного человека requester-ом
Знает свои инструменты — Это не только к DevOps относится.
Считает деньги и время — для меня большим открытием было то что я могу чего-то не делать потому, что суммарный выхлоп даст выгоды меньше чем моя зарплата за время разработки.
Или не заскриптовать таск, который хочется потому, что он прикольно на скрипт ляжет, а на самом деле не надо — он одноразовый (до сих пор иногда не могу удержаться и количество скриптов в ~/src/scratch растёт).
Если не относиться к профессии с прагматизмом и некоторой долей цинизма, выгоришь быстрее и эффекктивность будет страдать.
Мира и добра, кстати у нас есть печеньки.
Мой комментарий был к тому, что не зная ни Java не Kotlin и не собираясь в них углубляться в ближайшм будущем из статьи можно надёргать всякого полезного.
Кстати, если кто "внезапно" изберёт целевой платформой именно malbolge то с его или её мечтой мы скорее всего не познакомимся никогда.
Более мейнстримовые brainfuck или олдскульный intercal дадут хоть какой-то шанс.
Прекрасная статья.
Я не разрабатываю игр, плохо знаю java и вообще не знаю kotlin.
Но это никак не помешало мне получить огромное удовольствие от статьи, а также подчерпнуть из неё много полезного.
Статья хороший пример "промышленного" подхода к программированию.
Прекрасно видно что время затраченное на дизайн игры и рисование всех этих чудовищных диаграмм не прошло зря.
Всё это используется и в конце концов ускоряет и облегчает процесс написания игры.
Особое спасибо за приправленный юмором стиль.
Главное что мне в этих беспилотниках "нравится" это цена.
Они дешевле полноценного самолёта при этом дальность и боезапас можно иметь схожие.
Или иметь несколько разных поменьше под разные цели.
Делая их сверхманёвренными не надо следить за тем чтобы пилоты не померли от перегрузки.
А слабый ИИ позволит выживать в случае потери связи или неожиданного появления противника.
По летным характеристикам они наверное похожи на крылатые ракеты, которые в режиме огибания поверхности на сверхмалой высоте можно засечь толь когда они уже над тобой пролетели.
Короче лет через 15-20 живым пилотам придётся в небе туго.
Тут скорее то что он сумел создать такую ситуацию, что чтобы не происходило, он всегда оставался меньшим из зол.
Представьте себе что все эти 3Гб это программа, которая пишет другую программу, которая пишет другую и так много "слоёв".
Причем все, или некоторые из этих слоёв могут присутствовать одновременно и влиять друг на друга.
И каждая такая программа ещё и саму себя может модифицировать.
И вот из всех этих слоёв и их взаимодействий, какой-то небольшой процент транслируется в юелковую биохимию и получается муха.
Это очень упрощённый и совершенно неправильный пример, но он даёт некоторое представление о сложности процесса.
Поиск причин появления того или иного синдрома, особенно в случае не острого проявления, это та ещё чёрная магия.
В моём случае периодическую сухость глаза пока победить не удалось, хотя причина вроде понятна, аллергический конъюнктивит, триггер не нашли.
Немного добавлю про мышечные зажимы.
Дисклеймер: я не врач и не физиотерапевт, прикладная биомеханика это моё давнишнее хобби.
По поводу профилактики мышечных зажимов, есть один "универсальный" но сложный в реальной жизни рецепт — иметь несколько разнообразных активных двигательных моделей.
Это работает когда нет явных патологий.
Причём модели должны быть действительно разными.
Возьмём сферического хабровчанина в вакууме (СХВ).
У СХВ будет только одна активная двигательная модель — условно "сидячий образ жизни европейца"
Характерные мышечные зажимы — укорочение мышц голени, напряжённая шея, слабые мышцы кора, и т. д.
Как СХВ может разнообразить свой набор двигательных моделей так чтобы это не требовало приложения силы воли.
Выбросит европейскую мебель и обставит свой дом в японском стиле: татами, футоны, столы высотой в 15 сантиметров.
Увеличится гибкость таза и голеностопа.
Купит велосипед и начнёт ездить на работу.
Улучшится гибкость и немного усилится кор.
Наконец начнет делать то о чем твердит его семейный врач, 10000 и более шагов каждый день.
Удлиннится "ахиллес" (на самом деле неправда, удлинняются мышцы голени). Накачаются мышцы стабилизаторы позвоночника.
Переедет в дом с дровяной печью и участком;
посадит сад, огород, клумбы с цветами; построит теплицу и курятник.
Тут кстати ничего сильно не улучшится, зато улучшения будут сразу во многих областях.
Начнет заниматься спортом (физкультурой). В зависимости от вида спорта улучшаться будет состояние разных групп связок и мышц.
Наиболее перспективными кажутся кроссфит, пауэрлифтинг/бодибилдинг, единоборства, скалолазание.
Начнет заниматься йогой, фельденкразом, контактной имповизацией, небоевыми видами ушу.
Ну тут понятно. Повышается осознание своего тела и прививается "правильный" стереотип движений.
Заведёт себе хобби связанное с физическим трудом. Разовьётся конкурирующий с основным стереотип двигательных шаблонов. Чем таких стереотипов больше тем лучше.
Надеюсь общий подход понятен.
А ещё можно почитать "Анатомические поезда" Томаса Маерса и "Соматика" Томаса Ханна.
Тема соматики довольно спорная, как я понимаю.
Но примеры упражнений из этих книг вполне работают.
Для тех кто постоянно пользуется есть встроенные в маску/очки оправы под оптику.
Искать по словам RX goggles insert
В принципе там цены начинают покусывать но есть варианты.
Себе так баллистические нашел.
Вот сразу про форт подумал.
Когда на него смотрел почти достиг просветления.
Совсем немного не хватило.
Если я правильно понял те статьи что читал, то поддержания для генетического разнообразия и стабильного роста популяции требуется что-то вроде 10К человек.
А на поддержание цивилизации на близком к текущему уровню 100-200К минимум.
И это в стабильных условиях, без катастроф.
Любой такой анализ это в той или иной степени спекуляция, о чем авторы обычно пишут.
Проблему с малой популяцией можно частично решить банком генов и активным применением генной инженерии, правда генной инженерии такого уровня у нас ещё нет.
Для решения проблемы с поддержанием и дальнейшим развитием уровня цивилизации требуется серьёзный технологический скачок.
Вариантов решения много. Некоторые даже не чрезмерно фантастические.
На мой взгляд наименее инвазивным может стать вариант с универсальным репликатором совмещённым с машиной Фон-Неймана.
А вот сколько требуется человек и какого рода потребуются технологии для поддержания и развития культурного и научного потенциала я не представляю.
Статей на тему я не находил.
Так что имея такого порядка технологии и решения проблем можно относительно безболезненно колонизировать вселенную.
Вот только как ставить эксперименты и делать симуляции всего этого?
Вот меня грустит что нашел таймера для мобильного и/или десктопа позволяющего настроить производство кетчупа для целого офиса.
Достаточно было только действий.
Символы могут потребоваться если будет использоваться «отложенная память» например.
Других вариантов пока не придумал.
Добавь на тот же гитхаб ансибль который сможет настроить сервер. И пайплайн с деплоем настрой. При падении метеорита нужно будет приобрести новую VDS и сменить IP хоста в ансибле. После пуша поставится и настроится само.
Ага. Спасибо с этим не сталкивался.
Вот не знаю где их брать когда интервью делал то обычно мрак и ужас. Редко кто попадался с правильно настроенной головой.
Из личного опыта.
Мне повезло поддерживать R&D почти на всех работах и было просто любопытно что там разрабы пилят.
Пришлось освоить несколько языков на базовом уровне.
Тоесть программировать нормально я не умею, скилл и налёт часов нужен но в логике программы разберусь.
В предпоследней команде половина DevOps были выходцами из системщиков.
Так perl, python, Java вообще никого не пугали.
Не говоря уже о bash.
Хорошим тоном было найти место в коде, которое падало с ошибкой и если проблема маленькая и тривиальная то можно было к разрабу с пулл-реквестом прийти.
Но это редко было.
Разработчики в разы лучше ориентируются в коде.
В одном из мест где я работал кроме стенда, использовался изолированный кластер из прода.
Обычная схема была — в каждом гео сегменте несколько кластеров (3-6). И в сегменте по дизайну потеря одного из кластеров не приводит к насыщению больше 80% при пиковой нагрузке.
Это позволяло делать деплой кластера целиком, а также забирать один из них для стресс-тестов.
Для обстрела используется реплей запросов пользователей. Файлы по 5-10GB и з них случайно выбираются запросы.
Так что возможность делать стрессы относительно безболезненно можно учесть ещё при дизайне системы.
В телефонах это немного не так как в Windows работает, даже в ext[2,3,4] не говоря уже об остальных файловых системаз в Linux восстановление становится нетривиальным.
В телефонах при подключении после шифрования и сброса к заводским настройкам восстановить данные достаточно сложно на мой взгляд.
тёмнойобратной стороны.Сисадмины как и программисты бывают разные.
Для неплохого сисадмина прочитать и понять, а иногда и поправить, код на большинстве мейнстрим языков — не проблема.
При переходе такого в DevOps акценты просто смещаются в сторону большего количества кода и меньшего ковыряния в операционке/железе.
Ключевые качества прагматичного DevOps-а:
Но главное не зарываться и знать когда остановиться.
Чрезмерный перфекционизм не всегда полезен.
Противопоставлять примеры и тех. доки — зачем? У них цели разные.
Если есть готовое решение, и оно подходит, я не буду чего-то искать.
Если подходит не полностью — склонирую и допилю напильником.
Так никакие проекты не будут продвигаться.
В нормальной команде будет on-call дежурство, так вот именно on-call будет чинить то, что сломалось.
В это время свободные от дежурства спокойно делают запланированные таски и о факапах узнают на post-mortem.
Если вам «повезло» быть единственным DevOps на проекте, то во первых — мои соболезнования, во вторых — заставляйте всех открывать тикеты, даже для misson critical, начинайте чинить сразу, но чтоб тикет был.
Ну или сами открывайте ставя нужного человека requester-ом
Или не заскриптовать таск, который хочется потому, что он прикольно на скрипт ляжет, а на самом деле не надо — он одноразовый (до сих пор иногда не могу удержаться и количество скриптов в ~/src/scratch растёт).
Если не относиться к профессии с прагматизмом и некоторой долей цинизма, выгоришь быстрее и эффекктивность будет страдать.
Мира и добра, кстати у нас есть печеньки.
А вот зачем перезапись непонятно…
И для чего аккаунты в начале удалять...
Достаточно же просто два пункта сделать:
Может я чего-то не знаю
Мой комментарий был к тому, что не зная ни Java не Kotlin и не собираясь в них углубляться в ближайшм будущем из статьи можно надёргать всякого полезного.
Кстати, если кто "внезапно" изберёт целевой платформой именно malbolge то с его или её мечтой мы скорее всего не познакомимся никогда.
Более мейнстримовые brainfuck или олдскульный intercal дадут хоть какой-то шанс.
Прекрасная статья.
Я не разрабатываю игр, плохо знаю java и вообще не знаю kotlin.
Но это никак не помешало мне получить огромное удовольствие от статьи, а также подчерпнуть из неё много полезного.
Статья хороший пример "промышленного" подхода к программированию.
Прекрасно видно что время затраченное на дизайн игры и рисование всех этих чудовищных диаграмм не прошло зря.
Всё это используется и в конце концов ускоряет и облегчает процесс написания игры.
Особое спасибо за приправленный юмором стиль.
Главное что мне в этих беспилотниках "нравится" это цена.
Они дешевле полноценного самолёта при этом дальность и боезапас можно иметь схожие.
Или иметь несколько разных поменьше под разные цели.
Делая их сверхманёвренными не надо следить за тем чтобы пилоты не померли от перегрузки.
А слабый ИИ позволит выживать в случае потери связи или неожиданного появления противника.
По летным характеристикам они наверное похожи на крылатые ракеты, которые в режиме огибания поверхности на сверхмалой высоте можно засечь толь когда они уже над тобой пролетели.
Короче лет через 15-20 живым пилотам придётся в небе туго.
Я не из России. Но вот аппликацию скачать не получилось.
А вот админка открылась на ура.
Интересно чем был обусловлен выбор бренд технологий?