Comments 29
Спасибо, что продолжаете делиться своими наработками.
Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные.
Смысл опенсрса -- счастье команды.
И это вполне разумный аргумент.
Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол.
И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше.
Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным.
А вот утаивание кода приносит меньше профитов, чем принято думать.
Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду.
Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.
+100
Вообще, смысл вот таких выкладок в опен-сорс - это из разряда тем, которые, если человек не понимает и не схватывает сразу - ему уже невозможно объяснить. Увы. Некоторый потолок развития что ли: либо достиг просветления, либо нет.
Откуда такая щенячья наивность, что корпорации думают про счастье какого-то винтика, а не про деньги, которые можно делать из выкладки в open source, прямо или косвенно?
Корпорации, несомненно, про деньги и ради денег. Это правда, но это не вся правда. Вся правда в том, что на определённом этапе приходится думать о вещах, с деньгами связанных косвенно. Вплоть до винтиков. Ну нет прямой финансовой выгоды от всех этих кофемашин, столов для пинг-понга, тимбилдингов и прочей PR. Но есть нефинансовая и финансовая, но непрямая. Опенсорс для крупных корпораций - почти то же.
Антон, спасибо - вопрос: используется ли в этом проекте идиома / утилита fast pimpl (вы рассказывали о ней в презентации "C++ трюки из Такси" 2.5 лет назад)? Я заглянул в пару-тройку хедеров и не наткнулся на использование (пока). Предполагаю, что не используется - т.е. C++ утилита / приём весьма общего назначения, полезная в одном крупном C++ проекте, с которым вы работали, в другом крупном C++ проекте (в той же фирме) оказалась не так уж полезна?
Да, мы много где её используем
Весьма полезная штука)
Я за Open Source, но от выводов в статье остаётся ощущение недосказанности. Логика подсказывает, что коммерческая компания не просто так тратит такую уйму сил и не просто для того, что бы поделиться своими наработками с сообществом. Я хотел бы ошибаться, но мне кажется, что на самом деле здесь больше решаются юридические тонкости и основная цель - защитить те или иные российские разработки от нападок извне или наоборот, а Open Source это только форма. Опять же, не вижу в этом ничего плохого, думаю так многие компании делают, но если это действительно так, то всё встает на своё место.
Гадаю по фотографии, делаю кодревью, дорого. Один файл, и только сегодня, бесплатно. Рандом сказал read.cpp.
Макросы - зло, USERVER_NAMESPACE_BEGIN, UASSERT. У Вас современный C++, есть и static_assert, и if costexpr.
boost::filesystem::path - уже в C++17 появился , пожалуйста не тащите буст, когда можно без него.
Первая функция принимает const boost::filesystem::path& path, вторая std::string_view path - пожалуйста, определитесь, то у Вас path, а иначе c++ implicit conversion это зло.
Nit:
не будем тратить Ваше время~
1) Согласен что зло. Однако единственный способ отобразить произвольное выражение в виде массива символов - макросы вида `#define STRINGIZE(X) #X`
Задать произвольный namespace для большого фреймворка можно разными способами, и макрос - менее ужасающий из возможных вариантов
2) Мы и не используем Boost когда можно без него. В данном случае он необходим, так как на многих платформах где собирается userver авторы стандартных библиотек C++ помечают реализацию std::filesystem как experimental и неготовую к промышленному использованию
3) И правда некрасивенько. Можно будет поправить как-нибудь
4) Вы пропустили большую проблему в данном коде, сосредоточившись в ревью не на логике/архитектуре. Первый кто найдёт проблему до того как мы закомитим фикс, получит от нас маленький презент
Симлинки специально пропускаете?
GetRelative(f.path().string(), path)— не оторвётся ли случайно (или скорее наоборот останется) какой-нибудь слэш / в relative-пути, если передать path без завершающего слэша? Зависит, конечно, от того, как именно path доходит до сюда.
UPD: ну и в принципе смешивание std::string и fs::path для навигации звучит довольно взрывоопасно, вроде API fs должно хватать для всех GetRelative и т.д., но он ещё и нормализует пути.
Да, слеши обрабатываются "своеобразно". Не совсем баг, но презент вам явно полагается. Напишите пожалуйста в личку, куда его вам выслать.
Но большая проблема остаётся не разгаданной, есть шанс получить ещё приз
Там как-то странно, IsHiddenFile() реагирует не только на ".", но и на "..", вроде как это надо было в другом месте отфильтровать бы.
Макросы — зло, USERVER_NAMESPACE_BEGIN, UASSERT. У Вас современный C++, есть и static_assert, и if costexpr.
И как по-вашему современный C++ избавит нас от этих макросов?
Это же гениально. Мне кажется, что яндекс слил этот движок в open-source, только чтобы после разделения компании на российскую и международную, обе компании могли им пользоваться. Это же снимает проблемы с делением интелектуальной собственности. Ждём еще другие интересные наработки :)
Добрый день! Большое спасибо за статью! Удачи Вашему фрэймворку! Не могли бы Вы уточнить несколько моментов:
1. Реализованный Вами подход, как я понимаю, отличается от Coroutine TS C++. Почему Вы не использовали разработки Lewiss Baker (follycoro) (потому что к моменту начала разработки Userver их ещё не было, или по какой-либо другой причине)? Планируете ли Вы в будущем дрейфовать в сторону стандарта (в смысле в части корутин) (или, наоборот, считаете, что стандарт должен дрейфовать в Вашу сторону 😊).
2. Есть ли где-то более или менее подробное описание Вашего подхода к корутинам? Вынесены ли Ваши корутины в отдельную библиотеку (независимую от userver).
3. Есть ли где-то описание Вашего планировщика корутин? Вы использовали подходы, сходные с подходами Дмитрия Вьюкова (Go), или разработали что-то своё?
4. Не думали ли Вы над следующим вопросом: асинхронный сервер – это реально круто, статусно, но для большей раскрутки и востребованности проекта может имеет смысл попиариться и с точки зрения возможности делать асинхронные запросы к web-серверам (по типу pythonовского aiohttp) – чтобы привлечь на свою сторону пользователей, который запросы пишут, но которым не требуется сам web-сервер.
userver — что мы узнали за полгода в open-source