воскресенье, 30 сентября 2018 г.

[work] Свободная касса! (C++/Rust/D)

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

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

Специализируемся мы на C++. У нас большой опыт разработки на этом языке. Благодаря чему умеем писать на С++ без боли, чтобы ничего не текло и не падало.

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

Если качество нашего кода вас устраивает и вы хотите, чтобы аналогичного качества код был и у вас в проекте, то давайте пообщаемся на предмет взаимовыгодного сотрудничества. Пишите на info [at] stiffstream.com. Можно и напрямую мне: eao197 [at] stiffstream.com или eao197 [at] gmail.com.

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

пятница, 21 сентября 2018 г.

[prog.thoughts] Мнение пациента с хроническим NIH-синдромом: плюсы и минусы самодельного внутреннего инструментария

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

Как бы то ни было, так уж случилось, что за время своей работы в ИТ мне довелось создать несколько инструментов для разработчиков, которые использовались для создания прикладного софта. Созданный на базе моих инструментов работал годами и годами же находился на сопровождении. Ну, скажем, в 2002-ом году мной были сделаны первая версия SObjectizer-4 и встраиваемая ООСУБД ObjESSty, на базе которых затем был сделан агрегатор SMS/USSD сообщений. Этот агрегатор, как оказалось, до сих пор работает, прокачивает пару тройку десятков миллионов сообщений в сутки, что дает более полумиллиарда сообщений в месяц. Часть компонентов все еще работают именно на SO-4 и ObjESSty. Часть компонентов была написана уже на SObjectizer-5. Но, опять же, возраст этих "новых" компонентов так же измеряется годами.

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

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

вторник, 18 сентября 2018 г.

[prog.c++] Let's talk about hierarchical finite state machines and their support in SObjectizer-5.5

Finite state machine is a probably one of most basic and widespread thing in software development. Finite state machines (FSM) are actively used in many areas. For example in such niches as SCADA- and telecom systems FSM are used almost everywhere.

In this article we will try to speak about hierarchical FSM. And then we will try to take a look at FSM's support in SObjectizer-5. SObjectizer is one of a few OpenSource and live "actor" frameworks for C++ and actors in SObjectizer are FSMs. We will speak why SObjectizer's actors are FSMs and which capabilities they have.

A Brief Introduction Into Finite State Machines

It is hard to explain in a shot article such big topics as automata theory in general and finite state machines in particular. Because of that an basic understanding of these topics are required from a reader.

Advanced Finite State Machines And Their Features

There are several "advanced features" of FSM which significantly simplify usage of FSM. Let's talk about them briefly.

Disclaimer: if a reader has a good knowledge of UML's statechart diagrams then he or she doesn't find anything new here.

[work.thoughts] Люди, действительно, главный ресурс. Печально, когда это не так

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

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

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

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

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

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

PS. Что еще печально, так это то, что не удалось получить от бывшего работодателя success story по итогам разработок, который мой отдел когда-то делал на базе SObjectizer-а. Уже и отдела нет. И, как будто, сами эти разработки уже были проданы одному очень крупному банку. А уж от банка-то мы точно success story не получим.

четверг, 13 сентября 2018 г.

[prog.flame] Beast-vs-RESTinio or is Boost.Beast really good for solving simple tasks?

It seems that after inclusion of Beast C++ framework in Boost the Boost.Beast is regarded as the only right way to work with HTTP in modern C++. Maybe it is because some C++ developers know only Boost and look for libraries in Boost only. Some even don't know that there is something else except Boost.Beast (like CROW, Pistache, RestBed, served, C++REST SDK, POCO and so on).

And there also is a strong opinion that any library from Boost is the best in its class. For some Boost libraries it is just true. But now Boost has more than 100 libraries inside. It is hard to belive that all of them are exceptionaly useful, easy to use, well documented and maintained well...

Boost.Beast looks like a high-quality library. It just a bright example of C++ masterpiece. But there is a problem: it is too low-level. If you need to solve a simple task you have to write a lot of code on top of Boost.Beast.

To show this we reimplemented a simple example from Vinnie Falco's (he is Beast's author) talk at CppCon-2018 (code and slides can be found here) by using RESTinio library.

The repository with our implementation can be found here: https://bitbucket.org/sobjectizerteam/beast-cppcon2018-vs-restinio

We think that Boost.Beast is a great building block for something really complex (like high-performant HTTP server or client) or for something high-level and user-friendly (like that). But if you have to create a simple RESTful API or simple HTTP-service then it is better to look for something more simple and expressive. We hope our code shows this.

вторник, 11 сентября 2018 г.

[prog.flame] Взгляд на Akka глазами разработчика SObjectizer-а

