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

Никто же мне не мешал учиться всё это время.

Ну так я по высоким материям и не спорю с ним. Там, где мне нечего сказать, я просто молчу и учусь.

Почему я правлю? Потому что мне нужно делать свои таски, а баги блокируют работу.

Теперь специально для тебя ещё разок :-) То, что должен чей-то тимлид решать не тебе :-)

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

А те потом сидят и думают, чому проект такой говнокодовый и почему руководство зряплату не повысило. Под конец все разбегаются по нормальным конторам, и в шарашке только такие васяны как ты остаются. Сосать леденец и шестерить.

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

Мало ли кто что и какие вопросы задавал недавно. Вчера задавал нубские вопросы, а сегодня уже тимлид. И это нормальная практика. А не как у тебя, 10 лет в шарашке говнокодить.

да ладно, зачем агриться? тупят все, а студенты чаще. Если б я не хотел ничему научиться, то я б на форуме нифига не спрашивал, а просто пошёл дальше так же долбить в стену.

Руководителя надо уважать

Это в каком законе прописано?

Это в каком законе прописано?

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

я с лицензированием Qt не слишком знаком, но насколько я знаю, для коммерческой разработки нужно покупать. Бесплатно юзать можно, только если линковать не статически.

Не совсем. LGPL требует, чтобы при статической компоновке клиент имел возможность пересобрать продукт с другой версией Qt. Соответственно, можно дать клиенту либо исходники, либо объектные файлы, что совсем уж лёгкое требование.

Также предлагаю серьёзно подумать, нужна ли вам именно статика. ИМХО, она оправдана, пока всё ПО в продукте распространяетя одним жирным бинарем. Если же своих EXE/DLL у вас несколько, динамическая компоновка становится более экономной.

Тебе никак не переубедить тимлида. Суть в том, что он написал свой велосипед, потому что ему это хочется. А теперь представь, что ты тимлид, велосипедишь как тебе хочется и тут к тебе пристает назойливый джун, который хочет, чтобы ты бросил свой велосипед ради чего? Ага, ради его решения, потому что ему кажется, что его решение лучше и он не слушает твои доводы.

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

P.S. Если тимлид не просто пилит свой велосипед, но и по сути упертый баран, то ты рискуешь сломать с ним отношения (потому что ему не свой велосипед нужен, а осознание своей безоговорочной правоты). Это ни тебе ни проекту на пользу не пойдет. Еще раз повторю, найди лучше что-нибудь другое, полезное и тебе и проекту и такое, чтоб тимлид был не против. Доказывать кому-то что ты прав - убогая стратегия упертых баранов (а тебе принятие в проект boost::filesystem ничего не даст, кроме убеждения в собственной правоте - прокачивает твое эго, но вредит всему остальному). Если хочешь быть всегда правым - сам становись тимлидом (например, убеди менеджмент, что нужно выделить особый проект, в котором ты будешь тимлидом и на который никто кроме тебя влиять не будет).

Чё-та я прочитал тему по диагонали, подумал...

Лет так в 25 я бы тоже спорил по вопросам реализации, какие библиотеки тащить, какие нет, и т.д.

И внезапно, я довольно часто так и делал. Но то ли я это делал в максимально дипломатичной форме, то ли мне безумно везло с руководством - но где-то 80 % этого руководства ко мне как минимум, уважительно прислушивалось.

А сейчас... стремление затащить Boost в проект вместо велосипеда - это последнее, чем я стал бы заниматься. Если велосипед кроссплатформенный, то и на здоровьишко. Вдруг внезапно дорастёт до годноты. Но вот багрепорты бы я такому тимлиду на его велосипед отправлял бы регулярно. Во имя справедливости.

Плюнь. Пиши багрепорты. Наслаждайся, что ты пишешь код, а не документы по ГОСТ 19.402-78, например.

1. Попробовать получить от тимлида список технических аргументов почему его велосипед лучше Boost.Filesystem.

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

Твоя реакция?

P.S. Ах, да, твой mxx - гавно, cmake - круче: переходи уже на него, не заставляй людей использовать поделку на ruby.

// Голос разума в царстве тьмы

IMHO в такой ситуации есть два реальных варианта.

