Как убедить тимлида притянуть в проект Boost

Опровергнуть меня легко - давай в студию WinAPI вызов из kernel/user/winsock со сломанным поведением.

я тебе не дам код, потому что а) он закрытый и работал в Сбербанке б) я уже десять лет не работаю с маздаем и не собираюсь, слава макаронному монстру! но я разных багов, связанных с несовместимостью и кривыми апдейтами, я там видела сотни. тем более что инсталляций софта было дофига по всей стране, на разных конфигурациях. и все баги и глюки стекались ко мне и мне всё это приходилось разгребать. кроме разнообразных API, завёрнутых в ifdef'ы, там было много чего ещё весёлого. как-то раз, под новый год, мелкософт поломал математическую библиотеку плюсов. каким-то кривым апдейтом. из-за этого мне месяц полоскали мозги: почему в одном из отделений софт наглухо падает. оказалось - мелкий апдейт осла (осёл у них зачем-то стоял на сервере) уронил всё. там был банальный сегфолт из-за того, что они сменили сигнатуру одной из функций. таких приколов было много.

у мелкософта мне попадались даже баги в стандартных библиотеках и компиляторе. я как-то добралась сквозь все уровни техсуппорта до разработчиков с репортом о баге. лет через пять мне вдруг пришло письмо от мелкософта: мы пофиксили баг в компиляторе, о котором вы нам сообщали! охренеть. у меня тогда уж и маздая-то нигде не было. в общем, я не жалею, что я свалила с маздая и с ужасом вспоминаю весь этот мрак.

но то, что там до сих пор постоянные поломки от версии к версии, от сервиспака к сервиспаку - в этом я не сомневаюсь ни на минуту. индусский код стал только ещё более индусским.

Неверный в корне посыл.

Для сравнения у меня недавно был опыт переписывания мелкого java веб приложения на python. При одинаковом функционале код получился примерно в 7 раз короче (не считая шаблонов для шаблонизатора, но это спорный вопрос код это или данные). И времени я потратил в 20 раз меньше (буквально) (но тут ещё имеет место быть разница в квалификации и отсутвие фазы сбора требований и проектирования интерфейса).

Т.е. замер по количеству строчек совершенно не подходит. Плюс есть эмпирическое наблюдение, что вторая реализация почти всегда выходит компактнее, чем прототип (хотя прототип на плюсах это конечно сильно).

Какайа каноничная шестёрочка в треде.

Какайа каноничная шестёрочка в треде.

:-) :-) :-) :-) :-) :-)

Опять же, не забываем что в случае переписывания, особенно если требования не надо рёверсить, можно избавится от детских болезней проотипа на этапе проектирования. Что потенциально удешевляет поддержку от «в разы» до «на порядки». Раз дают денег на велосипеды, не исключено, что дадут и на r&d перехода на другую технологию.

ps: boost в нормальные проекты никто не тянет, у него репутация либы для наколенников-школьников

Ну-ну.

Школьников скорее выдают такие комментарии.

Так как тред зашёл в тупик, то я считаю нужным немного подытожить сие. Выслушав кучу мнений и уважая каждую точку зрения и учитывая тот факт, что пожалуй все, кто тут ответил, имеют опыт промышленной разработки как минимум больше чем у меня (а у многих этот показатель относительно меня исчисляется в разах, а то может и в десяток раз), к чему я пришёл:

1) Со сторонними либами, даже вроде не совсем левыми, а такими как Boost, никто маятся не хочет, так как: бояться поломки при будущем релизе и потенциальной головной боли при апдейте(а никому эта боль не нужна, и свой велосипед не сломается не по своей вине), то, что решение серьезной библиотеки не всегда является лучше твоего наколенного решения ввиду возможного оверхеда, увеличения времени компиляции, усложнения деплоя, etc.

2) Люди любят писать свои велосипеды, даже если они не совсем тривальны и зачастую можно найти уже готовый протестированный кучей тестов и людей решение.

3) При мысли привнести что-то новое надо сделать кучу работы по доказательству того, что ты не просто так разбазариваешь бюджет, а делаешь что-то полезное и что в будущем принесёт твоё изменение для проекта (а это сделать не так просто на самом деле).

Наверняка я что-то ещё забыл, но это неважно.

