[fury] Ну и еще за RSDN

Тема про RSDN оказалась очень активной. Кроме того, обсуждение на самом RSDN так же продолжается. Видимо, нужно сказать еще несколько вещей про RSDN.

1. Очень удивлен тому, что на RSDN меня еще помнят. Тем не менее, я вне RSDN-а уже гораздо дольше, чем был на RSDN-е. Пора бы уже перестать говорить про значимость или какой-то там вклад в RSDN персонажа под ником eao197.

2. Что-то не меняется. Например, пара свежих высказываний от AndrewVK. Номер раз:

Он, кстати, емнип, в итоге признал что был не прав.

И номер два:

Вот только даже мне приходилось регулярно отправлять его в бан за оскорбления.

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

По поводу регулярного отправления в бан могу лишь посоветовать поднять логи. На моей памяти за 5-летнее активное участие на RSDN количество отправлений в бан можно пересчитать по пальцам одной руки. Но без формальных подтверждений мы здесь оба можем врать как очевидцы.

3. Почему-то я вижу, что о судьбе RSDN-а беспокоятся те, кого я уважаю как профессионалов и как людей (например, kochetkov.vladimir и kaa.python). Но не те, кто приложил усилия к закапыванию RSDN-а. Т.е. то, что Володя и Александр переживают за RSDN меня совсем не удивляет. Удивляет, почему переживают только они.

4. Есть ощущение, что RSDN похож на обычное предприятие, попавшее в обычный кризис: внешние условия поменялись, выпускаемая предприятием продукция продается все хуже и хуже, а перестроиться и приспособиться к новым условиям не получается.

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

Конечно, не мне советовать, что делать ресурсу в данной ситуации. Но, если рассматривать случай с RSDN-ом с точки зрения обычной ситуации с обычным жизненным циклом обычного предприятия (как это было, скажем, с Крайслером в 80-х перед приходом туда Ли Яккока, как было с Эппл после ухода оттуда Стива Джобса, как было с LEGO в начале 2000-х), то думается, что кому-то нужно всерьез озадачиться поисками ответов на пару-тройку важных вопросов:

1. Зачем и для чего ресурс существует?
2. В чем уникальность ресурса? Т.е. почему в современных условиях пользователи должны предпочитать RSDN альтернативным площадкам?
3. На чем нужно сконцентрироваться для изменения ситуации, а от чего нужно избавиться?

Жизненный и профессиональный опыт подсказывает, что ответы на эти вопросы не ищутся коллективными усилиями. Тут важна роль личности. Лидера, который сможет сформировать видение и убедить всех остальных в правильности этого самого видения.

Есть ли такой лидер в команде RSDN?

А вот это мне уже совсем не интересно. Выживет RSDN -- ну и хорошо, будет больше профильных ресурсов в Рунете. Не выживет, ну бывает, такова жизнь.

[prog] Послесловие к релизу SObjectizer-5.5.19

Сегодня мы сделали релиз очередной версии SObjectizer-а. Основной анонс здесь, небольшие пояснения по поводу столь длительной паузы между версиями здесь. Так же сделаны анонсы на reddit-е и hacker-news (кто может поспособствовать +1, не сочтите за труд), не говоря уже про LOR и RSDN. Еще запланирована статья на Habr-е, но это уже не сегодня.

Здесь же мне хочется сказать о двух вещах.

Во-первых, это был один из самых трудных релизов за всю историю SObjectizer-5. А может и вообще за всю историю SObjectizer-а. С одно стороны, работа над версией 5.5.19 велась уже внутри новой компании "СтифСтрим", которая должна платить зарплату сотрудникам, налоги государству и т.д. Соответственно, нужно было изыскивать средства на все эти текущие расходы, ну и попутно заниматься SObjectizer-ом. С другой стороны, новые фичи версии 5.5.19 действительно заставили посмотреть на SObjectizer, его назначения и принципы работы, совсем с другой стороны. Это было непросто, потребовался ряд экспериментов и прототипов, часть из которых завершились неудачей.

Во-вторых, одна из фич этой версии -- мутабельные сообщения -- возникла буквально из ниоткуда. Из обсуждения в кулуарах после доклада на C++ Russia 2017. И лично меня это очень радует. Ведь одно дело, когда ты реализуешь собственные задумки. И совсем другое, когда адаптируешь свой продукт к требованиям реального мира. Хотелось бы, чтобы подобных неожиданных предложений со стороны подкидывали бы побольше.

Ну и еще один маленький ;) повод сбегать в магазин: SObjectizer-у в этом году исполняется 15 лет. Если мне не изменяет склероз, то основные работы над кодом SObjectizer-4.0.0 закончились в конце апреля 2002-го. А в мае 2002 на SObjectizer-4 я уже начал делать что-то для продакшена. Такой вот небольшой юбилей.

[fury] Про RSDN и аккаунт so5team

Тут на RSDN.ru начали выяснять, является ли аккаунт so5team реинкарнацией аккаунта eao197. Вынужден сказать по этому поводу следующее.

Аккаунт so5team был создан специально для контекстного маркетинга SObjectizer-а.