1. Ты просто говоришь (не пытаешься никого убедить, просто говоришь, т.е. передаешь информацию) свою идею. Дальше тимлид принимает решение. Если скажет «нет», то просто забываешь свою идею - ты не контролируешь проект и не отвечаешь за него (не можешь в принципе отвечать за проект, если не влияешь на решения). Продолжаешь заниматься другими полезными для себя и проекта делами (если таких нет - меняешь работодателя)

2. Ты делаешь по своему и ставишь всех перед фактом. Продолжаешь заниматься другими полезными для себя и проекта делами. Не понравится - пусть сами и переделывают. Есть много людей, которые готовы указывать другим что делать, но сами действовать не станут и велик шанс, что твое решение никто переделывать не будет - проще оставить как есть.

Ах, да, твой mxx - гавно, cmake - круче: переходи уже на него, не заставляй людей использовать поделку на ruby.

Ну вот, прибежал хз кто, набросал какашек и убежал. Желающим жрать cmake я никак не мешаю, нравится — жрите полной ложкой.

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

А так у вас в проекте есть человек, которого если что можно пнуть и он не ответит «хз, надо курить исходники буста». Потому что это ЕГО велосипед. И лучше автора его никто не знает.

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

А как посчитать время, потраченное на переход на boost, адаптацию проекта?

в маздай стандарты С++ довозят на оленях, через несколько лет после их выхода

Последние пару лет они настолько серьезно поддали, что C++17 стандарт завезли раньше C++14. Кроме того MS серьезно форсирует поддержку своего варианта модулей (есть еще от clang), пытается пропихнуть собственное видение корутин (ради чего придумали аж 3 новых ключевых слова). В общем, последние годы MS жжет в плане поддержки и пропихивания в стандарт своих поделок не по детски.

Каждый козел статически линкует, вот у них и получаются гигабайты в C:\Program Files

Если ты пытаешься провоцировать спор «статическая линковка против динамической», то динамически линковать имеет смысл только системные библиотеки (libc, zlib). Для остальных преимущества динамической линковки проявляются только в редких случаях (типа плагинов, например).

Но для начала ответь, чем тебе мешают гигабайты на диске?

Вот только на вопрос ты не ответил, что будешь делать с джуном, который действует по тобой написанному плану.

А как посчитать время, потраченное на переход на boost, адаптацию проекта?

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

Мой план относился к замене лисапеда на Boost. А не лисапеда на лисапед, написанный джуном.

Есть некоторая разница.

Мой план относился к замене лисапеда на Boost

А не мог бы ты разработать план как заменить арч на убунту? :-) Вот как убедить руководство в этом? :-) Лол :-)

Или убунту на сусю, или сусю на убунту :-) В общем, какой там самый лучший вариант, не знаешь? :-)

будет использоваться gtest

Посмотри в сторону https://github.com/philsquared/Catch

Фэйт какой то прям вам без буста тогда жить

Спасибо за ссылку, гляну обязательно.

Ну что ж поделать. Здесь собрались люди, которые в разработке много больше меня и лучше понимают, как вести в таких дилеммах. Стоит прислушаться к их мнению.

Почему я правлю? Потому что мне нужно делать свои таски, а баги блокируют работу.

Так это проблема тимлида! Он наговнякал и заблокировал работу по своей прихоти - его проблема.

У тебя денег не хватит, чтобы купить продукцию, для которой наша шаражка код пишет :D

ну ок. допустим, он тебе в проект ace припёр :)

ну ок. допустим, он тебе в проект ace припёр :)

В 2005-ом году довелось выбрасывать собственные велосипеды для работы с многопоточностью, сокетами и др. системными вещами как раз на ACE. Именно потому, что затраты на поддержание и развитие собственных велосипедов стали непозволительно высоки. Могли бы выбрать Boost, но не стали, т.к. разбираться в коде ACE намного проще, чем в коде Boost-а. И это неоднократно нам помогало, в том числе и выискивать ошибки в ACE, и отсылать в ACE наши дополнения.

Так что если джун припрет в проект что-нибудь хорошее, то это будет самым тщательным образом рассмотрено. И, если обнаружатся какие-то выгоды, тяготы подтаскивания сторонней либы в проект лягут на этого самого джуна, ибо инициатива наказуема. Справится, будет польза всему проекту. Не справится — наберется опыта.

ты не понял... именно ace. именно в твой проект. именно сейчас.

И? Ну ACE, ну в мой проект, ну сейчас. Хорошая библиотека, много лет пользовался. Если потребуется, попользуюсь еще.