Некоторое время назад от читателя в комментариях поступила просьба сравнить SObjectizer и Akka. Попытался вдумчиво подойти к этому вопросу. Ибо тут было над чем подумать, т.к. на первый взгляд, сам факт такого сравнения достаточно странный. Как будто сравниваются апельсины с помидорами, просто на том основании, что и то, и другое можно съесть. Действительно, вряд ли у кого-то будет стоять выбор между C++ и SObjectizer-ом и Scala/Java и Akka. Скорее сперва выбирается язык/платформа, потом уже фреймворк для этого языка/платформы. Так что с точки зрения практики более уместным было бы сравнивать SObjectizer и CAF с QP/C++ в рамках C++. Или Akka и Vert.x в рамках JVM.

Тем не менее, поскольку и SObjectizer и Akka реализуют вроде как похожие идеи (активные самостоятельные сущности, взаимодействующие с окружением только посредством асинхронных сообщений), то было любопытно посмотреть, насколько по разному в SObjectizer и Akka подходят к реализации этих самых идей.

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

Под катом можно найти некоторые поверхностные соображения о том, в чем SObjectizer и Akka похожи, а в чем они сильно или не очень, но отличаются.

понедельник, 10 сентября 2018 г.

[prog.c++] Видео с митапа в Питере

Стало доступно видео моего выступления на митапе St. Petersburg C++ User Group с докладом "Акторы в C++: взгляд старого практикующего актородела":

Презентацию можно скачать в виде PDF-ки отсюда, либо же просмотреть на SlideShare или на Google Docs.

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

PS. Так же можно договорится, чтобы я подъехал в офис вашей компании и сделал подобный, но более подробный, доклад про SObjectizer.

суббота, 8 сентября 2018 г.

[life.photo] Впечатления от посещения "Гранд Макет Россия"

В этот раз в Питере удалось посетить уникальное место -- музей "Гранд Макет Россия". Место, от которого захватывает дух.

20180824-161412-DSC_0422

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

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

пятница, 7 сентября 2018 г.

[life.work; humour] А что вы знаете про генеральский эффект? ;)

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

Вчера проявление этого эффекта я сам мог наблюдать на примере LinkedIn.

воскресенье, 2 сентября 2018 г.

[life.craftmanship] Видео про изготовление классических гитар

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

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

В общем, наверное лучшее из пока увиденных, это вот этот ролик:

Правда, он почти на 50 минут. Так что если кто-то хочет более компактную версию, то вот этот сделан качественно и с душой:

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


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

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

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

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

Идеальные незнакомцы (Perfectos desconocidos, 2017). Хорошая комедия, получил большое удовольствие. Это испанский ремейк итальянской картины от 2016-го. Вроде бы все тоже самое, но т.к. итальянский фильм я не смотрел, то не могу сказать, какой из них лучше.

Апгрейд (Upgrade, 2018). Вот этот фильм приятно порадовал. Не ожидал ничего хорошего, но оказалось на удивление динамично, бодренько и смотрибельно.

Голубая игуана (Blue Iguana, 2018). На мой взгляд (повторюсь: на мой взгляд) получилось нормальная криминальная комедия. Немного наивная, местами предсказуемая, но при этом обладающая достаточной укуренностью, чтобы понравится мне.

22 мили (Mile 22, 2018). Не понравилось. На экране творится какой-то несуразный бред, а перестрелок и экшена недостаточно, чтобы все это затмить. Единственный светлый момент -- это то, что русские всех сделали :)

суббота, 1 сентября 2018 г.

[prog.actors] Прочитал тут небольшую брошюрку "Designing Reactive Systems" от разработчиков Akka

Разработчики Akka время от времени публикуют небольшие книжонки полурекламного-полуобучающего содержания. Одна из них, а именно "Designing Reactive Systems" оказалась вполне себе даже ничего. Если кто-то имеет самое поверхностное впечатление о Модели Акторов и хочет погрузиться в тему чуть-чуть глубже, дабы понять, нужно ли вообще в Модель Акторов вкладываться или нет, эта брошюра вполне может оказаться полезной. Тем более, что не смотря на обычный изрядный налет маркетингового бла-бла-бла, она действительно дает нормальное и понятное описание достоинств аторов в практическом плане. Без теоретизирования и ухода в абстрактный Computer Science.

Что лично меня откровенно порадовало по ходу чтения, так это то, что в книге я находил все те же тезисы, которые сам рассказывал в своих докладах про модель акторов (как на CoreHard-ах, так и на недавнем митапе в Питере). В частности, тезисы про отказоустойчивость и закладываемые в акторов возможности по преодолению тех или иных проблем в процессе их работы. А так же, что я в чужих материалах встретил чуть ли не в первые, про активное использование таймеров в сочетании с шаблонами. Ведь про то, что таймеры являются одним из признаков того, что акторы применимы в конкретной задаче, и о том, что таймеры и акторы очень хорошо дружат друг с другом, я рассказывал чуть меньше года назад на CoreHard Autumn 2017.

Так что еще раз повторюсь, брошюра на удивление толковая. По крайней мере большая ее часть. Так что если кто-то только слышал краем уха про акторов, но хочет получить чуть более развернутое представление, то вполне можно эту книжку прочитать. Благо она небольшая и бесплатная. И хоть ее написали люди, плотно работающие с JVM, привязки к Java/Scala в ней нет. То, что там описано, сохраняет актуальность вне зависимости от языка программирования.

