Ну вообще это не "трюк", а вполне себе так, как и должно быть. В том смысле, что контейнер и вообще DI[njection] для того и нужны, чтобы сами потребители ("клиенты") не были жестко завязаны на какие-то конкретные реализации. Как именно для этой цели сконфигурировать DI - вопрос отдельный, и вариантов может быть масса. Но концептуально все верно.
С большей частью комментария согласен. Но как минимум не готов однозначно согласиться с причинно-следственной связью "не было бы возможности ..., не было бы ....". Как по мне, здесь как минимум проблема курицы и яйца. А где-то и вовсе обратная причинно-следственная связь: изначальное возникновение потребности/стремления и, как следствие, поиск какого-то из способов ее достижения.
Спасибо за статью. Читал и, откровенно говоря, порадовался, потому что сам давно хотел бы подобным заняться. Это в том числе к вопросу о том, что на легаси трудно найти разработчиков. Это так, если от легаси никто и не собиратеся избавляться. А если же сам заказчик понимает необходимость ухода от старья и перехода на новое - тут лично я, по крайней мере, с удовольствием бы взялся. Жаль только, что заказчики зачастую слишком поздно понимают необходимость внутреннего качества продукта, когда уже совсем, что называется, жареный петух ключнет. Впрочем, тут и к самой разработке бывает много вопросов, если с их стороны изначально нет подобной инициативы.
Не очень понял вашу логическую цепочку, но статья ровно о том, как вам приходится преодолевать трудности (или даже боль), вызванные вашим же выбором "удобных" ресурсов Ларавела. Я же пишу о том, что на подобные вещи изначально не стоит завязываться. А говоря про "не выходить без крайней необходимости", на всякий случай уточню, что "не завязываться" (или "отвязываться") не тождественно "не использовать".
Тут мораль простая: вместо того, чтобы закапываться в магию Laravel'а, от нее надо максимально уходить. Как и в целом от фреймворка стоит максимально отвязываться, помня, что это лишь инструмент для решения проблем, а не хозяин положения, диктующий, как и что должно быть (бизнес/заказчика меньше всего будет волновать, что так и как умеет или не умеет делать фреймворк).
Резонное замечание, и особо отметил бы важность абстрагирования от СУБД в том числе и в данном вопросе.
Как минимум по двум причинам:
1) СУБД бывают разные, а понимать суть по-прежнему нужно - это более-менее очевидно
2) А вот что менее очевидно: понимать суть нужно даже независимо от того, используется ли СУБД вообще или нет. Поскольку любая СУБД, да и вообще хранилище - это лишь инструмент для реализации некоторых задач. А когда мы говорим о каких-то задачах, мы чаще всего имеем ввиду какую-то бизнес-логику, которая, очевидно, понятия не имеет о каких-либо СУБД. И транзакции в данном смысле надо понимать не как транзакции в СУБД, а как "бизнес-транзакции", которые могут быть реализованы на самом разнообразном стэке, в том числе и быть распределены между различными сервисами (у каждого из которых может быть как своя СУБД, так и не быть вовсе). Однако обеспечить изолированность этих транзакции может быть по-прежнему нужно.
Ну в целом то да, мы примерно об одном и том же, просто с разных точек зрения. И идея "Архитектура как код" мне действительно нравится как раз из тех соображений, что описал выше: на любую систему уже смотрю с позиции, словно это работающее ПО, соотв-но таким же образом, по крайней мере лично, было бы удобно и описывать их, словно это и есть программа. А там уже и прочие фишки можно применить: проанализировать все те же зависимости и так далее.
Так вот... удержать в голове можно очень ограниченный контекст.
Тут, кстати, как раз кроется один из подходов в проектировании: откладывать решения на потом. Рассматривать часть системы независимо от того, как будет сделана остальная часть. Все то же абстрагирование.
Я уверен в величии ИТ.
Ну я так-то тоже не устаю восхищаться, какие возможности открывает для человека IT, и рад быть в этой сфере. Но все же иногда лишний раз одергиваю себя, когда возникает какая-то задача. Это можно сравнить с использованием какого-нибудь фреймворка в приложении. Один разработчик пишет "на" фреймворке, а второй фреймворк просто использует в той степени, какая ему нужна. Первый, когда у него возникнет какая-то задача, рассуждает в категориях "как это сделать в этом фреймворке", и порой может раздосадоваться, если фреймворк этого не умеет. Второй же рассуждает скорее в категориях "сможет ли мне здесь фреймворк помочь" (да, так да, нет так нет).
Касаемо последних двух абзацев: так и есть. Для меня работодатель тоже абстракция. Или чтобы звучало все же красивее и человечнее: партнер. То есть для меня отношения работодателя и сотрудника - это исключительно взаимовыгодное сотрудничество на тех условиях, на которых договорились. И пока мы друг друга устраиваем, сотрудничаем дальше. Как работодатель не зависит лично от меня, а зависит от абстракции, так и я не завишу конкретно от него. Но естественно, это не мешает нам плодотворно работать, но каждый - в своих интересах.
Я бизнес не романтизирую, я просто радею за то, чтобы любая компания (особенно в которых мне доводится работать) была грамотно "спроектирована". Я в таком ключе на любую систему в жизни уже и смотрю: точно так же, как и на ПО. Как она спроектирована. Что в ней может сломаться, что уязвимо, какие принципы в целом нарушены, и так далее. И это комично порой выглядит, когда приходишь работать в компанию, чтобы делать им крутое ПО, а сама копания сплошь на костылях работает. Типа как условный кладовщик одновременно и менеджер по продажам и чуть не бухгалтер. Ну и тому подобное.
Бизнес обязан видоизменяться и адаптироваться под внешние условия.
Я про это, в общем-то, и говорю. И как раз именно это, в том числе, и призвана обеспечить грамотная архитектура системы: способность к изменениям и отказоустойчивость. Говоря про "отвязку" от IT я же не говорю про отказ от его использования. Я говорю про абстрагирование от него.
Говоря про IT как инструмент, скажу вам больше: как сотрудник для бизнеса вы тоже инструмент. Бизнес, конечно, может и на вас лично жестко завязаться: какой вы замечательный человек, большое кол-во навыков и так далее. Но очевидно, люди приходят и уходят, на худой конец могут и заболеть, и так далее. Поэтому бизнес, если он хочет большей отказоустойчивости, будет от вас абстрагироваться. Для него вы - просто сотрудник по контракту. Ушел один - заменили другим. Или взяли еще одного помимо вас. А та часть бизнеса, что над вами, завязана не на вас лично, а на абстрактного сотрудника (контракт).
Как раз таки с позиции архитектуры это фатально, когда "бизнес и технологии сильно увязаны". Безусловно, могут появляется различные бизнесы вокруг каких-то конкретных технологий, и быть весьма успешными до поры до времени. Но это бизнес, что называется, на один вечер, если они от этих конкретных технологий не отвяжутся. Пока эта технология актуальна и они поспевают за спросом. Уйдет технология - уйдет и бизнес. Выше @funca тоже об этом написал.
Мой комментарий выше вообще и был по большей части про архитектуру бизнеса и процессов в нем. И конкретно про IT даже и не думал. И именно так воспринял саму статью. IT - это по-прежнему лишь инструмент для бизнеса. И как бы мы ни хотели возвеличивать важность и полезность этого инструмента, от него тоже нужно абстрагироваться.
В целом согласен с озвученной идеей. Правда от себя бы отметил, что важнее всего не "Архитектура как код" (то есть код - как один из вариантов формализации), а непосредственно применение лучших архитектурных практик в устройстве самого бизнеса. А уж в каком виде это записать/формализовать - вопрос второй. А то придумать то подобных способов можно массу, но толку от них не будет, если пользующийся ими человек в архитектуре не особо то и смыслит.
Как по мне, главное преимущество этого lazygit - исключительно в его консольности, то есть можно прямо на удаленной машине в случае чего запустить. Локально же да, из консоли вообще не вижу смысла что-то делать. Разве что иногда из соображений практики, чтобы совсем не забыть, как это делается.
Уже многие годы юзаю встроенный в JetBrains'овые IDE git-клиент и бед не знаю. Это если говорить про непосредственно локальную разработку. Ну а на ремоуте в любом случае консоль, и данная штуковина выглядит весьма интересной.
Это не отдельные профессии, а по-прежнему разработка, но само понятие "фулл-стэка" противоречит одному из основополагающих принципов, причем не только именно в разработке - Single Responsibility. Поэтому я скорее поддержу мнение о том, что "Senior Full-Stack" - это по миддлу и на фронте, и на бэке.
Тоже программист уже примерно такого же возраста. Но некоторые пункты - точно не про меня, но всех их можно свести в одну категорию: заниматься этим не то, чтобы пропало желание, но порой скучно, вследствие чего есть желание развиваться уже в других областях. Помимо прочего, именно как разработчик, уже давно ощущаю себя оверквалом на большинстве мест работы по найму. Ни одна задача не уже не вызывает вопросов: а как ее сделать. Все решение видно сходу. Однако некоторые задачи порой все равно бывают интересными хотя бы из тех соображений, которые были автором озвучены: показать молодняку, как надо.
Но минус всей этой истории в том, что действительно зная, как надо, все сложнее становится работать с коллегами, планка качества кода которых ниже твоей. Это, конечно, отдельная очень дискутивная тема: бизнес vs техдолг. Но с кодом посредственного качества работать уже в принципе не берусь. Если, конечно, это не какие-то разовые задачи.
Поэтому лично для себя, если не учитывать развитие в совершенно иных отраслях, или же собственный бизнес, развитие в сфере разработки уже вижу больше в направлении образования/менторства. А если что и писать, то уже только какие-то собственные проекты.
Тут стоит отметить, что это два компенсирующих друг друга процесса в природе: возрастающая энтропия и эволюция в широком смысле, упорядочивающая хаос посредством образования более стабильных структур. Одновременно с этим, стоит также говорить об иерархической сути энтропии, или по крайней мере об ее относительности (субъективности). Говоря о примере с костями, количество неизвестной нам информации относительно: если нам важен только результат броска, нам и не нужно знать, как выпала каждая отдельная кость. У нас уже есть готовый результат, таким образом, у нас нет неизвестной для нас информации с точки зрения цели нашего наблюдения. Более того - если нам нужен лишь результат, а нам говорят про каждую из 10 костей по отдельности - это избыточная информация, которая, при этом, не содержит нужной нам информации напрямую - нам ее еще предстоит вычислить. Другими словами - здесь содержится неизвестность. Более того. Что, если нам скажут даже не результат броска каждой кости, а выдадут все внутренние микросостояния - это еще больше усложнит нам задачу получения нужной нам информации, а именно - конечной суммы всех бросков.
То, что я описываю - это как раз тот противовес возрастающей энтропии, заключающийся в организации более стабильных структур, которыми можно оперировать на более высоком уровне, снижая энтропию. Хотим мы бросить кости - мы их бросаем без размышлений о том, что бросаем мы какие-то там атомы и молекула, а равно как и лежащие в их основе более элементарные частицы.
Говоря о человеке, изначально он, как представитель жизни - энтропию уменьшает. Он также способен уменьшать энтропию и своей высшей деятельностью. Но как справедливо отметили в комментарии выше, человек в значительно степени порождает и хаос вокруг себя. Тут мне ничего больше не остается, как прибегнуть к философским/эзотерическим/религиозным взглядам, которые я как минимум частично разделяю, и переводя которые в текущий контекст, говорят, что человек порождает слишком много энтропии в своей локальной системе, в результате чего неизбежно возникнут компенсационные механизмы, которые могут проявиться в чем угодно. Может, человек сам уничтожит себя. Может, возникнут какие-либо природные катаклизмы, которые сотрут человека с лица Земли. А может появятся какие-то другим биологические виды, типа вирусов, которые сделают эту работу. Не потому даже, что это чей замысел, есть он или нет. А потому что так устроена природа.
Безусловно, у всех все индивидуально. Но формально таким же качеством обладают абсолютно любые упражнения. Кому-то (или даже большинству) они пойдут на пользу, а кому-то они могут быть противопоказаны. К тому же не стоит забывать и правило "все хорошо в меру". И в палне физических нагрузок это особенно актуально. Даже в целом хорошее и безобидное упражнение можно превратить в опасное и травмирующее, если проявить слишком большие усердия. Есть и поговорок много на эту тему. Типа "Научи дурака Богу молиться, он себе лоб расшибет". Или "Сдуру можно и х** сломать". И так далее. Поэтому, как уже отметил выше, лично для меня главное правило - это чувствовать себя во время любых упражнений. Ну и не переусердствовать, естественно.
Я человек не всегда простой) Но конкретно тут у меня правило простое: делая любые физические упражнения, нужно чувствовать себя, а не просто делать, как сказано в инструкции. Конкретно упражнение 3 из этой статьи мне зашло неописуемо как. Я почти в буквальном смысле испытал кайф от того, как что-то каким-то образом заработало лучше в шее. В ней стало легко, а голова моментально просветлела.
Ну а говоря о приведенном вами видео... Я пока еще не посмотрел, но тренды ютуба порой играют злую шутку. Если раньше (да и сейчас в целом тоже) в моде были видео в позитивной формулировке: "сделай то-то, чтобы то-то (в плане здоровья)", или "как правильно делать то-то". То сейчас сплошь и рядом негативные формулировки: "этим упражнением вы убьете свой пресс!", "никогда больше не делай это упражнение!". К сожалению, зачастую это просто тренд, сложившийся в конкуренции за наиболее привлекательные заголовки.
Вообще, любопытно наблюдать, когда такое происходит вживую. 20 лет уже наблюдаю. И как все предприятие поддерживает и защищает несменное руководство. И как увольняются несогласные. Словно я пересилился в учебник истории. Читал эту статью и ловил достаточно толстые флэшбэки.
Ну это скорее юридическое определение. Мне же, например, интересно и бытовое опредление. Саботаж, кмк, весьма близок по смыслу. Разве что здесь цель была не сорвать работу как таковую, а именно разграбить.
Ну вообще это не "трюк", а вполне себе так, как и должно быть. В том смысле, что контейнер и вообще DI[njection] для того и нужны, чтобы сами потребители ("клиенты") не были жестко завязаны на какие-то конкретные реализации. Как именно для этой цели сконфигурировать DI - вопрос отдельный, и вариантов может быть масса. Но концептуально все верно.
С большей частью комментария согласен. Но как минимум не готов однозначно согласиться с причинно-следственной связью "не было бы возможности ..., не было бы ....". Как по мне, здесь как минимум проблема курицы и яйца. А где-то и вовсе обратная причинно-следственная связь: изначальное возникновение потребности/стремления и, как следствие, поиск какого-то из способов ее достижения.
Спасибо за статью. Читал и, откровенно говоря, порадовался, потому что сам давно хотел бы подобным заняться. Это в том числе к вопросу о том, что на легаси трудно найти разработчиков. Это так, если от легаси никто и не собиратеся избавляться. А если же сам заказчик понимает необходимость ухода от старья и перехода на новое - тут лично я, по крайней мере, с удовольствием бы взялся. Жаль только, что заказчики зачастую слишком поздно понимают необходимость внутреннего качества продукта, когда уже совсем, что называется, жареный петух ключнет. Впрочем, тут и к самой разработке бывает много вопросов, если с их стороны изначально нет подобной инициативы.
Не очень понял вашу логическую цепочку, но статья ровно о том, как вам приходится преодолевать трудности (или даже боль), вызванные вашим же выбором "удобных" ресурсов Ларавела. Я же пишу о том, что на подобные вещи изначально не стоит завязываться. А говоря про "не выходить без крайней необходимости", на всякий случай уточню, что "не завязываться" (или "отвязываться") не тождественно "не использовать".
Тут мораль простая: вместо того, чтобы закапываться в магию Laravel'а, от нее надо максимально уходить. Как и в целом от фреймворка стоит максимально отвязываться, помня, что это лишь инструмент для решения проблем, а не хозяин положения, диктующий, как и что должно быть (бизнес/заказчика меньше всего будет волновать, что так и как умеет или не умеет делать фреймворк).
Резонное замечание, и особо отметил бы важность абстрагирования от СУБД в том числе и в данном вопросе.
Как минимум по двум причинам:
1) СУБД бывают разные, а понимать суть по-прежнему нужно - это более-менее очевидно
2) А вот что менее очевидно: понимать суть нужно даже независимо от того, используется ли СУБД вообще или нет. Поскольку любая СУБД, да и вообще хранилище - это лишь инструмент для реализации некоторых задач. А когда мы говорим о каких-то задачах, мы чаще всего имеем ввиду какую-то бизнес-логику, которая, очевидно, понятия не имеет о каких-либо СУБД. И транзакции в данном смысле надо понимать не как транзакции в СУБД, а как "бизнес-транзакции", которые могут быть реализованы на самом разнообразном стэке, в том числе и быть распределены между различными сервисами (у каждого из которых может быть как своя СУБД, так и не быть вовсе). Однако обеспечить изолированность этих транзакции может быть по-прежнему нужно.
Ну в целом то да, мы примерно об одном и том же, просто с разных точек зрения. И идея "Архитектура как код" мне действительно нравится как раз из тех соображений, что описал выше: на любую систему уже смотрю с позиции, словно это работающее ПО, соотв-но таким же образом, по крайней мере лично, было бы удобно и описывать их, словно это и есть программа. А там уже и прочие фишки можно применить: проанализировать все те же зависимости и так далее.
Тут, кстати, как раз кроется один из подходов в проектировании: откладывать решения на потом. Рассматривать часть системы независимо от того, как будет сделана остальная часть. Все то же абстрагирование.
Ну я так-то тоже не устаю восхищаться, какие возможности открывает для человека IT, и рад быть в этой сфере. Но все же иногда лишний раз одергиваю себя, когда возникает какая-то задача. Это можно сравнить с использованием какого-нибудь фреймворка в приложении. Один разработчик пишет "на" фреймворке, а второй фреймворк просто использует в той степени, какая ему нужна. Первый, когда у него возникнет какая-то задача, рассуждает в категориях "как это сделать в этом фреймворке", и порой может раздосадоваться, если фреймворк этого не умеет. Второй же рассуждает скорее в категориях "сможет ли мне здесь фреймворк помочь" (да, так да, нет так нет).
Касаемо последних двух абзацев: так и есть. Для меня работодатель тоже абстракция. Или чтобы звучало все же красивее и человечнее: партнер. То есть для меня отношения работодателя и сотрудника - это исключительно взаимовыгодное сотрудничество на тех условиях, на которых договорились. И пока мы друг друга устраиваем, сотрудничаем дальше. Как работодатель не зависит лично от меня, а зависит от абстракции, так и я не завишу конкретно от него. Но естественно, это не мешает нам плодотворно работать, но каждый - в своих интересах.
Я бизнес не романтизирую, я просто радею за то, чтобы любая компания (особенно в которых мне доводится работать) была грамотно "спроектирована". Я в таком ключе на любую систему в жизни уже и смотрю: точно так же, как и на ПО. Как она спроектирована. Что в ней может сломаться, что уязвимо, какие принципы в целом нарушены, и так далее. И это комично порой выглядит, когда приходишь работать в компанию, чтобы делать им крутое ПО, а сама копания сплошь на костылях работает. Типа как условный кладовщик одновременно и менеджер по продажам и чуть не бухгалтер. Ну и тому подобное.
Я про это, в общем-то, и говорю. И как раз именно это, в том числе, и призвана обеспечить грамотная архитектура системы: способность к изменениям и отказоустойчивость. Говоря про "отвязку" от IT я же не говорю про отказ от его использования. Я говорю про абстрагирование от него.
Говоря про IT как инструмент, скажу вам больше: как сотрудник для бизнеса вы тоже инструмент. Бизнес, конечно, может и на вас лично жестко завязаться: какой вы замечательный человек, большое кол-во навыков и так далее. Но очевидно, люди приходят и уходят, на худой конец могут и заболеть, и так далее. Поэтому бизнес, если он хочет большей отказоустойчивости, будет от вас абстрагироваться. Для него вы - просто сотрудник по контракту. Ушел один - заменили другим. Или взяли еще одного помимо вас. А та часть бизнеса, что над вами, завязана не на вас лично, а на абстрактного сотрудника (контракт).
Как раз таки с позиции архитектуры это фатально, когда "бизнес и технологии сильно увязаны". Безусловно, могут появляется различные бизнесы вокруг каких-то конкретных технологий, и быть весьма успешными до поры до времени. Но это бизнес, что называется, на один вечер, если они от этих конкретных технологий не отвяжутся. Пока эта технология актуальна и они поспевают за спросом. Уйдет технология - уйдет и бизнес. Выше @funca тоже об этом написал.
Мой комментарий выше вообще и был по большей части про архитектуру бизнеса и процессов в нем. И конкретно про IT даже и не думал. И именно так воспринял саму статью. IT - это по-прежнему лишь инструмент для бизнеса. И как бы мы ни хотели возвеличивать важность и полезность этого инструмента, от него тоже нужно абстрагироваться.
В целом согласен с озвученной идеей. Правда от себя бы отметил, что важнее всего не "Архитектура как код" (то есть код - как один из вариантов формализации), а непосредственно применение лучших архитектурных практик в устройстве самого бизнеса. А уж в каком виде это записать/формализовать - вопрос второй. А то придумать то подобных способов можно массу, но толку от них не будет, если пользующийся ими человек в архитектуре не особо то и смыслит.
Как по мне, главное преимущество этого lazygit - исключительно в его консольности, то есть можно прямо на удаленной машине в случае чего запустить. Локально же да, из консоли вообще не вижу смысла что-то делать. Разве что иногда из соображений практики, чтобы совсем не забыть, как это делается.
Уже многие годы юзаю встроенный в JetBrains'овые IDE git-клиент и бед не знаю. Это если говорить про непосредственно локальную разработку. Ну а на ремоуте в любом случае консоль, и данная штуковина выглядит весьма интересной.
Это не отдельные профессии, а по-прежнему разработка, но само понятие "фулл-стэка" противоречит одному из основополагающих принципов, причем не только именно в разработке - Single Responsibility. Поэтому я скорее поддержу мнение о том, что "Senior Full-Stack" - это по миддлу и на фронте, и на бэке.
Тоже программист уже примерно такого же возраста. Но некоторые пункты - точно не про меня, но всех их можно свести в одну категорию: заниматься этим не то, чтобы пропало желание, но порой скучно, вследствие чего есть желание развиваться уже в других областях. Помимо прочего, именно как разработчик, уже давно ощущаю себя оверквалом на большинстве мест работы по найму. Ни одна задача не уже не вызывает вопросов: а как ее сделать. Все решение видно сходу. Однако некоторые задачи порой все равно бывают интересными хотя бы из тех соображений, которые были автором озвучены: показать молодняку, как надо.
Но минус всей этой истории в том, что действительно зная, как надо, все сложнее становится работать с коллегами, планка качества кода которых ниже твоей. Это, конечно, отдельная очень дискутивная тема: бизнес vs техдолг. Но с кодом посредственного качества работать уже в принципе не берусь. Если, конечно, это не какие-то разовые задачи.
Поэтому лично для себя, если не учитывать развитие в совершенно иных отраслях, или же собственный бизнес, развитие в сфере разработки уже вижу больше в направлении образования/менторства. А если что и писать, то уже только какие-то собственные проекты.
Тут стоит отметить, что это два компенсирующих друг друга процесса в природе: возрастающая энтропия и эволюция в широком смысле, упорядочивающая хаос посредством образования более стабильных структур. Одновременно с этим, стоит также говорить об иерархической сути энтропии, или по крайней мере об ее относительности (субъективности). Говоря о примере с костями, количество неизвестной нам информации относительно: если нам важен только результат броска, нам и не нужно знать, как выпала каждая отдельная кость. У нас уже есть готовый результат, таким образом, у нас нет неизвестной для нас информации с точки зрения цели нашего наблюдения. Более того - если нам нужен лишь результат, а нам говорят про каждую из 10 костей по отдельности - это избыточная информация, которая, при этом, не содержит нужной нам информации напрямую - нам ее еще предстоит вычислить. Другими словами - здесь содержится неизвестность. Более того. Что, если нам скажут даже не результат броска каждой кости, а выдадут все внутренние микросостояния - это еще больше усложнит нам задачу получения нужной нам информации, а именно - конечной суммы всех бросков.
То, что я описываю - это как раз тот противовес возрастающей энтропии, заключающийся в организации более стабильных структур, которыми можно оперировать на более высоком уровне, снижая энтропию. Хотим мы бросить кости - мы их бросаем без размышлений о том, что бросаем мы какие-то там атомы и молекула, а равно как и лежащие в их основе более элементарные частицы.
Говоря о человеке, изначально он, как представитель жизни - энтропию уменьшает. Он также способен уменьшать энтропию и своей высшей деятельностью. Но как справедливо отметили в комментарии выше, человек в значительно степени порождает и хаос вокруг себя. Тут мне ничего больше не остается, как прибегнуть к философским/эзотерическим/религиозным взглядам, которые я как минимум частично разделяю, и переводя которые в текущий контекст, говорят, что человек порождает слишком много энтропии в своей локальной системе, в результате чего неизбежно возникнут компенсационные механизмы, которые могут проявиться в чем угодно. Может, человек сам уничтожит себя. Может, возникнут какие-либо природные катаклизмы, которые сотрут человека с лица Земли. А может появятся какие-то другим биологические виды, типа вирусов, которые сделают эту работу. Не потому даже, что это чей замысел, есть он или нет. А потому что так устроена природа.
Безусловно, у всех все индивидуально. Но формально таким же качеством обладают абсолютно любые упражнения. Кому-то (или даже большинству) они пойдут на пользу, а кому-то они могут быть противопоказаны. К тому же не стоит забывать и правило "все хорошо в меру". И в палне физических нагрузок это особенно актуально. Даже в целом хорошее и безобидное упражнение можно превратить в опасное и травмирующее, если проявить слишком большие усердия. Есть и поговорок много на эту тему. Типа "Научи дурака Богу молиться, он себе лоб расшибет". Или "Сдуру можно и х** сломать". И так далее. Поэтому, как уже отметил выше, лично для меня главное правило - это чувствовать себя во время любых упражнений. Ну и не переусердствовать, естественно.
Я человек не всегда простой) Но конкретно тут у меня правило простое: делая любые физические упражнения, нужно чувствовать себя, а не просто делать, как сказано в инструкции. Конкретно упражнение 3 из этой статьи мне зашло неописуемо как. Я почти в буквальном смысле испытал кайф от того, как что-то каким-то образом заработало лучше в шее. В ней стало легко, а голова моментально просветлела.
Ну а говоря о приведенном вами видео... Я пока еще не посмотрел, но тренды ютуба порой играют злую шутку. Если раньше (да и сейчас в целом тоже) в моде были видео в позитивной формулировке: "сделай то-то, чтобы то-то (в плане здоровья)", или "как правильно делать то-то". То сейчас сплошь и рядом негативные формулировки: "этим упражнением вы убьете свой пресс!", "никогда больше не делай это упражнение!". К сожалению, зачастую это просто тренд, сложившийся в конкуренции за наиболее привлекательные заголовки.
Взять от жизни все, что называется.
Вообще, любопытно наблюдать, когда такое происходит вживую. 20 лет уже наблюдаю. И как все предприятие поддерживает и защищает несменное руководство. И как увольняются несогласные. Словно я пересилился в учебник истории. Читал эту статью и ловил достаточно толстые флэшбэки.
Ну это скорее юридическое определение. Мне же, например, интересно и бытовое опредление. Саботаж, кмк, весьма близок по смыслу. Разве что здесь цель была не сорвать работу как таковую, а именно разграбить.