Тоже не понимаю этого. Это же такая же «недобросовестная конкуренция», когда кто-то запретами и высосанными из пальца требованиями по сути продвигает альтернативные продукты, которые хуже по качеству. Хотите конкуренции — создайте лучший продукт, сделайте ему крутую рекламу, запилите эксклюзивные сервисы…
Тот же Касперский почему-то не спешил вложить тонны денег в разработку своей ОС, и ее продвижение, но почему требует предоставления ему эксклюзивных прав по доступу к новой системе.
Я правильно думаю, что большая часть проблем (будь то моно- или поли-) репозиторий возникает из-за следующих факторов:
1. Отсутствие нормальной декомпозиции кода (читай, стремная архитектура с высокой запутанностью между проектами без четких границ этих самых проектов)
2. Отсутствие людей, которые хотят/могут заниматься разделением и рефакторингом взаимодействия проектов внутри компании?
Thank you, author. Very nice introduction to Kalman filters. These techniques are very-very usefull in many control/estimate application. As I know the Kalman filter is applied even to artificial neural netwroks training!
I can only recommend the following work for better understanding:
Simon D. Optimal state estimation // New-York: John Wiley & Sons (2006)
This book was very helpfull when I was a master student :)
По моему опыту «творчество» и «бизнес» противопоставляют не самые лучшие разрабы, у которых «творчество» — это одно из двух:
— бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
— бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова
Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.
А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.
А не планируется никак переписывать внутренности Qt'а с поддержкой C++11/14/17/2a и ближе интегрироваться с stl? Или может быть как-то влиять на этот самый stl и стандарт?
А то QString очень приятно использовать, но некоторые вещи хочется взять из boost'а, некоторые из std (тот же string_view, например) и получается, что в одном проекте в разных неймспейсах 10 видов одних и тех же контейнеров.
Вообще, прям очень любопытно было заодно увидеть биндинги для OpenCV и PCL для Rust'а, вот только это как-то очень долго делать, имхо.
P.S. по вашим ссылкам в части GSL все вызовы плюсовых функций помечены как unsafe. В чем в таком случае будет преимущество использования Rust, если у меня какой-нибудь суровый математический модуль с gpu-оптимизациями? Проще уж тогда к этому моему C++ модулю писать Rust биндинг. Но вызовы модуля мне придется точно так же помечать как unsafe…
С каких пор зарабатывать деньги и ставить своей целью именно их заработок — это плохо? Что плохого в том, что делая отличный продукт — ты требуешь соответствующего вознаграждения? Почему ты должен отдавать бесплатно то, что ты создал, только потому что у остальных нет средств, чтобы за это заплатить?
Хороший список, но я бы еще добавил отдельным пунктом сложность изложения материала. Это частично отражено в седьмом и девятом грехах (ну потому что неподготовленный человек не может ясно объяснить сложные вещи).
Очень приятно, когда докладчику удается объяснить сложные вещи понятными словами, или, хуже, когда простые вещи объясняются так, что без серьезных усилий не разберешься.
Мне кажется, что вы путаете DevOps и какую-то смесь Project-manager'а, Team-lead'а и эникейщика в одном лице :) Попробую пояснить, как я понимаю, кто такие DevOps, ни разу не претендуя на истину в последней инстанции:
Со времени возникновения IT до его текущего состояния прошел очень большой период:
От голых языков программирования с бедными стандартными библиотеками мы пришли к вееру библиотек, сред исполнения, операционных систем, платформ (включая веб, мобильные платформы, серверы, IoT и другие), виртуализации, распределнным по кластерам вычислениям, кроссплатформенной разработке, частому деплою и т.д… Сложность IT-инфраструктуры, необходимой для разработки и выпуска конечного продукта возросла многократно. Если раньше достаточно было написать игру/приложение под Windows, скомпилировать все это msvc-компилятором, протестировать, записать на диск и спокойно продавать, то сейчас для создания какой-нибудь простенькой Веселой фермы с возможностью играть в нее с телефона и из браузера придется развернуть:
1. Окружение для кроссплаформенной разработки (Android, iOS, браузер), с библиотеками для связи с БД, поддержкой API соц. сетей, графикой, нативными библиотеками на устройства и т.д.
2. Систему CI/CD с автоматической пересборкой, автотестами, какой-нибудь распределенной системой контроля версий, типа git'а, чтобы обеспечить работоспособность продукта как на стадии разработки, так и в продакшне.
3. Функционирование всего этого в облаке (как минимум БД + браузерная версия на каком-нибудь популярном фреймворке).
Если речь идет о чем-нибудь более сложном, чем веселая ферма (например, о каком-нибудь крутом вычислительном кластере или сервисе поиска, типа Яндекса, который разрабатывают тысячи людей по всему миру), то все становится еще сложнее.
Собственно, DevOps — это человек, который всем этим занимается. Это далеко не просто сисадмин, который может поднять и настроить какой-нибудь удаленный почтовый сервер по ssh, это человек создающий и поддерживающий всю цепочную инфраструктуру от окружения разработчика до автоматического деплоя всего этого на серверы или устройства пользователей.
Плюсую: Bundle adjustment должен положительно сказаться на результате. Более того, с его помощью «подогнать» изображения друг к другу даже при наличии циклических связей в графе.
Вообще статья навела на мысли об известной реализации склейки изображений:
В этой реализации (ссылки на статьи в основе там же), кажется, решается даже более сложная задача склейки изображений близких сцен (там правда больше «красивости», чем точности). Насколько я помню, в opencv тоже строится некий граф изображений с ребрами-преобразованиями, из которого потом выкидываются лишние по критерию количества inlier'ов между парой изображений.
Понравилась статья, всегда очень любопытно посмотреть на опыт решения такого рода проблем в крупных компаниях.
Я только не совсем понял из текста:
Разработка ведется по модели Trunk based development. Большинство пользователей работает с HEAD или наиболее свежей копией репозитория, полученной из основной ветви, называемой trunk, в которой идет разработка. Фиксация изменений в репозитории осуществляются последовательно. Сразу после коммита новый код виден и может использоваться всеми разработчиками. Разработка в отдельных ветках не приветствуется, хотя ветки могут использоваться для релизов.
Что значит разработка в отдельных ветках не приветствуется? Имеются в виду ветки, в которых может осуществляться долгая параллельная разработка (до недель)? Потому что по ссылке trunkbaseddevelopment.com явно написано, что каждое изменение выделяется в одну ветку (feature branch), которая существует некоторое время (короткое — дни), а потом вливается в репозиторий при помощи мержа. Это не совсем то же самое, что и «каждый отдельный коммит». Или вы заставляете обязательно делать людей squash для всех коммитов в их feature branch, а потом rebase того, что получилось, от trunk (master)? Хотелось бы конкретики :)
А еще я проглядел (или в статье этого нет): какую систему контроля версий вы используете?
Тот же Касперский почему-то не спешил вложить тонны денег в разработку своей ОС, и ее продвижение, но почему требует предоставления ему эксклюзивных прав по доступу к новой системе.
1. Отсутствие нормальной декомпозиции кода (читай, стремная архитектура с высокой запутанностью между проектами без четких границ этих самых проектов)
2. Отсутствие людей, которые хотят/могут заниматься разделением и рефакторингом взаимодействия проектов внутри компании?
I can only recommend the following work for better understanding:
Simon D. Optimal state estimation // New-York: John Wiley & Sons (2006)
This book was very helpfull when I was a master student :)
— бесполезная трата времени на «а давайте еще покрутим параметры — вдруг заработает?» вместо реального анализа проблемы и создания рабочего кода
— бесполезная трата времени на накидывание костылей по всему проекту, «потому что надо быстрее-быстрее из палок и известной субстанции что-нибудь слепить», а потом снова и снова
Нужно понимать, что реальное полезное творчество не может не приносить денег. Если вы в состоянии придумать красивую расширяемую архитектуру — вам с удовольствием за нее заплатят. Если вы пишите красивый, простой и читабельный код — вас возьмут на сильно лучшую зарплату, чем говнокодера, поддерживать «творчество» которого невозможно.
А лень, плохие нестандартные решения, сорванные сроки и т.п. не стоит называть творчеством.
А то QString очень приятно использовать, но некоторые вещи хочется взять из boost'а, некоторые из std (тот же string_view, например) и получается, что в одном проекте в разных неймспейсах 10 видов одних и тех же контейнеров.
Имелась в виду вот эта библиотека: eigen.tuxfamily.org/index.php?title=Main_Page, которая, как назло, линкуется статически с C++ кодом, ибо header-only на шаблонах :P
Вообще, прям очень любопытно было заодно увидеть биндинги для OpenCV и PCL для Rust'а, вот только это как-то очень долго делать, имхо.
P.S. по вашим ссылкам в части GSL все вызовы плюсовых функций помечены как unsafe. В чем в таком случае будет преимущество использования Rust, если у меня какой-нибудь суровый математический модуль с gpu-оптимизациями? Проще уж тогда к этому моему C++ модулю писать Rust биндинг. Но вызовы модуля мне придется точно так же помечать как unsafe…
P.P.S. Как, кстати, у Rust'а с Cuda/OpenCL?
Очень приятно, когда докладчику удается объяснить сложные вещи понятными словами, или, хуже, когда простые вещи объясняются так, что без серьезных усилий не разберешься.
Очевидно, да
Со времени возникновения IT до его текущего состояния прошел очень большой период:
От голых языков программирования с бедными стандартными библиотеками мы пришли к вееру библиотек, сред исполнения, операционных систем, платформ (включая веб, мобильные платформы, серверы, IoT и другие), виртуализации, распределнным по кластерам вычислениям, кроссплатформенной разработке, частому деплою и т.д… Сложность IT-инфраструктуры, необходимой для разработки и выпуска конечного продукта возросла многократно. Если раньше достаточно было написать игру/приложение под Windows, скомпилировать все это msvc-компилятором, протестировать, записать на диск и спокойно продавать, то сейчас для создания какой-нибудь простенькой Веселой фермы с возможностью играть в нее с телефона и из браузера придется развернуть:
1. Окружение для кроссплаформенной разработки (Android, iOS, браузер), с библиотеками для связи с БД, поддержкой API соц. сетей, графикой, нативными библиотеками на устройства и т.д.
2. Систему CI/CD с автоматической пересборкой, автотестами, какой-нибудь распределенной системой контроля версий, типа git'а, чтобы обеспечить работоспособность продукта как на стадии разработки, так и в продакшне.
3. Функционирование всего этого в облаке (как минимум БД + браузерная версия на каком-нибудь популярном фреймворке).
Если речь идет о чем-нибудь более сложном, чем веселая ферма (например, о каком-нибудь крутом вычислительном кластере или сервисе поиска, типа Яндекса, который разрабатывают тысячи людей по всему миру), то все становится еще сложнее.
Собственно, DevOps — это человек, который всем этим занимается. Это далеко не просто сисадмин, который может поднять и настроить какой-нибудь удаленный почтовый сервер по ssh, это человек создающий и поддерживающий всю цепочную инфраструктуру от окружения разработчика до автоматического деплоя всего этого на серверы или устройства пользователей.
Вообще статья навела на мысли об известной реализации склейки изображений:
docs.opencv.org/2.4/modules/stitching/doc/stitching.html
В этой реализации (ссылки на статьи в основе там же), кажется, решается даже более сложная задача склейки изображений близких сцен (там правда больше «красивости», чем точности). Насколько я помню, в opencv тоже строится некий граф изображений с ребрами-преобразованиями, из которого потом выкидываются лишние по критерию количества inlier'ов между парой изображений.
Я только не совсем понял из текста:
Что значит разработка в отдельных ветках не приветствуется? Имеются в виду ветки, в которых может осуществляться долгая параллельная разработка (до недель)? Потому что по ссылке trunkbaseddevelopment.com явно написано, что каждое изменение выделяется в одну ветку (feature branch), которая существует некоторое время (короткое — дни), а потом вливается в репозиторий при помощи мержа. Это не совсем то же самое, что и «каждый отдельный коммит». Или вы заставляете обязательно делать людей squash для всех коммитов в их feature branch, а потом rebase того, что получилось, от trunk (master)? Хотелось бы конкретики :)
А еще я проглядел (или в статье этого нет): какую систему контроля версий вы используете?