...вот эта вот статья: "How fast is ASP.NET Core?"
Уж не помню где ссылка на нее мне попалась на глаза, но прочитал с большим интересом и удовольствием. Даже не смотря на то, она про .NET.
Очень напомнило как мой коллега лет шесть назад принимал участие с RESTinio в подобных соревнованиях объявленных Mail.ru. Особенно когда выяснилось, что лучшие результаты показывают решения, использующие хардкорный busy waiting loop на системных вызовах.
Несколько дней назад были зафиксированы версии SObjectizer-5.8.1 и so5extra-1.6.1. Сегодня были сделаны анонсы на нескольких профильных форумах и на Хабре была опубликована статья, рассказывающая о нововведениях. Так что всех интересующихся адресую к этой статье.
У меня же два главных впечатления от работы над версией 5.8.1 таковы:
проектирование и реализация bind_transformer заняли буквально несколько часов. А вот покрытие реализации тестами, да так, чтобы эти тесты не роняли компилятор в internal compiler error и не компилировались по 5 минут... Вот на это ушло в разы больше времени.
Вообще, тесты для bind_transformer -- это отдельная песТня с шаблонной магией (например, раз и два). У меня было даже желание описать все эту магию отдельным постом (или статьей), но прикинув приблизительный объем как-то взгрустнул и не решился 😔
Добавить сюда еще и написание примера, обновление документации, описание этой фичи для разнообразных анонсов... И запросто получается, что всей остальной работы получается раз в десять больше, чем собственно программирования.
Такая вот наглядная разница между "просто сделать" или "сделать хорошо".
Фичу с so_this_agent_disp_binder пришлось реально ждать три года. Прям как в народной мудрости "обещанного три года ждут". Правда, мы и не обещали. Просто вовремя вспомнили, что такая хотелка была 🙂
А почему вспомнили? А потому, что записано все было "в книжечке". Т.е. в виде issue на GitHub-е.
Отсюда мораль: хотелки надо фиксировать. Очень желательно в виде issue. Тогда будет хоть какой-то шанс, что хотелка получит воплощение.
Вот как-то так. Особо больше добавить нечего. Просто обычная рутина по развитию старого проекта. К счастью хоть кем-то востребованного. Отсюда и дополнительный стимул этим самым развитием заниматься.
Ну и да, SObjectizer на GitHub-е тихой сапой перебрался через рубеж в 400 звезд. Оно, конечно, на хлеб не намазывается, но таки чем больше звезд, тем больше доверие потенциальных пользователей. Так что отрадно. Того и гляди, такими темпами через 5 лет и до 1000 дойдем 😉
Сегодня наткнулся на блог пост "The road to hell is paved with good intentions and C++ modules", создателя Meason-а. А в этом блог посте ссылку на вот эту презентацию: "A new CMake Scripting Language?". Из которой можно узнать интересные цифры. Например, перевод некого проекта Trilinos с GNU Autotools на CMake обошелся Sandia National Laboratories (SNL) более чем в миллион долларов -- около $500K составила стоимость рабочего времени сотрудников SNL и еще около $700K было потрачено на контракты с Kitware по доработкам CMake/CTest/CDash.
Мои постоянные читатели наверняка знают мое отношение к CMake. Временами мне стыдно, что и меня, и разработчиков CMake называют программистами. Потому что сделать такое говно -- это, блин, нужно было постараться.
Но вот после знакомства с вышеупомянутой презентацией я вообще в шоке.
Это как же у Kitware получилось сперва выкатить откровенное дерьмо в мир, затем убедить кучу народа это жрать не просто причмокивая, а еще и доплачивая Kitware?
Снимаю шляпу.
Пару лет назад я был готов добавить в RESTinio поддержку HTTP-клиента за $3.5K (что на тот момент не превышало одной месячной ЗП C++ разработчика моего уровня, причем просто чистой ЗП, без налогов на ФОТ и прочих издержек). А тут создатели CMake не стесняются озвучивать сумму в миллион долларов для того, чтобы сделать улучшенный CMake.
И ведь, скорее всего, найдут и профинансируют. Чтобы на выходе получилось не пойми что. А я не верю в способность разработчиков CMake сделать что-то хорошее. Если бы у них такая способность была, они бы давно бы уже убили себя апстену.
Отдельно мне доставила фраза со слайда #11 в упомянутой презентации:
The book “Professional CMake” largely solves the CMake Documentation problem.
Вот нет! Эта книга, возможно, как-то решает вопрос получения денег с пользователей CMake. Но не решает проблему качества CMake-овской документации.
В общем, складывается у меня впечатление, что если подсчитать сколько разные компании потратили на оплату услуг Kitware напрямую, и сколько человеко-часов было потрачено разработчиками на попытки разобраться с CMake и написать на этом говне хоть что-то полезное, то счет, боюсь, пойдет на десятки миллионов долларов.
Говорил раньше и повторю еще раз: если собрать список причин по которым стоило бы распрощаться с C++, то CMake там был бы на одном из первых мест.
И не потому, что CMake плохой. Плохого софта не так уж и мало.
А потому, что сообщество, в котором такое дерьмо, как CMake, стало де-факто стандартом, не ждет ничего хорошего. И такое сообщество заслуживает того, чтобы скончаться в муках. Медленно и мучительно.
Один из пользователей SObjectizer-а, Марко Арена, начал публиковать серию статей под названием "SObjectizer Tales". Это не очередное руководство о том, как программировать с помощью SObjectizer-а. Это рассказ о том, как человек увидел SObjectizer, что полезного в нем нашел и как он решал стоящие перед ним задачи с помощью нашего инструмента.
Мне было очень интересно читать статьи Марко, в буквальном смысле возможность взглянуть на давно привычные вещи чужими глазами.
Содержимое серии на текущий момент:
Мы долго делали свой инструмент и прилагали множество усилий для его продвижения и популяризации. И вот, постепенно, результаты наших трудов начинают использовать в разных концах света. И не просто использовать, но и рассказывать об этом. Сперва это сделал ув.тов.Павел Вайнерман. Сейчас вот Марко Арена. Остается надеятся, что этим не ограничится.
Мне сложно выразить собственные эмоции по этому поводу. Пожалуй, для понимания лучше всего привести вот эту цитату из "Законов Паркинсона":
Не имея особых талантов, не отличаясь ничем, кроме способностей и здравого смысла, мы можем участвовать в творческой работе и радоваться ее результатам. Мы способны сыграть некую роль в создании чего-то полезного и прекрасного и имеем право поставить внизу свою размашистую подпись.
Вот точно все про меня: не имея талантов, не отличаясь ничем, кроме способностей и здравого смысла...
Ну реально, я учился в обычной школе, с большим трудом поступил в местный, мало кому известный ВУЗ, с еще большим трудом его окончил, не переехал в столицу, а остался в своем маленьком провинциальном городе, не работал в крупных и известных компаниях, не имел за спиной поддержки крупных брендов. И, тем не менее, поучаствовал в создании чего-то полезного, на чем стоит, в том числе, и моя размашистая подпись.
Прошу простить мне минуту самолюбования, но да, есть теплое чувство внутри.
Подошло время очередного отчета о просмотренных за минувший месяц фильмах. Традиционно в начале каждого из списков идет то, что понравилось больше всего, а в конце то, на что можно не тратить свое время. Ну и да, в списке сериалов всего два названия и оба отстой :(
Фильмы
Вызов (2023). Для современного российского кино просто отличный фильм. Есть пара мест в сюжете, которые лично мне подпортили впечатление, но в целом более чем OK. Посмотрел с большим удовольствием и, прямо скажу, не ожидал, что будет настолько OK.
Индиана Джонс и колесо судьбы (Indiana Jones and the Dial of Destiny, 2023). Вот если бы в этом кино было чуть меньше погонь, то было бы вот прям вообще здорово. Мне лично очень зашло, прям ностальгия по кино 1980-х.
О чем говорят незнакомцы (Bajo terapia, 2023). Мне зашло прям очень хорошо, т.к. люблю такое: ограниченное количество персонажей, ограниченное пространство и все держится исключительно на разговорах.
Кентавр (2023). Если бы не пара-тройка несуразностей в происходящем, то было бы вполне себе OK для российского кино. Ну а так вполне можно посмотреть, но не шедевр.
Яростный волк (Lobo feroz, 2023). Это испанский ремейк израильского Очень плохие парни (Big Bad Wolves, 2013). Так что если израильский оригинал смотрели, то можно пройти мимо, в испанской версии ничего неожиданного не будет. А вот если "Очень плохие парни" не видели, то я бы рекомендовал именно испанский ремейк, т.к. он как-то более по человечески сделан, с ощущением реального трагизма происходящего.
Пекарь (The Baker, 2022). Довольно средненькая по качеству попытка снять очередное кино про "боевого пенсионера". На этот раз с неподражаемым Роном Перлманом в главной роли. Перлман, конечно, мощен и брутален для своего возраста, но временами в происходящее на экране не верится.
57 секунд (57 seconds, 2023). В принципе, идея прикольная. И, местами, смотрится происходящее здорово. Однако в целом остается ощущение халтурности. Как будто можно было бы сделать сильно круче, но не смогли.
История одного ограбления (Ostaggi, 2021). Посредственное кино. Можно глянуть если никаких других альтернатив нет вообще.
Мег 2: Бездна (Meg 2: The Trench, 2023). Редкая дрянь, смело можно не смотреть.
Сериалы
Черное солнце (Geomeun teyang, первый сезон, 2021). Первые пару серий были довольно бодренькие. К завершению все скатилось в унылую санта-барбару. Ну и нельзя советовать этот сериал тем, кто, как и я, не запоминает корейские имена героев, организаций и географические названия. Потому с непривычки что Хан Джи-ёк, что Канг Пил-хо, что Ку Хуо-ён -- все одинаково пролетает мимо ушей :(
Дублинские убийства (Dublin Murders, первый сезон, 2019). Редкостная дрянь, купился на высокий рейтинг и сильно пожалел о потраченном времени.
Стало уже традицией публиковать в блоге подобный список. Для меня это очень удобно: если в каком-то обсуждении нужно показать, куда смотреть, если потребовалось реализовать HTTP-точку входа в приложение, то достаточно поискать по блогу.
Но все течет, все изменяется. Кто-то прекращает свое существование, кто-то появляется и становится новым "царем горы". Поэтому публикую очередную подборку. Вроде бы все нижеперечисленное подает признаки жизни и имеет не одну сотню (тысячу) звезд на GitHub-е.
Специально не даю никаких своих комментариев по поводу перечисленного, т.к. чукча не читатель (пользователь), чукча писатель (т.е. разработчик одного из перечисленных). Но к тем, кто сходу советует "бери Boost.Beast и не парься" отношусь с неодобрением ;)
И да, список отсортирован по алфавиту, так что в порядке следования названий никакого другого смысла искать не стоит. Но все должны знать, что выбирать и поддерживать следует RESTinio :))). Да, это неприкрытая реклама. Да, проплаченная мной. Да, могу себе позволить! ;)
Список не претендует на полноту, это лишь то, о чем я наслышан.
Это только чисто С++ные разработки. Инструменты, написанные на чистом Си, но которые могут использоваться и из C++ (вроде CivetWeb и Mongoose) сюда не включены намеренно.
Время от времени на просторах Интернета приходится сталкиваться с высказыванием, вынесенным в заголовок поста. Применительно к моей специфике оно часто формулируется так: "За C++ деньги не платят, платят за решение проблем" или "За C++ деньги не платят, платят за знания конкретной прикладной области".
Я понимаю подобные высказывания так: первичны знания человека в какой-то специфической области. Например, в обработке видео. Или в распознавании образов. Или в статистике. Или в компиляторостроении. И т.д., и т.п.
Наверное, если брать какие-то сложные темы, типа расчета прочности фундаментов или моделирования износа лопаток в газовых турбинах, то так оно и есть. Без серьезного образования в такие области с улицы не сунешься.
Однако, мне кажется, что подобное утверждение, применительно именно к разработке ПО, слишком уж категорично.
Как минимум по двум причинам.
Во-первых, любое объемное ПО -- это не только набор математических формул. Это все-таки огромное количество "сопроводительного текста" к этим самым формулам. Т.е. наукоемкое ядро будет занимать пару-тройку десятков процентов (а то и меньше) от общего объема кода. Тогда как большая часть -- это рутинная обвязка. И эту обвязку нужно написать. Желательно хорошо. А для этого нужен такой навык, как умение писать код. Что, вообще-то говоря, дано не всем. Особенно из числа математиков и физиков ;)
Ну и к умению писать код желательно бы еще и приложить владение инструментом, т.е. знание языка программирования и умение пользоваться этим самым языком (что далеко не всегда сопутствует знанию языка). Грубо говоря, если вы пишете на C++, то вы на автомате должны расставлять const и noexcept, и не создавать объекты через new там, где их можно просто разместить на стеке, ну и RAII во все поля, куда же без этого ;)
Во-вторых, не боги же горшки обжигают. Если не брать какой-то серьезный матан, для освоения которого нужны пять лет ВУЗа, три года аспирантуры + кандидатская степень, то большинству программистов приходится погружаться во что-то новое и совершенно незнакомое. И ничего, как-то же справляемся.
Оглядываясь назад, на время, когда занимался поиском и отбором людей в компанию, в которой работал, то тогда я понимал, что готовых специалистов в своей предметной области найти в наших палестинах нереально. Поэтому на первый план выходили другие факторы: умение и готовность учится, предсказуемость и надежность. Если это есть, то остальное со временем приложится. Практически как в старой народной мудрости: были бы кости, мясо нарастет.
Но, опять же, человек должен был уметь писать код. Знания C++ можно было подтянуть. А умение излагать свои мысли в виде понятного и нормально работающего кода уже должно было быть. Вот этому учить точно не было возможностями, такие навыки приобретаются самостоятельно в ВУЗе.
В общем, я думаю, что вынесенная в заголовок максима хороша для узкоспециализированных и наукоемких вещей. Но там, где нужно просто педалить код... Там нужно умение просто педалить код. Предсказуемо и надежно. И, очень желательно, качественно.
ЗЫ. Наверное, отчасти этот пост навеян легким сожалением о том, что такая штука, как "знание C++", не котируется. Столько лет насмарку, и как теперь жить? ;)))
ЗЗЫ. По большому счету к перспективе сменить основной язык программирования отношусь философски. Наверное среди используемых сейчас в индустрии языков найдется мало таких, которые я бы не смог толком освоить... Хотя вот Perl в свое время не смог ;) Жаль только, что на овладение новым языком время потребуется. Месяцев 9-10. Ну, чтобы овладеть. А не так, чтобы как курица лапой.
