Разработчик Тим Хаттон из Microsoft выпустил демо гравитации
Это демо преобразования неинерциальной системы отсчета в инерциальную. С учетом гипотезы, что законы физики не отличаются в системе с равномерным ускорением и однородным гравитационным полем, это демо подходит для однородного поля тяготения.
Но ОТО начинается там, где мы работаем не только с преобразованием систем отсчетов, а где появляется кривизна пространства времени. Т.е. когда не работают аксиомы Евклида. Например, через две точки на плоскости можно провести две прямые или через одну точку можно провести несколько прямых параллельных данной. Какими бы преобразования не были, такое пространство не отобразиться на плоскость (евклидову).
Суть ОТО — это описание как кривизна (не преобразование систем отсчета, а именно кривизна пространства-времени) порождается массой. (точнее тензором энергии-импульса, но не будем придираться до нудности)
те
1. демо — преобразование равномерно ускоренной системы отсчета, системы в однородном поле в инерциальную систему отсчета. Здесь не нужно ни ОТО, ни пространство-время. Достаточно классический физики, отдельно пространства и отдельно времени. + Эквивалентность гравитации и ускорения.
2. ОТО появляется там, где есть пространство- время (как целое) и его кривизна.
Несмотря на обилие метрик, не существует какого-то единственного способа для вычисления сопряжения и связности модулей.
Отчасти это связано с тем, что это рекомендации, а не закон. У них нет даже границ применения. И они косвенно влияют на коммерческий успех. Так же и SRP — это рекомендация.
Если абстрактно совсем, то DTO — это нарушение ОО парадигмы. Даже если разработать метрики по нарушению ООП, не факт, что от DTO откажутся. Отказ приведет к увеличению сложности и времени разработки и сопровождения (здесь мое мнение). Метрики не могут показать как конкретная команда изменит свою эффективность применяя эти рекомендации.
Кэрролл говорит, что, мол, все пространство-время возникает как эмерджентный феномен из свойств многомерного Гильбертова пространства, в котором существует ВФ нашей Вселенной.
Не является ли (на Ваш взгляд) это принципиальным отличием от «классической квантовой физики + ОТО», что пространство-время это некий особый квантовый объект. А в квантовой физике это нечто классическое псевдоэвклидовое.
Т.е. дело не в ММИ, а именно в этом. Т.е. суть теории.
Ни к коем случае претензия не к Вам) Скорее в автору.
Есть точка зрения, что в интерпретациях прячется более фундаментальная теория.
Вот здесь подробнее. Есть ли факты/ предположения фактов проверяемых на опыте, которые противоречат другим интерпретациям, но в многомировой они существуют. Те. что проверить, что бы определить «ММИ это теория», а не просто интерпретация.
Модель, которую ученый использует, что бы построить теорию и сама теория вещи разные.
И она часто бывает отброшена по окончании работ.
К сожалению, не все являются сторонниками многомировой интерпретации.
Почему «к сожалению»? Это одна из интерпретаций. Это не теория, она не предсказывает что-то новое, вне квантовой теории. Просто некоторый процессы с ней понимаются легче. Так можно сказать и про другие (популярные) интерпретации. Скажу честно, она мне симпатична и объясняя не физику, квантовую теорию я бы обязательно использовал и ее, но для специалиста, уверен, приверженность (горячая) какой-либо интерпретации, скорее, вредит.
Интерпретации в квантовой теории — точки зрения на эту теорию. Сама же теория не зависит от интерпретации. Желательно хорошо знать и оперировать всеми ими. Т.е. уметь объяснить результаты опыта, как на основе волн электрона, так и на основе суперпозиции состояния. Как используя классическое понятия суперпозиции, так и многомировое. Это является отличием межу поверхностным понимание и глубоким.
Спасибо за статью на интересную тему.
[далее замечания, но не для критики статьи]
Зона ответственности, как термин постоянно требует уточнения. [Не знаю почему. ] Обычно ее понимают как, «одна сущность делает, что-то одно», но это понятие связано сильно с вектором изменением. Есть даже определение у каждого класса/компонента и т.д. только один владелец. Или каждый класс должен иметь один вектор изменения.
Так вот. Самое интересное. Разработчик разбил на слои и компоненты свой проект и получает глубокое удовлетворение и счастье когда ему приходят требования тз совпадающие с вектором изменения, который заложен в проекте (т.е. с архитектурой). Но в реальности действует закон «Вектор изменения предполагаемый разработчиком строго перпендикулярный вектору изменения требуемого заказчиком». И здесь наша архитектура плывет.
Для примера.
Аналогия со сборкой машины. Там где делают колеса. Заказчик прислал ТЗ «сделать диаметр колес в два раза больше». В идеале, это изменение никак не должно затронуть другие цеха. Мы сделали новые колеса и их просто поставили. Это хорошая архитектура. Если потребовалось изменение в других компонентах (например кузова) — похуже.
Еще пример.
Заказчик прислал тз. наше приложение вышло на рынок под маркой «PoBuhay» и требуется подключить еще несовершеннолетних клиентов. С показом газировки (с указанием размера пузырьков). И если мы тапаем на газировку, открывается вьюха с Пяточком с подгрузкой данных по количество калорий и газа. Т.е новый элемент (прям очень) отличается от тех которых мы задумали первоначально. Изменения пройдут по всем слоям. И желательно сделать такие изменения, что при добавление других новых элементов это затронет как можно меньше слоев и классов. Улучшить архитектуру, сделать ее гибче.
Делая архитектуру гибче, мы ее делаем менее понятной. И все выливается в поиск баланса и вопросу «серебряная пуля vs незатратный проект»
Единственную ответственность класса иногда путают с единственной ответственностью функции. SRP это не только для разделения больших абстракций (класс, пакет) на несколько меньших, но и про то что иногда не нужно абстракции делить. SRP всегда требует учета вектора изменения. Для примера.
У нас есть класс который забивает гвозди и рассчитывает фазу луны. По первому взгляду, мы сразу должны его разделить на два. Но если, вдруг, функции забивания гвоздей и расчет фазы обязательно связаны между собой, то делить нельзя. Т.е. если мы уверены, что изменения затрагивающие фазы, предполагают изменения забивания, деление класса на два приведет к тому, что мы вносить изменения не в один класс, а два постоянно. Так мы сделали сложность в поддержке своего кода. И к тому же нарушили KISS.
отчасти Вы правы. Фотон поглощается электроном, затем испускается новый. Это в первом приближении. В случае зеркала — электронная жидкость отражает/ пере испускает фотон подобно отражению. Просто упрощенная модель оказалась настолько близкой к реальности, что ее можно не боясь применять.
Или подобное. Звук отражается от стены. Атомы также возбуждаются, а затем возбуждают обратную волну. Кстати, в этой книге Фейнмана объясняется почему движение фотона подобно движению частицы.
Вопрос из абстрактного мира:
Понятен переход на Kotlin.
Если бы сейчас выбирали технологии, был бы выбор в пользу МVP+Rx? Если писать с нуля?
Или какой-нибудь MVVM+Room+coroutines?
Вопрос скорее точна(верна) ли ОТО или нет? Ответ статьи — красное смещение это еще одно подтверждение. Т.е. ОТО дает предсказуемые результаты. (соотвествующие наблюдению за природой)
Вопрос об альтернативных теориях гравитации в статье не ведется. (Но ОТО, по факту, основная такая теория.)
Так же в статье нет слов что ОТО безошибочна. Такого взгляда нет даже у фанатов ОТО. Просто потому что она не стыкуется с квантовой механикой. (Которую считают, самой точной современной теорией). ОТО нуждается в доработке, но в своих границах дает результаты, которые подтверждаются.
Спасибо за статью. Спасибо за новый взгляд на SOLID.
Читая про сантехников, сразу подумалось «это же LSP». Оказалось не про то.
LSP — это когда интерфейс, вроде, одинаков — фильмы. Вроде и общее есть — сантехники, а вот поведение другое. Ждут от фильмов рассказ о немецких сантехниках, а получают Афоню.
Отличные аналогии, но хотелось бы уточнить «интерфейс»
«Второе, нам нужно описать требования для унифицированного самолета, у него должны быть определенны такие параметры как грузоподъемность...»
Возможно для понимания интерфейса лучше применять аналогию «способ использования» (хотя название не совсем точное). Например «летательный аппарат», «многоразовый аппарат», «грузоперевозчик», «пассажироперевозчик» и тп. Для летательного аппарата достаточно уметь взлетать и лететь. Для многоразового аппарата добавить еще и умение садиться. Для грузоперевозчика достаточно описать грузоподъемность, скорость. И т. п.
Интерфейс относиться к более высокой логике, чем сам класс. Например, транспортная компания будет использовать интерфейс «грузоперевозчик». Туристическая «пассажироперевозчик». Им даже не нужно особо знать, что это вообще самолет. Из-за этого появляется требование о компактности, минималистичности интерфейсов. Кроме того, конкретный тип самолета может реализовать много интерфейсов.
Это демо преобразования неинерциальной системы отсчета в инерциальную. С учетом гипотезы, что законы физики не отличаются в системе с равномерным ускорением и однородным гравитационным полем, это демо подходит для однородного поля тяготения.
Но ОТО начинается там, где мы работаем не только с преобразованием систем отсчетов, а где появляется кривизна пространства времени. Т.е. когда не работают аксиомы Евклида. Например, через две точки на плоскости можно провести две прямые или через одну точку можно провести несколько прямых параллельных данной. Какими бы преобразования не были, такое пространство не отобразиться на плоскость (евклидову).
Суть ОТО — это описание как кривизна (не преобразование систем отсчета, а именно кривизна пространства-времени) порождается массой. (точнее тензором энергии-импульса, но не будем придираться до нудности)
те
1. демо — преобразование равномерно ускоренной системы отсчета, системы в однородном поле в инерциальную систему отсчета. Здесь не нужно ни ОТО, ни пространство-время. Достаточно классический физики, отдельно пространства и отдельно времени. + Эквивалентность гравитации и ускорения.
2. ОТО появляется там, где есть пространство- время (как целое) и его кривизна.
Сказал все, что знал)
Если абстрактно совсем, то DTO — это нарушение ОО парадигмы. Даже если разработать метрики по нарушению ООП, не факт, что от DTO откажутся. Отказ приведет к увеличению сложности и времени разработки и сопровождения (здесь мое мнение). Метрики не могут показать как конкретная команда изменит свою эффективность применяя эти рекомендации.
Не является ли (на Ваш взгляд) это принципиальным отличием от «классической квантовой физики + ОТО», что пространство-время это некий особый квантовый объект. А в квантовой физике это нечто классическое псевдоэвклидовое.
Т.е. дело не в ММИ, а именно в этом. Т.е. суть теории.
Вот здесь подробнее. Есть ли факты/ предположения фактов проверяемых на опыте, которые противоречат другим интерпретациям, но в многомировой они существуют. Те. что проверить, что бы определить «ММИ это теория», а не просто интерпретация.
Модель, которую ученый использует, что бы построить теорию и сама теория вещи разные.
И она часто бывает отброшена по окончании работ.
Почему «к сожалению»? Это одна из интерпретаций. Это не теория, она не предсказывает что-то новое, вне квантовой теории. Просто некоторый процессы с ней понимаются легче. Так можно сказать и про другие (популярные) интерпретации. Скажу честно, она мне симпатична и объясняя не физику, квантовую теорию я бы обязательно использовал и ее, но для специалиста, уверен, приверженность (горячая) какой-либо интерпретации, скорее, вредит.
Интерпретации в квантовой теории — точки зрения на эту теорию. Сама же теория не зависит от интерпретации. Желательно хорошо знать и оперировать всеми ими. Т.е. уметь объяснить результаты опыта, как на основе волн электрона, так и на основе суперпозиции состояния. Как используя классическое понятия суперпозиции, так и многомировое. Это является отличием межу поверхностным понимание и глубоким.
[далее замечания, но не для критики статьи]
Зона ответственности, как термин постоянно требует уточнения. [Не знаю почему. ] Обычно ее понимают как, «одна сущность делает, что-то одно», но это понятие связано сильно с вектором изменением. Есть даже определение у каждого класса/компонента и т.д. только один владелец. Или каждый класс должен иметь один вектор изменения.
Так вот. Самое интересное. Разработчик разбил на слои и компоненты свой проект и получает глубокое удовлетворение и счастье когда ему приходят требования тз совпадающие с вектором изменения, который заложен в проекте (т.е. с архитектурой). Но в реальности действует закон «Вектор изменения предполагаемый разработчиком строго перпендикулярный вектору изменения требуемого заказчиком». И здесь наша архитектура плывет.
Для примера.
Аналогия со сборкой машины. Там где делают колеса. Заказчик прислал ТЗ «сделать диаметр колес в два раза больше». В идеале, это изменение никак не должно затронуть другие цеха. Мы сделали новые колеса и их просто поставили. Это хорошая архитектура. Если потребовалось изменение в других компонентах (например кузова) — похуже.
Еще пример.
Заказчик прислал тз. наше приложение вышло на рынок под маркой «PoBuhay» и требуется подключить еще несовершеннолетних клиентов. С показом газировки (с указанием размера пузырьков). И если мы тапаем на газировку, открывается вьюха с Пяточком с подгрузкой данных по количество калорий и газа. Т.е новый элемент (прям очень) отличается от тех которых мы задумали первоначально. Изменения пройдут по всем слоям. И желательно сделать такие изменения, что при добавление других новых элементов это затронет как можно меньше слоев и классов. Улучшить архитектуру, сделать ее гибче.
Делая архитектуру гибче, мы ее делаем менее понятной. И все выливается в поиск баланса и вопросу «серебряная пуля vs незатратный проект»
У нас есть класс который забивает гвозди и рассчитывает фазу луны. По первому взгляду, мы сразу должны его разделить на два. Но если, вдруг, функции забивания гвоздей и расчет фазы обязательно связаны между собой, то делить нельзя. Т.е. если мы уверены, что изменения затрагивающие фазы, предполагают изменения забивания, деление класса на два приведет к тому, что мы вносить изменения не в один класс, а два постоянно. Так мы сделали сложность в поддержке своего кода. И к тому же нарушили KISS.
Или подобное. Звук отражается от стены. Атомы также возбуждаются, а затем возбуждают обратную волну.
Кстати, в этой книге Фейнмана объясняется почему движение фотона подобно движению частицы.
Понятен переход на Kotlin.
Если бы сейчас выбирали технологии, был бы выбор в пользу МVP+Rx? Если писать с нуля?
Или какой-нибудь MVVM+Room+coroutines?
Вопрос об альтернативных теориях гравитации в статье не ведется. (Но ОТО, по факту, основная такая теория.)
Так же в статье нет слов что ОТО безошибочна. Такого взгляда нет даже у фанатов ОТО. Просто потому что она не стыкуется с квантовой механикой. (Которую считают, самой точной современной теорией). ОТО нуждается в доработке, но в своих границах дает результаты, которые подтверждаются.
Читая про сантехников, сразу подумалось «это же LSP». Оказалось не про то.
LSP — это когда интерфейс, вроде, одинаков — фильмы. Вроде и общее есть — сантехники, а вот поведение другое. Ждут от фильмов рассказ о немецких сантехниках, а получают Афоню.
Возможно для понимания интерфейса лучше применять аналогию «способ использования» (хотя название не совсем точное). Например «летательный аппарат», «многоразовый аппарат», «грузоперевозчик», «пассажироперевозчик» и тп. Для летательного аппарата достаточно уметь взлетать и лететь. Для многоразового аппарата добавить еще и умение садиться. Для грузоперевозчика достаточно описать грузоподъемность, скорость. И т. п.
Интерфейс относиться к более высокой логике, чем сам класс. Например, транспортная компания будет использовать интерфейс «грузоперевозчик». Туристическая «пассажироперевозчик». Им даже не нужно особо знать, что это вообще самолет. Из-за этого появляется требование о компактности, минималистичности интерфейсов. Кроме того, конкретный тип самолета может реализовать много интерфейсов.