пятница, 22 июня 2018 г.

[prog.flame] А наброшу-ка на Rust по случаю тяпницы и релиза 1.27 :)

Вышел Rust 1.27.

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

Понять такую спешку сложно (а объяснить можно разве что эффективным менеджментом). Особенно в сочетании с такими пассажами:

Additionally, we would like to draw attention to something: just before the release of 1.27.0, we found a bug in the ‘default match bindings’ feature introduced in 1.26.0 that can possibly introduce unsoundness. Since it was discovered very late in the release process, and has been present since 1.26.0, we decided to stick to our release train model. We expect to put out a 1.27.1 with that fix applied soon, and if there’s demand, possibly a 1.26.3 as well.

Т.е. в версии 1.26 добавили баг в компилятор. Обнаружили это незадолго до выхода версии 1.27. Но т.к. пофиксить до релиза 1.27 не успевали, то оставили все как есть. Т.е. обнаруженный баг теперь присутствует и в 1.26, и в 1.27. По-моему -- это просто прекрасно. Больше даров богам эффективного менеджмента, когда дата релиза важнее качества релиза.

Растоманы обижаются, когда им говоришь, что у Rust-а упоротый и нечитабельный синтаксис. Мол, это не Rust плохой, это у меня нет вкуса и желания полюбить Rust так, как Rust полюбил их самих. Но вот всего одна строчка из первого же примера в анонсе:

pub fn foo(a: &[u8], b: &[u8], c: &mut [u8]) {

Ну ведь реально в этой строке каждая закорючка имеет архиважное значение :)

А что бы еще набросить на тему синтаксиса, вот прям скопирую фразу из анонса:

Rust’s trait object syntax is one that we ultimately regret.

Это из раздела про нововведение под названием dyn Trait. Кстати, сам этот раздел почему-то сильно напоминает знаменитый афоризм "хотели как лучше, получилось как всегда".

PS. Пока что получается, что как бы меня не задолбал C++ за 25 лет, адекватной замены для него пока еще нет. Ибо переход с C++ на Rust иногда выглядит как замена шила на мыло.

PPS. Еще прекрасный образчик синтаксиса по ссылке из комментариев:

fn new<'a: 'f>(foo: &'f Foo<'a>) -> Self {
    let foo1: &'f Foo<'f> = foo;
    Context { foo: foo1 }
}

Ну ведь это же просто восхитительно! Сразу возникает желание программировать на языке с таким понятным и читабельным синтаксисом ;)

пятница, 15 июня 2018 г.

[prog.thoughts] Несколько слов о попытке спроектировать транспорт для SObjectizer-а на базе ZeroMQ

Сегодня попытаемся поговорить о том, зачем же я засел за изучение ZeroMQ. И, надеюсь, подведем некоторый итог небольшой серии постов про ZeroMQ (раз, два). Речь пойдет о попытках разработать транспорт для SObjectizer-а, чтобы дать пользователям возможность с минимальными усилиями строить распределенные SObjectizer-приложения. Поэтому, если кому-то не интересно читать про SObjectizer, то данный пост можно проигнорировать.

Ну а если тема SObjectizer-а вам интересна или вы вообще интересуетесь тем, как появляются те или иные проектные решения, тогда, надеюсь, данный пост будет вам интересен.

четверг, 14 июня 2018 г.

[prog.flame] Вещи, которые мне не понравились при знакомстве с ZeroMQ

После недели штудирования и обдумывания "0MQ - The Guide" попробую зафиксировать несколько вещей, которые мне не понравились в ZeroMQ. А в следующем посте я попробую рассказать о текущих соображениях на тему применения ZeroMQ для построения распределенных SObjectizer-приложений. Так что сегодняшний рассказ может быть интересен более широкому кругу читателей.

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

Вначале своего рассказа я попробую высказать некое общее впечатление (или даже несколько впечатлений) о ZeroMQ вообще, а затем перейду к перечислению вполне себе конкретных вещей, которые мы можем увидеть в ZeroMQ или вокруг ZeroMQ.

Disclaimer. Я не буду рассказывать об азах ZeroMQ. Поэтому, если вы со спецификой ZeroMQ не знакомы, то написанное ниже может быть для вас непонятно. Поэтому я могу посоветовать найти время и хотя бы поверхностно познакомиться с двумя первыми главами из "0MQ - The Guide" (под названиями "Chapter 1 - Basics" и "Chapter 2 - Sockets and Patterns", хотя может хватить и только первой главы).

[prog.flame] Удалось более четко сформулировать свое отношение к ZeroMQ

Штудируя 0MQ - The Guide в конце-концов поймал себя на том, что по ходу усвоения материала я думаю не о том, как использовать ZeroMQ в тех или иных сценариях, а о том, что мне в ZeroMQ не нравится и почему мне не хочется использовать ZeroMQ.

Т.е. глядя на ZeroMQ я вижу не достоинства, а недостатки (возможно, чисто субъективные).

Это, блин, нехороший знак. Хотя претензии к ZeroMQ "математически выразить" (с) еще не могу, на осмысление своих претензий к ZeroMQ требуется время.

PS. В качестве пояснения. В последнюю неделю пытаюсь разобраться с тем, можно ли использовать ZeroMQ в качестве транспорта для добавления поддержки распределенности в SObjectizer. Поэтому смотрю на ZeroMQ не как на инструмент для решения конкретной прикладной задачи, а как на подложку, на которую хотелось бы положить асинхронное взаимодействие SObjectizer-овских агентов.

вторник, 12 июня 2018 г.

[smartphones] Кто из производителей смартфонов регулярно выкатывает обновления для своих телефонов?

Хочу обратиться с внезапным вопросам к тем моим читателям, которые находятся в теме смартфонов на Android-е. Есть ли нормальные производители смартфонов, которые регулярно выкатывают обновления программной начинки для своих телефонов? Особенно если это не топовые модели, а более-менее бюджетные, за $100-150-$200?

Вот у меня двухлетний Samsung J200, который работает на Android 5.1.1. И что-то я не припомню, чтобы для него приходили обновления от Samsung-а. Обновления для установленных приложений, вроде GMail, приходят. А вот для самой системы... Вряд ли такое имело место быть.

Поскольку я далек от темы смартфонов (телефон для меня -- это прежде всего звонки, мобильный Интернет и, временами, навигация на местности), то не в курсе, есть ли производители, которые после выпуска своей модели на рынок регулярно выпускают софтварные обновления и, может быть, даже позволяют обновить версию Android-а на аппарате. Или же нормальной практикой является выпустить модель с актуальной на тот момент версией Android-а на борту, а потом забить на ее сопровождение?

понедельник, 11 июня 2018 г.

[prog] Два абзаца из zguide, которые отлично передают текущие ощущения от ZeroMQ

Очередное прекрасное в ØMQ - The Guide:

The basic request-reply pattern (a REQ client socket doing a blocking send/receive to a REP server socket) scores low on handling the most common types of failure. If the server crashes while processing the request, the client just hangs forever. If the network loses the request or the reply, the client hangs forever.

Request-reply is still much better than TCP, thanks to ZeroMQ's ability to reconnect peers silently, to load balance messages, and so on. But it's still not good enough for real work. The only case where you can really trust the basic request-reply pattern is between two threads in the same process where there's no network or separate server process to die.

Т.е. один из основных шаблонов взаимодействия в ZeroMQ, REQ-REP, на самом деле кривой и не подходит для использования в реальной работе.

И вот так по ходу чтения всего zguide получается: читаешь-читаешь, в голове закрадывается мысль -- "Да это же шляпа какая-то!" А чуть ниже это чуть ли не открытым текстом пишут. Мол, это не работает в таких-то и таких-то ситуациях, нужно использовать более сложные шаблоны... Но после знакомства с этими более сложным шаблоном привлекательность ZeroMQ начинает блекнуть. Тем более, что по ходу дальнейшего чтения опять начинает закрадываться мысль -- "Да это же шляпа какая-то!" :)

вторник, 5 июня 2018 г.

[business.flame] GitHub достался Microsoft-у: горшочек не вари! :)

Наблюдая за реакцией на покупку GitHub-а Microsoft-ом обожрался поп-корном, больше уже не могу :)

Никогда не был любителем творчества Ильфа и Петрова, но нельзя не отдать им должное -- явление "пикейных жилетов" ими было подсмотрено и описано очень точно и ярко. Развитие Интернета, форумов и социальных сетей подтверждает это каждый день. Особенно когда случаются такие громкие события.

Что еще хочется отметить, так это огромный всплеск внимания к GitLab-у. "Черный лебедь" Нассима Талеба в чистом виде. Не каждому стартапу такая удача перепадает, остается надеяться, что ребята смогут этим вниманием грамотно воспользоваться.

понедельник, 4 июня 2018 г.

[business.flame] Слухи о покупке GitHub-а Microsoft-ом заставляют запасаться поп-корном

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

Чтобы пояснить причину своего сарказма: если кто-то не знал, то GitHub -- это обычное коммерческое предприятие, целью которого должно быть принесение прибыли своим владельцам (основателям и инвесторам). То, что GitHub дает всем желающим бесплатный хостинг OpenSource-проектов -- это всего лишь часть маркетинговой стратегии конкретной коммерческой компании. Соответственно, халява может закончится как по причине прекращения существования конкретной коммерческой компании, так и по причине изменения маркетинговой стратегии. Кстати, если кто-то не знал, то компании смертны, порой -- внезапно смертны, причем подавляющее большинство компаний неизбежно смертны и в довольно таки короткий срок.

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

Ну и, вообще-то говоря, после того, как GitHub будет куплен, он продолжит стремится к той же цели -- приносить деньги своему владельцу. Кем бы этот владелец не был. Разве что, в зависимости от специфики занятий нового владельца, способы монетизации могут поменяться. Так, если будучи самостоятельной компанией, GitHub пытался зарабатывать на хостинге закрытых проектов (и, полагаю, был не очень успешен в этом начинании), то под крылом, к примеру, Microsoft-а, GitHub может приносить дивиденды новому владельцу каким-то другим способом. Ну и, соответственно, новый владелец может иметь больше ресурсов дабы затыкать финансовые дыры в бюджете GitHub-а из других источников.

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