PS. Хотя упор на дерево супервизоров -- это не есть характерная особенность Модели Акторов. Можно и по-другому, SObjectizer тому наглядная демонстрация. А в низкоуровневых языках, таких как C++, польза от супервизоров вообще сомнительна.

среда, 29 августа 2018 г.

[prog.c++] SObjectizer: планы на ближайшее будущее и вопросы к заинтересованным читателям

Есть у меня стойкое ощущение, что не смотря на блог, статьи на Хабре, выступления на конференциях и пр., SObjectizer, как инструмент, недостаточно раскручен и известен даже в русскоязычном C++ сообществе. Не говоря уже про англоязычное. В связи с этим на ближайшие пару месяцев (минимум) приоритеты в работах над SObjectizer-ом смещаются в сторону пиара. Т.е. в первую очередь пойдет работа над статьями, презентациями и пр. вещами, которые позволят увеличить publicity. А доработки самого SObjectizer-а будут выполняться по остаточному принципу.

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

Тем не менее, если кому-то чего-то в SObjectizer-е не хватает и вы хотели бы это получить в ближайшей перспективе, а не через три-четыре месяца, то обозначьте свои хотелки явным образом, пожалуйста. Сделать это можно либо через Feature Requests на SourceForge, в Issues на GitHub-е или напрямую мне на email (eao197 на гмайл ком).

В принципе, аналогичная просьба есть и по поводу статей/презентаций, которые мы будем делать в эти ближайшие пару месяцев. Может быть есть какая-то тема, которую бы вы хотели, чтобы мы осветили подробнее. Например, работу с состояниями агентов в SObjectizer-е, запуск нескольких экземпляров SObjectizer-а в одном приложении и т.д., и т.п. Оставляйте свои заявки и это нам поможет подготовить материалы, которые будут полезны именно вам. Оставить заявку можно либо здесь, либо через email (eao197 на гмайл ком).

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

Ну а если кто-то сможет поделиться своей success story, то это будет вообще супер.

PS. А может кому-то хотелось бы видеть SObjectizer (с кооперациями агентов, mbox-ами, диспетчерами, message limits и вот этим вот всем) для другого языка программирования. Какого-нибудь Rust-а, Go, Kotlin-а, Swift-а и т.п.?


На всякий случай продублирую разные свои контакты. Проще и надежнее всего со мной связаться по почте: eao197 на гмайл ком. Так же я есть на LinkedIn, в Facebook-е и на Habr-е. В принципе, через ник eao197 меня можно найти и в Skype, но в последнее время я не часто пользуюсь компом c Windows и Skype, так что через Skype доступен далеко не всегда.

вторник, 28 августа 2018 г.

[life.work] Некоторые впечатления от митапа в Питере

Если говорить коротко, то мне понравилось. Отличная организация со стороны JetBrians. Уютная и удобная площадка для выступления. Мне, как гостю Питера, было прикольно выступать в зале, из окон которого видны питерские крыши, одна из Ростральных колон и собор Петра и Павла. Хорошая аудитория подобралась, насколько я мог судить по выражениям лиц слушателей, подавляющему большинству было интересно. Вопросы толковые задавали, как в рамках самого доклада, так и затем в кулуарах.

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

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

Сложно сказать, какие результаты это выступление принесет нам в долгосрочной перспективе. В краткосрочной мы уже получили неожиданный результат: Павел Бегунков нашел время и сделал небольшое ревью кода SObjectizer-а, указав нам ряд мест, где можно почистить код и поднять производительность. Сейчас с этим как раз и разбираюсь. Многие из косяков имеют древнюю историю и восходят ко временам 2010-го и начала 2011-го годов, когда поддержка C++0x/11 в компиляторах только-только начала появляться и нам приходилось действовать по старинке. Как раз отличный повод все это почистить и выпустить обновленную версию SObjectizer-а.

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

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

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

Поэтому мой совет тем компаниям, которые владеют подобными инструментами и не знают, что теперь с этим делать: избавляйтесь от доморощенных решений. Если только вы не Google, Facebook, Amazon или Yandex.

Есть готовые фреймворки для C++. Не нравится вам SObjectizer -- возьмите C++ Actor Framework, QP/C++ или что-то другое. Если вы не очень представляете себе, что такое наш SObjectizer, какими возможностями он обладает и что с его помощью можно сделать, то пригласите нас рассказать об этом. Я могу подъехать и сделать доклад о SObjectizer-а. Хоть короткий, как на этом питерском митапе, хоть более расширенный и углубленный.

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

Так что если кому-то интересен SObjectizer или история, которая стоит за ним, то приглашайте. Мы с удовольствием поделимся своим опытом.

PS. Слайды доклада можно найти на SlideShare, в Google Docs или в виде PDF-ки на SourceForge.

понедельник, 27 августа 2018 г.

[life.photo] Пичалько...

20180822-141725-DSC_0018