Прототипированием на плюсах заниматься, имхо, глупая затея. У меня опыта переписывания проекта с одногоязыка на второй не было (я только переводил один проект с Си на С++, но то был несерьёзный проект),так что верю Вам наслово.

Не знаю насколько я школьник (в душе так точно), однако, я наблюдал тенденцию постепенного выпиливания boost в нескольких проектах, ведущего у улучшению производительности и уменьшению стоимости поддержки. Из opensource можно посмотреть на ceph, если я ничего не путаю.

Ну и заодно избавится багов в трекере типа этого

У них в репе же буст лежит: https://github.com/ceph/ceph/tree/master/src

я тебе не дам код

А я не просил у тебя код, я просил у тебя конкретный вызов WinAPI из ключевых библиотек системы.

И, я так понимаю, тебе нечего предъявить.

мелкософт поломал математическую библиотеку плюсов

А при чём тут WinAPI ?

мелкий апдейт осла (осёл у них зачем-то стоял на сервере) уронил всё. там был банальный сегфолт из-за того, что они сменили сигнатуру одной из функций

Подожди, подожди. То есть, ты написала софт для сервера, который должен был бы работать без IE, но он у тебя падал из-за того, что вызывал какую-то функцию IE с несовместимыми аргументами? И виноват в этом почему-то Microsoft?

у мелкософта мне попадались даже баги в стандартных библиотеках и компиляторе.

КАКОЙ УЖАС !!!!11111 То ли дело НЕ Microsoft. НИ ЕДИНОГО разрыва БАГА ни в копиляторах, ни в библиотеках. Во всех и всегда.

я уже десять лет не работаю с маздаем
то, что там до сих пор постоянные поломки от версии к версии, от сервиспака к сервиспаку - в этом я не сомневаюсь ни на минуту

Не иначе как windows update из астрала обновления качает.

индусский код стал только ещё более индусским.

Учитывая всё вышесказанное тобой, я бы предпочёл индусский код отечественному.

однако, я наблюдал тенденцию постепенного выпиливания boost в нескольких проектах

И о чём это говорит? Ну кроме как о «тенденциях в нескольких проектах»?

Заглянул в репу ceph, увидел кучу использований буста, закрыл. Честно говоря, плохо представляю как проследить «тенденции» без тщательного изучения коммитов, а этим заниматься откровенно лень.

У меня вот более положительный опыт использования буста, тем не менее, не тороплюсь делать выводы о том, что он нужен всем без исключения. С тем, что там есть не самые удачные, удобные или быстрые вещи спорить смысла нет, как и с тем, что велосипед под конкретную задачу может быть сильно быстрее. Вот только их ещё надо писать и потом отлаживать и не всегда есть смысл этим заниматься, особенно если нужна не одна платформа.

А ещё можно полистать список пользователей на их сайте.

нет. я просто не буду поднимать вопросы десятилетней давности. мне лень. ты просто тролль на форуме. а у меня архивы со старым кодом хотя и лежат, на всякий случай, но за ненадобностью свалены на винты, которые давно уж покоятся с миром где-то в шкафу. там этого добра навалом. но маздая у меня больше нет ни дома, ни на работе. так что мне ничего оттуда не пригодится и можно это всё похоронить и вздохнуть с облегчением. более того, я не стану на лорчике обсуждать половые проблемы маздая и его кривую архитектуру. мне ещё и дрова приходилось под это УГ писать. и бОльшего извращения я в жизни не видела. так что там даже на уровне ядра были косяки и поломки с несовместимостью API, особенно когда они сделали рывок и попытались в 64 бита. но поленились сделать всё нормально и сделали через одно место. поэтому посыпались все старые дрова. именно из-за того, что переделали сигнатуры некоторых функций. но уже в ядре, что было хуже. и отлаживать было неудобно и я коды ошибок с синих экранов наизусть помнила. в любом случае, это всё гнусный оффтоп и пусть маздай горит синим пламенем. я с ним намудёхалась за много лет от ядра до приложений верхнего уровня и больше не хочу к нему возвращаться ни как программист, ни как юзер.

