Все электроракетные движки страдают одним небольшим недостатком. Они превращают высоко организованную форму энергии (электричество) в менее организованную (движение ракеты). Для этого безобразия придётся ещё и радиаторы городить.
Касательно гравиманёвров — конечно же нужно использовать эффект Оберта возле Солнца либо Юпитера. Всё остальное — всякие ионники и парусы — от лукавого
У нас тут отправить АМС к спутникам Марса не могут уже лет 30, хотя пара попыток была, а технически это ещё проще, чем достигнуть поверхности Луны.
Для науки один конкретный межзвёздный объект конечно интересен, однако предпочтиельнее была бы статистика. Часто ли имеют вытянутую форму, средний хим. состав и т.п.
Намного проще протереть объективы получше и неспеша готовиться к близкому перехвату следующего межзвёздного объекта лет 10, чем догонять лет 30 Оумуамуа и перехватывать на расстоянии 100-200 АЕ от Земли, где даже связь будет уже затруднена.
Добавил оценки количества таких объектов в Солнечной Системе. Оценки опираются на единственном факте обнаружения вместо вменяемой выборки, поэтому должны считаться очень грубыми.
За pipeline должны отвечать всякие release инженегры.
За то, что QA тестирует по требованиям, которых разработчики не видели, последние ответственность нести не должны, я это специально оговорил.
Если требований по performance также не было, то это тоже не проблемы разработчиков.
В противном случае разработчик превращается в человек-оркестр, обязанный всем и вся, а также обязанный предугадать, сколько миитингов запланирует ему менеджер отняв у него время, когда он заболеет, сколько необходимой ему документации отсутствует — только чтобы оценить не очень нужный ему дъю дэйт. И такой разработчик довольно быстро уйдёт из Badoo. А разработчик ресурс ценный и на дороге не валяется, это чтоб ваш бизнес знал (а он таки знает). По моим наблюдениям все срывы сроков происходят по большей части из-за организационного бардака в компаниях и некомпетентности менеджеров, у которых 7 пятниц на неделе и 8 митингов. Почему-то современные методологии уходят от понятия физического времени, заменяя их story pointами. И задача менеджеров конвертировать story points в физическое время и даты, разработчика это парить вообще не должно.
Да, между "готово" у разработчика и "принято" у кастомэра ещё целая уйма задач, разработчика особо не касающихся и это проблемы продукт оунера/менеджера. Но в статье как-то акцентируется внимание на том, что разработчик несёт за всё ответственность, хотя вовремя сделанная разработчиками фича может не попасть в продакшн по целому ряду других причин. Pipeline сломат, QE несогласны, т.к. напрограммировали по одним требованиям, а тестируют по другим, performance просел, не дали времени на внятную валидацию и многое другое.
Честно говоря, много текста, содержащего лишь банальность, которая, кроме прочего ещё и разбивается при первом же столкновении с реальностью. Работники внезапно берут дэйоффы по срочным делам, заболевают, кто-то отключает электричество в лабе, интернет и ещё более 9000 причин мелких помех. Дъю дэйт хорошо подходит для фичи, над которой работает как минимум несколько чедовек, чтобы неизбежно возникающие ауты сглаживались в предсказуемую статистику, среднюю температуру по больнице. Спрашивать дъю дэйт с каждого одного человека не слишком корректно и попахивает карательным микроменеджментом.
Из свежего опыта общения с иностранными коллегами — фразы, что вводили меня в замешательство:
Денех всё равно не дадут. Надо мыслить реалистичнее и оттачивать поиск подобных объектов в промышленных масштабах
Все электроракетные движки страдают одним небольшим недостатком. Они превращают высоко организованную форму энергии (электричество) в менее организованную (движение ракеты). Для этого безобразия придётся ещё и радиаторы городить.
Касательно гравиманёвров — конечно же нужно использовать эффект Оберта возле Солнца либо Юпитера. Всё остальное — всякие ионники и парусы — от лукавого
У нас тут отправить АМС к спутникам Марса не могут уже лет 30, хотя пара попыток была, а технически это ещё проще, чем достигнуть поверхности Луны.
Для науки один конкретный межзвёздный объект конечно интересен, однако предпочтиельнее была бы статистика. Часто ли имеют вытянутую форму, средний хим. состав и т.п.
Намного проще протереть объективы получше и неспеша готовиться к близкому перехвату следующего межзвёздного объекта лет 10, чем догонять лет 30 Оумуамуа и перехватывать на расстоянии 100-200 АЕ от Земли, где даже связь будет уже затруднена.
Я не могу впихнуть в загаловок полное объяснение его необычности и весь контекст
Объект уже пару месяцев как на отлётной траектории
Не так. Ибо на объекты в ОО влияют звёзды, а планеты СС влияют уже на "выбитые" оттуда объекты
Я думаю, что если бы U1 не проходил бы «подозрительно близко», никто бы его просто не обнаружил и не фантазировал бы на тему парашюта Зубрина :)
Да, в более-менее крупных проектах/компаниях они есть, представьте
За pipeline должны отвечать всякие release инженегры.
За то, что QA тестирует по требованиям, которых разработчики не видели, последние ответственность нести не должны, я это специально оговорил.
Если требований по performance также не было, то это тоже не проблемы разработчиков.
В противном случае разработчик превращается в человек-оркестр, обязанный всем и вся, а также обязанный предугадать, сколько миитингов запланирует ему менеджер отняв у него время, когда он заболеет, сколько необходимой ему документации отсутствует — только чтобы оценить не очень нужный ему дъю дэйт. И такой разработчик довольно быстро уйдёт из Badoo. А разработчик ресурс ценный и на дороге не валяется, это чтоб ваш бизнес знал (а он таки знает). По моим наблюдениям все срывы сроков происходят по большей части из-за организационного бардака в компаниях и некомпетентности менеджеров, у которых 7 пятниц на неделе и 8 митингов. Почему-то современные методологии уходят от понятия физического времени, заменяя их story pointами. И задача менеджеров конвертировать story points в физическое время и даты, разработчика это парить вообще не должно.
Да, между "готово" у разработчика и "принято" у кастомэра ещё целая уйма задач, разработчика особо не касающихся и это проблемы продукт оунера/менеджера. Но в статье как-то акцентируется внимание на том, что разработчик несёт за всё ответственность, хотя вовремя сделанная разработчиками фича может не попасть в продакшн по целому ряду других причин. Pipeline сломат, QE несогласны, т.к. напрограммировали по одним требованиям, а тестируют по другим, performance просел, не дали времени на внятную валидацию и многое другое.
Честно говоря, много текста, содержащего лишь банальность, которая, кроме прочего ещё и разбивается при первом же столкновении с реальностью. Работники внезапно берут дэйоффы по срочным делам, заболевают, кто-то отключает электричество в лабе, интернет и ещё более 9000 причин мелких помех. Дъю дэйт хорошо подходит для фичи, над которой работает как минимум несколько чедовек, чтобы неизбежно возникающие ауты сглаживались в предсказуемую статистику, среднюю температуру по больнице. Спрашивать дъю дэйт с каждого одного человека не слишком корректно и попахивает карательным микроменеджментом.
Мне кажется дистрибутив Alpine получил огромную популярность благодаря контейнерам