В этот раз решил взять в Питер большой чОрный зеркальный фотоаппарат и пару чОрных объективов к нему: 40mm/2.0 для общих планов и 85mm/1.4 для репортажно-портреного стрит-фото. Думал пройтись по Невскому, поснимать тамошних уличных музыкантов и просто гродских сумашедших фриков, коих в местах большого скопления народа обычно целая уйма. Но врожденная запасливость заставила взять, на всякий случай, еще и старый добрый 50mm/1.4D. Хоть и делал это скрепя сердцем, т. к. лишний груз, лишний объем и т. д.

В первый выход в город вооружился 40mm и 85mm объективами. И где-то после первых 50 кадров, сделанных на 40mm-объектив, случайно обнаруживаю, что какие-то кадры оказываются пересвеченными. А т. к. чОрной зеркалкой не пользовался уже давно, то сразу не понял, в чем дело. Может встроенный экспонометр врет на ярком солнце, может режим экспозамера выставлен неудачно. В общем, что-то идет не так, но вот что, почему и что делать дальше – не понятно.

Перепробовал разное. Но, в итоге, пришел к выводу, что на 40mm-объективе начал барахлить репетитор диафрагмы. На части кадров срабатывает и тогда с экспозицией все ОК. А иногда не срабатывает. Тогда получается, что кадр снимается на полностью открытой «дырке» и пересвет просто жутчайший. Если это действительно проблема в объективе, то это не весело. Объектив «нетрадиционный» – мануальный Voigtlander, зверь в наших краях крайне редкий. Хорошо, если в Гомеле или Минске найдется сервис, который сможет взяться за его ремонт.

В итоге получилось что: взятый «на всякий случай» «полтинник» оказался основным объективом, который я использовал чуть ли не в 90% случаев. Пройтись по Невскому в самое интересное, вечернее, время в этот раз не удалось, поэтому 85-mm «портретник» пролежал без дела.

Самое страшное – это то, что изначально я хотел брать только один объектив, именно Voigtlander. И вот взял бы я его, без какой-либо замены, и чтобы потом делал?

PS. Фулфреймовая никоновская зеркалка даже со старым пластиковым 50mm/1.4D (который и достаточно компактный, и достаточно легкий) – это нифига не тревэл камера. Вот Fujifilm x30 – вот это настоящая трэвел камера. И маленькая, и легкая, и диапазон фокусных расстояний у встроенного зума подходящий, и меньше боится влаги/пыли. Но вот качество изображений, особенно на ISO выше 400 – это просто ахтунг какой-то. У зеркалки со светосильны фиксом огромная фора в качестве изображений. Однако, если захочется приблизится по универсальности к x30, то это нужно уже будет говорить про зум из категории 24-70mm/2.8. А это уже и совсем другие габариты, и совсем другой вес (если я правильно помню, будет что-то около 2кг), и совсем другая цена.

вторник, 21 августа 2018 г.

[life.work] В Питере пить? ;)

Отбываю в Питер делать доклад на митапе St. Petersburg C++ User Group. Пробуду в Питере несколько дней. Совмещу приятное с полезным. Слайды же доклада опубликую на SlideShare уже на следующей неделе, после возвращения домой.

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

[prog.c++] RESTinio обновился до версии 0.4.8

У нас очередной релиз. Наша легковесная C++14 библиотека для встраивания асинхронного HTTP/WebSocket сервера в C++ приложения, RESTinio, обновилась до версии 0.4.8. Изменений не так много, но среди них можно выделить одно весьма важное: нотификаторы для операций записи.

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

Вот тут-то нотификаторы и будут полезны. Вы пишете очередную порцию в response, затем вызываете flush() и передаете во flush() нотификатор. RESTinio запишет ваши данные и дернет ваш нотификатор когда запись закончится (положительно или отрицательно). И в этом нотификаторе вы сможете инициировать запись следующей порции.

Минималистичный пример использования нотификаторов:

#include <restinio/all.hpp>
#include <iostream>

int main()
{
  restinio::run(
    restinio::on_this_thread<>()
      .port(8080)
      .address("localhost")
      .request_handler([](auto req) {
        return req->create_response()
                 .set_body("Hello, World!")
                 .done( /* Notificator goes here */
                   [](const auto & ec ){
                     std::cout << "Sending response status: " << ec << std::endl;
                   });
      }));

  return 0;
}

Более актуальный пример можно найти в репозитории RESTinio.

В общем, не стесняемся, берем, пробуем, пользуемся, делимся впечатлениями. Любая конструктивная критика, соображения и предложения всячески приветствуются. Так же приветствуются лайки, плюсадынки и решары :) Кому не лень, можно плюсануть соответствующую тему на Reddit-е.

суббота, 18 августа 2018 г.

[life.business] Странные впечатления от одного видео и некоторая рефлексия на тему бизнеса

На LinkedIn попалась на глаза ссылка вот на это видео:

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

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

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