и да, в отличие от мелкософта, все баги, которые я репортила в никсовые проекты, от ядра до мелких библиотек, были исправлены очень оперативно. а не через пять лет. но даже если бы не были, я бы могла просто взять и исправить сама. в этом и есть плюс опенсорца.

ты просто тролль на форуме.

Правильно, нечего ответить - объяви собеседника троллем.

посыпались все старые дрова. именно из-за того, что переделали сигнатуры некоторых функций. но уже в ядре

Но ты их, конечно же, не приведёшь, потому что они все записаны в исходниках, которые на винтах, которые в яйце, которое в ларце, которое на дубе, а дуб на острове, и мы всё поняли.

все баги, которые я репортила в никсовые проекты, от ядра до мелких библиотек, были исправлены очень оперативно

Давай ты будешь сказки своим детям рассказывать?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823186

32-ух битный Chromium уже год падает на самой обыкновенной янедкс-почте.

У меня, в отличие от тебя, есть факты.

Ну ты смотри не на использования а на выпиливания, мне лень искать если честно, что бы тебя в чём то переубедить, можешь поверить на слово или поискать сам ;)

У меня тоже - исключительно положительный опыт использования буста (кроме хроно, имхо, самый убогий временной api что в стандарте, что в бусте, особенно по производительности на некоторых задачах). Однако, велосипеды в итоге всё равно оказываются лучше когда изготовлены квалифицированным велосипедоделами. В общем, бывает так что boost становится узким местом, бывает что и не становится. Как general purpose - вполне себе, один из лучших, как серебрянная пуля и всегда лучше великов - точно нет. Притом даже великов на старте.

Т.е. если ты например нагнал тим профессиональных велосипедоделов не факт что имеет смысл тянуть буст и в начале. Хотя, скорее всего оказалось бы не лишним, что бы хотя бы проверить идею (но эт если денег хватает, а если надо рискнуть и написать что то что выбьется на рынке сразу за счёт скорости работы, пусть и не стабильное...).

Коротенький и наглядный алгоритм выбора api, что бы понять переход от либы к велику:

Нам нужны портабельные потоки, утилизирующие железо и интерфейсы ОС по максимуму.

• - Давайте возьмём std::thread - потоки же. - Не, там нет работы с tls и cancellation points
• - Ок, давайте тогда возьмём boost::thread. - Аффинити завезли? Поддержку numa? Имена потоков?
• - Возьмём tbb? - Да он стоит (нашему коммерческому проекту) как самолёт ты чё сдурел, под win и линух я напишу за пару недель и ещё 10 недель на отладку и тестирование

можешь поверить на слово или поискать сам ;)

Да я, в общем-то, верю. Просто там ещё выпиливать и выпиливать. В любом случае, можно найти и контрпримеры.

Т.е. если ты например нагнал тим профессиональных велосипедоделов не факт что имеет смысл тянуть буст и в начале.

Ситуации, понятно дело, бывают разные, но вот у нас команда не самая маленькая и отличные специалисты имеются, но что характерно работы хватает и без переписывания буста. Причём разработка проходит не в режиме «как можно больше фич до релиза», находится время и для «всяких там рефакторингов» и оптимизациями заниматься приходится, но последние как-то больше приходятся на алгоритмы и структуры данных, а не на переписывание зависимостей.

Если ты такой умный, предлагаю организовать свою софтверную компанию и стать в ней тимлидом

Сперва добейся?

Ну и это серьёзно?.. Тимлиды оказывается уже «организаторы софтверных компаний»?

Я ж исключительно в контексте топика, не всё молотком единым забивать.

У меня например сейчас в работе условно два продукта, один использует другой, в в том что в базе - дело на велосипедах, вполне поддерживаемо, а главное расширяемо без плясок с сообществом или саппортом, скорости действительно выигрываются. В том что выше понаписано - чуть менее чем всё на boost (кроме как раз работы со временем :)) и тоже отлично работает и по скорости хватает. В обоих буст успешно используется в тестах (это кстати хорошее окошко для ТС в его благородном порыве показать лиду какой он дурак :)) Мне даже последнее время стал больше нравится boost_test чем gtest (как минимум возможностью пилить множественные фикстуры и их композицию без наследования). zamazan4ik - лови неинтрузивную идею.

