[prog.memories] Вспомнил кайф от работы над библиотекой timertt

Благодаря вот этой теме на Reddit-е вспомнилась работа над библиотекой timertt, которая у нас в SObjectizer-е применяется для обслуживания таймеров.

Кстати говоря, если кому-то интересно какие есть подходы к обслуживанию таймеров, то краткую выжимку можно посмотреть вот в этом небольшом блог-посте, который ссылается вот на эту основополагающую PDF-у (ее URL, на всякий случай: http://www.cs.columbia.edu/~nahum/w6998/papers/sosp87-timing-wheels.pdf, именно http://, а не https://).

Дело было в конце августа 2014-го года. Тогда SObjectizer еще использовал ACE в качестве базовой библиотеки. Но вот как раз к этому времени единственное, что нам нужно было из ACE -- это таймеры. Которые, как мне помнится, в ACE были сделаны весьма круто (все таки ACE, как инструмент, был отличной штукой, хоть и очень уж в стиле 1990-х). Но несмотря на крутизну и удобство ACE-овских таймеров от такой тяжелой зависимости, как ACE, очень хотелось избавится. Поэтому нужно было сделать свои таймеры.

Так, в общем-то, библиотека timertt и появилась.

Работы над ней сопровождались парой постов-размышлизмов в блоге: раз, два. Сейчас их мне самому интересно перечитывать... И ведь было время и желание такие лонг-риды писать 🤔

Да, так вот к чему это все вспомнилось.

К тому, что хоть деталей работы над timertt я уже не помню от слова совсем, но вот ощущение удовольствия осталось до сих пор.

Погрузился в новую область, посмотрел что к чему, поэкспериментировал, сделал. Чистый кайф.

И, что совсем уж удивительно, timertt работает себе и работает. Уже девять лет.

Последние ломающие совместимость модификации вносились шесть лет назад, как раз в октябре 2017-го. А с декабря 2019-го туда вообще ничего не добавлялось, просто нужды не было. Тупо справляется timertt со своей работой, потребности закрывает и все.

Из чего-то подобного еще вспоминается разработка PEG-парсера для RESTinio в 2019-ом. Тогда тоже был кайф от проделываемой работы, хотя шло все гораздо сложнее, чем с timertt. Но кайф от работы ощущался все равно.

Эх... Были времена... Приятно вспомнить.

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

PS. Во время подготовки этого поста перечитал собственную же статью на Хабре про easy_parser из RESTinio и офигел от сложности того, что там описано. Как будто совсем другой человек и тот код писал, и ту статью. Какая-то более лучшая версия меня 🙂

[prog] В склерозник: отличное чтиво на тему бенчмарков и маркетинга...

...вот эта вот статья: "How fast is ASP.NET Core?"

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

Очень напомнило как мой коллега лет шесть назад принимал участие с RESTinio в подобных соревнованиях объявленных Mail.ru. Особенно когда выяснилось, что лучшие результаты показывают решения, использующие хардкорный busy waiting loop на системных вызовах.

[prog.c++] Послесловие к релизу SObjectizer-5.8.1

Несколько дней назад были зафиксированы версии 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 дойдем 😉

[prog.c++.kill-them-all] Во что обходится это дерьмо, CMake?

Сегодня наткнулся на блог пост "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, стало де-факто стандартом, не ждет ничего хорошего. И такое сообщество заслуживает того, чтобы скончаться в муках. Медленно и мучительно.