Вообще говоря, размышляя по поводу всей этой хрени вокруг стартапов, подъемов инвестиций и пр. модной лабуды, поймал себя на мысли, что в моем случае занятие бизнесом -- это не попытки выстроить что-то масштабируемое (по типу того, что сделал Рэй Крок с McDonald's) и даже не попытки удовлетворить массовый спрос на что-то. Это скорее попытки научиться продавать тот набор знаний и умений, которым располагает наша команда. Мы не выводим на рынок новый офисный пакет и не выстраиваем очередную розничную сеть продуктовых магазинов, не делаем новый инновационный продукт, который перевернет ваши представления о чем-то. Наша задача -- рассказать о том, что среди множества подрядчиков, задачей которых является эффективная продажа жопочасов криворуких недоучек, есть маленькая команда, которая берет и делает. Осталась самая малость -- научится делать это хорошо.

пятница, 17 августа 2018 г.

[prog.c++] Завершение(?) серии статей про Shrimp на Хабре

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

среда, 15 августа 2018 г.

[prog.c++] Про попытку изобразить strong typedef из подручных средств

У нас завершается очередная итерация работ над демо-проектом Shrimp. На днях выйдет статья на Хабре с некоторыми подробностями (если кто-то пропустил, то вот первая статья про Shrimp, а вот вторая). Сегодня же я попробую рассказать об одной штуке в коде Shrimp-а, которая у меня самого вызывает неоднозначные впечатления. Если кому-то интересны потуги натянуть сову на глобус извращения старого сиплюсплюсника, то милости прошу под кат.

пятница, 10 августа 2018 г.

[prog.c++] json_dto-0.2.6: небольшое, но довольно важное обновление

Мы сегодня зафиксировали свежую версию 0.2.6 своей легковесной библиотеки json_dto. Там одна новая фича, но, думается, достаточно важная для определенных сценариев работы с JSON-документами.

Дело в том, что мы json_dto делали для себя, для ситуаций, когда JSON-документ хранил внутри единственный сериализованный объект. Т.е. мы имели дело с JSON-документами вида: {"field":...}. А вот на днях один из пользователей json_dto обратил наше внимание на ситуацию, когда JSON-документ представляет из себя вектор из объектов. Т.е. что-то вроде: [{"field":...}, {"field":...}, {"field":...}]. В такой ситуации json_dto оказывался бесполезным.

Этот же пользователь поделился своими соображениями о том, как он бы хотел использовать json_dto в такой ситуации. Он бы хотел иметь возможность написать json_dto::from_json<std::vector<Data>>(json_document) и чтобы результатом был экземпляр std::vector с объектами типа Data внутри.

Собственно, именно это мы и добавили в версию 0.2.6. Теперь можно писать вот так:

#include <json_dto/pub.hpp>

#include <iostream>
#include <algorithm>

struct data_t {
   std::string m_key;
   int m_value;

   template<typename Json_Io>
   void json_io(Json_Io & io) {
      io & json_dto::mandatory("key", m_key)
         & json_dto::mandatory("value", m_value);
   }
};

int main() {
   const std::string json_data{
      R"JSON(
         [{"key":"first", "value":32},
          {"key":"second", "value":15},
          {"key":"third", "value":80}]
      )JSON"
   };

   auto data = json_dto::from_json< std::vector<data_t> >(json_data);
   std::sort(data.begin(), data.end(),
      [](const auto & a, const auto & b) { return a.m_value < b.m_value; });

   std::cout << "Sorted data: " << json_dto::to_json(data) << std::endl;
}

И получать при этом вполне ожидаемый результат:

Sorted data: [{"key":"second","value":15},{"key":"first","value":32},{"key":"third","value":80}]

В общем, кто хочет легко и удобно работать с JSON-ом, то не стесняемся, берем json_dto, пользуемся, делимся впечатлениями. Взять json_dto можно на BitBucket-е или на GitHub-e (со временем версия 0.2.6 подтянется и на vcpkg).

Кстати говоря, с теми, кому json_dto интересен, можно было бы обсудить вот еще что: в принципе, в описанном выше сценарии вовсе необязательно работать только с std::vector<Data>. Запросто может быть использован и std::deque<Data>, std::list<Data> или даже std::array<Data, N>. Если кому-то хотелось бы видеть в json_dto поддержку и других STL-левских контейнеров, а не только std::vector, то дайте нам знать. Постараемся эту поддержку добавить. Ну а если это никому не интересно, то пусть все остается как есть.

среда, 1 августа 2018 г.

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

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

Миссия невыполнима: Последствия (Mission: Impossible - Fallout, 2018). Качественно выполненный аттракцион. Заходишь в кинозал, выключаешь мозги и наслаждаешься красочно сделанным зрелищем. Вполне в духе и на уровне предыдущих частей.

