[life.cinema] Неожиданное следствие "очередных кинообзоров"

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

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

У этой артели в последние годы есть серьезная проблема: утечка мозгов. Т.к. порядка 20% придуманных в Минске пилотов получают свое развитие в Москве, то зачастую вместе с рабочими материалами из Минска в Москву перебирается и кто-то из ключевых людей из команды, работавшей над пилотом. Кстати, говорят, что 20% -- это очень высокий процент, в аналогичных компаниях в России обычно едва достигается 10%.

А тут еще, как оказалось, одна крупная госкорпорация в РФ, связанная с телекомунникациями (название начинается на Рос-, а заканчивается на -телеком) уже довольно давно готовит запуск своей стримминговой платформы. Задумывалось как российский ответ Netflix-у. Но с анонсом из-за обычного разгильдяйства и присущей госкорпорациям бюрократии затянули, Apple о своем Apple TV+ объявила раньше. Так что руководителям соответствующего направления в этой госкорпорации "хвосты накрутили" и обещали влить дополнительных бюджетных средств для ускорения запуска свой собственной стримминговой платформы.

Все это привело к тому, что рынок телефильмов и телесериалов в РФ резко расширяется и этот рынок нужно чем-то заполнять, а текущих мощностей для этого в РФ (совместно с РБ и Украиной) не хватает. Поэтому компании, которые крутятся на этом рынке начинают всасывать с рынка труда всех, кого могут. В РБ этого рынка труда вообще-то практически и нет, так что даже дилетанты вроде меня оказываются востребованы.

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

Поворот в карьере, можно с полной уверенностью сказать, совершенно неожиданный. Но вполне себе логичный. Программировать за 30 лет уже надоело, а количество малолетных дебилов (с) за последние 10-15 лет в этом нашем ОйТи превысило все разумные пределы. Так что оставлю это самое программирование для тех, кому язык Go кажется вершиной прогресса.

Пока не понятно, как быть с завершением текущих работ по нашим OpenSource-проектам. Времени на "закрытие хвостов" совсем не много, не больше недели. Так что, наверное, на днях будет выпущена бета-версия SObjectizer-5.6. Не все удалось сделать, но, по крайней мере, код компилируется и 2/3 тестов стабильно отрабатывают. Жаль, что актуальной документации не будет. Но, с другой стороны, вполне себе обычная картинка для OpenSource. Месяца через два-три, после того, как втянусь в новую работу, должно появится немного свободного времени по выходным, чтобы заставить оставшуюся 1/3 тестов работать.

Ну вот как-то так. Много лет писал "меня фильм не торкнул" по отношению к чужим фильмам. А вскоре это же самое начнуть говорить и в мой...

[prog.c++] Как работать с STL-ными контейнерами без include-ов описаний этих контейнеров

Давеча мы обновили свою тоненькую обертку над RapidJSON. Очередным добавлением в json_dto стала поддержка STL-ных контейнеров (std::deque, std::list, std::forward_list, std::set, std::multiset, std::unordered_set, std::unordered_multiset, std::map, std::multimap, std::unordered_map, std::unordered_multimap). И добавляя эту поддержку нам нужно было решить, как это сделать с минимальными накладными расходами.

Идти по простому пути, т.е. делать в json_dto какой-нибудь #include <set>, а потом перегружать часть внутренних функций json_dto для std::set и std::multiset, очень не хотелось. Во-первых, это сильно увеличивает объем нашей собственной работы. Во-вторых, это увеличивает время компиляции проектов, в которых json_dto используется.

Поэтому мы пошли по пути современного C++: т.е. шаблонная магия и SFINAE во все поля :) Под катом несколько слов об этом для тех, кому тема современного C++ интересна.

[prog.bugs] Интересная ошибка, связанная с многопоточностью

В минувший вторник убил целый рабочий день на разбирательство с любопытным багом. В многопоточном коде, в котором пришлось иметь дело с голыми std::mutex-ами и std::thread. Кому интересно, милости прошу под кат. Ошибка, в общем-то, имеет C++ную специфику, но, полагаю, во что-то подобное можно втоптаться и в любом другом языке с ручным управлением ресурсами.

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

[prog] Тестов много не бывает...

В SObjectizer-е чуть менее 400 тестов. И когда вносишь ломающие совместимость изменения, то приходится изрядно попотеть, перелопачивая простыни старого кода, чтобы заменить устаревшие API-шные вызовы на новые.

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

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

Ну и да, традиционное: если у вас есть возможность не писать многопоточный код, то не пишите. А если вам все-таки нужно оный написать, то не опускайтесь на уровень голой многопоточности. Используйте лучше высокоуровневый инструментарий. Ну там акторов, CSP, task-flow, data-flow, STM и пр. Багов вы и там насажаете в свой код, можете даже не сомневаться. Но до такого траха, как с голой многопоточностью доходить будете гораздо, гораздо реже.

[prog.c++] C++Modules: there is no place for simplicity and beauty in C++?

C++Modules has been accepted in C++20. Nobody has a real experience with those modules and only few understand what C++Modules are. I don't understand that too. Moreover I don't read accepted Modules proposal yet. But I read a wonderful post "Understanding C++ Modules: Part 1: Hello Modules, and Module Units" and want to share some impressions.

It seems that simplicity and understandability weren't friends of C++ anytime in the past. But C++Modules lifts this up on another level.

It obvious that work on C++ standards is performed by very smart people. But sometimes you have to be as smart as they if not smarter to understand some of the new C++ additions and to find some beauty in them. C++Modules is an example.

