[prog;work;wow] Марко Арена завершил свою серию статей про SObjectizer

Марко Арена сегодня завершил свою серию статей "SObjectizer Tales", начатую в октябре прошлого года. Полный список статей из этой серии я приведу ниже.

Сперва же хочется сказать слова благодарности. Результат получился впечатляющим, я такого не ожидал от слова совсем. Вышло очень и очень круто, большое спасибо, Марко!

Так же поделюсь своим впечатлением от произошедшего. И тут сложно подобрать слова. Наверное, самым точным цензурным вариантом будет -- я шокирован. В хорошем смысле этого слова.

Изначально я даже и не мог предположить, во что же это все выльется. Когда Марко спросил у меня как я отношусь к идее того, что он сделает серию постов про SObjectizer, и в самых смелых фантазиях невозможно было представить, что эта серия будет содержать тридцать (тридцать, Карл!) статей.

Как по мне, так Марко написал целую книгу. Что по объему, что по глубине и качеству материала.

И, что особенно радует, так это то, что написано все это не кем-то из SObjectizer Team, а пользователем SObjectizer-а. Скажи мне об этом кто-то еще года два-три назад, я бы счел подобное ненаучной фантастикой. А теперь это реальность.

Более того, я бы даже назвал выход серии "SObjectizer Tales" целой вехой в истории развития SObjectizer-а. Важной и значимой лично для меня.

Так что, да, я шокирован. В хорошем смысле этого слова.

---

Вот как в итоге выглядит вся серия.

• Prelude (зеркало на dev.to).
• 1. Producing Images (зеркало на dev.to).
• 2. Can you call me back? (зеркало на dev.to).
• 3. Acquisition loop revisited (зеркало на dev.to).
• 4. Handling commands (зеркало на dev.to).
• 5. Sending commands (зеркало на dev.to).
• 6. Is the stream still in progress? (зеркало на dev.to).
• 7. Agent composition (зеркало на dev.to).
• 8. Representing errors (зеркало на dev.to).
• 9. Splitting work (зеркало на dev.to).
• 10. Handling GUI from main (зеркало на dev.to).
• 11. Interlude: testing (зеркало на dev.to).
• 12. Receiving commands from the network (зеркало на dev.to).
• 13. Routing images across the network (зеркало на dev.to).
• 14. Triggering agent shutdown (зеркало на dev.to).
• 15. Monitoring disconnections (зеркало на dev.to).
• 16. Interrupting work (зеркало на dev.to).
• 17. Limiting message flow (зеркало на dev.to).
• 18. Limiting message chains (зеркало на dev.to).
• 19. Thread-safe handlers (зеркало на dev.to).
• 20. Performance, part 1 (зеркало на dev.to).
• 21. Performance, part 2 (зеркало на dev.to).
• 22. Performance, part 3 (зеркало на dev.to).
• 23. Mutable messages (зеркало на dev.to).
• 24. Delivering messages at shutdown (зеркало на dev.to).
• 25. Runtime telemetry (зеркало на dev.to).
• 26. Dispatcher selection (зеркало на dev.to).
• 27. Design ideas (зеркало на dev.to).
• 28. If I had a magic wand… (зеркало на dev.to).
• Epilogue (зеркало на dev.to).

---

PS. Что доставляет отдельно, так это слоган, который Марко выбрал для своей серии: Concurrent C++, made simple. Таки да, для этого все когда-то и затевалось. Но я бы насколько лаконично и емко выразить бы не смог.

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

[wow] LOR торт, а я ай-ти-голодранец!

Простите, таки не удержусь, опубликую. Этот пост сделал мой день еще вчера, но сегодня с утра он мне кажется еще смешнее (выделение на скриншоте мое):

цинк

Надеюсь люди, которые задавали мне вопросы по нашим OpenSource разработкам или открывали Issues на GitHub-е, смогут составить свое впечаление о том отвечаю ли я за что-то и исправляю ли ошибки.