От семьи не убежишь (La ch'tite famille, 2018). Очередная добротная французская комедия с Дени Буном. В которой, местами, видно, что Дени не просто хороший комик, но и хороший актер.

Дыши во мгле (Dans la brume, 2018). Оказалось очень даже неплохо. Не ожидал.

Великий уравнитель 2 (The Equalizer 2, 2018). В принципе, тоже самое, что и в первой части. Только более занудно. Совсем без юмора. И финальная разборка унылая.

Шпионская игра (The Catcher Was a Spy, 2018). Удивительное дело: взяли за основу интересную историю, подтянули хороших актеров, сняли профессионально. А получилось неинтересно с невнятным финалом.

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

Хмарочос (Небоскреб, Skyscraper, 2018). Редкая бредятина. Не смотреть ни в коем случае.

суббота, 28 июля 2018 г.

[prog.memories] Хороший текст был написан почти три года назад. Есть на что оглянуться

В процессе подготовки к митапу в Питере пересматриваю свои старые материалы в поисках того, что можно переиспользовать в докладе. Дошел вот до этой заметки, написанной в августе 2015-го года, т.е. без малого три года назад: It's all about in-process message dispatching или...

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

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

среда, 25 июля 2018 г.

[prog.flame] И вот для этого стоило осваивать Хаскелл?

Люди сообщают с мест:

Компания называется Restaumatic, Польша. Пишем сервисы для ресторанов: заказ еды, системы скидок, сайты, вот это вот все. Обычный web, CRUD, фронтенд на PureScript, бэкенд на Haskell. На самом деле, переписываем потихоньку эту функциональность с RoR и добавляем новую.

Цинк: cpp_stm_free: монадическая STM библиотека для параллельного программирования.

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

Мне, например, нравится использовать C++ в вещах, связанных с низким или более-менее низким уровнем. Протоколы какие-нибудь реализовывать, устройствами какими-нибудь управлять, писать ядра СУБД или MQ-брокеров, ресурсы экономить (выжимать тактики из битиков, как кто-то когда-то хорошо сказал). Но это прежде всего потому, что сами эти задачи мне нравятся. А C++ оказался весьма хорошо приспособлен для таких задач.

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

А тут Web-приложение с бэкэндом на Хаскелле, которое суть складской учет, который во времена оные отлично покрывали dBase-ами и Clipper-ами... Нужно, наверное, очень сильно любить Хаскелл ;)

PS. Интересно было бы лет через 5-10 узнать, чем все закончилось. А то вспоминается пример Sociomantic-а, в котором когда-то выбрали в качестве языка реализации D1, а потом столкнулись с тем, что есть большая и работающая кодовая база на D1, который уже никому не нужен, и есть совсем другой D2, который с D1 не совместим ни на уровне языка, ни на уровне библиотек. Но там хотя бы выбор шустрого D был оправдан требованиями к скорости реакции. Ради чего выбирать Хаскелл для рядового Web-приложения -- это вопрос.

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

[prog.c++] В августе буду выступать на митапе St.Petersburg C++ User Group

Благодаря Анастасии Казаковой из JetBrians в августе, 23-го числа (четверг), выступлю в Питере на митапе тамошней C++ User Group с докладом "Акторы в C++: взгляд старого практикующего актородела". Все подробности и возможность зарегистрироваться на митап вот здесь.

Этот доклад будет квинтэссенцией из моих предыдущих докладов на CoreHard C++ и C++ Russia. Предыдущие доклады были сильно ограничены по времени: всего сорок минут на само выступление + 10-15 минут на вопросы. Здесь же будет практически часовое выступление, в процессе которого я постараюсь затронуть основные моменты, связанные с акторами в C++. Т.е. что такое Модель Акторов вообще и почему к ней сейчас такой интерес. Имеет ли смысл использовать акторы в C++ (да, имеет, но не всегда). Какие особенности накладывает C++ при этом. Что есть готового для C++ вообще, почему это настолько сильно отличается друг от друга. Ну и немного про SObjectizer, конечно. В общем, то, что раньше приходилось растягивать на 3-4 отдельных доклада в этот раз будет выдано в рамках одного рассказа, без лишней воды и философствований.

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

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

[prog.flame] И еще раз про Rust. Как я к Rust-у отношусь на самом деле

Судя по статистике посещений, недавние посты про Rust (№1, №2 и №3) продолжают привлекать к себе внимание. И, к сожалению, у некоторых альтернативно одаренных личностей складывается впечатление, что я пытаюсь гнобить Rust. Поэтому нужно расставить все точки над ё.

четверг, 19 июля 2018 г.

[prog.c++] Вторая статья про демо-проект Shrimp

Мы подготовили и опубликовали вторую статью про свой демо-проект Shrimp, наглядно показывающий, как может выглядеть более-менее реальное приложение на RESTinio и SObjectizer (ну и на C++17): "Развиваем Shrimp: контролируем параллельные запросы, логируем через spdlog и еще…".

Вторая статья описывает результат следующей итерации вокруг Shrimp-а. Мы кое-что доработали напильником и устранили шероховатости, которые были в самой первой версии Shrimp-а. Интересно было добавлять команду на принудительный сброс содержимого кэша в Shrimp-е. За счет удобного механизма роутинга запросов в RESTinio добавить обработку еще одного URL в HTTP-сервере -- это буквально дело нескольких минут. Правда, реализация реакции на эту команду в агенте transform_manager заняла больше времени, но и там отложенные сообщения, которые есть в SObjectizer-е, сильно помогли и упростили работу.