В общем, ничего личного, just business. А тем, кто живет в идеалистическом мире бесплатного OpenSource, в котором, якобы, не действуют обычные законы капиталистического общества, надо бы снять розовые очки.

пятница, 1 июня 2018 г.

[prog.c++] Попытка подружить "модульный" Boost с MxxRu::externals

Начал чесать репу на тему создания такого mchain-а или mbox-а для SObjectizer-а, который бы позволил двум SObjectizer-приложениям на одной ноде взаимодействовать друг с другом через разделяемую память. Беглый поиск по Интернету показал, что выбор инструментов для этой задачи сравнительно небольшой: либо придется делать свой собственный велосипед, либо же нужно брать что-то из Boost, ACE, POCO или чего-то сравнимого по размеру.

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

Решил попробовать Boost.Interprocess. Но т.к. с "большим" Boost-ом иметь дело не хочется, то попробовал подтащить в небольшой демо-проектик Boost.Interprocess и все его зависимости из "модульного" Boost-а, который нынче доступен на github-е.

Методом проб и ошибок это удалось сделать (в очередной раз скажу, что Boost в виде большой говнопомойки не нужен и должен быть разрушен). Результат можно увидеть в этом репозитории. Ниже чуть-чуть прокомментирую то, что получилось.

[prog.flame] Давненько не посылал лучей поноса в Boost, пора исправиться.

При всем уважении к авторам библиотек, которые входят в Boost, не могу не сказать в очередной раз, что сам по себе Boost -- это помойка. Все завязано со всем и если ты хочешь использовать какую-то милипиздрическую часть Boost-а, то ты вынужден иметь дело со всей помойкой. И таскать ты ее будешь за собой постоянно. Вот сделал ты 5 лет назад небольшую тулзу на Boost-1.54, сейчас тебе потребовалось что-то в ней поменять и... И либо ты берешь откуда-то этот самый 1.54, ли пытаешься собрать свой старый код с современным Boost-ом. Ну или делаешь ты сейчас что-то на Boost-1.66, твой код кто-то другой пытается доработать под своим Linux-ом, а там из коробки только Boost-1.58.

Так что еще раз, для лучшего понимания сути претензий. Boost -- это такое говносборище C++ных библиотек, которое изначально рассчитано на то, чтобы быть только говносборищем и работать только в говносборе.

[life.cinema] Очередной кинообзор (2018/05)

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

Ночные игры (Game Night, 2018). Понравился. Посмотрел с удовольствием.

Опасный бизнес (Gringo, 2018). Не шедевр, но понравился. ИМХО, отличное попадание в свои роли у Джоэла Эдгертона, Шарлто Копли и, особенно, Шарлиз Терон.

Винчестер. Дом, который построили призраки (Winchester: The House that Ghosts Built, 2018). Если ответственно подойти к созданию ужастика и привлечь толковых актеров, то получится вполне добротное кино. Но для любителей жанра, к каковым я уже не отношусь.

Мстители: Война бесконечности (Avengers: Infinity War, 2018). Красочно. Масштабно. Но лучше не вдумываться в происходящее, а то начинает казаться, что на экране происходит какой-то лютый звиздец. Но красочный. Масштабный.

Дедпул 2 (Deadpool 2, 2018). Мне было скучно. Показалось, что фильм для фанатов комиксов и серии фильмов про супергероев, которые находятся в контексте и лучше понимают намеки и отсылки к другим фильмам.

Тихое место (A Quiet Place, 2018). Ожидал много большего, сильно разочаровался при просмотре. Нудновато, не цепляет, не хватает саспенса.

Жажда смерти (Death Wish, 2018). Ждал большего. Посмотреть можно, но, на мой взгляд, Брюс Уиллис в главной роли -- это основная проблема фильма. Изначально понятно, что если главный герой "Крепкий орешек", то он в итоге всех замочит. Посему главному герою и не сопереживаешь, только ждешь когда же экшен начнется, а происходит экшен не так уж и часто.

Невидимка (In Darkness, 2018). Ерундистика. Затянуто, сюжет притянут за уши, мотивация героев не очень понятна, даже главный сюжетный поворот, случившийся в самом конце, предугадывался чуть ли не с самого начала.


Евгений BadComedian Баженов выпустил эпический разбор говношедевра "Движение вверх". Как по мне, так к просмотру обязателен. Не смотря на хронометраж более 2-х часов и матерную лексику. Цитаты из Никиты Михалкова расставлены очень к месту. Безусловно лучшая работа BadComedian-а за последнее время. Жаль только, что причина возникновения этого обзора, тот самый "Движение вверх", собрал столько денег. Это означает, что испражняться на великое прошлое великой страны, которую такие же "творцы" уже просрали однажды, не просто продолжат, а будут делать это гораздо активнее. Хотя еще более страшно не от того, что такие "творцы" есть и не тонут, а то, что многим зрителям фильм "Движение вверх" понравился. Что означает, что кто-то будет срать с удвоенной силой, а кто-то жрать это полной ложкой и с удовольствием.

понедельник, 28 мая 2018 г.

[prog.thoughts] На тему добавления поддержки распределенности в SO-5

В этом посте попробую зафиксировать текущие мысли и планы на тему поддержки распределенности в SO-5.

Краткий взгляд в историю вопроса

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

Изначально в SO-4 поддержка распределенности была. Причем была в двух вариантах.

четверг, 24 мая 2018 г.

[prog.c++] Новая статья о SObjectizer на Хабре. На этот раз добавление распределенности на базе MQTT

В этот раз получился довольно большой рассказ о нашем эксперименте по добавлению распределенности в SObjectizer-приложение на базе MQTT: "Добавляем распределенность в SObjectizer-5 с помощью MQTT и libmosquitto". Читаем, комментируем. Кому не удобно комментировать на Хабре, может сделать это здесь.

Отдельно хочу обратить внимание на раздел "Заключение" в статье. Если кому-то хочется видеть поддержку распределенности в SObjectizer-е, то найдите, пожалуйста, время и поделитесь своими хотелками. Без этого ничего никуда не сдвинется.

Так же дайте знать, пожалуйста, если кому-то хочется иметь перевод этой статьи на английский (точнее на то, что мы считаем английским).

В общем, приятного чтения!

четверг, 17 мая 2018 г.

[prog.c++] Data exchange between threads without a pain? CSP-channels to rescue

Development of multi-threaded code is a complex task. Really complex. Fortunately there are some high-level abstractions those have been invented long time ago, for example: task-based parallelism, map-reduce/fork-join, CSP, actors and so on.

But it seems that many C++ developers just don't know anything else than std::thread and std::mutex. There are too many questions like: "I have to launch three work threads. The first must do that, the second must do that, and the third must do that. I launch them this way and do information exchange between them this way. Am I do it right?"

It is a pity that many C++ developers, especially novices, know about std::thread but don't know about ready to use tools which can simplify their lives (like Intel TBB, HPX, QP/C++, Boost.Fiber, FastFlow, CAF, SObjectizer, etc).

It seems that a simple example of usage of some existing library can help to explain how high-level abstractions can reduce the complexity of multi-threaded code development. Because we develop SObjectizer as a tool for simplification of development on multi-threaded code in C++ we will try to show how to use CSP-channels implemented in SObjectizer to avoid developer's headache.

A Simple Demo Example

This repository contains a very simple demo example. It is a small application which performs a "dialog" with an user on the main thread. When an user enters 'exit' the application finishes its work.

среда, 16 мая 2018 г.

[prog.c++.flame] Неоднозначные впечатления от нового предложения Саттера "Zero-overhead deterministic exceptions: Throwing values"

На Reddit-е недавно дали ссылку на документ "Zero-overhead deterministic exceptions: Throwing values" за авторством Герба Саттера. Когда выдалось время пробежался по содержанию. Затем пробежался еще раз... Как-то все это неоднозначно.

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

С другой стороны, есть ряд моментов, которые сильно смущают.

Во-первых, смущает необходимость помечать функции ключевым словом throws. Есть смутное подозрение, что если такой механизм "статических исключений" введут, то подавляющее большинство функций в новом коде будут помечены как throws. А оставшиеся -- как noexcept. Наверное, это и не плохо, т.к. альтернатива с явным использованием типа std::expected (к примеру) приведет к тому, что большинство функций будут возвращать std::expected. В общем, и то, и другое - "масло-маслянное".

Во-вторых, смущает какие-то отсылки к предложению по добавлению контрактов в C++ (которого я толком не видел) и соображения следующего рода: "A precondition (e.g., [[expects...]]) violation is always a bug in the caller (it shouldn’t make the call). Corollary: std::logic_error and its derivatives should never be thrown (§4.2); use contracts instead."

У меня был опыт использования контрактов в Eiffel и D. Контракты -- это красивая штука, но с ней есть вот какая заковыка: полная проверка контрактов (т.е. и пред-, и постусловий, и инвариантов) -- это очень дорого. В том же Eiffel при компиляции проекта с полностью включенными контрактами (в том числе и в stdlib) результирующий exe-шник раздувался в разы и, соответственно, в разы падала производительность. Да, при этом ты перестаешь боятся того, что в программе что-то пойдет не так, но потеря скорости работы, да еще столь существенное... Поэтому в Eiffel-е, ЕМНИП, была рекомендация включать полную поддержку контрактов только в debug-билдах, а в release-билдах оставлять только проверку предусловий. А если вы хотите выжать из кода максимум, то и проверку предусловий приходится выключать.

Если же в release-билде отключить проверку контрактов вообще, то возникает вопрос: а что делать в ситуациях, когда какой-то вариант defensive programming нужно оставить даже в release-сборке? Ну вот работаете вы в своем коде с данными, приходящими из внешнего мира, неужели вы все проверки этих данных оформите в виде контрактов? Вряд ли. А раз так, то тогда приходится решать, что должно быть сделано в виде обычных проверок (с кодами ошибок или выбросом исключений), а что должно быть сделано с помощью контрактов.

