Затраты энергии больше. Зато с таким смещенным центром тяжести устойчивость при вертикальном полёте будет намного лучше, чем при горизонтальном.
А второй ряд крыльев придаст устойчивости и маневренность в горизонтальном полёте. Ниже привели примеры как это уже использовалось.
Кажется если поставить двигатели побольше, то в режиме вертикального взлёта будет стабильнее классической схемы.
А так не понятно почему не сделать хотя бы биплан, добавив небольшие крылья в район кабины?
По моему скромному опыту скорее всего проблема в том что ТЗ в принципе не было. Или существовало виде формулировки:"Хочу электронную систему оплаты проезда по дорогам и чтобы работало." В компании сели подумали, прикинули риски с таким ТЗ, что разброс от сайта визитки с прикрученными базами, до нейросетей с распознаванием образов и номеров под любой регион включая всех приезжих. Вот отсюда и получили сумму, добавьте сюда внушительный пакет документации как по гос заказу и саппорт и сумма уже не будет казаться такой большой. А если тут еще и площадку в дата-центре надо поставить то может еще и доплатить нужно будет.
Вопрос в защите интересов работодателя. На это и надо делать упор, т.е. чтобы у работодателя возникли вопросы, нужно ему наступить где-то в конкретно его бизнесе. Если перейти программировать тракторы которые будут продаваться там же где продаются тракторы бывшего работодателя — это проблема, если рынки сбыта разные проблемы не будет, потому что доказать ущерб будет невозможно. Кроме того, нужно смотреть на юрисдикцию договора. В крайнем случае можно релокейтнуться на годик в другой регион или страну пока не истечет срок действия договоров.
Менторство — это не мокание лицом в плохой код. Только у меня появился вопрос, а почему этот "крутой" программист не давал джуну на ревью свой код? Все люди учаться на примерах. И показывать надо не только как делать не надо, но и как делать надо, в том числе на примере своего "идеального" кода.
Я то думал, тут учат робомобили друг с другом общаться, а не с пешеходами. Вот это реально бы помогло. Обмен информацией по ходу движения — "хочу обгонять, ок я не тороплюсь, на встречной никого". Вот это был бы прорыв.
Лучше опцию иметь, чем не иметь. Silver bullet никто не обещал, но если даже нескольким людям это поможет спасти жизнь, будет уже круто. Разумеется, адекватный врач, по телемедецине не будет давать брать на себя ответственность. Он может советовать, но не более. Принимать решение делать или нет может только кто-то на месте.
Господа, объясните пожалуйста в чем смысл минусования коментариев, которые были написаны раньше 1го, но по причине модерации провисели сутки и стали не первыми? Это такой стимул не писать вообще? Ведь возможности отозвать его или отредактировать нет.
Как по мне тут кроется краеугольный камень бизнеса, который сам же бизнес не понимает. Чем больше компания, тем больше издержки по ее управлению, больше информации которую нужно хранить и обрабатывать и нужны совсем другие методы и инструменты, тяжелые и неповоротливые. 1я ступень зрелости — стартап, тут достаточно карандаша и тетрадки чтобы делать все — вести бухгалтерию, документировать продукт, учитывать кто сколько отработал и т.д. А можно вообще в голове держать, если память хорошая. Дальше уже больше сотрудников памяти 1го человека не хватает, тетрадка заканчивается очень быстро и смотреть в нее уже нужно нескольким людям а физически она в одном месте, а нужна она в разных и одновременно. Вот тут подключают IT отдел, трекинговую систему свою Wiki, бухгалтерскую систему. Все это желательно бесплатное, и обычно гибкое, костыляется скриптами иногда падает, но ведь простой 3-5 человек из-за упавшей на час другой системы — это не так дорого. Растем дальше, у нас уже 50-100 человек, и тут уже IT отдел понимает, что в случае чего простой будет у 60-80 человек и систеа обросла костылями и падает чаще и 1 час такого простоя обходится в 1-2 тыс. долларов для компании. В месяц набегает 10-20 тысяч, вот IT это понимает, а бизнес — нет. Спрашивается почему??? Бизнес кричит хочу гибкость хочу плюшки. Расходы от простоя растут, IT изо дня в день бьются с одними и теми же проблемами, бонусов уже давно не видели, потому как этот бюджет съеден падающими сервисами и простоями. Но бизнес же хочем гибкости, а не вложений в стабильную работу. Мотивация падает ниже плинтуса и начинается самый веселый этап — "текучка". И тут понеслось, бизнес кричит хочу быстро, поэтому документации минимум. Старые люди и знания уходят, приходят новые, которым никто не может объяснить как это все работает их бросают на монстра из костылей и без документации и говорят "в бой". В результате этот костыльный мостр загибается под собсвенной тяжестью один раз упавши и не в силах больше подняться.
Господа "бизнес", я вас очень прошу почитайте PMBoK, 2ой этап зрелости компании — бюрократизация и документация, плюс стабилизация систем и стандартизация инструментов. Цель этого этапа ликвидировать критические точки, т.е. людей чей уход однозначно ведет к краху компании. Его нужно просто пережить, лучше помогите своей компании его пережить и выйти дальше в масштабируемость.
Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
А как там с надежностью этих Б/У ступеней? В наш то век когда сделать новый экземпляр дешевле чем ремонтировать старый? Не будет ли дешевле производить новую ступень чем диагностировать старую разбираться что в ней требует ремонта/замены, выполнять работы, тестировать опять и запускать?
К сожалению с редакторами карт Quake и UT не сложилось. А вот за Blizzard'овскими провели много времени. Помню когда нашел программу запуска редактора уровней, вместо запуска игры был очень удивлен. А потом так затянуло, что даже не знаю на что больше времени потратил на игры или создание уровней.
Позволю себе несколько не согласиться с мнением автора, что "программист должен программировать и точка". Программировать и точка может может стажер или еловек оркестр который может сам сделать завершенный продукт. Во всех остальных случаях нужно коммуницировать с окружением, чтобы сообща решать задачи, чтобы не делать басню "Лебедь, рак и щука", да банально чтобы получить повышение. А при коммуникации, главное говорить на "одном языке" с общей системой терминов, поэтому даже программисту необходимо понимать остальных. Я за несколько лет насмотрелся на матерых технарей, которые не умеют доносить свои мысли до иностранных коллег, до менеджеров и т.д. Смотришь на них и печально становится, вроде идеальный программист, разбирается в предмете и продукте как архитектор. А из-за своего убеждения что программист должен программировать, а не заниматься всякой менеждерской ерундой типа митингов — так и сидит на одной должности без повышения лет 10-15. И ждет пока его заметят, подойдут похвалят и вручат билет в светлое будущее на блюдечке с золой каемочкой. Нет, в жизни так не работает. Даже если ты супер-пупер крутой программист и коммитишь патчи, например в ядро Linux, тебе придется еще быть очень красноречивым чтобы объяснить менеджеру, что в этом такого крутого и почему тебе надо больше денег, чем какому-нибудь другому сотруднику с которым он вместе играет в гольф.
Столько сложностей ради взлёта? Проще катапультой запускать и не возить лишних 2 двигателя.
Затраты энергии больше. Зато с таким смещенным центром тяжести устойчивость при вертикальном полёте будет намного лучше, чем при горизонтальном.
А второй ряд крыльев придаст устойчивости и маневренность в горизонтальном полёте. Ниже привели примеры как это уже использовалось.
Ну сами крылышки — утка. А планер с 2мя рядами крыльев — биплан.
Кажется если поставить двигатели побольше, то в режиме вертикального взлёта будет стабильнее классической схемы.
А так не понятно почему не сделать хотя бы биплан, добавив небольшие крылья в район кабины?
Складная третья полка — решит вопрос?
По моему скромному опыту скорее всего проблема в том что ТЗ в принципе не было. Или существовало виде формулировки:"Хочу электронную систему оплаты проезда по дорогам и чтобы работало." В компании сели подумали, прикинули риски с таким ТЗ, что разброс от сайта визитки с прикрученными базами, до нейросетей с распознаванием образов и номеров под любой регион включая всех приезжих. Вот отсюда и получили сумму, добавьте сюда внушительный пакет документации как по гос заказу и саппорт и сумма уже не будет казаться такой большой. А если тут еще и площадку в дата-центре надо поставить то может еще и доплатить нужно будет.
Вопрос в защите интересов работодателя. На это и надо делать упор, т.е. чтобы у работодателя возникли вопросы, нужно ему наступить где-то в конкретно его бизнесе. Если перейти программировать тракторы которые будут продаваться там же где продаются тракторы бывшего работодателя — это проблема, если рынки сбыта разные проблемы не будет, потому что доказать ущерб будет невозможно. Кроме того, нужно смотреть на юрисдикцию договора. В крайнем случае можно релокейтнуться на годик в другой регион или страну пока не истечет срок действия договоров.
Менторство — это не мокание лицом в плохой код. Только у меня появился вопрос, а почему этот "крутой" программист не давал джуну на ревью свой код? Все люди учаться на примерах. И показывать надо не только как делать не надо, но и как делать надо, в том числе на примере своего "идеального" кода.
Я то думал, тут учат робомобили друг с другом общаться, а не с пешеходами. Вот это реально бы помогло. Обмен информацией по ходу движения — "хочу обгонять, ок я не тороплюсь, на встречной никого". Вот это был бы прорыв.
Как по мне тут кроется краеугольный камень бизнеса, который сам же бизнес не понимает. Чем больше компания, тем больше издержки по ее управлению, больше информации которую нужно хранить и обрабатывать и нужны совсем другие методы и инструменты, тяжелые и неповоротливые. 1я ступень зрелости — стартап, тут достаточно карандаша и тетрадки чтобы делать все — вести бухгалтерию, документировать продукт, учитывать кто сколько отработал и т.д. А можно вообще в голове держать, если память хорошая. Дальше уже больше сотрудников памяти 1го человека не хватает, тетрадка заканчивается очень быстро и смотреть в нее уже нужно нескольким людям а физически она в одном месте, а нужна она в разных и одновременно. Вот тут подключают IT отдел, трекинговую систему свою Wiki, бухгалтерскую систему. Все это желательно бесплатное, и обычно гибкое, костыляется скриптами иногда падает, но ведь простой 3-5 человек из-за упавшей на час другой системы — это не так дорого. Растем дальше, у нас уже 50-100 человек, и тут уже IT отдел понимает, что в случае чего простой будет у 60-80 человек и систеа обросла костылями и падает чаще и 1 час такого простоя обходится в 1-2 тыс. долларов для компании. В месяц набегает 10-20 тысяч, вот IT это понимает, а бизнес — нет. Спрашивается почему??? Бизнес кричит хочу гибкость хочу плюшки. Расходы от простоя растут, IT изо дня в день бьются с одними и теми же проблемами, бонусов уже давно не видели, потому как этот бюджет съеден падающими сервисами и простоями. Но бизнес же хочем гибкости, а не вложений в стабильную работу. Мотивация падает ниже плинтуса и начинается самый веселый этап — "текучка". И тут понеслось, бизнес кричит хочу быстро, поэтому документации минимум. Старые люди и знания уходят, приходят новые, которым никто не может объяснить как это все работает их бросают на монстра из костылей и без документации и говорят "в бой". В результате этот костыльный мостр загибается под собсвенной тяжестью один раз упавши и не в силах больше подняться.
Господа "бизнес", я вас очень прошу почитайте PMBoK, 2ой этап зрелости компании — бюрократизация и документация, плюс стабилизация систем и стандартизация инструментов. Цель этого этапа ликвидировать критические точки, т.е. людей чей уход однозначно ведет к краху компании. Его нужно просто пережить, лучше помогите своей компании его пережить и выйти дальше в масштабируемость.
Аналитик в лучшем случае сможет преобразовать объяснения бизнеса в технически поставленную задачу. Прояснить связи между задачами и расставить технические зависимости сможет разве что аналитик с очень хорошим опытом в разработке.
Мне доводится весьма нередко после аналитиков, задавать уточняющие вопросы по Acceptance Criteria, выправлять критерии которые невозможно измерить, указывать что новая story конфликтует с другой иногда уже закрытой пару лет назад. Указывать что в коде присутсвуют workaround, которые когда-то задолго до подключения к проекту закостыляла другая команда, а новый функционал делает этот workaround в дальнейшем безсмысленным и неплохо бы добавить sub-task на рефакторинг с его удалением.
Короче говоря, в контексте Scrum, Lead оценивает постановку задачи в user story и помогает ее разбить на sub-tasks. При высоком уровне зрелости каждого члена команды разработчики/тестировщики, Lead может быть и не нужен. Но по-моему опыту и исследованию знакомого психолога, большинство програмистов интраверты и не любят общаться с не техническими людьми. Вот те немногие программисты экстраверты, которые находят контакты с менеждментом и отлично подходят на роль лида, и они общаются за своих колег которые не хотят/могут построить это общение продуктивно.
Поддерживаю, хочу только еще добавить, что далеко не каждый программист(даже senior) поговорив с "бизнесом" поймет задачу, важность и зачем она нужна бизнесу. TL должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
Позволю себе несколько не согласиться с мнением автора, что "программист должен программировать и точка". Программировать и точка может может стажер или еловек оркестр который может сам сделать завершенный продукт. Во всех остальных случаях нужно коммуницировать с окружением, чтобы сообща решать задачи, чтобы не делать басню "Лебедь, рак и щука", да банально чтобы получить повышение. А при коммуникации, главное говорить на "одном языке" с общей системой терминов, поэтому даже программисту необходимо понимать остальных. Я за несколько лет насмотрелся на матерых технарей, которые не умеют доносить свои мысли до иностранных коллег, до менеджеров и т.д. Смотришь на них и печально становится, вроде идеальный программист, разбирается в предмете и продукте как архитектор. А из-за своего убеждения что программист должен программировать, а не заниматься всякой менеждерской ерундой типа митингов — так и сидит на одной должности без повышения лет 10-15. И ждет пока его заметят, подойдут похвалят и вручат билет в светлое будущее на блюдечке с золой каемочкой. Нет, в жизни так не работает. Даже если ты супер-пупер крутой программист и коммитишь патчи, например в ядро Linux, тебе придется еще быть очень красноречивым чтобы объяснить менеджеру, что в этом такого крутого и почему тебе надо больше денег, чем какому-нибудь другому сотруднику с которым он вместе играет в гольф.