По результатам первых двух итераций над Shrimp-ом у нас уже обозначился набор фич, которые было бы полезно добавить как в RESTinio, так и в SObjectizer. Что-то уже пошло в работу (и даже нашло свое воплощение в RESTinio-0.4.7), до чего-то руки дойдут как только, так сразу. Если вы сами хотели бы увидеть что-то в RESTinio и/или SObjectizer-е, то дайте знать, к конструктивным соображениям мы всегда прислушиваемся и стараемся их воплотить. Ярчайший пример -- это добавление в SObjectizer мутабельных сообщений, идея которых возникла при обсуждении возможностей SObjectizer-а в кулурах C++Russia 2017. В том же Shrimp-е практически весь обмен данными между агентами выполняется как раз посредством мутабельных сообщений.

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

В общем, планы на ближайшее время есть. Осталось воплотить их в жизнь. Чем мы, собственно говоря, и займемся.

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

[prog.c++] Довелось столкнуться со странной структурой данных: и очередь, и multimap.

В рамках следующей итерации над демо-проектом Shrimp постарались закрыть несколько "косяков" самой первой, простейшей версии Shrimp-а. В частности, в простейшей версии Shrimp-а были возможны ситуации, когда пришедшие практически одновременно одинаковые запросы шли в параллельную обработку. Т.е., если мы получаем запрос "demo.jpg?op=resize&max=1024" и следом еще один такой же, то операция трансформации картинки demo.jpg к размеру 1024px могла быть запущена дважды.

Происходило это потому, что Shrimp проверял наличие уже трансформированной картинки в своем кэше. Если ее в кэше нет, то при наличии свободных worker-ов запрос сразу же шел в обработку. Получили запрос для demo.jpg, увидели, что в кэше результата нет, отдали на трансформацию. Результат трансформации еще не пришел, а у нас уже еще один запрос для demo.jpg. Поскольку трансформированной картинки в кэше, ожидаемо, нет, то отдаем запрос на обработку. И получаем, что одна и так же картинка трансформируется параллельно несколькими воркерами. Что не есть хорошо.

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

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

С другой же стороны, нужно иметь возможность эффективно проверить наличие конкретного ключа в контейнере. И, сюда же, нужно иметь возможность изъять из очереди сразу все элементы с одинаковым ключом. Нужно это в случае, когда освободился worker и мы берем самый старый элемент из очереди. Но, если ключ этого элемента не уникален (т.е. есть более свежие запросы с тем же ключом), то оставлять в очереди другие аналогичные элементы нет смысла. Ведь когда картинка будет трансформирована, то ее можно будет отдать сразу всем этим запросам.

четверг, 12 июля 2018 г.

[prog.c++] RESTinio v.0.4.7

Мы выпустили очередную версию своей легковесной C++ библиотеки для встраивания асинхронного HTTP/WebSocket сервера в C++ приложения: RESTinio v.0.4.7. В этой версии мы реализовали первую пачку улучшений по следам использования RESTinio в Shrimp-е. Дальше будет больше :)

В версии 0.4.7 основной упор был сделан на то чтобы использование RESTinio в каких-то случаях было удобнее и безопаснее (в смысле сокращения количество ошибок программиста). Какой-то принципиально новой функциональности в этот релиз не попало.

Взять RESTinio можно с BitBucket-а или с github-а. Пользователи vcpkg могут установить себе RESTinio через vcpkg install restinio

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

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

[prog.c++] Первая статья про Shrimp -- наш демо-проект для RESTinio и SObjectizer

Мы сегодня выкатили на Хабр первую статью о демо-проекте на базе RESTinio и SObjectizer-а: "Shrimp: масштабируем и раздаем по HTTP картинки на современном C++ посредством ImageMagic++, SObjectizer и RESTinio". Нам показалось, что такая задачка отлично показывает сценарий, при котором может потребоваться:

  • прикрутить HTTP-интерфейс к старому, давно отлаженному и работающему C/C++ коду. Особенно если нет возможности переписать этот код на новом, модном и безопасном языке. Ведь во многих случаях такой возможности нет;
  • асинхронно обслуживать HTTP-запросы, поскольку их прикладная обработка занимает на порядки больше времени, чем работа с самим HTTP-подключением;
  • использовать многопоточность для прикладной обработки запросов.

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

Первые практические результаты от разработки Shrimp-а мы уже получили. Появилось несколько идей и соображений как для RESTinio, так и для SObjectizer-а. Что мы и попытаемся воплотить в жизнь в грядущих обновлениях наших продуктов.

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

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

[prog.fuck] А не пора ли гнать активных растоманов ссаными тряпками?

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

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

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

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

Хан Соло: Звёздные войны. Истории (Solo: A Star Wars Story, 2018). Неожиданно хорошее впечатление произвел. Как по мне, так гораздо лучше 7-й и 8-й частей "Звездных войн". И, как по мне, очень удачно воспроизведена атмосфера самых первых фильмов саги. Только нужно понимать, что все это сказка и не требовать от сказки слишком многого.