Как только разработчику приходится что-то решать, так сразу же сложность использования языка возрастает. C++ и так далеко не самый простой язык и постоянно слышатся жалобы о том, что на C++ сложно программировать, т.к. есть множество способов сделать одно и то же. Появление контрактов, предположу, сделает C++ еще сложнее в использовании. При этом, повторюсь, контракты -- это красивая и прикольная штука, очень сильно способствующая документированию и повышению понятности кода. Но чтобы научиться разумно использовать контракты, нужно набить себе шишек.

Ну и в-третьих, очень мне не понравились пространные, но акцентированные рассуждения о том, что нужно пересмотреть поведение C++ного рантайма при исчерпании памяти. Мол, вместо выбрасывания bad_alloc-а нужно грохать все приложение. А кому такое поведение не нравится, тот пусть использует специальные варианты new(nothrow) или новые функции try_reserve с ручными проверками возвращаемого значения.

Вот это, как по мне, так уже полный трындец, дорогие товарищи. Ну нельзя же так :(

Я понимаю, что Саттер ссылается на большой опыт и приводит примеры того, что сделано в Microsoft и как в продуктах Microsoft подобные подходы давно используются. Но ведь эти примеры -- это же не весь мир. И далеко не все приложения, которые были и, что важно, еще будут на C++ написаны. Поэтому неприятно, когда такие судьбоносные решения принимаются на основании ограниченной выборки.

Причем отдельно непонятен такой аргумент как:

Most code that thinks it handles heap exhaustion is probably incorrect (see also previous point; there is some truth to the mantra “if you haven’t tested it, it doesn’t work”). Recovery from heap exhaustion is strictly more difficult than from other kinds of errors, because code that is correctly resilient to heap exhaustion can only use a re-stricted set of functions and language features. In particular, recovery code typically cannot ask for more memory, and so must avoid calling functions that could allocate memory, including functions that could fail by throwing another of today’s dynamic exceptions which would require increased allocation.

Если обработка исчерпания памяти реализована неправильно, то с вероятностью, близкой к 100%, программа все равно упадет. Хотя бы из-за того, что будут возникать повторные bad_alloc-и, в том числе и из деструкторов объектов, вызванных при раскрутке стека из-за первого bad_alloc-а. Так что неправильно написанное приложение все равно завершит свою работу преждевременно. Зачем же при этом мешать тем приложениям, которые смогут пережить исчерпание памяти?

В общем, раздел 4.3 в данном предложении расстроил меня очень сильно. Если бы его не было, я бы воспринял это предложение Саттера с гораздо большим воодушевлением.

Остается надеяться, что решение по этому предложению не будут принимать с бухты-барахты и его еще доведут до ума.

четверг, 10 мая 2018 г.

[prog] MxxRu обновился до версии 1.6.14.5

Сегодня выкатили очередное обновление для нашей системы сборки MxxRu (она же Mxx_ru). В версии 1.6.14.5 был исправлен недочет в поведении анализатора C++зависимостей, из-за которого происходило зацикливание, если в компилирующемся проекте активно использовались конструкции вида:

#include "../details/some_file.h"

Например, мы поймали эти проблемы при попытке использования spdlog-0.16.3, в котором как раз такие include и используются.

Обновится до версии 1.6.14.5 можно посредством команды:

gem update Mxx_ru

В каких-то Linux-ах это нужно будет делать с правами администратора, например, в Ubuntu:

sudo gem update Mxx_ru

пятница, 4 мая 2018 г.

[prog.flame] Язык Go как следствие деградации софтостроения или спусковой крючок для оной?

К языку Go у меня сложное отношение. С одной стороны, язык прост как две копейки, осваивается за один-два вечера, достаточно безопасен, чтобы клепать код не особо приходя в сознание и не отстреливая себе ничего по дороге, снабжен большим количеством модных батареек и, что важно, дает разработчикам простую, но мощную, модель для concurrent programming. Поэтому нельзя не отметить, что для ряда задач сейчас Go является гораздо более уместным выбором чем:

среда, 2 мая 2018 г.

[prog.c++] Небольшое обновление json_dto-0.2

Мы выкатили небольшое обновление своей легковесной библиотеки для упрощения работы с JSON и RapidJSON в C++ -- json_dto-0.2.4.

В версии 0.2.4 мы отвязали json_dto от особенностей работы RapidJSON с std::string и зависимости от RAPIDJSON_HAS_STDSTRING. Теперь json_dto нормально работает с std::string даже если RAPIDJSON_HAS_STDSTRING не определен.

Еще имеет смысл отметить добавление поддержки CMake для json_dto. А так же создание зеркала json_dto на github (думаю, что тем, кто может стягивать зависимости только с github-а, это должно понравится).

В общем, еще один наш инструмент стал еще лучше. Кто еще не пробовал -- рекомендуем ;)

вторник, 1 мая 2018 г.

[life.cinema] Очередной кинообзор (2018/04)

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

О чем говорят мужчины. Продолжение (2018). В принципе, достойное продолжение. Хотя, как по мне, первая половина фильма довольно слабая. Зато вторая половина и финал все оправдывает.

Ну, здравствуй, Оксана Соколова! (2018). Не знаю, может фильм попал под настроение, но зашел хорошо. Поржал.

Охота на воров (Den of Thieves, 2018). Добротный и, местами, довольно бодрый криминальный фильм.

Беспредел: Последняя глава (Autoreiji saishusho, 2017). Фильм для поклонников фильмов Такеши Китано и тех, кому интересна серия фильмов про японскую мафию "Беспредел". Остальным, скорее всего, будет неинтересно.

Пассажир (The Commuter, 2018). Был сильно разочарован. Сложилось ощущение, что в смысл происходящего лучше не вдумываться.

Недруги (Hostiles, 2017). Начал смотреть и с трудом досмотрел только из-за актерского состава. Фильм слишком уж тягомотный и слишком уж привязанный к американской специфики. Кроме того, на протяжении всего фильма не покидало ощущение, что это какое-то запоздавшее и лицемерное извинение за геноцид коренного американского населения. Т.е. эдакая заказуха.

Ограбление в ураган (The Hurricane Heist, 2018). Редкой тупости кино, как мне показалось.

Тебя никогда здесь не было (You Were Never Really Here, 2017). Трейлер гораздо круче самого фильма. А сам фильм какая-то невнятная тягомотина.

Титан (The Titan, 2018). Редкая дрянь. Не смотреть!

Тихоокеанский рубеж 2 (Pacific Rim: Uprising, 2018). Фильм для детей дошкольного возраста. Всем, кто постарше, лучше не смотреть вообще.


Отдельно хотелось бы сделать ремарки по поводу двух фильмов.

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

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

воскресенье, 29 апреля 2018 г.

[business.book] Впечатления от книги "Airbnb. Как три простых парня создали новую модель бизнеса"

По дороге в Питер и обратно прочел небольшую книгу "Airbnb. Как три простых парня создали новую модель бизнеса". Позволю себе высказать свои впечатления.

Книга не понравилась. Тратить свое время и деньги на нее не рекомендую.

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

Вот ты читаешь, что кто-то пожаловался на услугу Airbnb или на качество техподдержки Airbnb, прошло какое-то время и Airbnb выпустила пресс-релиз и обещала исправиться в будущем. Но меня интересует именно то, что происходило внутри Airbnb в связи с каким-то громким скандалом. Кто обосрался внутри компании и не принял вовремя нужных мер? Как и когда поняли, что все вышло из под контроля? Как выстраивали план решения проблемы? И выстраивали вообще? Кто принимал решения, какие меры воздействия были приняты? В общем, ничего, что действительно могло бы стать интересным и полезным, в 2/3 книги нет.

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

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


Отдельного разговора, наверное, заслуживает вся эта возня вокруг фондового рынка, рыночной капитализации и IPO. В книге пишут, что Airbnb оценивается чуть ли не в 30 миллиардов долларов. Миллиардов, Карл! При том, что это пока еще частная компания, которая не обязана отчитываться о своем финансовом состоянии. За время своего существования (т.е. с 2009-го года) Airbnb привлекла порядка 3 миллиардов долларов инвестиций и сейчас она оценивается в 31 миллиард (судя по Wikipedia). Последний раунд инвестиций состоялся в 2017-ом и составил один миллиард долларов. При этом, как я полагаю, мало кто реально знает, сколько действительно Airbnb зарабатывает. Вроде как речь идет о прибыли порядка 100 миллионов в год.

Сразу видно, что очень далек я от мира финансов, не понять мне, как компания с прибылью в $100 миллионов и долгами в $3 миллиарда может оцениваться в $31 миллиард. Не понимаю. Но, видимо, из-за этого непонимания я и не миллионер :)

суббота, 28 апреля 2018 г.

[life.book] Так вот о книге "Время Березовского"

Таки дочитал, сжав зубы, книгу Петра Авена "Время Березовского". Поэтому можно вернуться к начатой несколько ранее теме.

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

Первые две трети книги я прочитал часто матерясь про себя. Но не слишком сильно. Потом я взял паузу из-за того, что от прочитанного не просто подташнивало, а уже откровенно тошнило. И так уж получилось, что в эту паузу посмотрел на YouTube ряд роликов с выступлениями Елены Анатольевны Прудниковой. То, что она рассказывала про последние годы существования царской России, про то, что происходило в первые годы в СССР, вот все это всколыхнуло воспоминания из прочитанных когда-то мемуаров людей, добившихся больших успехов в СССР. Можно по разному относиться к том, что было в СССР и к тому, чего и как достигла советская власть. Но глупо отрицать, что за всего несколько десятков лет отсталая аграрная страна с практически отсутствовавшим промышленным производством, отсталым сельским хозяйством, тотальной нищетой и безграмотностью превратилась в одну из двух(!) сверхдержав. И вот в 1980-е и 1990-е все это было успешно профукано, вплоть до исчезновения самой страны и возникновением на ее месте каких-то мелких образований с неопределенным временем полураспада... Осознавая все это читать оставшуюся треть было гораздо сложнее, и матерился про себя я уже гораздо чаще и сильнее.

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

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