Unfortunately I'm not as smart to participate in the evolution of C++ language. I'm just a (very ordinary) user of C++ and use C++ as a tool for solving my and my client's problems. Because of that, I can understand that there were some reasons to accept C++Modules in that form. But it's very hard to find and understand those reasons.

I can't understand why there are different types of module units (module interface, module implementation, module interface partition, module implementation partition, primary module interface) and very strange looking sentences like "export import :something;". Why not just:

module greeting; export {    public import another_module; // Instead of export import another_module.    ... // Some ordinary C++ code. } // interface. implementation {    ... // Some ordinary C++ code. } // implementation.

If we have to deal with very big amount of code for a module we can simply use old #include directive:

module greeting; export {    public import another_module; // Instead of export import another_module.    #include "some_declarations.hpp"    #include "some_more_declations.hpp" } // interface. implementation {    #include "some_implementations.cpp"    #include "some_more_implementations.cpp"    #include "yet_more_implementations.cpp" } // implementation.

It's also hard to understand why modules and namespaces are orthogonal. Namespaces played their role in the pre-Modules world where we had only headers files and namespaces were used for "modularization" of C++ code.

But it's hard to imagine why we can write something like that:

import hello; int main() {    bye::tell(); }

From experience with different languages I expect that "import hello" introduces stuff from "hello" namespace. But in C++ we can "import hello" but receive "bye" namespace. Maybe there is some logic, but it seems also that "least surprise principle" doesn't live here.

I can suppose that there are some very important reasons why C++Modules and C++ namespaces are different entities. And I want to read the justification for this decision because as for me modules should make namespaces obsolete. With modules, we can get namespaces and nested namespaces (top-level modules and submodules).

Namespaces in C++ are open. It had two benefits in the past:

1. The content of namespace could be stored in several headers and source files. We opened namespace in one header file then reopened it in another file and so on.

But this benefit doesn't have sense with modules. IMHO.

2. An user can add specialization for its own types into external namespace.

But we can keep this benefit with modules if we add something like module's specialization (based on example from our json_dto library):

module json_dto specialization; export {    import my_module;    template<>    read_json_value( my_module::some_type & v, const rapidjson::Value & object )    {       ... // Specific version for some_type from my_module.    } }

---

Instead of conclusion.

I don't want to say that C++Modules proposal is bad. But it seems that C++Modules look much more complex than many of us expected. It also seems that C++Modules are intended to solve different problems than many of us can suppose.

It would be great to have some explanation about what C++Modules actually are, which problems they address, why C++Modules do it that way.

Without such explanation C++Modules remind me things like "export template" and "throw specification" from C++98 and "concept maps" from C++0x. They looked good in theory, but were deprecated or/and eliminated later.

[life.books] "Мастер своего дела": начал читать, дошел до первого примера, закончил читать

По случаю прикупил книгу "Мастер своего дела" Мортена Хансена. Хансен мне известен тем, что был соавтором у "гуру" Джима Коллинза при работе над "Великие по собственному выбору". В аннотации к "Мастеру своего дела" было сказано, что автор провел многолетнее исследование и выявил ряд привычек, которые присущи людям, демонстрирующим высокую личную производительность.

Начал читать. В начале слишком много вступительных слов о том, как автор пришел к идее этого исследования, как он решился на исследование, как исследование проводилось и о чем же пойдет рассказ дальше. Что уже несколько насторожило. Но потом я все-таки дошел до первой имеющей отношение к делу главы. Это глава под названием "Делай меньше, да лучше". Где автор в качестве самого яркого демонстрационного примера решил использовать удачный поход к Южному полюсу Руаля Амундсена и неудачный поход туда же Роберта Скотта. И вот тут у меня стали закрадываться подозрения: либо автор не очень понимает суть приводимого им примера, либо, что хуже, старается переинтерпретировать факты в свою пользу.

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

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

Оверлорд (Overlord, 2018). Фильм вторичный и трэшовый, но я получил удовольствие от просмотра. Какой-то привет из видеосалонов 1980-х, где можно было попасть на пусть и тупой, но бодрый боевичок в котором несколько главных героев мужественно сражаются с невесть откуда взявшимися монстрами.

На краю (Cut Bank, 2014). Далеко не шедевр. Но мне понравился. Добротный фильм. Хотя какие-то вещи в итоге остались непонятными, что портит общее впечатление.

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

Виновный (Den skyldige, 2017). На удивление неплохо. Прекрасный образец того, как можно построить напряженный сюжет только на одном персонаже и диалогах. Хотя некоторые моменты вызывают вопросы и портят впечатление, но сам факт того, что это датская картина, очень сильно и приятно удивляет.

Алита: Боевой ангел (Alita: Battle Angel, 2019). Понравилось исполнение, картинка радует глаз. Понравилось то, что это один из немногих фильмов за последние годы, который хоть как-то претендует на жанр научной фантастики. Сюжет не понравился. Да и само по себе это кино для детей.

Зеленая книга (Green Book, 2019). Мне не зашел. Довольно примитивно, сильно предсказуемо, никакой интриги. Такое ощущение, что целью фильма было скрыть ужас отношения к неграм в США даже спустя 100 лет после отмены рабства обаятельным главным героем. Мол, да, к неграм относились как к скоту, но ведь не все же, были среди белых и нормальные люди.

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

Правила бойни (Slaughterhouse Rulez, 2018). Редкая муть. Даже непонятно, как туда попали Саймон Пегг, Марго Робби и Ник Фрост.