Спасибо за статью. Позволю себе несколько комментариев на ваши вопросы.
‑как сделать возвращение к собственному и чужому опыту максимально быстрым? Как вернуться не к знанию, а к своему состоянию на момент понимания?
Для эффективного сохранения опыта нужны эмоциональные “якоря”. Сделал что-то в течение дня, получил какой-то результат, осознал его важность и закрепил верность движения к следующему этапу. Как через внутреннюю авторефлексию, либо через внешнюю оценку близких людей, либо иными способами, немножко порадовался результату. Наиболее мощные эмоциональные якоря формируются у детей, потому именно в детстве быстрее всего расширяются когнитивные способности. С возрастом эта эффективность падает на базовом уровне, но её можно поддерживать также через авторефлексию, самоубеждение в важности и правильности результата. Этому активно помогает накопленный ранее опыт, схожие ситуации, схожие пути, схожие инструменты. Уже интуиция помогает понимать, что результат верный, либо движение в нужном направлении. Кстати, тот самый совет разбивания пути к сложной цели на этапы с обязательной фиксацией промежуточных целей - это эффективный механизм создания якорей, которые в ближайшем времени можно будет быстро вспомнить, восстановить их контекст во всех смыслах, продолжить от этого решение новых схожих задач.
Пока не придумали машину времени, а только лишь спорят, чья квантовая теория толще и ближе к гравитации - до тех пор полного восстановления/отката на предыдущее состояние сделать будет невозможным. Стоит подумать, а так ли важен подобный переход, требуется ли постоянно вся его глубина контекста, а был ли он в реальности качественно сохранён и не закрепились ли ранее ошибки в опыте? Если новый опыт начинает активно противоречить хорошо сохранённому старому, всё менее кореллирующему с реальностью - то так ли было важно его настолько точно сохранять, жертвуя своей эффективностью памяти? Были ли качественно потрачены ресурсы на закрепление такой глубины опыта? Думаю, что ответ уже не настолько очевиден. Потому, для сохранения универсально эффективной работы мозга - ему необходимо чем-то жертвовать, что не было достаточно эмоционально закреплено опытом, устарело, начало активно конфликтовать с новым опытом.
Забывать что-то это нормально. В мозговом “порте” также очевидно ограниченный объём мест, куда можно сбросить “якорь” для долгосрочной стоянки. Рано или поздно, якорь оторвётся ото дна, либо его принудительно затопят, заменив чем-то новым.
‑с какими «налогами на внимание» сталкивается человек, когда нужно решить какую‑то нешаблонную задачу?
Время - это и есть такой налог на внимание. Мы пока живём конечное время, довольно много из которого тратим на восхождение в гору знаний/опыта, а потом ещё и на спуск. Этот налог платится дважды: сначала на получение и закрепление знаний, сразу и много, а также всё остальное время жизни хранилища такого знания (мозг человека), по чуть-чуть, но многократно больше изначальных затрат, до момента полной утери.
Внимание жёстко связано со степенью мотивации получения ожидаемого результата: чем важнее он вам, тем выше может формироваться качество внимания к процессу получения результата. Нужно что-то запомнить - отыщи свой мотиватор получения результата. Желательно, не в форме еды, хотя это всё ещё работает, даже у людей. Лучше всего выстроить систему подкрепления, опять же, эмоционального. Получил результат - расскажи другим. Брось “якорь”. Получил негативный опыт - всё равно, движение к цели/результату от обратного также зачастую возможно. Если можешь в беседу с самим собой, авторефлексию, самоанализ - можно и так, но это инструмент, в основном, чуть слабее по эффективности, чем эмоции. Сложно сформировать всю картину в голове - разбей путь на эпизоды, промежуточные цели, обязательно с конкретным результатом. Заодно это будет проверкой, а тем ли путём вообще идёшь. Подбери свой наиболее эффективный инструмент микромотиваций, потом более долгосрочной - и работай с этим, улучшай. Мы не роботы, мозги это как глина - плохие пальцы и моторика улучшаются инструментами, а если вообще нужен только результат физически и много - тут уже помогут станки. Разные сложности получения результатов требуют проработки разной степени силы мотивации их получить. Второе не получится без первого.
‑почему память (моя, по крайней мере) так плохо запоминает нужные знания?
Самая сильная сторона человеческого мозга - способность в очень эффективное аналитическое мышление, поиск и фильтрацию важных данных внешней среды и имеющейся памяти, чтобы не приходилось запоминать много, а достаточно было понять и запомнить принципы взаимосвязи сущностей, с которыми работаешь некоторое время в обособленном контексте. Память также разная по длительности хранения и скорости восстановления, краткосрочная и долгосрочная. Для быстрого восстановления контекста работы над задачей, процесса и полученных результатов - нужны визуально-смысловые “якоря”, в идеале, завязанные на возникшие в процессе эмоции, для усиления закрепления. От длительности и силы таких эмоций, в общем случае, зависит скорость и сила закрепления полученного результата. Чем выше эмоциональный внутренний отклик, чем желаннее результат и сложнее/длительнее процесс его достижения - тем с бОльшей вероятностью в мозгу сохранятся все детали рабочего контекста. В противоположность, чем более обычная задача, быстрее получение ожидаемого результата - тем меньше эмоциональный отклик и ниже необходимость что-либо запоминать нового из таких задач. Отточенный автоматизм не формирует новых навыков, незачем тратить ресурсы мозга на уже ясные механизмы получения результатов.
Основной механизм формирования “якоря” - визуальный/осязаемый просмотр объектов и их оценка, а также регулярность повторения процесса анализа через небольшие промежутки времени.
‑как сделать так, чтобы СРЕДА взяла на себя как можно больше тривиальных задач, чтобы человек мог оставить себе мышление? А не продирание через дебри инфраструктуры.
Автоматизация в реальном мире именно это и делает. Чтобы не таскать вещи, сначала придумали колесо. Без знания про трение качения, сопротивления материалов, всей инженерки. Просто последовательно логичная реакция на внешнюю среду. Появился инструмент решения базовой задачи - перемещения вещей. Далее это всё развилось в автомобили, ракеты, судостроение и прочее. В физических вещах реализованы решения тех самых базовых, тривиальных задач, чтобы человек мог тренироваться с решениями других проблем и целей. В чём-то реально новом, новому направлению в науке, возникших массовых проблем - всегда придётся лезть через дебри. Потому как никто ранее их для тебя не прорубал, придётся уже существующими инструментами прокладывать себе путь. Либо к решению, либо в болото, гарантий результата также никто не даст, опыт эффективен на старом и немного в предсказание направления, куда “копать”.
‑как снизить стоимость создания инструкции для себя будущего, если не знаешь, пригодится ли тебе то знание в будущем?
Для начала определиться с реальной степенью важности того, что это за инструкция и частотой обращения к ней. Потом потратить в среднем больше времени, чем обычно, подкреплять промежуточный результат какими-нибудь эмоциями, формировать визуальные образы, закреплять якоря на важном, опять же, затрачивая больше на это времени. Работать с мотивацией достижения результата, промежуточного, общего.
Гениями не рождаются, ими становятся. Один человек потратил 5 минут на попытку получить нужный результат, потом забил и пошёл листать тикток, забивая десятки эмоциональных якорей в кучу дерьма. Другой, потратил день на изучение среды той проблемы, стороннего опыта, сделал пару десятков попыток с ошибками, оптимизировал маршрут к цели, по итогу добился её. У него в голове также десятки якорей, которые не сорвёт на следующее утро подчистую (хотя, тот же алкогольный шторм или иное физ отравление в мозге может унести всё). Этот опыт потом можно расширять, используя те же подходы и инструменты.
Учиться учиться - тоже нужно учиться. Изначально, эту задачу отдали на откуп садам, школам и ВУЗам, но, на самом деле, это персональная задача каждого, повышать свою эффективность обучения и глубину знаний/опыта. Обучение из-под палки работает только на очень низком уровне. Всё, что выше - только через мотивацию. Чем сложнее цель - тем сильнее она требуется.
‑почему человек может не понимать чего‑то, хотя кажется, что уже все объяснили?
Если коротко - то разная степень мотивации в результате.
‑как форма чужого опыта и форма упаковки этого опыта могут не совпадать?
Очевидный ответ - люди живут каждый свою жизнь, у всех разный опыт. Кто-то поджигает спичку ради интереса, одних такой опыт может привести к желанию быть пожарным, других к изучению химии и физики процесса, третьих - к попытке понять зачем это всё и как можно улучшить, и нужно ли улучшать. Очень яркие новые события, новый опыт, закреплённый эмоциональный “якорь” может сформировать долгосрочные стремления изучить, попробовать, посмотреть что делают другие в схожих целях/задачах. Через коллаборацию расширить опыт, описать его, по возможности, универсальным способом, понятным для других.
На мой взгляд, язык и позже письменность сформировались именно в результате массовой потребности в таком сохранении опыта, процессов и результатов. По сути, это и есть нынешние межчеловеческие стандарты упаковки любого опыта. Написаны миллиарды книг, на сотнях язков, которые хранят опыт многих поколений. Некоторые группы слов, со временем, стали межязыковыми, когда частично передавая схожий смысл или его оттенок, когда - полностью изменяя его, атрофируясь во смысле от первоисточника, и просто как набор звуков/букв встроившись в новую, отдельную группу языков.
Базовые инструменты, на основе которых практически всё современное развитие человечества до этого времени выстроено - уже существуют и продолжают активно развиваться. Если поставить цель двигаться в сторону оптимизации взаимодействия через такие инструменты, речь и текст, то здесь вряд ли можно ожидать какого-то глобального прорыва в ещё бОльшей эффективности, даже при переходе на киборгизацию по типу neuralink и аналогов. Скорость речи, письма - довольно сильно связана со “скоростью” работы мозга. Углублять построение концепций, оптимизировать их описание, агрегировать накопленный опыт - эти процессы также сами по себе происходят из-за внутреннего взаимодействия в обществе. Количественно и качественно многие проблемы уже так или иначе нашли своё оптимальное решение.
Интересно, можно ли как-то узнать величину общего подъёма Африканской тектонической плиты за время формирования Сахары и как-то численно оценить её? Нет ли где на планете мест со схожей динамикой, в историческом и современном времени? И есть ли какие либо существенные изменения плотности земной коры за всё её время формирования, что могло бы сформировать устойчивый в сотни млн лет вектор "подъёма"? Возможно ли, таким образом, неизбежное формирование глобальной пустыни на планете Земля, по аналогии с результатом как сейчас на Марсе (не касаясь в целом вопроса потери скудной атмосферы у последнего)?
Большое спасибо за статью. Очень жаль, что тема подписи коммитов недостаточно популярна, как и осознание потенциальных рисков при работе без подтверждения авторства. Также крайне не рекомендую создавать бессрочные ключи.
Интересно было бы придумать механизм оценки качества работы таких AI-тренеров. Возможно, через сотни тестовых вопросов с заложенной в них случайной, но контролируемой вариацией, и тестировать одновременно как тренера, так и обученную им сеть.
Также стоит серьёзно подумать о fact checking и логике в исходных данных при обучении, чтобы застывший цемент не вытекал из стакана. В целом, есть проблема оценки достоверности обучающего материала и пока сети не могут качественно решить такой вопрос (перепроверки достоверности и перестройки логики фактов во всём масштабе сети), особенно, если недостоверность в обучаемых данных просто берёт количеством. То есть, обучать сети по содержимому тех же СМИ - довольно "опасное" занятие в социальном плане, если подобным обученные сети будут получать статус первичного авторитета знаний.
Следующим шагом в развитии GPT-like моделей должна быть роль child: когда сети массово разрешат задавать вопросы людям, а не просто отвечать на запросы. На основе этого механизма можно сильно улучшить ту самую перепроверку достоверности. Но, всё равно, фактор массовой ошибки будет продолжать влиять на качество выводов такой сети.
Есть некоторое подозрение, что в глобальном плане именно к этому всё и идёт - к созданию country-specific сетей-оракулов, со своей "достоверной" информацией и правильной "логикой". На которые, со временем, привяжут все сферы жизни общества - от обучения в школах, до законотворчества и решения судов. Очень хочется ошибаться в подобных прогнозах.
В целом, это как с ядерными технологиями: можно строить полезные станции с серьёзной генерацией и, через удешевление стоимости первичных ресурсов производства, делать всё остальное дешевле и доступнее, на десятилетия. А можно психануть и расхерачить всё к чертям, создав непригодные территории, на столетия. Инструмент в обоих случаях по сути един и вопрос лишь в том, как им пользоваться, и какие цели ставить.
Какой у книги ISBN (оригинала)? Это третье издание "Python for finance" (если да - в чём различие между версией последнего релиза второго издания от 31.07.2020) с переводом на русский или же другая книга?
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
Ещё интереснее механизмы многомерной оптимизации в динамических системах (изменяющаяся топология, изменяющиеся веса/"нагрузка"), когда есть, к примеру, базовая оптимальная модель и далее происходит оптимизация различных отклонений целевых показателей. Также можно рассматривать более сложную модель с грузоперевозками/такси, когда не только надо минимум по расходам, но и минимум по "штрафам", при невозможности или задержках доставки при динамической маршрутизации. Один авто только с одним пассажиром, только с точками A и B - это относительно просто.
Продолжайте эту тему, при желании и возможности. Большое спасибо за статью.
Было бы здОрово продолжить развитие этого проекта в сторону небольшого автоматизированного тестера на том же STM32, по аналогии с китайскими мультитестерами различных компонентов. Но с бОльшей информативностью, чем просто показатель индуктивности и сопротивления. К примеру, находить пики по мощности, частотам, КПД и пр. Возможно даже определить примерный подсчёт витков, для конфигурации всего двух обмоток или же просто соотношения витков в обмотках.
Если кто-то с вышеописанным в качестве законченного и недорогого устройства сталкивался - буду благодарен информации/ссылкам.
Спасибо за статью. Позволю себе несколько комментариев на ваши вопросы.
Для эффективного сохранения опыта нужны эмоциональные “якоря”. Сделал что-то в течение дня, получил какой-то результат, осознал его важность и закрепил верность движения к следующему этапу. Как через внутреннюю авторефлексию, либо через внешнюю оценку близких людей, либо иными способами, немножко порадовался результату. Наиболее мощные эмоциональные якоря формируются у детей, потому именно в детстве быстрее всего расширяются когнитивные способности. С возрастом эта эффективность падает на базовом уровне, но её можно поддерживать также через авторефлексию, самоубеждение в важности и правильности результата. Этому активно помогает накопленный ранее опыт, схожие ситуации, схожие пути, схожие инструменты. Уже интуиция помогает понимать, что результат верный, либо движение в нужном направлении. Кстати, тот самый совет разбивания пути к сложной цели на этапы с обязательной фиксацией промежуточных целей - это эффективный механизм создания якорей, которые в ближайшем времени можно будет быстро вспомнить, восстановить их контекст во всех смыслах, продолжить от этого решение новых схожих задач.
Пока не придумали машину времени, а только лишь спорят, чья квантовая теория толще и ближе к гравитации - до тех пор полного восстановления/отката на предыдущее состояние сделать будет невозможным. Стоит подумать, а так ли важен подобный переход, требуется ли постоянно вся его глубина контекста, а был ли он в реальности качественно сохранён и не закрепились ли ранее ошибки в опыте? Если новый опыт начинает активно противоречить хорошо сохранённому старому, всё менее кореллирующему с реальностью - то так ли было важно его настолько точно сохранять, жертвуя своей эффективностью памяти? Были ли качественно потрачены ресурсы на закрепление такой глубины опыта? Думаю, что ответ уже не настолько очевиден. Потому, для сохранения универсально эффективной работы мозга - ему необходимо чем-то жертвовать, что не было достаточно эмоционально закреплено опытом, устарело, начало активно конфликтовать с новым опытом.
Забывать что-то это нормально. В мозговом “порте” также очевидно ограниченный объём мест, куда можно сбросить “якорь” для долгосрочной стоянки. Рано или поздно, якорь оторвётся ото дна, либо его принудительно затопят, заменив чем-то новым.
Время - это и есть такой налог на внимание. Мы пока живём конечное время, довольно много из которого тратим на восхождение в гору знаний/опыта, а потом ещё и на спуск. Этот налог платится дважды: сначала на получение и закрепление знаний, сразу и много, а также всё остальное время жизни хранилища такого знания (мозг человека), по чуть-чуть, но многократно больше изначальных затрат, до момента полной утери.
Внимание жёстко связано со степенью мотивации получения ожидаемого результата: чем важнее он вам, тем выше может формироваться качество внимания к процессу получения результата. Нужно что-то запомнить - отыщи свой мотиватор получения результата. Желательно, не в форме еды, хотя это всё ещё работает, даже у людей. Лучше всего выстроить систему подкрепления, опять же, эмоционального. Получил результат - расскажи другим. Брось “якорь”. Получил негативный опыт - всё равно, движение к цели/результату от обратного также зачастую возможно. Если можешь в беседу с самим собой, авторефлексию, самоанализ - можно и так, но это инструмент, в основном, чуть слабее по эффективности, чем эмоции. Сложно сформировать всю картину в голове - разбей путь на эпизоды, промежуточные цели, обязательно с конкретным результатом. Заодно это будет проверкой, а тем ли путём вообще идёшь. Подбери свой наиболее эффективный инструмент микромотиваций, потом более долгосрочной - и работай с этим, улучшай. Мы не роботы, мозги это как глина - плохие пальцы и моторика улучшаются инструментами, а если вообще нужен только результат физически и много - тут уже помогут станки. Разные сложности получения результатов требуют проработки разной степени силы мотивации их получить. Второе не получится без первого.
Самая сильная сторона человеческого мозга - способность в очень эффективное аналитическое мышление, поиск и фильтрацию важных данных внешней среды и имеющейся памяти, чтобы не приходилось запоминать много, а достаточно было понять и запомнить принципы взаимосвязи сущностей, с которыми работаешь некоторое время в обособленном контексте. Память также разная по длительности хранения и скорости восстановления, краткосрочная и долгосрочная. Для быстрого восстановления контекста работы над задачей, процесса и полученных результатов - нужны визуально-смысловые “якоря”, в идеале, завязанные на возникшие в процессе эмоции, для усиления закрепления. От длительности и силы таких эмоций, в общем случае, зависит скорость и сила закрепления полученного результата. Чем выше эмоциональный внутренний отклик, чем желаннее результат и сложнее/длительнее процесс его достижения - тем с бОльшей вероятностью в мозгу сохранятся все детали рабочего контекста. В противоположность, чем более обычная задача, быстрее получение ожидаемого результата - тем меньше эмоциональный отклик и ниже необходимость что-либо запоминать нового из таких задач. Отточенный автоматизм не формирует новых навыков, незачем тратить ресурсы мозга на уже ясные механизмы получения результатов.
Основной механизм формирования “якоря” - визуальный/осязаемый просмотр объектов и их оценка, а также регулярность повторения процесса анализа через небольшие промежутки времени.
Автоматизация в реальном мире именно это и делает. Чтобы не таскать вещи, сначала придумали колесо. Без знания про трение качения, сопротивления материалов, всей инженерки. Просто последовательно логичная реакция на внешнюю среду. Появился инструмент решения базовой задачи - перемещения вещей. Далее это всё развилось в автомобили, ракеты, судостроение и прочее. В физических вещах реализованы решения тех самых базовых, тривиальных задач, чтобы человек мог тренироваться с решениями других проблем и целей. В чём-то реально новом, новому направлению в науке, возникших массовых проблем - всегда придётся лезть через дебри. Потому как никто ранее их для тебя не прорубал, придётся уже существующими инструментами прокладывать себе путь. Либо к решению, либо в болото, гарантий результата также никто не даст, опыт эффективен на старом и немного в предсказание направления, куда “копать”.
Для начала определиться с реальной степенью важности того, что это за инструкция и частотой обращения к ней. Потом потратить в среднем больше времени, чем обычно, подкреплять промежуточный результат какими-нибудь эмоциями, формировать визуальные образы, закреплять якоря на важном, опять же, затрачивая больше на это времени. Работать с мотивацией достижения результата, промежуточного, общего.
Гениями не рождаются, ими становятся. Один человек потратил 5 минут на попытку получить нужный результат, потом забил и пошёл листать тикток, забивая десятки эмоциональных якорей в кучу дерьма. Другой, потратил день на изучение среды той проблемы, стороннего опыта, сделал пару десятков попыток с ошибками, оптимизировал маршрут к цели, по итогу добился её. У него в голове также десятки якорей, которые не сорвёт на следующее утро подчистую (хотя, тот же алкогольный шторм или иное физ отравление в мозге может унести всё). Этот опыт потом можно расширять, используя те же подходы и инструменты.
Учиться учиться - тоже нужно учиться. Изначально, эту задачу отдали на откуп садам, школам и ВУЗам, но, на самом деле, это персональная задача каждого, повышать свою эффективность обучения и глубину знаний/опыта. Обучение из-под палки работает только на очень низком уровне. Всё, что выше - только через мотивацию. Чем сложнее цель - тем сильнее она требуется.
Если коротко - то разная степень мотивации в результате.
Очевидный ответ - люди живут каждый свою жизнь, у всех разный опыт. Кто-то поджигает спичку ради интереса, одних такой опыт может привести к желанию быть пожарным, других к изучению химии и физики процесса, третьих - к попытке понять зачем это всё и как можно улучшить, и нужно ли улучшать. Очень яркие новые события, новый опыт, закреплённый эмоциональный “якорь” может сформировать долгосрочные стремления изучить, попробовать, посмотреть что делают другие в схожих целях/задачах. Через коллаборацию расширить опыт, описать его, по возможности, универсальным способом, понятным для других.
На мой взгляд, язык и позже письменность сформировались именно в результате массовой потребности в таком сохранении опыта, процессов и результатов. По сути, это и есть нынешние межчеловеческие стандарты упаковки любого опыта. Написаны миллиарды книг, на сотнях язков, которые хранят опыт многих поколений. Некоторые группы слов, со временем, стали межязыковыми, когда частично передавая схожий смысл или его оттенок, когда - полностью изменяя его, атрофируясь во смысле от первоисточника, и просто как набор звуков/букв встроившись в новую, отдельную группу языков.
Базовые инструменты, на основе которых практически всё современное развитие человечества до этого времени выстроено - уже существуют и продолжают активно развиваться. Если поставить цель двигаться в сторону оптимизации взаимодействия через такие инструменты, речь и текст, то здесь вряд ли можно ожидать какого-то глобального прорыва в ещё бОльшей эффективности, даже при переходе на киборгизацию по типу neuralink и аналогов. Скорость речи, письма - довольно сильно связана со “скоростью” работы мозга. Углублять построение концепций, оптимизировать их описание, агрегировать накопленный опыт - эти процессы также сами по себе происходят из-за внутреннего взаимодействия в обществе. Количественно и качественно многие проблемы уже так или иначе нашли своё оптимальное решение.
Оптоволокно разбухло. /s
Большое спасибо за статью!
Большое спасибо за статью.
Интересно, можно ли как-то узнать величину общего подъёма Африканской тектонической плиты за время формирования Сахары и как-то численно оценить её? Нет ли где на планете мест со схожей динамикой, в историческом и современном времени? И есть ли какие либо существенные изменения плотности земной коры за всё её время формирования, что могло бы сформировать устойчивый в сотни млн лет вектор "подъёма"? Возможно ли, таким образом, неизбежное формирование глобальной пустыни на планете Земля, по аналогии с результатом как сейчас на Марсе (не касаясь в целом вопроса потери скудной атмосферы у последнего)?
Спасибо за статью!
Спасибо за статью!
Большое спасибо за статью. Очень жаль, что тема подписи коммитов недостаточно популярна, как и осознание потенциальных рисков при работе без подтверждения авторства. Также крайне не рекомендую создавать бессрочные ключи.
November 18, 2021
https://www.gutenberg.org/files/33283/33283-pdf.pdf
Про блох на 8-й странице.
Отличная статья, большое спасибо! В ожидании следующей части.
Отличная статья, большое спасибо!
Большое спасибо за статью!
Интересно было бы придумать механизм оценки качества работы таких AI-тренеров. Возможно, через сотни тестовых вопросов с заложенной в них случайной, но контролируемой вариацией, и тестировать одновременно как тренера, так и обученную им сеть.
Также стоит серьёзно подумать о fact checking и логике в исходных данных при обучении, чтобы застывший цемент не вытекал из стакана. В целом, есть проблема оценки достоверности обучающего материала и пока сети не могут качественно решить такой вопрос (перепроверки достоверности и перестройки логики фактов во всём масштабе сети), особенно, если недостоверность в обучаемых данных просто берёт количеством. То есть, обучать сети по содержимому тех же СМИ - довольно "опасное" занятие в социальном плане, если подобным обученные сети будут получать статус первичного авторитета знаний.
Следующим шагом в развитии GPT-like моделей должна быть роль child: когда сети массово разрешат задавать вопросы людям, а не просто отвечать на запросы. На основе этого механизма можно сильно улучшить ту самую перепроверку достоверности. Но, всё равно, фактор массовой ошибки будет продолжать влиять на качество выводов такой сети.
Есть некоторое подозрение, что в глобальном плане именно к этому всё и идёт - к созданию country-specific сетей-оракулов, со своей "достоверной" информацией и правильной "логикой". На которые, со временем, привяжут все сферы жизни общества - от обучения в школах, до законотворчества и решения судов. Очень хочется ошибаться в подобных прогнозах.
В целом, это как с ядерными технологиями: можно строить полезные станции с серьёзной генерацией и, через удешевление стоимости первичных ресурсов производства, делать всё остальное дешевле и доступнее, на десятилетия. А можно психануть и расхерачить всё к чертям, создав непригодные территории, на столетия. Инструмент в обоих случаях по сути един и вопрос лишь в том, как им пользоваться, и какие цели ставить.
Какой у книги ISBN (оригинала)? Это третье издание "Python for finance" (если да - в чём различие между версией последнего релиза второго издания от 31.07.2020) с переводом на русский или же другая книга?
Спасибо за статью. Можно попробовать всё это перенести в ansible роли, на bash-е далеко не уедешь. По возможности - без terraform.
Изначально моя мысль была про то, что сам kubernetes как инструмент, усложняется и становится дороже. Что приводит к удорожанию всего, что вокруг него. Что для варианта bare metal, что в целом для варианта as service в облаках.
Утрированно, но всё же: мне не нужно 50 различных вариаций исполнения сетей внутри подов, также не нужно 50 вариаций мониторингов policy и менеджмента кастомных ресурсов. Сам факт необходимости сделать правильный выбор из всего этого существующего зоопарка, необходимость знания всех его "обитателей" - будет повышать как стоимость админов/DevOps-ов, так и стоимость исправления ошибки, если выбор по каким-то причинам неверен. Клиенты при этом не особо понимают, а зачем платить больше, мне нужно чтобы всё работало, а что вы там за сеть к подам сделаете, как настроите service discovery, как это всё и чем будет в плане ACL/policy разграничиваться - это всё слишком сложно, решите всё сами.
И "чем дальше в лес, тем толще волки".
Облачные сервисы сложно назвать быстрыми в плане решения проблем, особенно, если они нетривиальные и затрагивают несколько продуктов такого сервиса. Решения таких проблем может занять несколько дней и более, и это стабильно случалось с 2 из 3 топ мировых облачных провайдеров. SLA они заявляют одни, на деле, при длительном использовании (годы), их не особо стремятся поддерживать, от sorry letter мало пользы в итоге, время на простой тратится с оплатой не из их кармана. Быстрый отклик у облаков в основном по простым вещам.
В плане железа при работе напрямую с одним вендором, с поддержкой и прочим - та же по сути ситуация: чем сложнее задача, тем дольше её будут решать. Или вообще не будут, потому что у большинства всё ок.
Если речь исключительно о софтовой платформе, то можно также упереться в годами неисправляемые баги, даже с открытыми bounty на них, часто где-то на уровне драйверов с железным слоем. И железо это не всегда вариант поменять.
В итоге, чем больше клиентов у такого сервиса, тем с бОльшей вероятностью, что время особо вам, как клиенту, уделять не будут. Когда компания-вендор маленькая, для её репутации проблемы клиентов - её проблемы. Когда уже большая - то проблемы клиентов, в основном, это только проблемы клиентов. Общая очередь и ожидание. Даже если реальный источник проблемы клиентов находится на стыке использования нескольких продуктов такого вендора. Или же в его же железе/конфигурации. Если наберётся много клиентов со схожими задачами - будут решать. Если нет - можно ждать решения годами. Ни один договор ни с одним вендором не заключает полноценных материальных возмещений убытков при неисполнении SLA. Это, как правило, оговаривается допсоглашением в индивидуальном порядке. Как и набор обслуживания по сервисам, если вне общих "тарифов". Выход на уровень судебных разбирательств в итоге не решает изначальную проблему, а только даёт надежду на возмещение убытков. За которую также придётся заплатить. В итоге будет дешевле переехать.
Самодельные инсталляции требуют оперативного наличия опытных админов, готовых быстро помочь. Не всегда это в принципе получается за разумное время: версии софта растут, диффы изменений мало кто вообще смотрит, документация почти никогда не поспевает за версиями. Могут даже в новой минорной версии что-то молча поломать. На разбирательства может уйти уйма времени, да, это будет долго и дорого в итоге.
Если изначально подойти к вопросу изоляции инфраструктуры от её провайдера, формировать её сразу как набор сервисов на основе kubernetes, то в этом случае перенос даже части инфраструктуры, как между облачными провайдерами, так и переезды на собственный bare metal вариант будет гораздо проще. Да, потребуются так или иначе service-specific штуки, которые неизбежно привязаны к провайдеру, но их, по возможности, надо втягивать в описание инфраструктуры проекта как можно меньше. То же относится к любым вариациям хранилищ, key vaults, image storage-ам, настройкам сетей и пр. В случае же разрозненности сервисов в проекте и подхода к их изначальному созданию - всегда будет длительный переход. С тестами, оценкой по ресурсам. Возможно, что даже и перенос станет слишком дорогим и дешевле будет переписать всё "с нуля".
Любая привязка к какому-то конкретному облачному провайдеру это всегда боль и расходы в будущем. Крайне желательно создавать инфраструктуру с минимальными завязками на что-то конкретное из сервисов провайдера. В идеале, перенос с облаков на bare metal (подготовленный в плане сети) должен проходить довольно просто. Даже для стабильных крупных проектов. Но, к сожалению, желание кастомизации здесь и сейчас довольно часто перевешивает понимание больших расходов в не столь далёком будущем. И это без учёта каких-либо архитектурных ошибок.
Тоже, скорее всего, выскажу непопулярную мысль про то, что необходимо, по возможности, уходить от использования terraform-а и строить инфраструктуру на KaS, что облачном, что bare metal. Не всегда это получается (что-то network-specific), но у реализаций terraform-а у каждого облачного провайдера, на мой взгляд, часто слишком много используется специфичного в описании инфраструктуры, что будет неизбежно приводить к осложнению и удорожанию любого переезда куда-либо ещё. И чем дольше такая ситуация сохраняется в процессе роста проекта, с сохранением привязок к провайдеру - тем хуже.
В любом случае, оценку правильности выбора или решения о переездах куда-либо имеет смысл делать на основе метрик ближе к деньгам/расходам на инфраструктуру. Не только через сбор до принятия решения, но и после (об этом практически все забывают). Может со временем стать выгоднее вернуть часть инфраструктуры в облака, к примеру. В идеале, метрики стоимости обслуживания (и даже возможного переноса, через конфиги тарифов провайдеров) лучше всего собирать по каждой изолированной сущности/сервису. Итоговое решение можно вообще отдать логике скрипта, генерирующего рекомендации, чтобы исключить потенциально коррупционный человеческий фактор или эмоции.
Готовые сервисы в начале, как правило, дешевле, да. Стоимость решений граблей, пока они ещё маленькие, также дешевле у готовых сервисов. Но потом постепенно начинается привязка инфраструктуры своих проектов к таким готовым сервисам и, с определённого момента, цена за такое удобство в итоге становится сильно дороже, чем было в начале (с учётом уже стоимости миграции на что-то другое). Особенно в стоимости оперативного решения проблем. При этом, параллельно с этим растёт и стоимость такого перехода из-за роста сложности инструментария и недостаточности рук на рынке.
В итоге, наиболее правильным переход в кубер был бы при очевидных перспективах резкого роста нагрузки и/или уже при её существенном наличии, а не просто "чтобы было", "нам нужен быстрый деплой 60 раз в день" или "все так делают и мы будем делать". Инструменты стали сложнее, обслуживание стало также дороже.
Если компания уже решила, что kubernetes нужен с первого дня без вариантов, то разумнее всего делать независимую конфигурацию, чтобы сначала (пока дёшево и нет сложности в проекте) использовать kubernetes as service в облаках, а потом уже тяжёлые части, не требующие зональности и доступа из сети, перетягивать на свой bare metal. При этом собирать доп метрики про то, а действительно ли такой шаг привёл к экономии. Это очень поможет в объяснении последующих миграций в ту или иную сторону. Как минимум, инвестор будет видеть, что вы понимаете, что вы собираетесь делать и решения на чём-то основаны, кроме эмоций.
Возможно, выскажу непопулярную мысль, но kubernetes с годами превращается в дорогого в содержании монстра (если всё делать изначально правильно и не забивать на мониторинг/поддержку), даже если брать средний масштаб компаний.
Инструментов для "помощи" до сих пор ежегодно появляется довольно много, при этом общая сложность и общие риски системы в целом уже давно не уменьшаются, а, скорее, наоборот. Безопасность часто заканчивается на сетевом уровне (до подов) и чеками образов, часто с забиванием болта на безопасность инструментов проверки таких образов. Платить за сервис настройки и "дорогих" админов/DevOps-ов также особо никто не хочет, дешевле получать и дальше граблями в лоб, сносить кластера и выкатывать всё заново. К обновлению версий кубера очень популярен тот же подход.
Инструменты, по возможности, должны упрощаться и улучшаться, чтобы экономить время и ресурсы их пользователям. Но этого, в случае с kubernetes, не происходит, на мой взгляд.
Ещё интереснее механизмы многомерной оптимизации в динамических системах (изменяющаяся топология, изменяющиеся веса/"нагрузка"), когда есть, к примеру, базовая оптимальная модель и далее происходит оптимизация различных отклонений целевых показателей. Также можно рассматривать более сложную модель с грузоперевозками/такси, когда не только надо минимум по расходам, но и минимум по "штрафам", при невозможности или задержках доставки при динамической маршрутизации. Один авто только с одним пассажиром, только с точками A и B - это относительно просто.
Продолжайте эту тему, при желании и возможности. Большое спасибо за статью.
Большое спасибо за статью.
Было бы здОрово продолжить развитие этого проекта в сторону небольшого автоматизированного тестера на том же STM32, по аналогии с китайскими мультитестерами различных компонентов. Но с бОльшей информативностью, чем просто показатель индуктивности и сопротивления. К примеру, находить пики по мощности, частотам, КПД и пр. Возможно даже определить примерный подсчёт витков, для конфигурации всего двух обмоток или же просто соотношения витков в обмотках.
Если кто-то с вышеописанным в качестве законченного и недорогого устройства сталкивался - буду благодарен информации/ссылкам.