Получается, что для того, чтобы у меня сложилась какая-то картинка происходившего, мне нужно самому вооружится бумагой и карандашом, после чего тщательно выискивать и сличать показания разных персонажей об одних и тех же событиях. Плюс к тому, эти показания берет один человек, который задает интересные ему вопросы и не только/столько задает, сколько еще и высказывает собственное мнение. Соответственно, до меня доходит только та информация, которую захотел получить интервьюер и которой интервьюер удовлетворился. Что, возможно, во многих случаях меня бы не устроило и я бы, возможно, задал бы какие-то другие вопросы.

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

Часть вторая. Собственно о событиях из книги. При чтении складывалось ощущение, что люди просто не ведали, что творили. Ну т.е. люди из какого-то академического института проблем управления вдруг решили, что они должны стать бизнесменами, управленцами, войти в правительство и управлять страной. Не имея никакого отношения ни к реальному производству, ни к управлению чем-либо серьезным. Полагаю, даже не представляя, в какой именно стране они находятся, что за люди в подавляющем большинстве живут в этой стране, что нужно этим людям. Распад СССР и "лихие" 90-е -- это всего лишь закономерный итог. Читаешь и удивляешься, как это еще Россия умудрилась не докатиться до полного трындеца.

Часть третья. О Борисе Березовском. Если честно, то я всегда был более чем прохладен с творчеству Ильфа и Петрова. Конечно же, в детстве я прочел и "12-ть стульев", и "Золотого теленка". Но никогда не интересовался, был или у Остапа Бендера реальный прототип или нет. Но, определенно, Борис Березовский -- это и есть реальный Остап Бендер. Такой же "великий комбинатор" с тем же самым итогом. Редкий пройдоха и проныра, полагаю, откровенный мудак в определенных вопросах, которого вынесло наверх мутными водами перемен в СССР. Ну и ценность он представляет для тех людей, которых, как и его, вынесло наверх этими же самыми мутными водами. Обычным людям, вроде меня, остается только жалеть, что этого персонажа, вместе с ему подобными, не пустили в расход решением ВЧК по законам революционного времени.

Часть четвертая. О людях, отметившихся в книге. И о Петре Авене в частности. Вот уж, действительно, наглядное подтверждение тезиса: дай дураку выговорится и он сам о себе такого расскажет, что все с ним станет совершенно ясно и понято. Так и здесь. Многие персонажи там абсолютно прекрасны в своей незамутненности. Петр Авен, без сомнения, ох*енный бизнесмен. И, возможно, милый и хороший человек в жизни. Но, при этом, наглядная демонстрация того, что можно быть очень талантливым в одном и совершеннейшим профаном в другом. Наверное, Авен является одним из столпов, на котором держится Альфа-Групп. Но, при этом, как же хорошо, что он не имеет отношения к управлению государством. Ибо в конце книги автор приводит три свои большие статьи, касающиеся разных периодов в истории России конца 1990-х и начала 2000-х. Читая эти статьи просто недоумеваешь, как можно управлять большим бизнесом и при этом быть таким наивным идиотом в отношении всего остального?

Вот это самое непонимание и является одним из главных итоговых ощущений от прочтения сего сборника интервью.

Резюмируя. Книга говно. Читать можно только из энтимологического интереса, только если хочется лучше понять, какое скопище мудаков в 1990-х годах приложило свою руку к тому, что сейчас стало современной Россией.


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

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

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

вторник, 24 апреля 2018 г.

[life.photo] Магазин "Гитарного клуба" в Питере и внезапная фотосьемка в режиме характерного портрета...

Некоторое время назад дочка изъявила желание научиться игре на гитаре. Соответственно, встал вопрос выбора и покупки гитары. Проблема, однако была в том, что ни мы сами, ни наши близкие знакомые к музыке вообще и к гитарам в частности отношения не имели. Нужно было как-то самим разбираться в том, что за гитары бывают, как они различаются, на что нужно обращать внимание при покупке и т.д. Но как?

В наш век Интернета естественный подход -- поискать ответ в Сети. Что мы и попробовали сделать. В частности, на YouTube можно отыскать великое множество роликов о гитарах, об их выборе и вообще обо всем, что с этим связано.

Но, как это часто бывает, качество большинства роликов оставляет желать много лучшего. Если не ошибаюсь, было найдено всего 3 (три) толковых обзора на тему разновидностей гитар и особенностей их выбора. Один из этих роликов был найден на канале "Гитарного клуба". И, что самое ценное, на этом канале нашлось еще много всего интересного и полезного. Не только обзоры гитар и советы по их выбору. Но и рассказы мастеров по ремонту гитар о том, как гитары доводятся до нужного состояния, как меняются струны и т.д.

Причем, что меня очень подкупало в роликах "Гитарного клуба", так это любовь авторов роликов к музыке, гитарам и вообще ко всему, что они делают. Не часто такое бывает, но тут людям удалось свой энтузиазм и увлеченность донести до зрителей. Ну до меня, по крайней мере, точно. В общем, однозначно респект и уважуха ребятам за то, что они делают. Жил бы в Питере или в Москве, то обязательно бы поехал покупать гитару именно к ним. Но мы вообще не в России, так что купили, надеюсь, лучшее, из того, что смогли разыскать у себя в Гомеле.

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

20180422-142340-DSCF9893

Мне понравилось. Маленькое, тихое, уютное место для "своих". Абы кто случайный туда не попадет, а тот, кто идет туда целенаправлено, сможет спокойно попробовать те инструменты, которые ему понравились.

Помимо того, что я смог сказать свое спасибо людям, снимающим такие классные ролики про гитары, мне еще и повезло провести внезапную фотосъемку в любимом мной жанре "характерный портрет в профессиональном интерьере". Молодая пара покупала укулеле и гитарный мастер Евгений минут за 15-20 провел доводку покупаемого инструмента. Ну а я заснял этот процесс.

20180422-143118-DSCF9903

Правда, в моем распоряжении был только простенький и довольно старый по нынешним меркам Fujifilm x30, который совсем не предназначен для такого рода съемок. Да и условия для фотоаппарата с такой маленькой матрицей и невысокими рабочими ISO были крайне непростые. Так что получилось так, как получилось. Пришлось перевести серию в ЧБ, чтобы хоть как-то компенсировать потерю качества на ISO800. Тот самый случай, когда очень пожалел, что не взял свою большую чОрную зеркалку с большим чОрным портретником... Тут даже им пришлось бы постараться.

В общем, посмотреть как получилось можно вот в этом альбоме. Не знаю, как кому, а я получил большое удовольствие как от самого магазина, так и от фотосъемки. Давно не доводилось брать фотоаппарат для таких целей, к сожалению.

Ребятам же из "Гитарного клуба" еще раз хочется сказать спасибо за то, что они делают. И пожелать успеха и процветания их бизнесу.

PS. А еще... А еще мне дали подержать в руках Sigma S000M-18E (полностью из массива). Вещь, конечно. Внушаить. Даже такой дятел как я (в смысле полного отсутствия слуха и вообще способностей к музыке), смог оценить :)

понедельник, 23 апреля 2018 г.

[prog.thoughts] Более развернуто про свой доклад на C++ Russia 2018 и возможных дальнейших действиях...

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

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

А раз многие люди не знают про то, что такое асинхронное программирование вообще и как оно может быть реализовано, то вполне уместным мог бы быть доклад, вроде "Actors for fun and profit" с CoreHard Autumn 2017. Но не в чистом виде, а разбавленный большим количеством примеров кода.

Это навело меня на мысль, что имеет смысл подготовить доклад на тему "Actors vs CSP vs Tasks vs ...", в котором будет рассматриваться решение какой-то одной (или не одной) несложной задачки с помощью нескольких подходов. Мол, вот у нас есть акторных подход, который характеризуется тем-т и тем-то. Есть CSP-подход, который почти как акторный, но отличается тем-то и тем-то. Есть еще вот такой подход... И вот есть у нас такая задача. С помощью акторов мы ее решаем вот так, а с помощью CSP вот так, а с помощью task-ов вообще не решаем, ибо забабахаемся...

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

Теперь о том, о чем я рассказывал на C++ Russia 2018. С одной стороны, мне показалось, что примеров кода с какими-то пояснениями не хватило. Скажем, когда я говорил, что наличие хорошей поддержки ООП в C++ -- это достоинство, то можно было бы это на примере проиллюстрировать. Но, с другой стороны, при тестовых прогонах я едва укладывался в 40 минут даже с тем материалом, который был. Добавлять еще 1-2 слайда и 3-5 минут дополнительного рассказа было очень стремно. Так что этот недостаток я постараюсь исправить при подготовке текстовой версии доклада.

Однако, чем больше я думаю о том, как можно больше и лучше привлекать внимание к SObjectizer-у, тем больше прихожу вот к чему:

Есть определенный класс библиотек/фреймворков, надобность которых не вызывает больших вопросов. Например, работа с регулярными выражениями. Или работа с TCP-сокетами. Или работа с файловой системой.

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

Но есть и другие библиотеки/фреймворки. Использование которых вызывает определенные вопросы само по себе или же в сочетании с конкретным языком программирования.

Например, библиотека для поддержки software transaction memory для C. Или библиотека lock-free структур данных для Ruby или Perl-а. Или библиотека для реактивной обработки потоков данных для C++. Ну или вот, как в случае SObjectizer-а, библиотека акторов для C++.

Проблема здесь заключается в том, что a) люди далеко не всегда знают, о чем вообще идет речь, и b) не всегда очевидно, зачем это все для конкретного языка программирования. Вряд ли многие Ruby-программисты имеют представление о lock-free структурах данных вообще. И, даже если часть из них в должной степени просветить, то следом встанет вопрос -- а имеет ли смысл применять оные структуры в программах на Ruby? И даже если смысл в этом есть, то для какого процента Ruby-новых программ это будет иметь смысл?