Если кого-то действительно интересует вопрос почему я не занимаюсь опакечиванием под Linux-ы, то, пожалуй, здесь есть исчерпывающий ответ: тыц.

[prog.c++;blog;wow] Интересно, это уже успех или ещё нет? :)))

Посмотрел сегодя откуда ко мне в блог люди приходят. А тут такое:

Не меньне, не больше, а "быстрый ответ" в выдаче Яндекса по запросу "виртуальный деструктор C++ зачем нужен". Однако! :)

Если (а скорее когда) придется проходить собеседование по C++, то на вопрос о виртуальном деструкторе в C++ нужно будет показать этот скриншот.

[wow] Хочешь попасть в Лабораторию Касперского? Изучай SObjectizer! :)

Сам офигел когда увидел:

Цинк (не знаю, как долго будет актуальным).

[prog.history] Между тем COBOL-у исполняется 60 лет и исчезать он никуда не собирается

Тихо и незаметно подкрался очередной юбилей языка COBOL, про который многие слышали, но мало кто видел. Имхо, из мейнстрима он выпал еще до того, как я сам познакомился с программированием. Но программы на нем до сих пор работают и код на COBOL-е до сих пор продолжают писать.

В общем, долголетие COBOL-а заставляет задуматься о том, как долго могут жить языки программирования, получившие в свое время широкое распространение.

Свежая статья на тему COBOL-а: "COBOL turns 60: Why it will outlive us all"

А я нескромно дам ссылочку на аналогичную запись из этого блога, написанную к 50-летию COBOL-а. Там ряд интересных фактов приведен. Ряд из которых, наверное, продолжает оставаться актуальным до сих пор.

[prog.wow] Самое удивительное для меня в судьбе Erlang-а в Ericsson-е между 1986-ым и 1995-ым

Читаю сейчас урывками историю Erlang-а от Джо Армстронга. Одну вещь ну очень тяжело лично мне осознать, пока не получается и все.

Дело в том, что судя по тому, что рассказывает Армстронг, Erlang в Ericsson-е не выходил за пределы лабораторий до 1995-го года. При том, что собственно над тем, что стало Erlang-ом Армстронг начал работать в 1986 (а вообще к проблематике создания языка для упрощения разработки софта для телефонии он подключился на год раньше, в 1985-ом). В самом конце 80-х были эксперименты по прототипированию на Erlang-е. В начале 90-х группа Армстронга убедила руководство начать раздавать Erlang заинтересовавшимся людям за пределами Ericsson-а. В 1993-ем вышла книга про Erlang. И Ericsson создал дочернее подразделение Erlang Systems AB для коммерциализации Erlang-а. Но в самом Ericsson-е Erlang был востребован в продакшене только в 1995-ом, когда стартовали AXD после неудачи проекта AXE-N.

Т.е. девять лет несколько разработчиков на зарплате Ericsson-а делали что-то, что сам Ericsson не использовал. И, особенно в первые два-три года, никто даже и не знал, во что это в итоге выльется.

Афигеть просто.

В качестве наемного разработчика я проработал почти 20 лет. И не припомню ситуаций, когда можно было уйти в какое-то вольное плавание хотя бы на пару месяцев без предьявления по итогу чего-то, пригодного для использования. Посему и не могу представить себе, какую свободу Ericsson предоставлял сотрудникам своих исследовательских лабораторий, какой огромный кредит доверия там выдавался.

Внушаить.

[prog.wow] Очень мощно про понятность кода, внушаить! :)

С позволения автора выношу из комментария:

Код не должен быть понятным, он должен быть готовым к комфортному внесению изменений.

[project.management] Обалденный доклад о UX. Но далеко не только о UX

Вот:

Ведение коротких, сложных и серьёзных кросс-медийных дизайн-проектов в условиях военного времени, Антон Уткин.

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

