[work;business;life] Очередной ДР у StiffStream-а

Официально "СтифСтрим" начал свое существование 10-го октября 2016-го года. Так что сегодня у нашей маленькой компании очередной день рождения, нам уже шесть.

Конечно, когда все это начиналось в 2016-том, то будущее спустя 5-6 лет виделось совсем другим, более ярким и красочным :)

Но, с учетом того, что более 90% компаний не доживают и до трех лет, результат еще не самый плохой.

Хотя тут как посмотреть, т.к. начинали мы совсем маленькой компанией -- три человека в штате и один совместитель, а за прошедшие шесть лет стали совсем крохотной: один штатный сотрудник + один совместитель. Благо ушедшие ребята, с которыми мы это все организовывали, помогают по мере сил, за что им отдельное спасибо.

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

• то, что называется wishful thinking. Не сказал бы, что мы безоглядно выдавали желаемое за действительное (но и не возьмусь утверждать обратного), скорее была в нас слишком сильная вера в то, что мы "прогнем этот изменчивый мир" своими способностями и своим упорством. Типа "терпение и труд все перетрут" + "у нас крутые продукты" и вот это вот все;
• то, что мы располагали возможностью сразу много инвестировать в компанию и долгое время не уделяли достаточного внимания заказной разработке.

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

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

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

Тут дело вот в чем. Года до 2020-го все наши проблемы однозначно были следствиями наших же собственных ошибок, недоработок, неверных прогнозов, отсутствия смелости, недостаточной гибкости и дипломатичности, и т.д., и т.п. А раз мы накосячили, то мы можем извлечь уроки и исправиться.

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

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

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

Но пока что внешние потрясения, над которыми мы не властны, нас не добили. Так что мы еще повелосипедим. Надеюсь, по полной программе и от души. Благо силы еще есть и мозги на месте ;)

Посему продолжаем продолжать :)

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

---

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

Аналогично и с собственным бизнесом: открывать его нужно не тогда, когда можешь, а когда уже не можешь не.

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

---

PS. Если кто не в курсе, "СтифСтрим" по-русски означает "упрямый поток". Или, более точно, "упертый поток". Думаю, что шесть лет существования "СтифСтрима" наглядно показывают, что упертости нам не занимать ;)

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

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

Фильмы

Шпион, которого не было (Rogue Agent, 2021). Мне очень понравился. Может быть слегка затянут, но не сильно и, возможно, это тоже работало на вовлечение зрителя в происходящее. Так что один из немногих вменяемых фильмов за последнее время.

Тед К. Унабомбер (Ted K, 2021). Если бы его сократить минут на 15-20, то было бы просто отличное кино. А так получилось слишком уж заунывно местами. Но все равно на фоне остального киношлака это хоть что-то достойное просмотра.

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

Черный телефон (The Black Phone, 2021). Вроде бы и снято хорошо, и следить за происходящим интересно. Но, во-первых, не страшно. И, во-вторых, быстро начинаешь понимать, что "финал окажется несколько предсказуем" (с). В итоге я так и не понял, понравилось ли мне или нет. Скорее не понравилось.

Я был там (I Came By, 2022). Странные впечатления от фильма. Вроде бы и сюжет нормальный, и актеры пытаются играть, и куча трупов образовалась в процессе. А вот никакого желания сопереживать происходящему на экране не происходит. Так что глянуть можно, но меня не торкнуло.

Стейк от кутюр (Tendre et saignant, 2020). Большую часть фильма смотреть было интересно, но вот финал откровенно разочаровал. Такое ощущение, что ради хэппи-энда создатели фильма решили наплевать и послать по известному адресу всю логику предыдущего повествования.

Тор: Любовь и гром (Thor: Love and Thunder, 2022). Ну такое себе. Третий Тор был смешным и в должной мере самоироничным, этот попытались сделать в таком же духе, но получилось какое-то лоскутное одеяло, в котором какие-то фрагменты еще ничего, но остальное сильно так себе. Любителям серии можно глянуть, а вот нелюбители могут смело проходить мимо.

Вышка (Fall, 2022). Как по мне, так заурядная сказочка, в которой есть всего один интересный момент, а все остальное вызывает желание воскликнуть "не верю!"

Барракуда (The Enforcer, 2022). Занудно и экшена не хватает.

В постели с незнакомцем (The Stranger in Our Bed, 2021). Пока смотришь, то вроде бы интересно. Но когда в финале пытаешься связать воедино все ниточки, то возникает ощущение, что тебе попытались впарить какую-то нелогичную фигню. Так что меня лично фильм сильно разочаровал.

Пропавшая (Alone, 2020). Начиналось очень даже неплохо. Но затем повествование свалилось в такую муть, что оставалось только разбивать себе лицо фейспалмами.

Сериал

Перевал (Der Pass, 2018, два сезона). В обоих сезонах первые пару серий достаточно нудные, их нужно перетерпеть (особенно во втором сезоне). Дальше все смотрится достаточно интересно, но вот финалы лично меня разочаровали, особенно во втором сезоне. Так что на безрыбье сойдет, но чего-то выдающегося ждать не стоит.

[soft.bragging] Третья сотня звезд на GitHub-е для SObjectizer

Однако, триста.

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

Что особенно отрадно, как это то, что очередная сотня была набрана практически без PR-а с нашей стороны. Всего каких-то жалких три статьи на Habr-е и лишь один анонс на reddit-е. В районе 2017-2020 годов в популяризацию SObjectizer-а нами вкладывалось гораздо больше усилий.

