userver — что мы узнали за полгода в open-source

[rotor]

Спасибо, что продолжаете делиться своими наработками.
Вы абсолютно правы, смысл опенсорса не в том, что вам будут присылать багрепорты или писать код за вас. Хотя и в этом тоже. Эти поводы легко объяснить далёким от IT менеджерам, но они не главные.
Смысл опенсрса -- счастье команды.
И это вполне разумный аргумент.
Высшее счастье инженера -- видеть как результатами его труда пользуются и они приносит пользу другим людям, а высшее несчастье -- работа в стол.
И если у вас команда профессионалов, то выкладка кода в открытый доступ безусловно принесёт удовлетворение, мотивирует работать лучше.
Кроме того, чего греха таить, когда мы знаем что наш код попадёт в опенсорс, мы прикладываем больше усилий, что бы код был максимально качественным.
А вот утаивание кода приносит меньше профитов, чем принято думать.
Ну и конечно, опенсорс повышает престиж компании. Ведь мы судим о компании в том числе по её коду.
Рад, что ответственные люди в Яндексе на стороне прогресса. И надеюсь, что эта практика понемногу станет нормой повсеместной.

[DmitryKoterov]

+100

Вообще, смысл вот таких выкладок в опен-сорс - это из разряда тем, которые, если человек не понимает и не схватывает сразу - ему уже невозможно объяснить. Увы. Некоторый потолок развития что ли: либо достиг просветления, либо нет.

[slonopotamus]

Ну зачем так категорично. Человеки вполне имеют право в течение жизни шагать вверх по пирамидке товарища Маслоу.

[k-morozov]

Откуда такая щенячья наивность, что корпорации думают про счастье какого-то винтика, а не про деньги, которые можно делать из выкладки в open source, прямо или косвенно?

[Clock_Source]

Корпорации, несомненно, про деньги и ради денег. Это правда, но это не вся правда. Вся правда в том, что на определённом этапе приходится думать о вещах, с деньгами связанных косвенно. Вплоть до винтиков. Ну нет прямой финансовой выгоды от всех этих кофемашин, столов для пинг-понга, тимбилдингов и прочей PR. Но есть нефинансовая и финансовая, но непрямая. Опенсорс для крупных корпораций - почти то же.

[sashagil]

Антон, спасибо - вопрос: используется ли в этом проекте идиома / утилита fast pimpl (вы рассказывали о ней в презентации "C++ трюки из Такси" 2.5 лет назад)? Я заглянул в пару-тройку хедеров и не наткнулся на использование (пока). Предполагаю, что не используется - т.е. C++ утилита / приём весьма общего назначения, полезная в одном крупном C++ проекте, с которым вы работали, в другом крупном C++ проекте (в той же фирме) оказалась не так уж полезна?

[antoshkka]

Да, мы много где её используем

Весьма полезная штука)

[sashagil]

Отлично, спасибо! Я себе сделал попроще, по мотивам той презентации, буду иметь в виду, если понадобится улучшить.

[Videoman]

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

[Tuxman]

Гадаю по фотографии, делаю кодревью, дорого. Один файл, и только сегодня, бесплатно. Рандом сказал 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: не будем тратить Ваше время~

[antoshkka]

1) Согласен что зло. Однако единственный способ отобразить произвольное выражение в виде массива символов - макросы вида `#define STRINGIZE(X) #X`

Задать произвольный namespace для большого фреймворка можно разными способами, и макрос - менее ужасающий из возможных вариантов

2) Мы и не используем Boost когда можно без него. В данном случае он необходим, так как на многих платформах где собирается userver авторы стандартных библиотек C++ помечают реализацию std::filesystem как experimental и неготовую к промышленному использованию

3) И правда некрасивенько. Можно будет поправить как-нибудь

4) Вы пропустили большую проблему в данном коде, сосредоточившись в ревью не на логике/архитектуре. Первый кто найдёт проблему до того как мы закомитим фикс, получит от нас маленький презент

[mobi]

Симлинки специально пропускаете?

[antoshkka]

Специально, в этом месте ОК

[mobi]

И то, что GetRelative не проверяет, что path действительно начинается c dir, тоже ок? (хотя, скорее всего за пределами он не используется)

[antoshkka]

Функция действительно используется только в одном месте из этого файла, только на директориях с заданным префиксом. Так что ОК

[mobi]

И runtime_error при ошибке чтения (например, нет прав) тоже можно не обратывать?
Да boost в некоторых случаях может filesystem_error выбросить.

[antoshkka]

Такие ошибки обрабатываютя вызывающим кодом, исключения тут как раз кстати

[mobi]

-

[Readme]

GetRelative(f.path().string(), path)

— не оторвётся ли случайно (или скорее наоборот останется) какой-нибудь слэш / в relative-пути, если передать path без завершающего слэша? Зависит, конечно, от того, как именно path доходит до сюда.

UPD: ну и в принципе смешивание std::string и fs::path для навигации звучит довольно взрывоопасно, вроде API fs должно хватать для всех GetRelative и т.д., но он ещё и нормализует пути.

[antoshkka]

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

Но большая проблема остаётся не разгаданной, есть шанс получить ещё приз

[Kelbon]

    FileInfoWithData info{};
    info.size = boost::filesystem::file_size(f.path());
   ...
    info.data = ReadFileContents(async_tp, f.path().string());

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

[antoshkka]

Ага, гонка. Вам полагается подарок! Напишите в личку адрес доставки

[Kelbon]

Сербия, Хаб яндекса...

[Tuxman]

Там как-то странно, IsHiddenFile() реагирует не только на ".", но и на "..", вроде как это надо было в другом месте отфильтровать бы.

[Playa]

Макросы — зло, USERVER_NAMESPACE_BEGIN, UASSERT. У Вас современный C++, есть и static_assert, и if costexpr.

И как по-вашему современный C++ избавит нас от этих макросов?

[mr_kani]

Это же гениально. Мне кажется, что яндекс слил этот движок в open-source, только чтобы после разделения компании на российскую и международную, обе компании могли им пользоваться. Это же снимает проблемы с делением интелектуальной собственности. Ждём еще другие интересные наработки :)

[antoshkka]

Спасибо!

Но мы уже 5 лет назад говорили, что готовим userver к выходу в open-source. Так что по срокам не сходится %)

[shoenfield]

Добрый день! Большое спасибо за статью! Удачи Вашему фрэймворку! Не могли бы Вы уточнить несколько моментов:

1. Реализованный Вами подход, как я понимаю, отличается от Coroutine TS C++. Почему Вы не использовали разработки Lewiss Baker (follycoro) (потому что к моменту начала разработки Userver их ещё не было, или по какой-либо другой причине)? Планируете ли Вы в будущем дрейфовать в сторону стандарта (в смысле в части корутин) (или, наоборот, считаете, что стандарт должен дрейфовать в Вашу сторону ?). 

2. Есть ли где-то более или менее подробное описание Вашего подхода к  корутинам? Вынесены ли Ваши корутины в отдельную библиотеку (независимую от userver).

3. Есть ли где-то описание Вашего планировщика корутин? Вы использовали подходы, сходные с подходами Дмитрия Вьюкова (Go), или разработали что-то своё?

4. Не думали ли Вы над следующим вопросом: асинхронный сервер – это реально круто, статусно, но для большей раскрутки и востребованности проекта может имеет смысл попиариться и с точки зрения возможности делать асинхронные запросы к web-серверам (по типу pythonовского aiohttp) – чтобы привлечь на свою сторону пользователей, который запросы пишут, но которым не требуется сам web-сервер.