Видео короткое, всего 21 минута. Сам доклад в два раза короче, остальное вопросы, которые так же полезно послушать. Но первые 11-12 минут выступления просмотреть нужно обязательно.

[prog.wow] В 2015-ом код уже можно не отлаживать?

Походу, я проспал какой-то фундаментальный прорыв. По крайней мере на RSDN так утверждают:

В 2015 году код, который после написания нужно еще и отлаживать, считается говнокодом. Без вариантов. К код ревью даже не допускается.

[life.art] Это просто ну очень круто: рисованный рекламный ролик РЖД к 175-летию

Может этот ролик демонстрировали в РФ, но здесь, в РБ, я его раньше, к сожалению, не видел.

Вот здесь статья о ролике, в которой есть видео, посвященное его созданию.

[life.wow] Верстовой столб 419.99 -- отличный пример настоящего trouble-shooting-а

Одна из моих недавних записей в G+ касательно байки об изготовления обуви в разных странах появилась в результате прочтения очередной перепечатки статейки о trouble-shooter-ах. Мифических специалистах, придумывающих оригинальные решения для любых проблем. В прочитанной мной статье приводилось два примера. Первый касался издателей справочников вроде Yellow Pages, когда один издатель благодаря совету trouble-shooter-а стал выпускать свое издание в меньшем формате. Второй пример касался уже упомянутого совета шить кроссовки для левой ноги в одной стране, а для правой -- в другой стране. Тем самым, устранив возможности для воровства продукции.

В поисках подтверждения этой байки про кроссовки наткнулся на сайт muzey-factov.ru. Там, например, выяснилось, что японцы на одном из Курильских островов для прекращения воровства обуви использовали два склада -- один для левых сапог, второй -- для правых. Видимо, это и послужило базой для создания байки про совет trouble-shooter-а компании Nike.

Там же, в музее фактов, на глаза попался еще один замечательный пример нестандартного решения проблемы. В данном случае проблемы воровства знака миля "420". Чтобы знак больше не воровали власти установили вместо него знак "419.99".

Кстати, при поиске подтверждений оказалось, что это не новый прием. До этого, для того, чтобы прекратить воровство знака "69" устанавливали знаки "68.5" или "68.99".

[life.sport.darts] Только что Борис Кольцов открыл новую страничку в истории российского дартса

Если не ошибаюсь, такое происходит впервые: российский игрок попадает в основную сетку Чемпионата Мира по версии PDC. Победив в очень нервном матче отборочного раунда японца Харуки Мураматсу, россиянин Борис Кольцов вышел в первый круг ЧМ-2015 и через пару часов будет играть против Кевина Пайнтера.

Upd. 1-3 проигрыш Кевину Пайнтеру :( Имхо, не смотря на взятый лег, матч у Бориса не задался. Возможно, это объективно уровень отечественного дартса на данный момент. Но, зато у нас стало чуть больше людей, которые на своем опыте знают, что такое матчи с такими звездами на такой сцене.

PS. Наверное, далеким от дартса людям это мало о чем говорит, но вообще-то это просто афигенно круто! Что-то вроде возможности для российского игрока попасть на ЧМ по снукеру.

PPS. Зимой 2013 мне довелось играть против Бориса Кольцова (понятное дело 4-0 не в мою пользу). Так что ощущение такое, как будто это мой приятель на ЧМ мира сейчас играет :)

[management] Лень русского человека -- это...

Лень русского человека - это естественная реакция на кипучую деятельность руководящих им идиотов.

Отсюда.

[life.craftsmanship] Красивый видеоролик про изготовление ножа

Кстати, вопрос к читателям из Гомеля (да и Минска, пожалуй): а у нас есть такие мастера? Я бы с удовольствием пофотографировал такого умельца за работой. По типу вот такой вот серии, только с учетом того, что за прошедшие два года я чуть побольше поднаторел в фотографии (например, из не очень давнего).