Но ты их, конечно же, не приведёшь, потому что они все записаны в исходниках, которые на винтах, которые в яйце, которое в ларце, которое на дубе, а дуб на острове, и мы всё поняли.

это ты верно понял. ты не заслужил такого внимания, чтобы я свою задницу подняла и побежала сломя голову добывать какие-то исходники столетней давности и вспоминать в деталях все говна от маздая. я не хочу колупаться в этой каналье, даже если бы были на то причины. но даже причин нет.

Давай ты будешь сказки своим детям рассказывать?

не держу спиногрызов. не умею рассказывать детям сказки. поэтому извиняй, не могу тебе ничем помочь.

32-ух битный Chromium уже год падает на самой обыкновенной янедкс-почте.

у меня нет проприетарного хромиума и я не пользуюсь яндексом. но у меня самое последнее ядро, самые свежие версии всего софта, собранные из сорцов. и всё работает! более того, у меня дохрена старого железа, на котором 32-битный софт стоит. и там много ручных патчей, потому что железо нестандартное. и тоже всё работает. наверное, тут что-то связано с кривизной рук.

Что-то что-то менять, нужны конкретные оценки затрат и профита, а не пафос. Если менять выгодно - меняют, если не выгодно - не меняют. Всё просто.

проприетарного хромиума

лел

ты не заслужил такого внимания, чтобы я свою задницу подняла

Но, я надеюсь, ты всё же проскакала тысячу миль, чтобы сообщить мне об этом? ;)

не умею рассказывать детям сказки

Этот тред - прямое опровержение твоих слов.

у меня нет проприетарного хромиума

нет проприетарного хромиума

проприетарного хромиума

хромиума

проприетарного

Тебе, случайно, врачи никаких таблеток не прописывали? У меня ощущение, что либо ты приняла таблетки без ведома врачей, либо пропустила приём выписанных.

а труп куда деть

Ах, да.

я не хочу колупаться в этой каналье

За это - отдельное спасибо.

Возьмём tbb? - Да он стоит (нашему коммерческому проекту) как самолёт ты чё сдурел, под win и линух я напишу за пару недель и ещё 10 недель на отладку и тестирование

Intel® Parallel Studio XE (это как бы самое дорогое что я нашел на сайте и куда входит tbb) From $2,949 - это как самолет? Сколько стоят 10 недель работы программиста, способного адекватно написать либу потоков с поддержкой тобой перечисленного?

- Возьмём tbb? - Да он стоит (нашему коммерческому проекту) как самолёт ты чё сдурел, под win и линух я напишу за пару недель и ещё 10 недель на отладку и тестирование

Там вроде лицензию сменили с GPL на Apache 2.0 прошлой осенью.

Ну, видимо уже не как самолёт. Но я думаю цена там всё таки за лицензию, и возможно на разработчика в год?

Как убить тимлида и притянуть в проект Boost

fix

Я, признаюсь - не очень слежу :) Это была просто наглядная модель рассуждений с более менее реалистичными примерами.

Да и всё меняется, была вроде бесплатная parallel studio, а потом то ли пропала, то ли запрятали её на сайте прост.

Сперва добейся?

Не сперва добейся, а если человек считает себя умнее тимлида, то какой смысл ему работать под его руководством? :-) Логичнее стать тимлидом, организовать что-то своё, чем пытаться навязать свои хотелки кому-то :-) Ну а если не хочешь или не можешь, то работай под чьим-то руководством, получай свою зарплату :-)

Ну и это серьёзно?..

Да, это серьёзно :-)

Тимлиды оказывается уже «организаторы софтверных компаний»?

Оказывается, да :-) Правда, когда ТС организует компанию и станет в ней тимлидом, может прийти его подчинённый за советом как убедить тимлида выпилить буст, ибо он сложный и для итерации по директориям можно обойтись нативным API :-) И опять начнётся дискуссия не о чём и такие вот вопрос, как у тебя :-) Лол :-)

Прототипировать можно на чём угодно, это зависит от условий. Но нужно понимать отличия требований к прототипу и требований к продукту. Ну и общее правило неиспользования кода прототипа в продукте.

Не дорос я до тимлида пока что.

так и не мешай человеку делать то что ему нравится