Если бы джун в проект MFC предложил подтащить... Или настаивал бы на использовании Mozilla-вского style guide в проекте, тогда другое дело. Тогда бы джун начал бы искать другую проектную команду.

ace

Что скажешь о poco?

Весьма неплохая штука. С упором на простоту использования и простоту реализации (возможно в ущерб производительности). Авторы, имхо, были немного покусаны Java, но разобраться и начать использовать ее проще, чем тот же ACE.

опять не поня :) я о том, чтобы заменить им твои велосипеды.

опять не поня :) я о том, чтобы заменить им твои велосипеды.

Какие именно?

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

которые ты здесь раньше пиарил.

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

Ну и стартовое сообщение прочтите, там довольно внятно все описано. К моим велосипедам не имеет никакого отношения.

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

никакого желания тебя обосрать, естественно, нет

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

Ага, конечно.

Ну и дай определение «крупного проекта», чтобы было интереснее.

когда-то давным-давно, в /development с периодом раз в месяц-два появлялся пост

{22.09.2014}, {01.10.2014}, {12.02.2015}, {07.04.2015}, {02.09.2015}, {20.01.2016}.

Ну как бы не так часто. Разница меньше чем в два месяца была всего в двух случаях.

о каждом минорном релизе одной библиотеки

Это не были минорные релизы, у нас просто система нумерации с четырьмя числами в номере (крайний нолик опускается зачастую).

также стало известно, что сначала она была запилена на ace, а потом переписана на своих велосипедах.

Из ACE там использовались ACE_Thread, ACE_Mutex, ACE_Condition_Variable, ACE_Mutex_Guard, ACE_Refcounted_Auto_Ptr + механизм таймеров. Со временем в тех компиляторах, которые мы использовали, появилась более-менее нормальная поддержка C++11 и мы перешли на аналоги из stdlib. Велосипед только один — своя реализация таймеров.

Итак, что мне может предложить взять из ACE этот гипотетический джун сейчас?

Таймеры? Ну так в ACE, емнип, нет такой штуки, как наши timer_managers из timertt (когда вся работа выполняется на одном и том же рабочем потоке). А это сейчас для нас важно.

Оказывается, да :-)

Нет, не оказывается.

да пусть те же таймеры. скажет, «хватит ерундой заниматься. вот есть хорошая протестированная библиотека». тебе лень будет с ним возиться и просто откажешь. тогда

- появится аналогичный пост на лоре, только про ace

или

- он начнёт партизанить как ты предлагал пару страниц назад :)

Нет, не оказывается.

А может быть, просто, тебе не светит? :-) Тогда для персонально тебя, понятное дело, не оказывается, да :-)

да пусть те же таймеры.

Картинка, которая была у нас:

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

Имхо, ситуация совсем другая, чем у ТС. И если ко мне придет джун и скажет, а давайте-ка вернем ACE-овские таймеры взад, то я ему сначала объясню, почему от ACE отказались, затем, если он не передумает, поручу сделать интеграцию с ACE заново, после чего заставлю править баги, которые он обязательно сделает. И уже затем, если он через все это пройдет, попрошу еще раз привести список аргументов «за» и «против».

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

Вот если бы у ТС-а в проекте изначально Boost был, затем бы Boost по какой-то причине выпилили, а затем ТС начал бы попытки впилить Boost назад, тогда это была бы ситуация, в которую вы пытаетесь меня поставить. Но есть у меня подозрение, что в проекте ТС-а Boost-а вообще никогда не было.

затем, если он не передумает, поручу сделать интеграцию с ACE заново, после чего заставлю править баги, которые он обязательно сделает. И уже затем, если он через все это пройдет, попрошу еще раз привести список аргументов «за» и «против».

За чей счёт эти исследования? :-) И какую прибыль в денежном выражении получит компания, пока некий экспериментатор будет «проходить через все это» по поручению тимлида? :-)

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

В этой точке вспомнился мультик про одного мечтателя, который из одного куска шкурки поручил портному пошить 12 шапок :-)

Тимлид молодец. Тех, кто тянет всякую каку в рот, надо бить по румяной попке

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

Тимлид молодец

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

Воистину молодец.

в самом LLVM не используется boost, так же не используются rtti и исключения, вместо всего этого запилены свой код

тред не читал, ждать 17 предлагали для filesystem?