Ох! Конечно же все, что написано во втором абзаце моего предыдущего комментария относится только к зависимостям вида библиотеки и подобное (в папке vendor традиционно хранятся библиотеки).
Изначально в статье был вопрос:
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.
> Почему же вы не храните в репозитории компилятор того языка, который вы используете?
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.
Я думаю, что случаях, когда любой инженер или ученый дал бы примерно одинаковый ответ Борис Евсеевич думал скорее всего аналогичным образом.
Ситуация в которой с появлением новых знаний старые работающие решения признаются либо неправильными(неоптимальными), либо ненадежными является на столько типичной, что мне странно, что она для кого-то может быть неожиданной. Для этого не надо быть медиумом. Достаточно быть инженером.
> «Если бы сейчас положили на полигоне корабль «Восток» и все современные главные, сели бы и посмотрели на него, никто не проголосовал бы пускать такой ненадёжный корабль…
Спросите любого конструктора любой техники сложнее утюга и они ответят Вам точно так-же. В этой части цитаты нет никакого откровения для инженеров.
Легко видеть правильный путь, когда результат достигнут, но чтобы его достичь придется пройти через ошибки и работу с недостатком информации. Черток это понимал, что в вашей цитате подтверждается фразой «Получил огромный опыт и понял, как сильно мы рисковали», а Вы к сожалению нет…
Позвольте в свою очередь не согласиться с Вами.
Вы путаете проблему старта в предметной области и дальнейшее развитие в оной.
Старт отличается тем, что Вы или абстрактный человек имеет только вопросы, но не знает даже примерных направлений куда копать, в связи с этим выучиться самостоятельно можно, но из-за частого и не всегда верного выбора направления в слепую «очень много времени будет потрачено просто зря». Наличие же кого-нибудь, кто будет задавать направление этого поиска ответов сократить время обучения в разы.
В дальнейшем же развитии специалиста в ответ на большинство вызовов он сможет сам задавать себе направления поиска, так как его знания помогут это направление определить. Думаю, не сильно ошибусь, если скажу, что в разработке не так много задач, в которых совершенно непонятно с какой стороны пробовать начинать искать решение.
+1 к Андромеде.
Правда, огорчает тот факт, что этот сериал пережил смену сценаристов и стройность/обоснованность сюжета была принесена в жертву ради понижения порога вхождения в сериал зрителей с любой серии.
> Краткая суть — реальные условия эксплуатации двигателей отличаются от лабораторных. Ну кто бы мог подумать, а?
Если про мой комментарий, то совершенно нет.
Краткая суть моего комментария — вред нужно оценивать комплексно, а не брать для сравнения двух технологий в первой фактор, где она безусловно проигрывает, а во второй — где она безусловно выигрывает и на этом основании говорить что вторая лучше.
Если же в общем, то да, полностью согласен. Выбросы в реальных условиях эксплуатации по сути не регламентированы.
> смотришь на шлейф дыма за соседним грузовиком
Так это же очевидно. Грузоперевозки — это большие деньги и лоббирование. Кто пойдет против тех, кто и ответить может?
Не путайте интересы политиков, которым нужно заставить средний класс что-то делать и реальные потребности среднего класса. Я прекрасно понимаю и то и то, а еще и психологию толпы, которую в данном случае нещадно эксплуатируют.
Что же касается сравнительных характеристик, пусть это останется на Вашей совести…
> Правда, потом оказалось, что с уловителем частиц машина заводится плохо, и его лучше снять, к тому же, дизель выдаёт в несколько раз больше оксидов азота, чем бензин. Оксиды азота, в частности, пагубно влияют на людей с респираторными заболеваниями. Дизельные двигатели сложнее бензиновых и сильно дороже в обслуживании.
Это манипулирование фактами и как следствие суммарно получилась ложь практически от первого и до последнего слова.
1) ПДК на выбросы частиц сажи для дизелей был всегда, а для бензиновых появился только в ЕВРО-5. Более того, эта норма для бензиновых двигателей точно такая-же, как и для дизелей.
Кстати, в бензиновых двигателях тоже ставят нейтрализаторы и т.д., которые при неисправности могут усложнять запуск двигателя и которые тоже можно снять, но об этом почему-то молчат.
2) Да, дизель выдает больше оксидов азота, так как в его цилиндрах значительно жарче, но при этом выдает в разы меньше угарного газа, углеводородов, летучей органики и т.д.
К сожалению, ни одной статьи на тему, что из этого В КОМПЛЕКСЕ вреднее для экологии я не видел. Везде выдергивают из контекста один параметр и изучают только его влияние.
В очередной раз прошу сообщество подсказать, есть ли исследования опубликованные в серьезных изданиях о комплексном вреде выхлопа разных типов двигателей. Мне, к сожалению, таких найти не удалось. Может быть я плохо или не там искал?
3) Современный дизель компоновочно не сложнее бензинового с непосредственным впрыском, Больше различий, в том числе в весе, из-за повышенных требований к прочности изделия. Ну и за аккумулятором приходится следить.
Что-же касается обслуживания, то за время гарантии разница в цене выйдет в несколько сотен долларов, которые будут полностью компенсированы снижением операционных расходов (мой пепелац с массой 2-2,5т потребляет от 8 до 11 л/100км, у бензиновых пепелацев этой-же марки расход начинается литров с 12, а заканчивается под 20, при этом требуют они бензин, который в наших краях дороже солярки).
> Уже в 2014 году началась кампания по избавлению Европы от дизельных автомобилей – вероятно, в пользу велосипедов…
А это правда. Только причина скорее всего в очередном лоббировании обновления автопарка. В свое время переход на дизеля этому хорошо поспособствовал…
P.S. Поддержу так-же точку зрения господина Dee31, что такая избирательность огорчает, а так-же вызывает недоумение…
На мой взгляд изначально вопрос был не в том, как по умолчанию, а как можно сделать договором или другими способами.
В США можно распространить трудовой договор и на код (интеллектуальную собственность) написанный в нерабочее время. В России трудовой договор не может распространяться на нерабочее время.
Например, в США легально, а в России — нет.
Если, конечно, под свободным временем понимается исключительно НЕ рабочее время, а не ситуации когда часы рабочие, но задач нет и нечем заняться на работе.
> Намек не понял, я вам показал пример что есть система где страховка вполне покрывает все что нужно.
Единственным аналогом приведенного Вами в качестве примера страхового продукта в России является обязательное медицинское страхование. Частники таких аналогов не имеют, по этому приводить в пример аналог ОМС и говорить, что это есть у частников в России довольно странно (собственно на это и был намек, что сравнивать нужно доступные в России, а не где-то там решения).
> В россии медицины вообще нету
В России есть медицина, уровень которой не уступает мировой. НО, она неравномерно распределена по стране в этом ее существенная проблема.
Кстати, то, что вся передовая медицина только в Москве — это тоже миф, который тоже легко опровергнуть вооружившись гуглом.
Мы все еще о России (Это прозрачный намек на то, что сравнивать нужно реально существующие на рынках решения)?
В России безлимитных страхований я на рынке не видел вообще (хотя если они реально есть, то мне будет любопытно на них посмотреть), а те лимиты которые я видел в серьезных случаях сгорят за считанные месяцы. Вот и получается выбор между качеством сервиса в простых и средних случаях и между гарантированным лечением практически чего угодно, но с худшим сервисом.
> Я как ИП заплатил взносами в ФОМС примерно 30 тысяч в этом году. За эти же 30 тысяч рублей я купил страховку в страховой компании и безлимитно обслуживаюсь в поликлинике управления делами президента и еще в десятке частных клиник по всей Москве.
Какой у Вас лимит страхового возмещения?
К чему этот вопрос. На первый взгляд кажется, что бизнес тут эффективнее, но бизнес играет в короткую. Пока у Вас простые или дешевые заболевания, Вас лечат, но если случиться что-нибудь тяжелое, то государство Вас будет лечить все равно столько, сколько понадобиться (возможно, не так хорошо, как хотелось бы, но будет. к сожалению, проверено и не дай Вам бог проверять это на себе или близких), а бизнес перестанет лечить в момент исчерпания страховой суммы. А в сложных случаях она может закончиться быстро и Вы останетесь без лечения.
Вроде бы Чуть ранее Вы правильно рассуждаете про быстрые и медленные инвестиции, стоимость денег, но странно от Вас видеть демонстрацию непонимания этого же факта прямо в следующем комментарии, когда дело касается индустрии страхования…
> Вы искренне считаете, что угонщик не долбанет кувалдой по блокировке руля что бы свернуть ее. Ведь руль будет жалко.
И Вы будете смеяться, но не долбанет. Машина без руля неуправляема, а следовательно для угонщика бесполезна (не на эвакуаторе же он ее повезет со сломанным рулевым валом). Если посмотреть на статистику то она тоже подтвердит, что при внезапном обнаружении механических блокировок их либо аккуратно вскрывают (ключи не дают 100% надежность), либо такие машины дальше не трогают переходя на огромное количество более легкодоступных целей.
А в соседней статье пишут (http://habrahabr.ru/post/267697/#comment_8590875):
> BigData начинаются там, где уже невозможно весь набор данных поместить в память сервера. Для текущих конфигураций 2х-сокетных серверов это где-то в районе 3ТБ twitter.com/thekanter/status/559034352474914816
Соответственно, если взять средние сервера, то задача будет из области bigdata, а если hi-end, то задача станет рядовой (у SGI есть решения с 64ТБ общей RAM).
На мой взгляд для термина BigData вообще некорректно давать количественные определения, иначе мы будем вынуждены его переписывать с каждым новым анонсом серверов.
> Насчёт 2: может быть, «мощь» tbbmalloc и впрямь велика, но насколько часто она действительно нужна? Стоит ли она того, чтобы за неё платить в описанной ситуации (прим: использовал прив. код в комм. софте)?
За TBB нужно платить только если нужна поддержка.
Наличие runtime exception позволяет использовать opensource версию TBB даже в коммерческих проектах с закрытым кодом.
А у вас контейнеры, использующие аллокатор parallel_allocator, используются строго в одном потоке?
В смысле, что все модифицирующие (не const) методы вызываются исключительно в одном потоке?
Если нет, то у Вас проблемы. Например, resize или какой-нибудь push_* может вызвать перераспределение памяти и если он будет вызван из другого потока, то heapSlot.get() вернет не ту кучу, которую Вы ожидаете.
Если такая проблема возможна, то, как вариант, можно посмотреть в сторону stateful аллокаторов (С++11), но я не уверен, поддерживает ли их STL из VisualStudio (но они работают в boost::container).
В дополнение могу посоветовать посмотреть на tbbmalloc из Intel Threading Building Blocks. Их opensource лицензия позволяет применять библиотеку даже в ПО с закрытым кодом, сейчас у них появились Community лицензии, а на моих задачах (многопоточных с высокой интенсивность перераспределения памяти) использование этого аллокатора сократило нагрузку на CPU на 5-7% по сравнению с tcmalloc (который сейчас живет по адресу: https://github.com/gperftools/gperftools).
Это хорошо, но когда срок самой поставки может быть большим, то в случае отмена тендера провести новый в текущем году можно не успеть и велик риск остаться и без товара и без денег.
> Стоит ли хранить содержимое папки vendor в наших репозиториях?
Для меня наш репозиторий — это все то, что находится под моим управлением, включая условные svn.company.com, git.company.com, files.company.com, pkg.company.com и другие варианты. Гитхаб и репозитории вендоров по этому определению не наши.
Да, в дальнейшем было уточнение, что вопрос следует понимать как «прямо в репозитории с проектом».
Если брать этот вопрос, то на него однозначно я ответить не могу, однако, склоняюсь к мысли, что можно и хранить, так как единственный контраргумент по сути — это размер репозитория, но для меня это не критично. А на девелоперскую и сборочную машину все равно весь этот объем тащить надо для сборки.
Почему не храним?
Например, у меня в отдельном репозитории лежат и iso-образы сборочной ОС, и клоны репозитория, и скрипты ее автоустановки и автонастройки, чтобы в любой момент времени нужные виртуальные машины могли быть автоматически пересобраны даже если билд-кластер умрет полностью.
Только вот этот репозиторий не git или svn, а отдельный каталог на файловом сервере.
Да, это занимает дополнительное место, но все это дает мне гарантированную воспроизводимость окружения сборки и всех зависимостей (зависимости проектов я тоже храню у себя), что для меня важно.
Ну и независимость от внешних репозиториев в моменты сборки тоже неплохой бонус, а если сборка всегда проводится на чистых машинах, то для загрузчиков зависимостей нужно либо кэши городить, либо каждый билд тащить из интернета сотни мегабайт библиотек.
Ситуация в которой с появлением новых знаний старые работающие решения признаются либо неправильными(неоптимальными), либо ненадежными является на столько типичной, что мне странно, что она для кого-то может быть неожиданной. Для этого не надо быть медиумом. Достаточно быть инженером.
Спросите любого конструктора любой техники сложнее утюга и они ответят Вам точно так-же. В этой части цитаты нет никакого откровения для инженеров.
Легко видеть правильный путь, когда результат достигнут, но чтобы его достичь придется пройти через ошибки и работу с недостатком информации. Черток это понимал, что в вашей цитате подтверждается фразой «Получил огромный опыт и понял, как сильно мы рисковали», а Вы к сожалению нет…
Вы путаете проблему старта в предметной области и дальнейшее развитие в оной.
Старт отличается тем, что Вы или абстрактный человек имеет только вопросы, но не знает даже примерных направлений куда копать, в связи с этим выучиться самостоятельно можно, но из-за частого и не всегда верного выбора направления в слепую «очень много времени будет потрачено просто зря». Наличие же кого-нибудь, кто будет задавать направление этого поиска ответов сократить время обучения в разы.
В дальнейшем же развитии специалиста в ответ на большинство вызовов он сможет сам задавать себе направления поиска, так как его знания помогут это направление определить. Думаю, не сильно ошибусь, если скажу, что в разработке не так много задач, в которых совершенно непонятно с какой стороны пробовать начинать искать решение.
Правда, огорчает тот факт, что этот сериал пережил смену сценаристов и стройность/обоснованность сюжета была принесена в жертву ради понижения порога вхождения в сериал зрителей с любой серии.
Если про мой комментарий, то совершенно нет.
Краткая суть моего комментария — вред нужно оценивать комплексно, а не брать для сравнения двух технологий в первой фактор, где она безусловно проигрывает, а во второй — где она безусловно выигрывает и на этом основании говорить что вторая лучше.
Если же в общем, то да, полностью согласен. Выбросы в реальных условиях эксплуатации по сути не регламентированы.
> смотришь на шлейф дыма за соседним грузовиком
Так это же очевидно. Грузоперевозки — это большие деньги и лоббирование. Кто пойдет против тех, кто и ответить может?
Что же касается сравнительных характеристик, пусть это останется на Вашей совести…
Это манипулирование фактами и как следствие суммарно получилась ложь практически от первого и до последнего слова.
1) ПДК на выбросы частиц сажи для дизелей был всегда, а для бензиновых появился только в ЕВРО-5. Более того, эта норма для бензиновых двигателей точно такая-же, как и для дизелей.
Кстати, в бензиновых двигателях тоже ставят нейтрализаторы и т.д., которые при неисправности могут усложнять запуск двигателя и которые тоже можно снять, но об этом почему-то молчат.
2) Да, дизель выдает больше оксидов азота, так как в его цилиндрах значительно жарче, но при этом выдает в разы меньше угарного газа, углеводородов, летучей органики и т.д.
К сожалению, ни одной статьи на тему, что из этого В КОМПЛЕКСЕ вреднее для экологии я не видел. Везде выдергивают из контекста один параметр и изучают только его влияние.
В очередной раз прошу сообщество подсказать, есть ли исследования опубликованные в серьезных изданиях о комплексном вреде выхлопа разных типов двигателей. Мне, к сожалению, таких найти не удалось. Может быть я плохо или не там искал?
3) Современный дизель компоновочно не сложнее бензинового с непосредственным впрыском, Больше различий, в том числе в весе, из-за повышенных требований к прочности изделия. Ну и за аккумулятором приходится следить.
Что-же касается обслуживания, то за время гарантии разница в цене выйдет в несколько сотен долларов, которые будут полностью компенсированы снижением операционных расходов (мой пепелац с массой 2-2,5т потребляет от 8 до 11 л/100км, у бензиновых пепелацев этой-же марки расход начинается литров с 12, а заканчивается под 20, при этом требуют они бензин, который в наших краях дороже солярки).
> Уже в 2014 году началась кампания по избавлению Европы от дизельных автомобилей – вероятно, в пользу велосипедов…
А это правда. Только причина скорее всего в очередном лоббировании обновления автопарка. В свое время переход на дизеля этому хорошо поспособствовал…
P.S. Поддержу так-же точку зрения господина Dee31, что такая избирательность огорчает, а так-же вызывает недоумение…
В США можно распространить трудовой договор и на код (интеллектуальную собственность) написанный в нерабочее время. В России трудовой договор не может распространяться на нерабочее время.
Если, конечно, под свободным временем понимается исключительно НЕ рабочее время, а не ситуации когда часы рабочие, но задач нет и нечем заняться на работе.
Боюсь, что без этого конструктивного диалога не получится.
Единственным аналогом приведенного Вами в качестве примера страхового продукта в России является обязательное медицинское страхование. Частники таких аналогов не имеют, по этому приводить в пример аналог ОМС и говорить, что это есть у частников в России довольно странно (собственно на это и был намек, что сравнивать нужно доступные в России, а не где-то там решения).
> В россии медицины вообще нету
В России есть медицина, уровень которой не уступает мировой. НО, она неравномерно распределена по стране в этом ее существенная проблема.
Кстати, то, что вся передовая медицина только в Москве — это тоже миф, который тоже легко опровергнуть вооружившись гуглом.
В России безлимитных страхований я на рынке не видел вообще (хотя если они реально есть, то мне будет любопытно на них посмотреть), а те лимиты которые я видел в серьезных случаях сгорят за считанные месяцы. Вот и получается выбор между качеством сервиса в простых и средних случаях и между гарантированным лечением практически чего угодно, но с худшим сервисом.
Какой у Вас лимит страхового возмещения?
К чему этот вопрос. На первый взгляд кажется, что бизнес тут эффективнее, но бизнес играет в короткую. Пока у Вас простые или дешевые заболевания, Вас лечат, но если случиться что-нибудь тяжелое, то государство Вас будет лечить все равно столько, сколько понадобиться (возможно, не так хорошо, как хотелось бы, но будет. к сожалению, проверено и не дай Вам бог проверять это на себе или близких), а бизнес перестанет лечить в момент исчерпания страховой суммы. А в сложных случаях она может закончиться быстро и Вы останетесь без лечения.
Вроде бы Чуть ранее Вы правильно рассуждаете про быстрые и медленные инвестиции, стоимость денег, но странно от Вас видеть демонстрацию непонимания этого же факта прямо в следующем комментарии, когда дело касается индустрии страхования…
> Вы искренне считаете, что угонщик не долбанет кувалдой по блокировке руля что бы свернуть ее. Ведь руль будет жалко.
И Вы будете смеяться, но не долбанет. Машина без руля неуправляема, а следовательно для угонщика бесполезна (не на эвакуаторе же он ее повезет со сломанным рулевым валом). Если посмотреть на статистику то она тоже подтвердит, что при внезапном обнаружении механических блокировок их либо аккуратно вскрывают (ключи не дают 100% надежность), либо такие машины дальше не трогают переходя на огромное количество более легкодоступных целей.
> BigData начинаются там, где уже невозможно весь набор данных поместить в память сервера. Для текущих конфигураций 2х-сокетных серверов это где-то в районе 3ТБ twitter.com/thekanter/status/559034352474914816
Соответственно, если взять средние сервера, то задача будет из области bigdata, а если hi-end, то задача станет рядовой (у SGI есть решения с 64ТБ общей RAM).
На мой взгляд для термина BigData вообще некорректно давать количественные определения, иначе мы будем вынуждены его переписывать с каждым новым анонсом серверов.
За TBB нужно платить только если нужна поддержка.
Наличие runtime exception позволяет использовать opensource версию TBB даже в коммерческих проектах с закрытым кодом.
В смысле, что все модифицирующие (не const) методы вызываются исключительно в одном потоке?
Если нет, то у Вас проблемы. Например, resize или какой-нибудь push_* может вызвать перераспределение памяти и если он будет вызван из другого потока, то heapSlot.get() вернет не ту кучу, которую Вы ожидаете.
Если такая проблема возможна, то, как вариант, можно посмотреть в сторону stateful аллокаторов (С++11), но я не уверен, поддерживает ли их STL из VisualStudio (но они работают в boost::container).
В дополнение могу посоветовать посмотреть на tbbmalloc из Intel Threading Building Blocks. Их opensource лицензия позволяет применять библиотеку даже в ПО с закрытым кодом, сейчас у них появились Community лицензии, а на моих задачах (многопоточных с высокой интенсивность перераспределения памяти) использование этого аллокатора сократило нагрузку на CPU на 5-7% по сравнению с tcmalloc (который сейчас живет по адресу: https://github.com/gperftools/gperftools).