В нормальных конторах технические вещи принято обсуждать. «Делай что говорят» могут сказать джуну работающему пару дней. Иначе тимлиду придётся думать за всех, у ного что-нибудь треснуть может. Очень часто бывает что принятые в проекте решения откатывают. В этом нет ничего страшного, если это в пределах разумного. Если нет более срочных задач, тимлид может попросить написать маленький прототип, демонстрирующий преимущество (которое на словах может не быть очевидным). Но обычно такие вещи записываются в технический долг до лучших времён, так как нужно делать релиз и править баги. Думать о таких вещах лучше на фазе проектирования, если ещё есть смысл её запускать на этом этапе проекта.

В некоторых случаях это будут просто хедеры.

Очень многие библиотеки Boost, хоть и являются чисто заголовочными, но в конечном итоге зависят от libboost-system, libboost-thread и, кажется, libboost-date-time, которые вовсе не заголовочные (а уж от каких заголовочных они зависят так сразу и не скажешь). Так что действительно заголовочных библиотек в бусте очень мало.

Хотя, возможно, после добавления в Boost поддержки c++11 они стали убирать из него зависимости от других бустовых библиотек в тех местах, когда нужная функциональность поддерживается стандартной библиотекой (типа использования once_flag из стандартной библиотеки вместо бустовой).

В любом крупном проекте почти весь c++ переписан на себе самом и кривые поделки, чем является буст в таких проектах всегда свои.

Проблема с хромиумом это во-первых закрытая разработка как и в андроиде, а ещё если ты таки решишься в него залезть, то тебе предстоит слойить уйму фана, так как сборка хромиума дело весьма нетривиальное... Мозилла гораздо в этом плане less evil, если таки осилишь вытянуть репозиторий. Поэтому баги хромиума будут висеть до второго пришествия, если фиксы на них не интересны самому гуглу.

у нас пока что юнит тестов на этом проекте нет, но будет использоваться gtest

Вообще, быть в чём-то умнее тимлида не зазорно и обычно не создаёт проблем. Задачи сильно разные. Чай не боги горшки обжигают. Здоровая дискуссия - признак нормального развития проекта. Я не говорю при этом про срачики на кухне, а про обсуждение решений, почему они такие, что привело к ним. Это позволяет всем немного прокачать скиллов. Когда все сидят кругом как сычи и каждый делает свою работу не интересуясь работой других - это не нормально и часто приводит к забавным проблемам в проекте.

В нормальных конторах технические вещи принято обсуждать.

Принято обсуждать? :-) На здоровье :-) Только OP уже обсудил с тимлидом использование буста, получив отказ :-) В нормальных конторах все взрослые люди :-) Обсудили, приняли решение, двигаемся дальше :-) И последнее слово за руководителем, если он руководитель конечно, а не ландух :-)

Вообще, быть в чём-то умнее тимлида не зазорно и обычно не создаёт проблем.

Кто сказал что зазорно? :-) Руководителя надо уважать, а не навязывать свои более умные идеи :-) Предложить можно, навязывать нельзя :-)

я показал тимлиду, что статический анализ действительно умеет искать ошибки, и ошибки довольно серьёзные. После пары писем со здоровенными списками ошибок и списком тулз, которые юзались для их поиска, он дейтсивтельно оценил и сказал, что мол годные утилиты. Уже маленькая победа. Следующий шаг - уговорить встроить это дело в night builds, чтобы крутилось постоянно, а не только когда я локально проверяю наши проекты, а потом рассылаю письма счастья и лезу править баги.

Я смог доказать эффективность code review в нашем случае, так как опять же я составил список ошибок, которые я нашёл просто просмотором чужого кода, и после этого тимлид согласился, что code review - это хорошо.

Я смог убедить, что гадить постоянно в trunk - крайне фиговая идея, и для мало-мальски серьёзной вещи нужно создавать отдельную ветку, и только потом мержить ветку с основой.

Я показал, что заниматься всякими оптимизациями без профайлера - ну крайне фиговая затея, и если уж заниматься оптимизацией кода, то нужно гонять профайлером, а не «ну тут я вот позаменяю контейнеры и ускорю программу на 0.1%.». А то, что асимптотику алгоритма по соседству можно неплохо так снизить и получить выигрыш в программе до 10%