Предположу, что похожая ситуация есть и в отношении STM и, скажем, plain old C.

Вот мне кажется, что с акторами и C++ что-то очень похожее. Хотя тут все-таки получше, чем с STM :) Но все равно не просто.

И, кстати говоря, для меня лично сложность с рассказом про модель акторов и ее применимость в том, что, с моей точки зрения, акторы -- это такой же инструмент, как и нити/потоки (они же threads). Поэтому объяснять, где и когда выгодно применять акторов, почти то же самое, как объяснять где и когда применять многопоточность. Ведь, в общем-то тривиальная вещь. Многие сами разбираются, где им нужен многопоточный код, а где однопоточный, даже не сильно об этом задумываясь. Тоже самое происходит и с акторами.

Похоже, что единственный выход тут -- это брать какую-то несложную задачу и разбирать ее на пальцах. Только вот какую именно? Мы не можем сослаться на то, что мы делали в прошлом. Это уже не наш код, нам никто не разрешал разглашать информацию о том, что мы делали. К сожалению. Поэтому нужно будет выдумать какую-то подходящую задачу самостоятельно. Либо же кто-то из читателей поделится своей задачей. Но направление движения становится понятнее.

[prog.c++] Мои личные впечатления от C++ Russia 2018

Сегодня таки доехал из Питера в родной Гомель. Хочу поделиться своими впечатлениями от C++ Russia 2018. При этом подчеркну, что это мои личные впечатления, это не классический trip-report, в котором перечисляются прослушанные доклады и дается их краткий обзор. Сорри, я буду говорить о своих переживаниях. Зато будет несколько фоточек ;)

20180420-124522-DSCF9600

среда, 18 апреля 2018 г.

[prog.c++] Наглядная разница при работе с многопоточностью "вручную" и с помощью CSP-шных каналов

Для очередной статьи на Хабре нужно было реализовать собственный диспетчер, заточенный под конкретную специфическую задачу. Первоначально я этот диспетчер начал делать "в лоб", с собственными очередями, mutex-ами, condition_variable и вот этим вот всем.

Однако, уже по ходу реализации в голову пришла простая мысль о том, что все тоже самое можно получить и используя CSP-шные каналы, благо в SO-5 они уже давно есть. В общем, было сделано две реализации. Одна на нитях/mutex/condition_variable. Вторая -- на SObjectizer-овских mchain-ах. То, какая в итоге вышла разница, можно увидеть под катом.

суббота, 14 апреля 2018 г.

[prog.c++] Послесловие к релизу SO-5.5.22 и so_5_extra-1.1.0

Мы сегодня официально выкатили очередной релиз SObjectizer-а. Это SObjectizer-5.5.22 и so_5_extra-1.1.0. Но в данном посте речь пойдет не о том, что вошло в этот релиз (и даже не о том, что не вошло). А о более важных вещах :)

Где-то до версии 5.5.19 у нас у самих был какой-то список хотелок, набор идей, которые хотелось воплотить в SObjectizer-е. А после релиза версии 5.5.19 этот список исчерпался. Плюс к тому, SObjectizer-5 стал гораздо сложнее и несколько объемнее с момента своего первого публичного релиза летом 2013-го. И даже сложнее и объемнее первого релиза ветки 5.5 в октябре 2014-го. Так что добавление какой-то новой фичи в нынешний SObjectizer -- это, зачастую, не такая простая задача, как еще пару лет назад.

В связи с этим последний год наблюдается следующая тенденция: в SObjectizer попадают лишь те фичи, которые кому-то потребовались. Вот столкнулся человек с тем, что в SO-5.5 ему чего-то не хватает, или что работает не так, как хотелось бы. Сказал нам об этом. Мы попробовали сделать. Если получилось, то фича попала в SObjectizer и состоялся очередной релиз.

А вот если никто ничего не сказал, ни о чем не попросил, то ничего и не сделали.

Так что можно с уверенностью сказать, что в настоящий момент SObjectizer дошел до такой стадии, в которой новая функциональность в него будет добавляться только если найдется конкретный человек, который скажет "мне нужно вот это". И если с этим человеком мы сможем обсудить то, что ему нужно и как это может выглядеть в итоге.

Если будут такие инициативы "снизу", то будут появляться новые версии SO-5.5. Если не будет, то обновления SO-5.5 будут выходить только тогда, когда нам самим в SO-5.5 что-нибудь новое понадобится. А с учетом того, сколько уже всякого разного в SObjectizer сделано, сложно прогнозировать когда же у нас самих появится нужна в чем-нибудь новеньком.

В общем, все просто: хотим что-то видеть в SO-5.5? Не стесняемся, говорим об этом :)

С SO-5.6, который не будет оглядываться на 100% совместимость с SO-5.5, пока больше вопросов, чем ответов. С одной стороны, есть соображения о том, что от чего в SO-5.6 имеет смысл отказаться. Так же, скорее всего, при разработке SO-5.6 мы будем отталкиваться уже от C++17, не оглядываясь на C++11 и C++14. Но, с другой стороны, нет понимания о том, откуда брать ресурсы на его разработку. Будем посмотреть, в общем. Никаких прогнозов на данный момент.

вторник, 10 апреля 2018 г.

[prog.flame] Недосказанное про Rust на C++ CoreHard Spring

По мере подготовки к участию в C++ CoreHard Spring 2018 более четко сформировал собственное текущее отношение к языку Rust. Пытался озвучить его на самой конференции в рамках панельной сессии, но там пришлось сильно спешить, поэтому толком это сделать не удалось. Попробую исправить положение в данном посте.

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

воскресенье, 8 апреля 2018 г.

C++ CoreHard Spring 2018: благодарности пост

Вернулся сегодня утром с C++ CoreHard Spring 2018. Впечатления просто "Вау!!!".

20180407-115740-DSCF9500

Это была, наверное, шестая конференция C++ CoreHard, на которой мы присутствовали и пятая, на которой был представлен доклад от нашей небольшой компании. Смело могу сказать, что это была самая крутая и представительная конференция, проведенная сообществом CoreHard. По уровню организации и представленных докладов, как мне показалось, ничуть не уступает прошлогодней C++Russia. Так что организаторы большие молодцы, огромное им спасибо за проделанную работу. И отдельная благодарность за предоставленную возможность поучаствовать в такой серьезной конференции.

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

Следом еще принял участие в "панельной дискуссии" Игоря Садченко "Rust vs C++". Но там случилось то, что называется "первый блин комом" :( Формат для конференции новый, еще не опробованный, поэтому получилось нечто среднее между обычным обзорным докладом и панельной дискуссией. Сам я не сразу разобрался когда можно сразу вставлять свои пять копеек, когда лучше жевать чем говорить помолчать. В общем, прошло не так гладко, как хотелось бы. Зато отдельное спасибо Игорю за то, что дал стимул проштудировать второе издание Rust book-а. Пока добрался только до 10-й главы. Но нужно собраться с силами и добить эту тему. Как язык Rust меня не торкает совершенно, но для каких-то вещей это может быть гораздо более практичный (удобный, безопасный и т.д.) инструмент, чем C++.

В общем, очень насыщенный и интересный день получился. Планку качества организаторы подняли на очень большую высоту. Если представится возможность поучаствовать в следующей C++ CoreHard, то нужно будет готовится основательнее и тщательнее, чтобы соответствовать.

пятница, 6 апреля 2018 г.

[prog.c++] Только что довелось самому воспользоваться msg_tracing-фильтрами при поиске проблемы

Делаю примеры для новой статьи про SObjectizer. В примерах имитируется работа с оборудованием и собирается небольшая статистика о задержках в обработке сообщений при разных политиках обработки этих сообщений. По сути, в примерах работает два агента. Первый, a_device_manager, имитирует работу с оборудованием. Второй, a_dashboard, раз в пять секунд выдает на экран текущие показатели.

И вот при первых запусках примеров обнаруживается, что в какой-то момент статистика перестает обновляться. Становится понятно, что это происходит потому, что не обрабатывается одно из сообщений, a_device_manager_t::reinit_device_t. Но почему не обрабатывается? Подписка на него есть:

четверг, 5 апреля 2018 г.

[prog.c++] RESTinio обновилась до версии 0.4.4

Мы сегодня выкатили очередное обновление для своей C++библиотеки для встраивания HTTP/WebSocket-сервера в C++ное приложение. С полным текстом анонса можно ознакомиться у нас на сайте: русская версия и английская версия.

Мы постарались упростить работу с запросами, которые содержат сжатые zlib-ом данные. Если вам кажется, что у нас получилось не очень и у вас есть идеи о том, как это сделать более просто и удобно -- дайте знать, плиз, постараемся творчески переосмыслить конструктивную критику и предложения.

Ну и вообще, если у вас есть какие-то пожелания к RESTinio, то мы всегда открыты и готовы выслушать любые соображения. Про поддержку пакетных менеджеров мы в курсе, как только, так сразу :)

среда, 4 апреля 2018 г.

[soft.business] Любопытная статья на Хабре про ИТ-шную составляющую клининговой компании

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

Чем статья зацепила меня? Речь в ней идет о компании, которая, как я понимаю, занимается "сводничеством" на тему уборки помещений. Вы на сайте компании заказываете уборку офиса/квартиры, компания подбирает исполнителей из числа тех кто подключился к их системе. Вот что они сами о себе говорят:

Мы начинали в 2014 году с квартиры-офиса на Арбате (с переговоркой в кухне), 300 клиентов и организацией всего “руками”. Вся информация фиксировалась в экселе, а разработкой и не пахло. Со временем количество клиентов увеличивалось, потребовалась автоматизация, и сегодня Qlean — это зрелая компания, в которой отдел разработки насчитывает более 25 человек. Сегодня через наш сервис делается в среднем около 1000 уборок в день силами 3000 подключенных к системе исполнителей.