Написанное из под so5team, имеет целью принести пользу, прямую или косвенную, проекту SObjectizer и стоящей за ним команде.

Поэтому, следует рассматривать персонаж so5team только лишь как одного из команды разработчиков SObjectizer-а. Не важно какого именно. Upd. Из под so5team на RSDN пишет не один человек.

Если бы eao197 хотел высказывать свое мнение на RSDN, то он бы делал это как eao197. Точно так же, как он продолжает делать это на LOR-е, Habr-е, FB и других ресурсах.

[book.business] Интересная книга "Что не убило компанию LEGO, а сделало ее сильнее. Кирпичик за кирпичиком"

Закончил читать интересную книгу Билла Брина и Дэвида Робертсона "Что не убило компанию LEGO, а сделало ее сильнее. Кирпичик за кирпичиком". Книга о том, как компания LEGO достигла своего расцвета в середине 1990-х, затем затеяла целую волну инноваций, чуть не вылетела в трубу в начале 2000-х, но смогла перестроиться и пережить кризис.

Книга интересная, но читается достаточно тяжело. Мне с трудом дались первые страниц семьдесят. Ибо авторы выбрали достаточно специфический подход к изложению материала. Сначала они описали проблемы, с которыми LEGO столкнулась во второй половине 1990-х. Затем описали шаги для преодоления этих проблем, предпринятые руководством компании и перечислили достоинства и преимущества этих самых шагов. И вот тут у меня зачастую возникало ощущение, похоже на "что за фигня?", ибо здравый смысл подсказывал, что ничего хорошего не должно было произойти... А авторы пишут про положительные результаты... Не было понятно, то ли я идиот (что весьма вероятно), то ли авторы врут (во что не верилось), то ли нужно было набраться терпения и посмотреть, что будет дальше.

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

По ходу чтения неоднократно возникало ощущение, что описываемое в книге очень сильно перекликается с тем, о чем говорится в замечательной книге "Живая компания". В частности, мне показалось, что предпринятые LEGO шаги по выходу из катастрофического пике в 2003-2004 годах, полностью соответствуют, как минимум, трем принципам, описанным Ари де Гиусом:

• восприимчивость компании, ее чувствительность к изменениям окружающей среды, дающие возможность учиться и адаптироваться;
• сплоченность коллектива и идентификация всех сотрудников компании как части единого целого;
• консервативное и спокойное отношение к собственным финансам: без рискованных инвестиций, обеспечение роста и развития за счет собственных средств.

Еще одно ощущение после прочтения: ее материал может оказаться полезен тем здравомыслящим управленцам, которые волею судьбы оказались подчинены команде "эффективных менеджеров" с наполеоновскими планами развития. Когда ретивый ТОП-менеджер бодро декларирует грандиозные планы расширения сразу в нескольких очень разных областях, перечисляет десяток главных приоритетов на ближайший год, то интуиция подсказывает, что добром это не закончится. А вот математически это выразить сложно. Как раз история компании LEGO может служить отличным примером того, что следует ждать от таких слишком оптимистичных планов по захвату новых рыночных ниш. Вряд ли эффективных менеджеров получится переубедить, но хотя бы для самого себя можно будет спрогнозировать развитие событий и выбрать соответствующую линию отходаповедения.

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

[prog.humour] Ну реально: "Why do all this RAII or GC shit, if you just can manage your runtime as a round robin?"

По наводке из G+ ленты Meeting C++ вышел на интересное на reddit-е:

Here is something that was described to me as a real production configuration that was done to solve memory leaking everywhere.

It was a Java service taking fairly high amount of traffic. In order to get consistent response times they setup this configuration in each machine:

1) Each machine runs 4 JVMs. 2) 1 JVM that is starting up 3) 1 JVM that is shutting down 4) 2 JVMs that are serving traffic. 5) Every 2 minutes a JVM starts/stops. 6) No JVM lives for more than 8 minutes.

I found that to be both horrifying and a rather clever way to work around the problem.

Т.е. рассказывают по некую систему на Java, которая должна была обрабатывать изрядный поток трафика. И для того, чтобы не бороться с утечками памяти люди просто сделали так, что у них одновременно работает четыре JVM: одна стартует, вторая завершается, две другие нормально работают и обслуживают трафик. Каждые 2 минуты одну из работающих JVM заглушают, а на ее место запускают новую JVM. В итоге ни одна из JVM не работает дольше 8 минут.

Был бы я лет на 10 помоложе, наверняка бы постебался на тему криворуких программистов в частности и атрофии головного мозга, которую вызывает использование Java вообще. Но количество набитых шишек все-таки дает о себе знать. Поэтому сейчас мне кажется, что это отличное инженерное решение. Ну что поделать, shit happens. А если можно построить железобетонное решение, которое работает не смотря на этот самый shit, то это просто здорово.

В связи с чем вспоминается две похожие истории.

Первая связана с патерном Disruptor, о котором много говорили в узких кругах несколько лет назад. Помнится, компания Lmax, которая Disruptor и описала, рассказывала, что у них JVM, внутри которой массированная обработка событий посредством патерна Disruptor и крутилась, просто-напросто раз в сутки перезапускалась. На сутки RAM для этой JVM хватало, а потом следовал простой "освежающий рестарт" и следовали очередные сутки работы нагруженного приложения.