Тут 2 варианта: либо в вашей фирме скоро сменится лид, либо тебе надоест сражаться с мельницами.

А так – молодец, взор горящий это здорово.

// Но буст ради фс – это оверкилл.

Задача тимлида не форсить то, что ему кажется субъективно правильным, а то, что лучше для проекта. Он в данном случае не должен принимать решение сам, так как будучи тимлидом не должен заниматься деталями имплементации. Если буст сэкономит бюджет, он не должен отбрасывать эту идею. Он должен был заставить ОП оформить прототип и обсудить с коллегами что лучше на очередном скраме. Или отложить задачу в технический долг. Но если проект уже в стадии стабилизации перед релизом, то замена базовых фреймворков - плохая идея. И это он также должен был объяснить ОП. А сейчас выглядит всё так «мне не нравится boost так как я его не сам писал, поэтому будет мой велосипед». Такое поведение необычно и разрывает мой шаблон тимлида. Таких тимлидов я никогда не видел.

Задача тимлида не форсить то, что ему кажется субъективно правильным, а то, что лучше для проекта. Он в данном случае не должен принимать решение сам, так как будучи тимлидом не должен заниматься деталями имплементации. Если буст сэкономит бюджет, он не должен отбрасывать эту идею. Он должен был заставить ОП оформить прототип и обсудить с коллегами что лучше на очередном скраме.

Теперь специально для тебя ещё разок :-) То, что должен чей-то тимлид решать не тебе :-) Становись тимлидом, составь регламент и качай права как пожелаешь :-) Заставляй ОПов оформлять прототипы, обсуждай с коллегами и т.д. :-)

А сейчас выглядит всё так «мне не нравится boost так как я его не сам писал, поэтому будет мой велосипед». Такое поведение необычно и разрывает мой шаблон тимлида. Таких тимлидов я никогда не видел.

Мне не нравится буст :-) Мой велосипед лучше :-) Решение окончательное и принято давно :-)

нет, не сменится - на нём завязано очень много проектов + сам по себе мужик толковый.

Пожалуй, кроме ФС буст нам в проекте больше и не нужен. lexical_cast можно, DLL, но это мелочи. Если это оверкилл, то тогда своё решение и останется.

Ну с таким тимлидом наши бы дорожки разошлись очень быстро. Но я таких за всю свою карьеру ни разу не встретил. ни одного не видел который бы лез в детали имплементации. Многие таки пытались писать код дабы не утратить квалификацию, но предпочитали всегда слушать коллег. Да и на код у тимлида мало времени. А вот обратного, когда тимлиду было всё пофигу, знал один вопрос «когда релиз?» и вообще не интересовался что происходит в проекте, такого до фига.

Я своим тимлидом доволен: он разбирается во всех деталях проекта, помогает, если что-то не получается и в целом довольно приятный человек, пишет постоянно код. Только вот код у него частенько говно и с багами и очень любит свои велосипеды.

Ну если он не пытается быковать на счет своего кода, и его кода минимум в проекте, и таки задачи тимлида он выполняет хорошо, то баланс соблюдён, терпите! :) Бывает сильно-сильно хуже. А код у тимлида и будет не очень - код у него не основное, это скорее для фана. Времени на хороший код у него банально нет, а хочется.

Я своим тимлидом доволен: он разбирается во всех деталях проекта, помогает, если что-то не получается и в целом довольно приятный человек, пишет постоянно код. Только вот код у него частенько говно и с багами и очень любит свои велосипеды.

Вот и работай с ним, набирайся опыта :-) В командной разработке часто приходится принимать как должное указания тимлида или мейнтейнера, или считаться с мнением большинства коллег после дискуссии, если это open source :-) И часто со своими собственными хотелками приходится повременить :-) Так, до твоего тимлида, скорее всего, само дойдёт понимание, что т.к. filesystem уже в стандартной библиотеке цепепе-17, то есть резон его использовать :-)

Ты вроде не давно довольно нубские вопросы по плюсам задавал а тут уже с тимлидом споришь...

Зачем ты его баги фиксишь?! Нашёл баг в чужом коде, создал тикет, сплавил ему типа «я твой код не трогаю ты лучше знаешь». И все. Если там все плохо, то может ему самому надонст...