[prog.wow] Афигеть: OpenSource .NET Core, да еще и Visual Studio Community Edition

Имхо, Microsoft-у следовало сделать это гораздо раньше. Лет на десять. Ну да лучше поздно, чем никогда: Announcing Open Source of .NET Core Framework, .NET Core Distribution for Linux/OSX, and Free Visual Studio Community Edition.

Больше всего в связи с этой новостью меня интересует, а будет ли Visual Studio 2015 в виде Community Edition?

Ну и еще один вопрос, уже чисто праздный, а нафиг теперь Mono? ;)

PS. Если честно, то лет десять назад я бы понял, какие выгоды MS может извлечь от перевода .NET в OpenSource. Сейчас уже не понимаю. Может быть от того, что далек от сферы применения .NET-а в "живой природе". Но больше склоняюсь к мысли, что MS опенсорсит то, что самой тянуть уже тяжело, а может и не нужно.

PPS. Наброс с неожиданной стороны: боюсь, что OpenSource может тупо убить разработку софтового инструментария. Как бы не случилось так, что зарабатывать на софте можно будет только при работе "на заказ" или "на пожертвования". Внутренние разработки (вроде той же Kafka (в недрах LinkedIn) или Thrief (в недрах Facebook)) попадают под категорию "на заказ", только заказчик и исполнитель работают под одной крышей.

[life.music] Pink Floyd. The Endless River. 2014

Иногда в жизни происходят вещи, которых не ждешь от слова "никогда".

Ноябрь 2014-го. Через двадцать(!) лет после последнего студийного альбома "The Division Bell" группа Pink Floyd выпускает свой новый студийный альбом "The Endless River".

Не знаю, что еще сказать. "The Division Bell" был заслушан в свое время "до дыр". Сейчас с удовольствием слушаю новый альбом, звучит как хорошее продолжение. Настолько же он гениален ли он или нет -- пока рано судить.

Важно другое. Такие события отлично напоминают о том, что возможно все.

[prog.c++] Презентация "Modern Template Metaprogramming: A Compendium" с CppCon2014

За наводку большое спасибо ув.тов.Sergey Sikorskiy.

Здесь лежит PDF-ка со слайдами. Для хорошо воспринимающих английский язык на слух видео в двух частях: первая и вторая.

Не знаю, как видео (а там почти 2 часа), но PDF-ка в меня заходила со скрипом. Для шустрого восприятия материала знания C++ нужны покруче моих.

Мощно, конечно, там все задвинуто, внушаить... Но теперь люто реквестирую что-то вроде "C++ Template Metaprogramming in Real World", дабы сирым и убогим инженеришкам/менеджеришкам вроде меня на простых и доступных примерах объяснить, где от всех этих шаблонных конструкций будет реальная польза, а где лучше обойтись копипастой более привычными средствами.

PS. Прошу прощения за последующую ассоциацию -- это все особенности моего больного воображения. Однако ж. Вот для чего вся эта крутизна в C++? Для того, чтобы выжимать больше из железа, и чтобы получившийся код был менее бажным и более-менее сопровождаемым. Ради этого программисты готовы идти на трехэтажные шаблоны, длительную компиляцию и периодические internal compiler errors компилятора, который афигевает от невообразимого полета фантазии некоторых особо одаренных программистов. Но блин, когда пропускная способность нагруженного сервиса вырастает в два раза благодаря колдовству с распределением обработчиков прерываний от железа по ядрам процессора, причем исключительно на уровне конфигов ОС... Возникает резонный вопрос: а в том ли направлении копают?

[prog.idiotic] LOR: написать Erlang может каждый!

Анонимные тимлиды с LOR-а жгут напалмом непАдетски:

[prog.flame] Haskell vs C++: анонимусы на LOR-е жгут напалмом

Цинк:

Так что хаскель, как ни крути, это как раз то, чем должны быть кресты, если бы Страустрап не циклился на Си.