Вторая история связана с одним из написанных на C++ проектов в компании Интервэйл. Там был родительский процесс диспетчер и N дочерних процессов. Каждый дочерний процесс выполнял запросы к удаленному серверу по HTTPS. Но время от времени, иногда после нескольких часов, иногда после нескольких дней непрерывной работы какой-нибудь из дочерних процессов тупо повисал. Непонятно почему. Просто зависал и все. Естественно, это обнаруживалось и процесс прибивался, но т.к. запрос не был выполнен, то это сказывалось на пользователе, чей запрос не обрабатывался. И хотя таких сбойных запросов оказывалось всего ничего, какие-то тысячные доли процента, но все равно неприятно.

Т.к. причину подвисаний нам найти не удалось (непонятно, на что нам было грешить -- на libcurl, openssl, CryptoPro или еще что), то мы просто сделали ограничение на время жизни дочерних процессов. Прожил больше нескольких часов -- будь добр, заверши свою работу, а мы вместо тебя запустим новый дочерний процесс. Поскольку такое принудительное умерщвление дочерних процессов приходилось на моменты, когда дочерний процесс запросы пользователей не обрабатывал, то получилось, что мы и от проблемы избавились, и запросы пользователей терять перестали.

PS. Пока писал, вспомнил еще одну историю. Совсем древнюю, относящуюся к временам, когда Ruby-On-Rails произвел эффект разорвавшейся бомбы. Помниться, читал какой-то блог пост, в котором автор описывал как они решали проблему обслуживания большого количества запросов в RoR-приложении. Способ был примитивный: на сервере запускалось несколько десятков серверов lighttpd и отдельный балансировщик разруливал нагрузку между ними. Но важно то, что RoR вместе с lighttpd не всегда работали устойчиво и иногда падали. Поэтому у них на серверах работал по крону специальный скрипт, который опрашивал инстансы lighttpd и, если обнаруживал отсутствие оного, то просто рестартовал упавший инстанс заново. Самая мякотка была в том, что рестарты происходили с темпом где-то раз в минуту. Т.е. раз в минуту какой-то инстанс RoR-приложения и lighttpd просто переставал работать. Ну, по крайней мере, я так запомнил :)

[prog.tale] Сегодняшнее. Hа тему "ну как жопой чувствовал..."

Функциональность новой версии SO-5 готова уже несколько недель как. Первоначально даже были планы сделать сегодня, 4-го мая, официальный релиз. Но где-то пониже спины было неприятное чувство, что этого делать не нужно. Во-первых, хотелось больше актуальной документации подготовить. Во-вторых, имело смысл дождаться окончания майских праздников, поскольку у изрядной части русскоязычной аудитории сейчас что-то вроде небольших каникул. В-третьих, было ощущение, что можно еще накидать каких-то тестов и примеров, которые бы позволили выявить какие-нибудь скрытые ошибки в новом функционале. Про такие ощущения еще говорят "жопой чую", уж простите мне мой французский.

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

В общем, с одной стороны, повезло. С другой -- интуиция не подвела, что не может не радовать :)

[prog.c++] Пример асинхронного однопоточного http-сервера на базе so-5.5, restinio и asio

Подготовка к релизу SO-5.5.19 вышла на финишную прямую. Есть надежда, что за неделю завершим подготовку документации и сопроводительных материалов, и после майских праздников выкатим официальный релиз. Пока же попробую на примитивном примере показать две основные фичи версии 5.5.19: способность SObjectizer-а работать только на одной рабочей нити и распространение мутабельных сообщений. Более того, в этом примере будет использоваться такой вариант SObjectizer Environment, который использует asio-шный event-loop в качестве бэк-энда. Подробнее обо всем этом ниже в посте.

Пример представляет из себя примитивнейший http-сервер, который при выполнении запроса к URL '/' генерирует простенькую html-страничку. Но генерирует с задержкой, которая постепенно увеличивается. При этом, не смотря на то, что обработка отдельного http-запроса "тормозит", http-сервер спокойно занимается приемом и обработкой параллельных запросов.

В качестве http-сервера используется наш restinio, который мы как раз и создавали для того, чтобы иметь возможность легко и непринужденно делать асинхронную обработку http-запросов. Так, благодаря архитектуре restinio мы имеем возможность делегировать обработку запроса SObjectizer-овскому агенту (хотя сам restinio к SObjectizer вообще не привязан и может использоваться отдельно). В примере задействована находящаяся в активной разработке версия restinio-0.2. В публичный ее репозиторий актуальные изменения мы пока еще не влили, вероятно сделаем это ближе к дате релиза SO-5.5.19.

Основная фишка данного примера в том, что в нем все работает на одной общей нити: и asio, и restinio, и SObjectizer. Т.е. SObjectizer не создает никакой дополнительной инфраструктуры, для диспетчеризации событий агентов и таймеров используется asio и евоный event-loop.

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

Итак, сначала подключаем необходимые заголовочные файлы: