Часть команды работает на VS Code, часть на QtCreator. Стэк не очень распространённый: C — под микроконтроллеры, С++ — под QNX и Windows и Python. В QtCreator до недавнего времени не очень ладилось с Python. Поэтому стали смотреть в сторону. CLion несколько разочаровал. Хоть и не заявлена поддержка qcc, но обламаться потому что в IDE наглухо вшиты ключи компиляции под gcc, которые не поддерживаются в qcc было обидно. Неужели нельзя было это в конфигурацию вынести?
Попробую еще WSL2. Но моя попытка работать с WSL убилась об отсутствие поддержки tun интерфейсов. А VPN заказчика подразумевает их использование для подключения к инфраструктуре. Так что далеко не всё там идеально.
Мне кажется мы дискутируем о деталях. Биплан — это схема с 2мя рядами крыльев в любой конфигурации. Частным случаем которой является биплан-тандем. Расположение рядов вертикально или горизонтально не меняет факта что есть 2 ряда крыльев. Трипланы тоже бывают разные. Как с вертикальной конструкцией, так и горизонтальной, СУ-33 или СУ-47.
Затраты энергии больше. Зато с таким смещенным центром тяжести устойчивость при вертикальном полёте будет намного лучше, чем при горизонтальном.
А второй ряд крыльев придаст устойчивости и маневренность в горизонтальном полёте. Ниже привели примеры как это уже использовалось.
Кажется если поставить двигатели побольше, то в режиме вертикального взлёта будет стабильнее классической схемы.
А так не понятно почему не сделать хотя бы биплан, добавив небольшие крылья в район кабины?
По моему скромному опыту скорее всего проблема в том что ТЗ в принципе не было. Или существовало виде формулировки:"Хочу электронную систему оплаты проезда по дорогам и чтобы работало." В компании сели подумали, прикинули риски с таким ТЗ, что разброс от сайта визитки с прикрученными базами, до нейросетей с распознаванием образов и номеров под любой регион включая всех приезжих. Вот отсюда и получили сумму, добавьте сюда внушительный пакет документации как по гос заказу и саппорт и сумма уже не будет казаться такой большой. А если тут еще и площадку в дата-центре надо поставить то может еще и доплатить нужно будет.
Вопрос в защите интересов работодателя. На это и надо делать упор, т.е. чтобы у работодателя возникли вопросы, нужно ему наступить где-то в конкретно его бизнесе. Если перейти программировать тракторы которые будут продаваться там же где продаются тракторы бывшего работодателя — это проблема, если рынки сбыта разные проблемы не будет, потому что доказать ущерб будет невозможно. Кроме того, нужно смотреть на юрисдикцию договора. В крайнем случае можно релокейтнуться на годик в другой регион или страну пока не истечет срок действия договоров.
Менторство — это не мокание лицом в плохой код. Только у меня появился вопрос, а почему этот "крутой" программист не давал джуну на ревью свой код? Все люди учаться на примерах. И показывать надо не только как делать не надо, но и как делать надо, в том числе на примере своего "идеального" кода.
Я то думал, тут учат робомобили друг с другом общаться, а не с пешеходами. Вот это реально бы помогло. Обмен информацией по ходу движения — "хочу обгонять, ок я не тороплюсь, на встречной никого". Вот это был бы прорыв.
Лучше опцию иметь, чем не иметь. 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 должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.
Часть команды работает на VS Code, часть на QtCreator. Стэк не очень распространённый: C — под микроконтроллеры, С++ — под QNX и Windows и Python. В QtCreator до недавнего времени не очень ладилось с Python. Поэтому стали смотреть в сторону. CLion несколько разочаровал. Хоть и не заявлена поддержка qcc, но обламаться потому что в IDE наглухо вшиты ключи компиляции под gcc, которые не поддерживаются в qcc было обидно. Неужели нельзя было это в конфигурацию вынести?
Попробую еще WSL2. Но моя попытка работать с WSL убилась об отсутствие поддержки tun интерфейсов. А VPN заказчика подразумевает их использование для подключения к инфраструктуре. Так что далеко не всё там идеально.
А все качали навык лука на людоеде, который не мог добраться к персонажу через деревья? Оставляя компьютер включенным на ночь.
Мне кажется мы дискутируем о деталях. Биплан — это схема с 2мя рядами крыльев в любой конфигурации. Частным случаем которой является биплан-тандем. Расположение рядов вертикально или горизонтально не меняет факта что есть 2 ряда крыльев. Трипланы тоже бывают разные. Как с вертикальной конструкцией, так и горизонтальной, СУ-33 или СУ-47.
Столько сложностей ради взлёта? Проще катапультой запускать и не возить лишних 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 должен кроме прочего выступать связующим звеном, которое сможет выслушать/вычитать "поток сознания" бизнеса(менеджеров), переварить это дело, разобрать как его лучше сделать или может вообще лучше не делать или поменять местами порядок выполнения задач, что сократит "критический путь" достижения цели и изложить уже в понятной техническим людям(разработчикам) форме. Грубо говоря он должен защищать команду от менеджеров и давать им комфортно работать и выступать переводчиком с бизнес языка на технический язык.