За четыре года рост ИТ-сектора с нуля до 25 человек... Для компании, которая выполняет, грубо говоря, всего 1000 заказов в день... Какой-то перебор как по мне. Еще один звоночек:

Всего у нас около 30 различных сервисов, которые живут на более чем 70 виртуальных машинах...

30 сервисов и 70 виртуальных машин? И все это для того, чтобы обслуживать 30K клиентов и 3K исполнителей, при нагрузке в районе 100rps.

Ну и список языков+технологий доставляет: Ruby, nodejs+React, clojure, react native, python, go. Ну и куда же без docker, memcached, redis :)

И вот что у меня в голове не сходится. 25 разработчиков. Пусть затраты на каждого из них (ЗП со всеми налогами и отчислениями с ЗП) составляют 60K RUB в месяц. Это означает, что расходы компании только на свой ИТ-шный сектор будут составлять 1.5M RUB в месяц. Еще раз: полтора миллиона рублей только на зарплаты разработчикам (насколько правдоподобна ЗП разработчика в 60K со всеми налогами судите сами). Чтобы отбить только эти расходы компания должна получать по 50 RUB с каждой уборки (1000 уборок день при, грубо говоря, 30 днях в месяц).

Но ведь расходы на ЗП программистов не единственные. Есть же еще ЗП всего остального персонала компании. Есть арендная плата, есть коммунальные платежи, есть расходы на амортизацию оборудования, есть расходы на маркетинг. Есть налоги в конце-концов. Плюс должна же быть и какая-то прибыль.

И что-то мне подсказывает, что для того, чтобы держаться на плаву, компания должна зарабатывать с каждой уборки далеко не 50 RUB. И, возможно, даже не 200 RUB. Соответственно, если уборка однокомнатной квартиры стоит 1600 RUB, из которых, как минимум, 200 RUB забирает себе компания, то насколько выгодно с такой компанией сотрудничать клинерам-исполнителям?

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

Конечно, есть еще вариант, что под соусом клининговых услуг разрабатывается технологическая платформа, с помощью которой можно будет развернуть подобные же сервисы для других типов работ: выгул домашних животных, например, услуги сиделки, репетиторство и т.д. Тогда да, тогда компания может инвестировать большие средства в разработку платформы, чтобы затем быстро и дешево выкатывать новые сервисы под новыми брендами. Но и в этом случае 25 человек в разработке -- это как-то многовато, как по мне. Явно мы у себя в СтифСтриме чем-то не тем занимаемся... Нужно еще учиться и учиться, чтобы так умело разводить инвесторов на бабло :(

вторник, 3 апреля 2018 г.

[prog.flame] Таки Rust -- это язык, где каждая закорючка имеет огромное значение

В последние дни пытаюсь читать вторую редакцию Rust book-а. Но не потому, что сильно воспылал желанием попрограммировать на Rust-е, а потому, что предлагают принять участие в обсуждении Rust-а и C++ на грядущей C++ CoreHard Spring 2018. Вот и пытаюсь слегка погрузиться в тему.

По ходу чтения складывается ощущение, что второе издание писали с прицелом на дебилов веб-разработчиков, которые кроме Ruby и JavaScript-а ничего не видели. Плюс еще и очень сильно ощущается маркетинговая составляющая. Мол, Rust -- это чуть ли не лучшее, что появилось в области разработки софта, и с Rust-ом ваши волосы всегда будут... ;) Возможно, что я ошибаюсь, но года три назад, когда я впервые начал к Rust-у серьезно приглядываться, у меня не было такого ощущения.

Но в этот раз хочется заострить внимание на другом. Всегда, когда доводилось погружаться в Rust, ловил себя на том, что при чтении Rust-овского кода приходится заострять внимание буквально на каждом символе. И вот наткнулся на очередное подтверждение этого впечатления. Простая программка:

[prog] В склерозник: ссылки на тему очередного key-value-хранилища под названием Anna

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

PDF-ка от исследователей из Беркли, Йеля и Колумбийского университетов: Anna: A KVS For Any Scale. Рассказывает о проекте с непонятным статусом (прототип, экспериментальная разработка, ...), в котором реализуется высокопроизводительное и масштабируемое key-value-хранилище под названием Anna. Что особенно привлекательно для меня, так это то, что Anna реализована на C++, да еще и с использованием модели акторов (для реализации взаимодействия между акторами используется механизм pub-sub и ZeroMQ в качестве транспорта).

Еще очень интересная ссылка на обсуждение этой темы на Hacker News: тыц. Там в комментариях большое количество других ссылок, на разные key-value-хранилища и не только.


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

Ну и есть ли здесь вообще какой-нибудь коммерческий потенциал? Т.е. поставщики решений, вроде Redis-а, memcached или Cassandra, они что-нибудь на этом зарабатывают? Типа продают лицензии, платную техподдержку или что-то в этом духе. Или же здесь как с Linux-ом: несколько крупных компаний держат отдельных разработчиков, чтобы те совместно пилили большой OpenSource-проект в режиме full-time.

понедельник, 2 апреля 2018 г.

[life.cinema] Очередной кинообзор (2018/03)

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

Первому игроку приготовиться (Ready Player One, 2018). Сюжет полное Г. Но вот визуальная составляющая доставляет по полной программе. И вообще, это фильм для семейного просмотра, так что в этом качестве к нему претензий нет -- хороший, динамичный и красочный аттракцион.