Точка невозврата (High Wire Act, 2017). Не шедевр, но добротно. Мне понравилось.

Рэмпейдж (Rampage, 2018). Редкая муть. Мог бы быть фильмом для детской аудитории, если бы не жестокость и несколько шуток "ниже пояса".


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

Операция «Шаровая молния» (Entebbe, 2018). Такое ощущение, что целью создателей фильма было показать людьми всех участников событий -- и террористов, и заложников, и израильских политиков, и израильских спецназовцев. При этом, как мне показалось, настоящими людьми были показаны именно террористы. Они же через многое прошли, приняли для себя тяжелое решение, твердо следуют своим убеждениям несмотря ни на что, им тяжело, но они все равно идут к своей цели... Некоторые заложники тоже люди, конечно, но не все, в основном же безликое жертвенное стадо. Политики преследуют свои цели и большинству из них жизни каких-то там заложников безразличны от слова совсем. Солдаты... Солдаты тоже люди, но что о них говорить, они же солдаты.

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

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

Кавалерия (12 Strong, 2018). Не досмотрел даже до половины. Во-первых, пропагандой от фильма несет так, что даже советское кино эпохи застоя на этом фоне начинает выглядеть как строго документальное, без какой-либо идеологии. Во-вторых, первая же батальная сцена лихой кавалерийской атаки, когда атакующим противостоят несколько танков и БМП + пара джипов с крупнокалиберными пулеметами + моджахеды на оборудованных позициях с ручным автоматическим оружием. Я, конечно, далеко не военный человек. Но, судя по тому, что доводилось читать про применение пулеметов против атакующей пехоты, от несущихся с горки кавалеристов не должно было остаться вообще никого. А тут не только какие-то нелепые метания под плотным пушечно-пулеметным огнем, но еще и подмога тем же путем подоспела, а потом практически все атакующие, которые почему-то все еще живы, той же дорогой, под тем же огнем смогли убраться восвояси. Понятное дело, что американские вояки самые вояки в мире, особенно в американском кино. Но для меня это оказалось уже слишком.

План побега 2 (Escape Plan 2: Hades, 2018). Очевидно, что фильм снимался для того, чтобы попилить бабки китайских инвесторов. Но блин, от Слая участия в таком дерьме не ожидал. Больше 20 минут фильма осилить не смог, накал идиотии (причем во всем) какой-то запредельный.

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

[prog.business] Смена курса: С++ мертв и совсем скоро никто не будет его знать. Кроме...

Читая очередной срач на тему "Жив ли C++ и есть ли для него место в будущем", внезапно испытал озарение: хватит обманывать себя и других!

С++ мертв. У него нет будущего. Новые языки и технологии, такие как Go, Rust, Swift, Kotlin Native, .NET Native, GraalVM и пр., не оставили C++ никаких шансов. Не будут больше использовать C++ для разработки новых проектов. И изучать его уже смысла нет. Скоро вообще никто C++ знать не будет.

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

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

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

Хотя... Хотя, есть, конечно, небольшая компания, в которой работают люди, умеющие в С++ и способные приводить C++ный говнокод разной степени окаменелости в надлежащий вид. Но тут уж вам решать: либо быть немодным и в тоске и печали развивать за вменяемые деньги то, что у вас уже есть и работает годами, либо же с головой окунуться в новый прекрасный мир современных технологий и модных трендов, да еще и отпилить себе чего-нибудь от громадных бюджетов, которые потребуются для переписывания C++ на Go/Rust или что еще там станет модным буквально через пару-тройку лет.


PS. Если кто не понял, то пост -- джинса. Проплачено мной ;)

среда, 27 июня 2018 г.

[prog] В склерозник: фреймворк Bistro от Facebook

Наткнулся сегодня в Интернетах: Bistro -- A toolkit for making services that schedule and execute tasks. Зафиксирую ссылку здесь, чтобы затем можно было найти.

На первый, поверхностный взгляд, это что-то вроде Google-овского Borg-а. И, как по мне, хороший пример задачи, в которой уместно использовать и C++, и фреймворки вроде нашего SObjectizer-а.

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

[prog.thoughts] Еще раз про шизофреничность нашей профессии

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

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

Шизофреничность проявляется в том, что программист по отношению к своему коду должен играть две прямо противоположные роли. С одной стороны, программист должен стремиться сделать свой код как можно лучше. Что вряд ли возможно, если ты не любишь писать код и если тебе не нравится то, что ты пишешь. С другой стороны, программист постоянно должен критиковать свой код и выискивать в нем любые дефекты (например, при тестировании). Получается, что нужно и любить свой код (иначе не напишешь), и ненавидеть (иначе не протестируешь и не улучшишь).

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

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

[prog.thoughts] В догонку к посту про Rust 1.27

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

пятница, 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). Фильм для детей дошкольного возраста. Всем, кто постарше, лучше не смотреть вообще.


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

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

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