Традиционно уже скажу, что проект живет. В 2022-ом даже получилось сделать полноценный релиз SObjectizer-5.7.4 и so5extra-1.5.0. И пусть это относительно минорные обновления, но на фоне всей той жести и неопределенности, которая творится в мире в последние два года, удалось сделать хотя бы это.

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

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

В заключение хочу поблагодарить всех, кто рискнул выбрать SObjectizer для своего проекта или иным образом поспособствовал его популяризации. Если бы не вы, то история SObjectizer-а уже давно бы закончилась. А так еще поборемся... :)

[prog.c++] Опыт встраивания интепретатора Python-а в C++ приложение посредством pybind11, vcpkg и CMake

Давеча потребовалось встроить интерпретатор Python-а в C++ приложение.

Поскольку в проекте уже использовался vcpkg, то часть проблем отпала сама собой: подтянуть Python3 в проект и слинковаться с ним особой проблемы не составило. Правда пришлось в CMakeLists.txt для приложения, в которое Python3 вставлялся, добавить несколько строчек, чтобы на Linux-е к приложению линковалось бы еще и библиотеки util и dl.

Под Linux-ом результирующий бинарник даже сразу запустился. А вот под Windows при старте приложение выдавало ошибку типа вот такой:

Fatal Python error: init_fs_encoding: failed to get the Python codec of the filesystem encoding
Python runtime state: core initialized

ModuleNotFoundError: No module named 'encodings'

и все, никакой нормальной работы.

Как я понял, проблема в том, что когда Python стартует, то он пытается разыскать свою стандартную библиотеку (т.е. туеву хучу *.py файлов). И под Windows он ее найти не может.

В процессе разбирательства выяснилось интересное. Когда мы работаем в Linux-е, то vcpkg при компиляции Python3 раскидывает компоненты Python следующим образом (cmake-build -- это каталог, в котором идет сборка проекта):

[prog.flame] Пару слов на тему cpp2/cppfront от Герба Саттера

Досмотрел выступление Герба Саттера на CppCon 2022, где он рассказывал про свой эксперимент на тему cpp2 и транслятора cppfront.

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

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

Так что всячески желаю этому проекту успехов и бурного развития.

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

[prog.c++] Отказался от использования маркера can_throw в arataga

В проекте arataga использовался прием, который на момент активной работы над arataga, существенно повышал мне коэффициент спокойного сна. Подробнее об этом трюке я писал два года назад на Habr-е: can_throw или не can_throw?

В двух словах: в функции/методы, в которых можно было спокойно выбрасывать исключения, передавался специальный маркер типа can_throw_t. Этот маркер указывал, что функция/метод вызывается из контекста, в котором исключения перехватываются и обрабатываются. Соответственно, если такой маркер в функции/методе есть, значит я могу сделать throw или вызвать какую-то бросающую исключение операцию. А если такого маркера нет, то мне нужно обрамить свои действия блоком try-catch.

К появлению can_throw привело то, что в arataga пришлось писать много callback-ов, которые вызывались при выполнении IO-операций через Asio и парсинге HTTP-протокола посредством http_parser. В таких контекстах исключения нельзя было выпускать наружу и требовалось понимать, пишу ли я сейчас код для callback-а или для чего-то другого.

Надо сказать, что прием can_throw мной всегда оценивался как не вполне однозначный.

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

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

Потом же развитие aragata было заморожено вообще. Сейчас этот проект важен для меня как демонстрация того, как выглядит реальный код для продакшена на SObjectizer.

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

Проект arataga интересен еще и тем, что это один из двух проектов за последние несколько лет, в которых я серьезно задумывался над использованием stackfull-короутин. В arataga в виде короутин можно было бы реализовать обработчики отдельных подключений (т.е. модель coroutine per connection). И, если бы в SObjectizer была поддержка stackfull-короутин "искаропки", то может быть именно с модели coroutine per connection я реализацию arataga и начал бы.

Но в SObjectizer поддержки stackfull-короутин нет. Все еще нет.

Давеча у меня появилось некоторое время чтобы подумать о том, что же в SObjectizer можно добавить. Вариантов для рассмотрения не так, чтобы много, и stackfull-короутины в short-list-е.

Тут-то проект arataga в очередной раз и вспомнился. Если добавлять короутины в SObjectizer, то в arataga их можно будет и сразу же протестировать "в деле".

Дабы освежить в памяти детали работы arataga погрузился в код...

И слегка прифигел от количество can_throw в реализации connection-handler-ов.

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

Обилие can_throw обескуражило настолько, что стало понято, что с этим нужно что-то делать. Только после этого можно было задуматься о попытке переписать arataga на короутинах.

Анализ кода показал, что сейчас в arataga осталось совсем не так много мест, в которых нужно заботиться о выбросе исключения наружу. И эти все места уже старательно обернуты в try-catch. Так что can_throw реально стал выглядеть избыточным рудиментом.

Поэтому в итоге can_throw из кода arataga был полностью изъят.

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

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

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

---

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

PS. Я заикнулся о том, что рассматриваю возможность добавления stackfull-короутин в SObjectizer. Но тут все очень не просто. Погружение в arataga наводит на мысль о том, что stackfull-короутины здесь могут и не помочь. Так что еще рано говорить о том, что решение о добавлении stackfull-короутин в SObjectizer принято. Тут еще нужно думать и думать, да и вообще это уже совсем другая история.

[photo.wtf] Что-то меня нехило так бомануло при попытке посмотреть запись стрима с разбором композиции в фотографии учеников

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

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

И уже на втором снимке меня бомбануло так, как не бомбило уже давно.

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

И все!

Ну ахиреть, блин.

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