Большая игра (Molly's Game, 2017). Наверное, не шедевр. Но мне понравилось.

Все деньги мира (All the Money in the World, 2017). Первый фильм Ридли Скотта за последние годы, который можно спокойно посмотреть.

Tomb Raider: Лара Крофт (Tomb Raider, 2018). Еще один красочный аттракцион для семейного просмотра. Как по мне, так самое достойное, наверное, из приключенческого кино в стиле "Индианы Джонса" за последнее время. Ну и, по-моему, гораздо лучше, чем фильмы по мотивам Tomb Raider с Джоли в главной роли.

Джуманджи: Зов джунглей (Jumanji: Welcome to the Jungle, 2017). Очень неплохая приключенческая комедия.

Аутсайдер (The Outsider, 2018). Посмотреть можно. Но как-то все очень неспешно в фильме происходит, к этому нужно быть готовым.

10 на 10 (10x10, 2018). Могло бы быть хорошо, если бы не несколько моментов, в которые приходится вопрошать "Ну что за...? Ну как же так...?"

Аннигиляция (Annihilation, 2018). Очень занудная нудятина-бредятина с предсказуемой концовкой.

Форма воды (The Shape of Water, 2017). Тот самый случай, когда и во время, и после просмотра хочется воскликнуть: "Коллега, что за фигню нам здесь показывают?!!!"

Титан (The Titan, 2018). Обычная история для фильмов Netflix: замах на рубль, удар на копейку. Но в данном случае все настолько скучно, занудно и убого, что можно смело не смотреть.

пятница, 30 марта 2018 г.

[prog.thoughts] Тяпничное про оглядки на старые версии C++ компиляторов

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

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

Возможно, на заре моей программерской деятельности это было не совсем так, поскольку тогда и C++ весьма активно развивался, и сами платформы активно развивались и вытесняли друг друга (например, многие ли помнят, как 16-битовый Windows пытался бороться с 16-битовым MS-DOS, а всех их уделывала 32-х битовая OS/2, которая затем не смогла устоять перед Windows-95 и Windows-NT?). Ну и плюс к тому, мы сами тогда работали над новыми, перспективными проектами и не сильно были знакомы с понятием legacy (под "мы" здесь понимаются те небольшие коллективы, в которых мне довелось поработать в 1990-х).

Но вот года с 1998 или 1999-го оглядываться на то, что у тебя самого или у кого-то из твоих клиентов может быть далеко не самый новый C++ компилятор, и что у этого компилятора могут быть какие-то заскоки по части поддержки той или иной части C++... Вот на это оглядываться уже приходилось. Отлично помню момент, как на рубеже 2000-го года под каким-то из Linux-ов довелось поработать с gcc версии, кажется, 2.95, который не умел нормально ловить исключения при использовании наследования. Т.е. если у тебя есть базовый тип Exception, и есть наследник FileNotFoundException, ты бросаешь FileNotFoundException, а ловишь его по ссылке на Exception, то исключение просто не ловилось. Пришлось тогда в каком-то проектике отказываться от иерархии исключений.

Да, так вот с конца 90-х и до сего времени приходится задумываться о том, что кто-то может еще сидеть на каком-то специфическом Linux-е с проплаченной на 10-ть лет коммерческой поддержкой. А там, дай Бог, если gcc-4.8, а то может быть и какой-нибудь gcc-4.4. И, что самое печальное, я сам до недавнего времени считал, что такие оглядки -- это вполне себе нормально и забота о потенциальных пользователях, которые не могут переходить на новые версии компиляторов -- это разумно и оправдано.

Но в последние дни мое отношение к этой ситуации начало меняться. Не то, чтобы это произошло внезапно. В общем-то с SObjectizer-ом мы ограничились поддержкой на уровне gcc-4.8 и msvc-12.0. Была попытка опуститься до gcc-4.7, но там уж совсем все было грустно, поэтому плюнули. Ну и для RESTinio мы сразу решили ограничиться только C++14 на уровне где-то gcc-5.4 и msvc-14.0. Там, однако, был расчет на то, что пока мы будем доводить RESTinio до версии 1.0, пройдет ну очень много времени. И минимум на уровне C++14 к тому времени будет казаться вполне себе нормальным. Пока что этот расчет оправдывается, т.к. прошел уже год с момента начала работ над RESTinio и скоро будет год с первого публичного релиза, а мы еще только на уровне версии 0.4 и впереди еще прорва работы.

Сейчас же я прихожу к мысли, что C++ с 2011-го года вышел на совсем другой темп развития. Мало того, что бумажные стандарты выходят каждые три года, так еще и основные компиляторы в последние годы очень быстро подтягиваются с поддержкой самых свежих стандартов. Это делает ситуацию совершенно не похожей на то, что было до C++11. В 2008-ом году, например, было вполне нормально оглядываться на то, что умеет поддерживать, скажем, VC++6.0. Потому, что в 2008-ом был только C++98 и VC++6.0 в изрядной степени C++98 поддерживал. Но в 2018-ом году оглядываться на то, что поддерживает VC++12.0, наверное, уже не разумно. Жизнь слишком коротка для того, чтобы ждать, пока плюшки и вкусности из C++17 станут тебе доступны потому, что уже прошло 10-15 лет после принятия 17-го стандарта и практически никто уже не использует VC++12.0 (хотя я уверен, что в 2028-ом еще найдется какой-нибудь ынтерпрайз, который будет завязан на 12-ю версию VC++). Плюс к тому, конкурирующие технологии развиваются еще быстрее. И в таких условиях сложно находить для себя убедительные объяснения того, почему я не могу использовать std::optional из C++17, если его аналоги уже много лет как есть в стандартных библиотеках каких-нибудь Scala или Rust.

Еще один веский довод -- это постоянно возрастающий объем и сложность наших OpenSource проектов. Тот же SObjectizer за прошедший 2017-й год увеличился в объеме и сложности более чем прилично (если считать вместе с so_5_extra). Что уж говорить про RESTinio. Соответственно, добавление новой функциональности в OpenSource-проекты требует все больше и больше усилий. И не так-то просто оправдать те усилия, которые тратятся на поддержку старых компиляторов. Особенно с учетом того, что OpenSource-проекты распространяются бесплатно.

В связи с этим я думаю, что в современных условиях, особенно с поправкой на то, как развивается C++ и какие изменения нас ждут в C++20, мне кажется вполне разумным для своих проектов ограничится поддержкой всего двух стандартов C++: самого последнего и предпоследнего. Т.е. на данный момент это C++17 и C++14. Соответственно, когда появится C++20, поддержка C++14 закончится. А для новых проектов, которые еще только-только стартуют и достигнут стабильности лишь в отдаленной перспективе, можно ограничится вообще только последним стандартом.

К чему это может привести на практике?

SObjectizer-5.5 будет требовать не более чем gcc-4.8 до апреля следующего года. Мы пару лет назад пообещали, что SObjectizer-5.5 будет привязан к gcc из Ubuntu 14.04 LTS. И от этого обещания мы не отказываемся. С поддержкой VC++12.0 сложнее. Скорее всего, мы на нее забьем после выхода очередной VisualStudio. Т.е. как только появится VisualStudio-2018, так мы сразу же перестанем оглядываться на VC++12.0.

Другой вопрос -- это насколько активно будет дальше развиваться SO-5.5? Сейчас мы работаем над версией 5.5.22. Затем, возможно, будет еще и 5.5.23. И, может быть, после этого ветка 5.5 перейдет в режим поддержки. А развиваться будет новая, нестабильная ветка 5.6, в которой мы будем закладываться уже на C++17. Но тут мы посмотрим еще на то, что за gcc будет в Ubuntu 18.04 LTS и на то, когда у нас появятся ресурсы для начала работ над 5.6.

RESTinio, по крайней мере, в этом году, будет требовать C++14. В следующем году посмотрим, выгодно ли нам держаться за C++14 или же проще и дешевле ограничится только C++17.

Вот как-то так. Имхо, времена изменились. И сейчас местами даже C++14 уже может быть слишком старым, чтобы ориентироваться на него. Что уж говорить про C++11 и, тем более, C++98/03.

среда, 28 марта 2018 г.

[prog.c++] Статья на Хабре про нововведение в грядущей версии SObjectizer-а.

Собственно, вот: Когда акторный фреймворк превращается в «черный ящик» и что мы можем с этим сделать?. Те, кто не может/любит комментировать на Хабре, могут оставить свое "Фи" в комментариях к этой заметке.

Первая альфа новой версии SObjectizer-5.5.22 уже зафиксирована (архив доступен на SourceForge, так же обновлено зеркало на github-е (но там тег не фиксировался)). Так что желающие могут брать и пробовать.

Если будут конкретные предложения о том, как msg_tracing сделать лучше, то мы будем над ними работать до тех пор, пока не достигнем хорошего результата. Если же серьезного фидбэка не будет, то, скорее всего, зафиксируем и выкатим 5.5.22 на следующей неделе. Вместе с обновленным so_5_extra.

вторник, 27 марта 2018 г.

[life.books] Промежуточные впечатления от книги Петра Авена "Время Березовского"

Читаю сейчас книгу, которую написал бизнесмен Петр Авен. Книга называется "Время Березовского". Книга весьма объемная. С трудом добрался до середины.

Основное ощущение как будто копаешься в здоровенной куче известной субстанции, в которой круто замешаны самолюбование, прохиндейство, обман и, как мне кажется, очевидный непрофессионализм. Собственно, сама книга может служить примером того, что получается, когда человек берется за не свое дело. Она ведь представляет из себя всего лишь сборник интервью с различными личностями, близко или не очень знавших Березовского в 1980-х, 1990-х и 2000-х годах. Получается, что если ты покупаешь книгу чтобы составить себе впечатление о том, что же это был за человек, какое реальное влияние он оказывал, что он на самом деле сделал, где граница между мифами и правдой, то тебе самому нужно продраться через сотни страниц дружеских бесед в духе "мы были моложе, бабы давали чаще". При этом, естественно, на ум постоянно приходит афоризм "Врет как очевидец".

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

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

вторник, 20 марта 2018 г.

[prog.c++] Как лучше добавить детализацию активности агентов в SObjectizer?

В SObjectizer уже довольно давно существует такая штука, как work thread activity tracking. Но этот механизм дает только самую общую информацию о том, сколько событий было обработано на конкретном диспетчере (точнее, на конкретной нити диспетчера), сколько времени это заняло, сколько раз приходилось ждать поступления событий и сколько времени это ожидание заняло. Механизм самый базовый. Но уже, при необходимости, помогающий посмотреть на то, куда и как тратится время в программе.

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

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

суббота, 17 марта 2018 г.

[life.thoughts] Странные ощущения от чтения серьезных книг в последнее время

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

Любопытный эффект. Буквально ощущается, как накопленный опыт и текущий груз забот препятствует изучению нового.

[books.business] Впечатления от книги "Единственная книга по брендингу, которая вам нужна, чтобы начать, раскрутить и сделать бизнес прибыльным"

Уже не помню, когда и зачем купил книгу с названием "Единственная книга по брендингу, которая вам нужна, чтобы начать, раскрутить и сделать бизнес прибыльным" за авторством Мишеля Маандага и Лиисы Пуолакка, но добрался до нее только сейчас. И, скажу прямо, мало какая книга о бизнесе выбешивала меня так сильно, как эта.

Дело в том, что книгу написали два непонятных человека, один из которых консультант с якобы большим опытом в области глобального маркетинга, а вторая -- бывший дизайнер моды, которая в течении пяти лет возглавляла отдел, "отвечающий за глобальную идентичность бренда" в Nokia (и где та Nokia сейчас?). А сама книга представляет из себя альбом детских рисунков, с небольшими вкраплениями текста. Причем местами, видимо там, где авторы говорят о сфере своей профессиональной деятельности (например, в описании требований к логотипам), там все по делу. А вот там, где они пытаются говорить о рыночном позиционировании, продвижении новых товарных линеек под флагом старых брендов или даже про диверсификацию бизнеса... Вот там уже к авторам возникают вопросы. И ладно бы авторы вели повествование с оговорками "по нашему мнению" или "мы считаем разумным". Так нет, рекомендации из книги сомнению не подлежат. Яркий пример:

Когда вашей маркетинговой команде или агентству надоест повторять одно и то же, сошлитесь на эту книгу, чтобы объяснить важность повторения. Или увольте их.

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

Вот так же и в этой книге. Пара маркеров, которые обратили на себя внимание и запомнились.

Про компанию Philips. Сперва авторы много перемывали косточки Philips на тему того, что компания продвигает разные продукты под общим брендом, а не создает отдельные бренды для бытовой электроники и, скажем, медицинского оборудования. Тут уже у авторов хочется спросить: "а какие у вас есть основания полагать, что Philips действует неправильно?" Может они какие-то финансовые отчеты изучали? Проводили маркетинговые исследования? Изучали динамику продаж определенной категории товаров под разными брендами? Это все риторические вопросы, понятное дело, что авторы книги ничего подобного не делали.

Но вот что откровенно выбесило, так это обсуждение слогана компаний. К слогану Philips-а, который звучит "Let's make things better" (или "Изменим жизнь к лучшему" в русском варианте), предъявили такую претензию: "Разве существующие продукты Philips недостаточно хороши?"

Я сперва вообще не понял, о чем речь идет. Ибо сам всегда воспринимал слоган Philips-а как "Изменим жизнь к лучшему с помощью продуктов Philips". Т.е. Philips говорит мне "у меня такие классные товары, которые сделают твою жизнь лучше". И, мне думается, слоган Philips-а был ориентирован именно на людей, которые воспринимают этот слоган так же, как я. Альтернативно одаренные и профессионально деформированные личности, вроде авторов обсуждаемой книги, воспринимают реальность по-своему.

Второй же момент, еще более показательный, касался совета компаниям Canon и Nikon. В частности:

Аналогичным образом, когда произойдет окончательный переход от ставших уже привычными цифровых фотоаппаратов к смарт-камерам — например на операционной платформе Android, — это существенно затронет бизнес производителей традиционных цифровых камер — Canon и Nikon.

Обе марки тесно связаны с существующей товарной категорией, поэтому они, скорее всего, попытаются растянуть свои бренды. Canon и Nikon следовало бы создавать новые бренды смарт-камер, пока у них еще есть такая возможность.

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

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

среда, 14 марта 2018 г.

[books.business] Отличная книга "Дилемма инноватора: Как из-за новых технологий погибают сильные компании"

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

Итак, в чем суть? Суть в том, что автор на ряде примеров из истории нескольких отраслей промышленности показывает следующую закономерность: успешные компании, которые являются лидерами текущего рынка, раз за разом пропускают появление "подрывных" технологий. Эти "подрывные" технологии сперва являются не конкурентноспособными на уже сложившемся рынке. Но вокруг этих технологий сперва появляются новые рынки, успех на которых приводит к бурному росту и совершенствованию "подрывных" технологий. После чего технологии становятся зрелыми, успешными, что позволяет им затем быстро и полностью захватить старые рынки, на которых доминировали предыдущие технологии и предыдущие компании-лидеры. Как результат, только единицы из старых компаний-лидеров выживают, остальные перестают существовать.

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

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

В общем, книга из категории must read. По крайней мере для тех, кто хоть как-то интересуется продуктовой разработкой, а так же управлением продуктовым бизнесом. Еще лучше, если до прочтения "Дилеммы инноватора" будет изучена хрестоматия Генри Минцберга "Структура в кулаке". Тогда будут лучше понятны рассуждения о том, почему корпоративная культура успешных компаний-лидеров препятствует освоению новых технологий. И почему маленькие дочерние предприятия могут сильно помочь своим родительским компаниям. (Компании-лидеры -- это механистические бюрократии, они ориентированы на оптимизацию расходов и снижение издержек при эксплуатации уже выверенной и работающей бизнес-модели. Тогда как маленькие дочерние компании -- это адхократии, которые быстро находят новые бизнес-модели.)

Пожалуй, у книги есть всего два небольших недостатка. Первый -- это ее объем. Как по мне, можно было бы сократить раза в три, слишком уж много повторений одного и того же, но под чуть-чуть разными углами. Впрочем, это характерно для большинства западных книг, в которых одна и так же мысль повторяется снова и снова. Уж не знаю, для повышения гонорара автора книги или для того, чтобы до определенной категории читателей все-таки материал дошел. Второй недостаток -- это то, что книга базируется на достаточно старых примерах середины и конца XX-века. Она бы сильно выиграла, если бы в новые издания вошли более современные примеры. Например, крах Kodak-а после появления и развития цифровой фотографии. Но это уже чистой воды придирки.

PS. Если найду время, постараюсь написать, как можно ценить появление новых языков программирования и их влияние на индустрию с точки зрения идей из "Дилеммы инноватора". Как по мне, Java и Go полностью вписываются в теорию "подрывных" технологий. Хотя в софтостроении есть своя специфика, которую нельзя не учитывать.

вторник, 13 марта 2018 г.

[prog.c++] doctest vs Catch2: влияние на скорость компиляции

Для so_5_extra мы использовали Catch/Catch2 в качестве фреймворка для unit-тестирования. Catch2, конечно же, отличная штука. Но вот время компиляции самих unit-тестов -- это ахилесова пята. Особенно в таком проекте, как so_5_extra, который сам весь на шаблонах, да еще и часть компонентов оттуда базируются на Asio, которая вся из шаблонов.

В общем, с ростом количества тестов для so_5_extra, увеличение времени компиляции меня задолбало настолько, что в версии 1.1 попробовал использовать конкурирующий инструмент, doctest. Гораздо менее раскрученный и известный. Но зато более шустрый.

Вот результаты сегодняшних замеров. Полная сборка so_5_extra-1.1 под Windows с VC++15.6 на реальном железе:

  • Catch2: 37m 55s;
  • doctest: 26m 30s.

Но еще круче разница выглядит под виртуалкой, которую я кручу на этой же Windows-машине. ArchLinux с GCC 7.3:

  • Catch2: 1h 21m 17s;
  • doctest: 36m 25s.

В общем, явно с Catch2 в проекте so_5_extra мы попрощаемся. Может быть Catch2 обладает большей функциональностью, но нам и doctest-а более чем хватает. А времени doctest экономит сильно больше.

PS. В so_5_extra-1.1 будет сделан переход на asio-1.12.0. Плюс, наверное, будет добавлен еще один диспетчер (autoscaling_thread_pool, автоматически увеличивает и уменьшает количество нитей в пуле в зависимости от загрузки). Если кто-то хочет видеть что-то еще, то дайте знать.

понедельник, 12 марта 2018 г.

[prog] А кому-нибудь приходится иметь дело с HTTP/2?

Вот такой вот внезапный вопрос к читателям блога. Может HTTP/2 уже вовсю работает в каждом утюге, а я просто этого не замечаю?

В частности интересует такой аспект: применяется ли HTTP/2 для реализации взаимодействия микросервисов?

Или же пока еще повсеместно HTTP 1.0/1.1 применяются и до широкого распространения HTTP/2 пока еще далеко?

суббота, 10 марта 2018 г.

[books] Прочел книгу про Pixar под претенциозным названием...

..."PIXAR. Перезагрузка. Гениальная книга по антикризисному управлению" за авторством Лоуренса Леви.

Сразу скажу, что ничего гениального в ней нет. Ну вот вообще. Как и нет чего-то именно про антикризисный менеджмент. Так что пусть название не вводит вас в заблуждение.

Книгу написал бывший финансовый директор Pixar-а, который был приглашен Стивом Джобсом в Pixar в конце 1994-го года. И который проработал финансовым директором до 1999-го, после чего от оперативного управления финансами Pixar Лоуренс Леви ушел, но зато вошел в совет директоров компании. За это время Леви успел поучаствовать в очень знаковых событиях в жизни Pixar-а: выводе компании на IPO, пересмотре контракта с Disney после успеха первой части "Истории игрушек", продаже Pixar-а Disney-ю. Поэтому речь в книге идет о том, что связано с этими событиями. Собственно про управление и, тем более, про антикризисное управление лично я в книге ничего не нашел :)

