Я не о маневре сближения с Землей, а скорее о кейсе, когда отброшенная масса, объясняющая маневр, попадает в Землю, как в наиболее интересный целевой объект.
Интересно - есть ли для этого хотя бы теоретическая возможность?
Проще говоря - носитель сбросил зонд. Импульс сброса придал ускорение носителю. Попадет ли зонд в Землю?
Известен ли временной диапазон приобретения объектом негравитационного ускорения?
Выяснено ли, является ли негравитационное ускорение объекта разовым импульсом (условно - включение двигателя на несколько секунд), или продолжительным (пример - ионнный двигатель, работавший несколько суток или более)?
Если импульс был относительно разовым, то каков его вектор? Есть ли данные?
Если известен вектор разового импульса, то решалось ли уравнение, позволяющее построить поле траекторий отброшенной массы?
Если решалось - есть ли в этом поле траектории, пересекающиеся с Землей?
Любое противопоставление "разработки" и "бизнеса", неважно, какую из сторон вы считаете условно "хорошей", а какую - условно "плохой" - это, конечно же, абсолютное зло.
Если у вас в команде есть и культивируется такое противопоставление - у вас плохая команда и очень плохие управленцы.
Ну, во-первых лучше не использовать автоинкременты, конечно.
Во-вторых первичный ключ сущности не входит в множество данных, описывающих ее значение. В этом и отличие сущности от просто объекта-значения — у сущности есть отдельная идентичность, по идентификатору.
У языка PHP своя спецификация и у байт-кода ZE своя. И это две разные вещи.
Сам байт-код является по сути «интерпретируемым» на виртуальной машине.
И можно себе представить любой другой язык, который компилируется в оп-коды ZE.
Язык PHP требует обязательную стадию компиляции. И назвать его интерпретируемым не получится.
Потому что было еще и двойственное число… Когда оно стало исчезать, часть слов взяли в качестве формы множественного числа старое множественное, а часть — старое двойственное.
Сравните (написание условное!)
одно небо — два небеси — многие небеса
одно око — два очи — многие очеса
Во-первых то, что вы забыли о существовании нагрузочного тестирования говорит лишь о том, что вы забыли о существовании нагрузочного тестирования, а не о том, что «приложению нужен реальный трафик».
Пропускаете этапы разработки — получаете факап с разработкой. Всё логично.
Во-вторых, конечно, любой вменяемый разработчик начал бы проектирование архитектуры не с сущностей ORM, а с вопроса «А какие типовые сценарии выборки и манипуляции данными предполагаются?»
А вот уже из типовых запросов и стали бы рождаться схемы данных. А не наоборот, как у вас.
Абсолютно. Код размещен в репозитории, ссылка в конце статьи. Вы можете его запустить.
А в чем вопрос? Почему я должен быть неуверен?
Я не о маневре сближения с Землей, а скорее о кейсе, когда отброшенная масса, объясняющая маневр, попадает в Землю, как в наиболее интересный целевой объект.
Интересно - есть ли для этого хотя бы теоретическая возможность?
Проще говоря - носитель сбросил зонд. Импульс сброса придал ускорение носителю. Попадет ли зонд в Землю?
Несколько вопросов автору:
Известен ли временной диапазон приобретения объектом негравитационного ускорения?
Выяснено ли, является ли негравитационное ускорение объекта разовым импульсом (условно - включение двигателя на несколько секунд), или продолжительным (пример - ионнный двигатель, работавший несколько суток или более)?
Если импульс был относительно разовым, то каков его вектор? Есть ли данные?
Если известен вектор разового импульса, то решалось ли уравнение, позволяющее построить поле траекторий отброшенной массы?
Если решалось - есть ли в этом поле траектории, пересекающиеся с Землей?
Увидел заголовок, подумал, что будут опять Питон рекламировать. Прочитал статью, не нашел рекламы Питона, поставил плюс ))
Любое противопоставление "разработки" и "бизнеса", неважно, какую из сторон вы считаете условно "хорошей", а какую - условно "плохой" - это, конечно же, абсолютное зло.
Если у вас в команде есть и культивируется такое противопоставление - у вас плохая команда и очень плохие управленцы.
Что мы и видим в вашей статье.
Во-вторых первичный ключ сущности не входит в множество данных, описывающих ее значение. В этом и отличие сущности от просто объекта-значения — у сущности есть отдельная идентичность, по идентификатору.
Сам байт-код является по сути «интерпретируемым» на виртуальной машине.
И можно себе представить любой другой язык, который компилируется в оп-коды ZE.
Язык PHP требует обязательную стадию компиляции. И назвать его интерпретируемым не получится.
Так в чем разница?
Но я восхищен
Я имею в виду, написать что-то типа
при условии, что конструктор класса Collection может принять массив, как аргумент?
Может через атрибуты как-то попробовать, придумать какой-нибудь #[Init]?
Но аргументы атрибутов тоже должны быть компайл-тайм константами…
PHP на данный момент это язык со слабой динамической типизацией, стандартная реализация которого является компилируемой.
Ну а в чем принципиальная разница? Кроме того, что PHP не компилирует неиспользуемые файлы?
Ну тогда и Java тоже называйте «интерпретируемым» языком. Ведь в ней, как и в PHP:
Потому что было еще и двойственное число… Когда оно стало исчезать, часть слов взяли в качестве формы множественного числа старое множественное, а часть — старое двойственное.
Сравните (написание условное!)
одно небо — два небеси — многие небеса
одно око — два очи — многие очеса
Здесь знак вопроса — точно не опечатка?
Пропускаете этапы разработки — получаете факап с разработкой. Всё логично.
Во-вторых, конечно, любой вменяемый разработчик начал бы проектирование архитектуры не с сущностей ORM, а с вопроса «А какие типовые сценарии выборки и манипуляции данными предполагаются?»
А вот уже из типовых запросов и стали бы рождаться схемы данных. А не наоборот, как у вас.
Что-то вроде конечных автоматов?
Да не, шизофазия, разумеется...