пятница, 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 потому, что мозгов разобраться с чем-то еще у них просто не хватает.

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


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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

20180422-142340-DSCF9893

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

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

20180422-143118-DSCF9903

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20180420-124522-DSCF9600

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

20180407-115740-DSCF9500

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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