Тем не менее, книга не самая плохая. Читается легко. Некоторые воспоминания и внутренние переживания автора, местами, мне казались неинтересными и я бы их из текста убрал. Но общей картины они не портят.

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

Во-первых, я почему-то после прочтения биографий Стива Джобса считал, что Джобс был основателем и главным двигателем Pixar-а. Оказалось, что это сильно не так. Pixar была подразделением компании Джорджа Лукаса, которое затем было выделено в отдельную структуру и продано Джобсу. Первоначально Pixar развивалась как компания по производству специфического компьютерного железа и софта для компьютерной графики. Компьютерная анимация была лишь побочным продуктом. Но из-за того, что железо так никому продать и не удалось, компания, в итоге, сконцентировалась именно на анимации. В общем, для меня стало открытием, что Pixar не было детищем Джобса, вроде Apple или NeXT-а. Более того, даже в 1995-м, когда компания напряженно готовила к выходу "Историю игрушек" и, одновременно, готовилась к IPO, отношение к Джобсу внутри компании было настороженным и даже негативным. Сам Джобс регулярно стал появляться в Pixar только в 1995-ом, до этого его там месяцами не видели.

Во-вторых, оказалось, что Pixar за все время своего существования до IPO 1995-го не была прибыльной (вроде как даже в составе Lucasfilm и Industrial Light & Magic это подразделение не было прибыльным). И в течении всего этого времени она жила за счет инвестиций. Сперва Джорджа Лукаса, затем Стива Джобса. Джобс вложил в компанию порядка $50 миллионов собственных средств. Получается, что 16 лет (ну пусть даже 9 лет с момента покупки Pixar-а Джобсом) убыточности перед тем, как стать мегауспешной компанией... Это внушать. Н - Настойчивость.

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

Ну и еще один момент был в книге, который сильно удивил. Когда Леви пришел в Pixar, он взял пару месяцев на то, чтобы познакомиться с компанией. Просто ходил, смотрел, изучал. Становился "тенью" того или иного сотрудника: т.е. ходил за сотрудником, слушал, что сотрудник говорит, смотрел, что делает. В общем, финансовый директор в течении двух месяцев совершал глубокое погружение в новую компанию, для того, чтобы детально разобраться с тем, с чем ему нужно иметь дело. И только после этого он начал предпринимать какие-то самостоятельные действия.

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

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

вторник, 6 марта 2018 г.

[prog.c++] RESTinio 0.4.3

У нас очередная приятная новость: релиз очередной версии RESTinio, на этот раз 0.4.3. Главное нововведение -- поддержка операции sendfile. Выполняется средствами системного вызова sendfile() на Linux/FreeBSD/macOS или TransmitFile на Windows. Плюс незадолго до этого у нас был еще один маленький релиз версии 0.4.2, в которой добавились новые перегрузки для restinio::run().

В общем, наша маленькая библиотека для встраивания HTTP/Websocket сервера в C++ приложения стала еще более функциональной.

Мы же собираемся приступать к разработке следующей версии. Свой список хотелок у нас есть. Но было бы интересно услышать и мнение потенциальных или актуальных пользователей: чего именно вам не хватает в RESTinio и/или что мешает вам начать использовать RESTinio?

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

понедельник, 5 марта 2018 г.

[prog.c++] Async processing of incoming and outgoing HTTP-requests with RESTinio and libcurl

We started development of RESTinio because sometimes we had to implement REST-like interfaces for legacy systems with one common feature: long response times. We can make a request to a distant system and response can arrive after a dozen of seconds, sometimes after a several dozen of seconds. It is not appropriate to block a work thread that handles incoming HTTP-request for such a long time. That’s why we needed an embeddable C++ HTTP-server which supports async request processing. After experimenting with some existing solutions we decided to build our own solution with very simple goals: it should be user-friendly and very easy to use, but should provide reasonably good performance and be cross-platform. So RESTinio was born.

Time shows that a situation when someone needs to deal with long-responding distant hosts is not unique. Recently we received an interesting question about integration of async processing of incoming HTTP-requests via RESTinio with async processing of outgoing HTTP-requests via libcurl.

Answering this question we prepared a demo that includes some simple C++ applications showing how async processing of incoming and outgoing HTTP-request can be done. Source code for the demo can be found here. This post briefly describes the major aspects of using RESTinio and curl_multi interface from libcurl.