Уходящий год был непростым. Грядущий вряд ли будет проще... Тем не менее, все будет хорошо.
Посему поздравляю всех своих читателей с праздником! С Новым Годом!
PS. И хватит сидеть за компьютером ;)
Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
Уходящий год был непростым. Грядущий вряд ли будет проще... Тем не менее, все будет хорошо.
Посему поздравляю всех своих читателей с праздником! С Новым Годом!
PS. И хватит сидеть за компьютером ;)
Мы добавили в Wiki SObjectizer-а статью "Leassons learnt from 10+ years with actors in C++". В этой статье тезисно описывается несколько уроков, которые нам пришлось выучить на собственной шкуре в по ходу разработки и сопровождения нескольких программных систем.
Это наш опыт, никому его не навязываем. Не пытаемся утверждать, что все, кто попробует использовать подход на основе модели акторов при разработке софта столкнуться с такими же проблемами. И что решения, найденные нами, окажутся полезными для кого-то еще.
Тем не менее, почти тринадцать лет разработки C++ных программ на основе модели акторов и модели publish-subscribe -- это довольно таки серьезно. ИМХО, имело смысл этим опытом поделиться. Может быть кому-то и поможет.
PS. Интересно, что первая публичная статья о SObjectizer-е под названием "SObjectizer: I Love This Game", вышла в RSDN Magazine ровно десять лет назад (плюс-минус буквально пару дней) ;) SObjectizer тогда был совсем другой и за эти 10 лет мы прошли очень большой путь.
PPS. Вы очень сильно поможете развитию проекта, если сможете поделиться ссылкой на этот пост тем или иным способом.
В рамках дальнейшего развития SObjectizer обдумываю такую тему, как иерархические конечные автоматы. Агенты в SO-5 сейчас являются КА, но простыми, их состояния не могут быть вложены друг в друга. Интересно рассмотреть вариант, когда у агентов появляются вложенные состояния и другие плюшки, присущие более продвинутым КА.
В качестве маленькой тестовой задачки использую крайне упрощенный пример с домофоном. Т.е. есть устройство с 10-ью цифровыми кнопками, кнопкой сброса "С", кнопкой с решеткой "#" и кнопкой со звонком "B". Большую часть времени устройство проводит в неактивном состоянии, в котором не светится ни дисплей, ни кнопки. Когда пользователь нажимает любую кнопку устройство должно активизироваться (т.е. перейти в режим активного ожидания действий пользователя, включив при этом подсветку дисплея и кнопок). Если пользователь ничего не делает в течении 30 секунд, то устройство должно вернуться в неактивное состояние (при этом сбросив весь предыдущий ввод пользователя и погасив подсветку).
Если пользователь вводит комбинацию вида "dddB" (т.е. нажимает несколько цифр и кнопку звонка), то должен быть выполнен звонок в квартиру с указанным номером. Если вводит комбинацию "#ddd#dddddB", то это должно рассматриваться как предъявление секретного кода "ddddd" для квартиры с номером "ddd", если код предъявлен правильно, то замок должен быть открыт. Если вводит комбинацию "##ddddd#", то "ddddd" должен быть уникальным сервисным кодом, открывающим замок.
Если в процессе ввода пользователь нажимает "C", то весь ввод пользователя должен быть выброшен, а устройство должно опять начать активное ожидание ввода.
С начала осени являюсь владельцем Fujifilm x30. Время от времени снимаю этой камерой. За прошедшие несколько месяцев, надеюсь, сложилось некое более-менее взвешенное впечатление, которым и поделюсь с читателями.
Главное впечатление -- камера возвращает удовольствие от фотосъемки, но ценой качества фотографий.
Если попытаться тезисно раскрыть этот вывод, то получится что-то вроде:
Добавленный в версии 5.5.13 механизм mchain-ов может использоваться не только для организации взаимодействия между SObjectizer-овскими и не-SObjectizer-овскими частями приложения. Но и для защиты агентов от перегрузки. В версии 5.5.14 добавлен новый пример producer_consumer_mchain, который демонстрирует эту возможность. Под катом несколько слов о том, как это работает.
Состоялся релиз версии 5.5.14. Подробнее об изменениях под катом. Но сначала хотелось бы поделиться мыслями о том, что будет дальше. Не уверен, что следующая версия SO-5 выйдет так же быстро, как это происходило в последнее время. Если только не появится какая-то идея, простая в реализации, но дающая серьезную выгоду. Пока же таких идей нет :)
А так в планах на ближайшие три-четыре-пять недель следующее:
В общем планов много, так что даже не знаю, когда ждать 5.5.15 и 5.6.0. Вряд ли раньше января, а то и февраля.
Ну а теперь чуть подробнее о релизе 5.5.14...
Коллеги с прошлой работы вчера рассказали маленькую историю. В ноябре из-за bad_alloc-а завершил работу один из компонентов, написанных на C++ и SObjectizer. Когда стали разбираться что к чему, выяснилось, что этот компонент работал безостановочно с февраля, обслуживая по сотне миллионов запросов ежемесячно. В конце-концов, в 32-х битовом приложении из-за фрагментации памяти не удалось выделить непрерывный блок в 150MiB для in-memory обработки файла с новой управляющей информацией (эта информация обновляется каждый день). Выскочил bad_alloc, приложение завершилось, было автоматически рестартовано и продолжило свою работу.
Сейчас не хочется задаваться вопросами о том, что было с апдейтами для сервера, на котором крутился компонент. И о том, почему обработка больших управляющих файлов осуществлялась in-memory. Просто приятно получить очередное подтверждение тому, какой солидный фундамент был заложен много лет назад. При моем непосредственном участии ;)
Пару недель назад поставил себе цель дойти до 101-й страницы книги "Бизнес в стиле фанк". С трудом дошел, но где-то на 90-х страницах обнаружил обещания поговорить о неких серьезных вещах более предметно в главе "Fanky Inc." Пришлось собрать оставшиеся силы, дойти до этой главы и прочесть ее. В итоге, прочитано 200 страниц из 280 и данная книга отправляется туда, куда, на мой взгляд, ей и следует -- в мусорку.
Если кому-то интересно, почему я лично столь невысокого мнения об этом общепризнанном бестселлере, то милости прошу под кат.
Когда я работала над книгой «Цинковые мальчики» о войне в Афганистане, я поехала туда сама и видела там собственными глазами, какие ужасные вещи творили русские солдаты. В одной больнице я видела детей и женщин без ног. Одной женщине я дала игрушку — у нее на груди был ребенок. И в этот момент я заметила, что у него нет ни ручек, ни ножек. Я была шокирована! Она мне сказала: «Это сделали русские! Советские гитлеровские фашисты!»
Советские гитлеровские фашисты... Именно так сказала раненая афганская женщина.
На этом в теме правдивости историй от госпожи Алексеевич можно ставить большую и жирную точку.
PS. О, на днях люди один из потоков сознания современной сказительницы разобрали.
По-сути, работы над релизом 5.5.13 еще не закончились. Сегодня добил актуализацию документации, но пока странички еще остаются помеченными как находящиеся в процессе адаптации к v.5.5.13. Эта отметка будет убираться постепенно, в последующих ревизиях. Заодно подправил информацию в презенташке "What's SObjectizer-5.5?". По-хорошему, следовало бы еще и обновить остальные презентации из серии "Deep Dive into SO-5.5", но это неслабый кусок работы и не так-то просто собраться с силами и взяться за это. Кстати говоря, еще большим уважением проникся к OpenSource проектам с хорошей и актуальной документацией.
Тем не менее, на релизе 5.5.13 жизнь проекта не останавливается, как-то нужно двигаться дальше...
Состоялся релиз версии 5.5.13. Это первая версия в линейке 5.5.*, в которой была нарушена совместимость с предыдущими версиями.
Хочу задать пару вопросов своим читателям.
Первый вопрос связан с темой, которая некоторое время назад всплывала на RSDN: Об очередном антипаттерне. Модель акторов. В стартовом сообщении темы тов.LaPerouse затронул тему состояний акторов. И сказал, что иерархические КА для описания состояний акторов никто не использует. В связи с этим вопрос: если кому-то доводилось сталкиваться с ситуациями, когда использование иерархических КА было выгодно, не могли бы вы кратко поделиться своим опытом в комментариях?
Второй вопрос такой: появилась мысль сделать презенташку или статью, в которой рассказывалось бы о нескольких основных уроках, извлеченных из более чем десятилетнего опыта использования акторов/агентов в C++. Основных уроков, навскидку, четыре: 1) большое количество агентов -- это не решение проблемы, а ее часть; 2) нужно обеспечивать защиту агентов от перегрузки; 3) мониторинг потрохов приложения нужен и 4) С++ -- не Erlang, let it crush тут работает иначе; 5) агенты склонны к полноте и изрядно толстеют со временем. Будет ли такая презентация/статья кому-нибудь интересна?
...из-за вот такого поведения GCC 5.2.0 под моим ArchLinux-ом:
При этом MinGW 5.2.0 (как с флагом -fpermissive, так и без), а так же clang 3.7.0 под тем же Linux-ом компилируют этот пример без проблем.
А с учетом того, какой геморрой будет связан с выбрасыванием суффикса _t как в SO-5, так и в проектах, где SO-5 давно используется, не говоря уже про переделку документации... Блин, нужно все еще раз взвесить и обдумать. А может и не один раз :(
Фактически, дополнение к посту двухнедельной давности, в котором идея механизма взаимодействия между SObjectizer-овскими и не-SObjectizer-овскими частями приложения описывалась под названием msg_stream. За это время механизм сменил несколько названий, называется сейчас mchain, вполне себе работает и, думаю, уже близок к тому, чтобы считать его стабильным и вполне готовым к релизу. Под катом немного информации о том, что получилось.
Так же небольшая просьба к читателям: пара идентификаторов, задействованных в механизме mchain-ов, мне кажется не очень удачной. Но это лучшее, что пока пришло в голову. Если кто-то сможет предложить более благозвучные и понятные варианты, то это будет серьезная помощь проекту.
Еще один пример того, как C++ные шаблоны позволяют избавиться от дублирования кода.
Задача метода create_mchain в том, чтобы проанализировав несколько аргументов создать экземпляр шаблонного класса mchain_template с нужным набором шаблонных параметров. Слева код, который был написан сходу, с применением копипасты. Справа -- результат простого рефакторинга.
Вот следствие чего вот это вот: свободы нести в Интернете всякую чушь или того, что на волне высоких зарплат и спроса на рабочую силу в ИТ, в программисты попадает большое количество альтернативно одаренных личностей?
Забавно наблюдать за тем, какой статус приобретают тривиальные, в общем-то, вещи, оказавшиеся мейнстримом. Взять, например, паттерны проектирования. Полагаю, многие разработчики в начале-середине 90-х годов использовали в своих проектах большую часть паттернов из GoF, даже не зная, что они используют паттерны (уж такие вещи как Factory, Proxy и Command, полагаю, каждый "переизобретал" по нескольку раз). Тем не менее, после выхода книги "банды четырех" паттерны получили статус чуть ли не священного писания, лишь за попытку критического осмысления которых следует подвергать анафеме, не говоря уже о преднамеренном пренебрежении ;)
Сейчас вот что-то подобное происходит по отношению к Semantic Versioning.
...чтобы выбросить пространство имен so_5::rt и отказаться от использования суффикса _t в именах типов. Ну и, заодно, перейти на C++14, отказавшись от поддержки старья, вроде VC++12.0.
Правда, боюсь, тогда SO-5 перестанут использовать даже в тех редких проектах, где он еще используется :(
Тем не менее, буду признателен читателям, которые в комментариях укажут, какой из двух приведенных ниже фрагментов кода выглядит более привлекательным и/или простым в восприятии:
Походу, сказав "А", нужно сказать и "Б". Правда, из-за того, что уже давно никаким боком не связан с системой образования, не берусь судить, насколько изложенные ниже мысли соответствуют современным реалиям.
Клюнул на множество хвалебных отзывов и начал таки читать "Бизнес в стиле фанк".
Пока ощущение такое, что не дочитаю. Дотерплю до 101-й страницы и, если все будет продолжаться в таком же духе, брошу нафиг.
Полагаю, у подкаста DevZen довольно-таки широкая аудитория в Рунете, хотя сам я его не слушаю, впрочем, как и другие подкасты. Но если доводится послушать кусок этого подкаста, то просто оторопь берет. Так было в прошлый раз. Так произошло и сегодня, когда что-то дернуло меня прослушать кусок подкаста 0067 (где-то с пятидесятой минуты, когда речь зашла про обучение C++ и ООП).
...на невозможность просто так поменять эти решения.
Известный в Рунете автор блога eax.me и один из ведущих подкаста DevZen, Александр Алексеев, ищет интересную работу бэкенд-разработчика высоконагруженных систем. Москва. Список страшных слов такой: C/C++, Python, Scala/Java, Akka, Erlang, PostgreSQL, MySQL, Cassandra, RabbitMQ, AWS.
Связаться с Александром можно по мейлу: mail@eax.me
Необходимое дополнение: сам я лично, к сожалению, с Александром не знаком. Однако, в течении последних пары лет время от времени общаюсь с ним в комментариях к блогам и в личной переписке, где он произвел на меня впечатление очень адекватного и широко эрудированного человека. Способного спорить не переходя на личности, прислушиваясь при этом к аргументам оппонента и, что немаловажно, обстоятельно, понятно и доступно объясняя свою собственную точку зрения. Что, на мой взгляд, встречается далеко не часто.
В комментариях к одной из предыдущих заметок была затронута тема использования указателей (как умных, так и "голых") и ссылок в качестве параметров методов/функций в C++. Тема эта не простая, сдобренная изрядной долей вкусовщины и legacy-подходов. Тем не менее, можно вскользь по ней пройтись.
Состоялся релиз версии 5.5.12. В этой версии исправлена проблема с производительностью операций подписки/отписки агентов на local_mbox-ы в случае, если для одного типа сообщения оказывается большое количество подписчиков. Эта проблема возникла в результате модификации логики работы local_mbox-ов некоторое время назад и обнаружилась она вскоре после релиза версии 5.5.11.
Вчера более-менее четко оформилась мысль, бродившая в голове уже несколько недель. Попытался ее зафиксировать под катом. На мой взгляд, msg_stream может не только упростить интеграцию частей приложения, написанных на SObjectizer и без него. Но и оказать влияние на разработку SObjectizer-овских агентов.
По катом небольшой пример того, как C++ные шаблоны и лямбда функции позволили избавиться от копипасты и, надеюсь, упростили дальнейшее сопровождение кода. Желание показать этот пример появилось после прочтения вот этого комментария в обсуждении свежего выпуска подкаста DevZen.
Вчера полдня прикидывал, как можно реализовать хитрый контейнер для хранения упорядоченных по ключу данных. Чтобы при малом количестве элементов данные хранились в vector-е, а при большом -- в set-е или map-е. Но чтобы наружу выставлялись обычные итераторы (или их жалкие подобия), дабы пользователь такого контейнера мог вызвать, скажем, for_each(begin(c),end(c)) и не думать о том, будут ли итерироваться элементы vector-а или set-а. Появилось пару соображений, как это сделать на основе union-ов. Сейчас сел писать тестовый прототип...
И тут до меня доходит, что в MSVS2013 нет поддержки т.н. descriminated unions. Т.е. для VC++12.0 все, что я придумал, не реализуемо. В принципе :(
В общем, с большим удовольствием в январе 2016-го откажусь от поддержки этого компилятора. А оставшиеся полтора месяца нужно как-то дотерпеть :)
C++ -- это гибридный язык, он поддерживает несколько стилей(парадигм) программирования. Что при проектировании отдельных кусков программы заставляет делать выбор в пользу одного или другого стиля. В частности это касается полиморфизма: будет ли код использовать run-time полиморфизм или же compile-time.
Состоялся релиз версии 5.5.11. В этой версии закончено изменение диспетчеров, начатое в версии 5.5.10. Теперь для любого диспетчера можно указать, какой тип объекта синхронизации должен использоваться очередями сообщений этого диспетчера.
Состоялся релиз версии 5.5.10. В этой версии реализована всего одна новая вещь: возможность указать, какой тип объекта синхронизации должен использоваться MPSC очередями сообщений.
Мы тут посовещались и я решил, что схема релизов для новых версий SO-5.5.* несколько изменится. Вместо того, чтобы делать большие релизы раз в два-три месяца с помпой и фанфарами, будем тихо и незаметно выпускать новые версии так часто, как это будет получаться. Т.е. сделали новую фичу -- выкатили новую версию. Исправили проблему -- выкатили новую версию. Не важно, сколько прошло времени с прошлого релиза: если неделя, то неделя, если месяц, то месяц.
В связи с этим на SF.net будет выкладываться всего три архива: zip-файл с полными исходниками, zip-файл с бинарниками для x86 и zip-файл с бинарниками для x86_64. Бинарники будут собираться MSVS2015 (т.е. VC++14.0). Если кому-то нужны другие типы архивов (со сгенерированной doxygen-ом документаций или бинарные сборки для MSVS2013 (т.е. VC++12.0), то дайте знать. Собрать и выложить их не проблема, если это кому-то нужно.
Больших анонсов на профильных форумах так же не будет. Максимум -- это обновления для уже начатых тем.
Ближайший релиз, версии 5.5.10, если все будет нормально, состоится завтра или послезавтра. А потом, еще через несколько дней, релиз версии 5.5.11.
Пока читал на OpenNet-е про выход Pyston 0.4 подумалось, что подобная тенденция, возможно, является ответом на периодически озадачивающий меня вопрос. Вопрос этот возникает когда начинаешь думать, почему же в мейнстриме сейчас так широко используются динамически-типизированные языки программирования, которые, скажем так, имеют весьма высокие накладные расходы.
Дизайн std::condition_variable в C++11, как по мне, продиктован интересной смесью POSIX-овских стандартов и C++ной идиомы RAII. Из-за этой смеси метод condition_variable::wait требует не std::mutex, а std::unique_lock<std::mutex> (тогда как в POSIX функция pthread_cond_wait получает мутекс напрямую).
Подход C++11 удобен в подавляющем большинстве случаев, т.к. wait нужно вызывать под уже захваченным мутексом, а захват мутекса unique_lock-ом -- это эффективно, просто и безопасно. Но вот довелось оказаться в несколько необычной ситуации: потребовалось задействовать condition_variable::wait() в отсутствии unique_lock-а. Тут-то и столкнулся с собственной тупизной и, отчасти, законом дырявых абстракций... :)
Никогда раньше с таким применением умных указателей не сталкивался, но забавная тема на LOR-е показала, что стандартные умные указатели легко могут использоваться не только для уничтожения объекта, но и для возврата объекта в тот пул объектов, из которого объект был взят.
Суть проблемы: есть пул объектов типа T, объект берется на какое-то время из пула, а когда объект становится больше не нужен, он должен вернуться обратно в пул. Причем пулов в программе может быть много. А код, который использует взятый из пула объект, ничего про пул не знает, но объект должен вернуться в тот пул, которому принадлежит. При этом гарантируется, что пулы живут долго, так что о той проблеме, что пул будет разрушен раньше, чем в него вернут все взятые ранее объекты, можно не беспокоится.
A version 5.5.9 of SObjectizer core is released!
In short the changes in 5.5.9 are:
The sixth part of "Dive into SObjectizer-5.5" describes synchronous interaction between agents:
This presentation is also on SlideShare.
The seventh part of "Dive into SObjectizer-5.5" describes message limits:
This presentation is also on SlideShare.
All parts of "Dive into SObjectizer-5.5" can be found here.
Вчера вечером, когда подготовка к релизу очередной версии SObjectizer-а не просто вышла на финишную прямую, а уже почти подошла к самой финишной черте, всплыла серьезная ошибка. Суть в том, что у каждого агента есть свой собственный direct_mbox. Этот direct_mbox представляет из себя что-то вроде хитрого прокси через который сообщения доставляются агенту напрямую. Важнейшим свойством direct_mbox-а должна была быть возможность корректно обрабатывать ситуацию, когда сообщение отсылается агенту, а агента уже и нет, он закончил свою работу и был уничтожен ранее. Так вот внезапно оказалось, что это свойство не работает! Т.е. в direct_mbox-е остается повисший указатель, при обращении к которому может происходить все, что угодно: от зависаний до крахов приложения.
Очевидно, что в процессе переделок реализации direct_mbox-ов и агентов, коих было не так уж и мало, вышеозначенное важнейшее свойство было утеряно. Но почему это не было отловлено ни одним из тестов (коих сейчас уже больше 170)? И вот тут-то выяснилась интересная история :)
Глянул краем глаза RSDN-овское обсуждение такой прикольной штуки, как Intel Stick. Почему-то вспомнились две вещи.
Когда-то давным давно, лет 15 назад, был опыт защиты программы от копирования посредством хардварного ключа Aladdin, цеплявшегося к одному из портов компьютера. Сейчас штуки вроде Intel Stick-а могут существенно упростить поставку программно-аппаратных комплексов заказчику, что называется, "под ключ". Какое-нибудь специализированное ПО для кассовых терминалов или рабочих мест банковских РКЦ. Особенно если в Stick-ах будет какое-нибудь встроенное хранилище криптографических ключей (какой-то аналог HSM-ов), то вообще круто.
Так же давно, лет 12 назад, а может и больше, сильное впечатление на меня произвела статья о том, как Google подходил к выбору компьютеров для своих дата-центров. Вместо ТОП-овых серверов они закупали дешевые морально устаревшие персоналки (помнится тогда писали о Pentium III, хотя у всех уже были машины с процессорами следующего поколения). Производительности Google достигал за счет распараллеливания вычислений на большое количество узлов, а не за счет мощности отдельных узлов кластера. Если попытаться сейчас представить Intel Stick-и в роли тогдашних Pentium III в Google, то рынок серверного хозяйства может ждать больших перемен. И, может быть, что-то интересно ждет и системы виртуализации, вокруг которых было много движухи в последние время...
К счастью, очень давно не смотрел на язык программирования D. А тут в рамках LOR-овского флейма потребовалось выяснить, какие аналоги C++ных умных указателей есть в D. И увидел прекрасный прототип метода refCountedPayload() в шаблоне std.typecons.RefCounted:
inout nothrow @property ref @safe inout(T) refCountedPayload() return;
Внимание, вопрос: при чем здесь тот самый Александреску? ;)
Две строки такого мощного в своей альтернативной одаренности потока сознания, что не утащить к себе для увековечивания просто нельзя:
Программирование заключается в порождении абстракций. Использование готовых абстракций, скажем, абстракций предоставляемых языком программирования, это не программирование. В этом смысле, секретарша, форматирующая текст в M$word — тоже программистка, только специфика другая.
Upd. Сообщение с LOR-а выпилили, но оно было фееричным.
PS. Почему-то мне кажется, что таких персонажей в софтостроении будет все больше и больше.
Просто в качестве небольшого статус репорта: первый релиз-кандидат новой версии SObjectizer-а зафиксирован в виде тега. Список изменений описан в Wiki. Осталось подготовить пару-тройку презентаций и можно будет делать релиз. Надеюсь, к 29-му октября получится.
В версии 5.5.9 будет несколько "вкусных" вещей, вроде возможности использовать произвольные типы в качестве типов сообщений. Плюс к тому, благодаря стараниям Алексея Сырникова SObjectizer теперь собирается и проходит тесты на MacOS, т.е. сейчас список поддерживаемых платформ выглядит как Windows, Linux, FreeBSD и MacOS. Что не может не радовать :)
Еще один очень простой пример использования возможностей современного C++ для сокращения объема "тупого" кода. На этот раз variadic templates были задействованы для того, чтобы упростить формирование похожих друг на друга строчек для последующего логирования.
Добавил трассировку механизма доставки сообщений до агентов в версию 5.5.9. По ходу дела пришлось решить одну задачку, которая может быть интересна сама по себе, безотносительно SObjectizer. А именно: как создать две слегка отличающися версии одного кода, но без его дублирования и без потери его эффективности.
При написании библиотек иногда сталкиваешься с такой ситуацией: есть некий публичный класс X с набором публичных методов (т.е. этот класс видит и использует пользователь библиотеки). Есть набор других классов в этой библиотеке, не важно публичных или нет, которые так или иначе используют класс X. Пока они работают только с публичными методами класса X, то все хорошо. Но что делать, если им требуется получить доступ к закрытой части X?
Наткнулся на фееричный фрагмент в рассказе об опыте использования Go в Яндексе:
В Go не может быть ошибок памяти, это сильно помогает, так как не всегда и не всем удается быть внимательным. У нас есть приложение suggest-data, оно при старте загружает в себя 300 мегабайт данных. Когда оно было написано на плюсах, то временами падало, что вызывало легкий дискомфорт у нашего админа. В первый раз когда оно падало, это было из-за фреймворка Кокаина. Это пофиксили, но потом падения продолжились, во второй раз мы до конца не разобрались в причинах, возможно, была проблема и в том, что мы что-то не так написали. В результате решили не заморачиваться и переписать его на Go (там было всего 200 строк кода). Падения сразу исчезли.
Честно скажу, не сразу осознал написанное. Программисты хваленого Яндекса, который славился жесткими методами отбора сотрудников, вроде как должны были бы быть разработчиками высокой квалификации -- и не смогли найти утечки в C++ной программе на двести (двести, Карл!) строк?!!
Блин, как такое возможно вообще?
А вот это: "возможно, была проблема и в том, что мы что-то не так написали"?
Возможно? Они еще спрашивают, возможно ли в этом была причина?
Честно скажу, после такого эпичный фэйл с перезапуском Кинопоиска начинает играть новыми красками.
Тут вот народ удивляется, что в C++ до сих пор нет writeln. Мол, C++ники вместо xs.writeln все еще кипятят используют std::copy(std::begin(xs), std::end(xs), std::ostream_iterator
Действительно, что-то вроде свободной шаблонной функции writeln, которая берет поток и объект-последовательность, и отображает все элементы последовательности в поток, не помешала бы. Но в стандартной библиотеке C++ нет столько всего полезного, что сожалеть об отсутствии writeln в голову как-то и не приходит.
Может быть потому, что написать writeln можно буквально с полпинка:
template< typename STREAM, typename SEQUENCE > void writeln( STREAM && to, SEQUENCE && what ) { using type = decltype(*std::begin(what)); std::copy( std::begin(what), std::end(what), std::ostream_iterator<type>(to) ); to << std::endl; } |
Под катом тестовая программка, на которой проверялась работоспособность.
В версии 5.5.9, которая сейчас находится в активной разработке, был сделан небольшой шаг, последствия которого сейчас сложно предугадать: может быть получится мегаполезная фича, может быть наоборот. Как бы то ни было, впервые за все время существования SObjectizer появилась возможность включить трассировку механизма доставки сообщений. Т.е. можно увидеть следы попадания сообщения в почтовый ящик, оттуда в очередь агента, затем итог поиска обработчика события у агента...
Раньше довольно обыденной ситуацией было отсутствие какой-либо реакции на сообщение: вроде бы все подписки сделал, сообщение отослал, а ничего не вызвалось. И что делать непонятно... Может агент не в том состоянии. Может подписка не на то сообщение. Может сообщение не в тот mbox ушло. Сиди и думай :(
Сейчас же можно при старте отдать в параметрах SOEnvironment объект-трассировщик, а потом по его выхлопу посмотреть, что и к чему. Понятно, что еще нужно тщательно дорабатывать напильником, но сам факт появления такой фичи не может не радовать :)
Продолжение предыдущего поста. Тогда была цель сделать минимальный, простейший рефакторинг. После ее достижения можно пойти дальше и сделать вариант в духе Modern C++ Overdesign, с преферансом и куртизанками. Т.е. с исключениями и RAII в полный рост :)
Ув.тов.asfikon в своем блоге eax.me ведет серию постов, посвященных изучению работы с OpenGL (вот самый свежий пост из этой серии). Для работы с OpenGL используется C++. Код живет на GitHub, где его можно посмотреть и пощупать руками.
Любопытства ради заглянул, глянул краем глаза. Код как код, очень простой, разобраться в нем труда не составляет. Смело могу сказать, что доводилось видеть намного более страшные образчики C++ного кода. Однако...
Именно 14 октября 1985-го года состоялся публичный релиз первого C++компилятора Cfront и вышла первое издание книги "The C++ Programming Language".
Так что можно сказать, что сегодня у C++ юбилей :) Тридцать лет. С чем и поздравляю Бъёрна Страуструпа и всех причастных! Да и непричастных тоже ;)
PS. Из этих 30 лет я сам пользуюсь C++ом уже 23 года, с 1992-го.
После написания заметки про фэйл с Кинопоиском еще лучше стало понятно одно из принципиальных различий разработки программного продукта силами своей команды и с привлечением аутсорсинга.
Найдено здесь:
Коммерчески успешная метамодель — это оксюморон.
Там весь комментарий фееричный. Причем, как обычно, особый стиль мышления демонстрируют анонимные герои LOR-а.
Для тех, кто не в курсе одного из самых громких скандалов Рунета последнего времени: 8-го октября состоялся запуск новой версии популярного сайта kinopoisk.ru. Новый сайт выглядел совершенно по-другому, старым пользователям Кинопоиска, особенно неискушенным компьютерным пользователям, искать нужную для себя информацию на новом сайте стало очень неудобно. Плюс к тому, в работе нового Кинопоиска наблюдались нестабильности. Такой внезапный поворот событий вызвал неслабый поток говн, в котором поучаствовал и основатель, Виталий Таций, высказавшийся кратко, но по делу. В итоге, Яндекс, а это нынешний владелец Кинопоиска, вернул в продакшен старую версию, а новую переместил на beta.kinopoisk.ru, где на данный момент можно лицезреть итоги двухгодичного процесса запуска новой версии.
Посмотрел слайды презентации Reactive Stream Processing Rx4DDS с конференции CppCon 2015. Любопытно.
World Grand Prix, один из самых суровых больших турниров в календаре PDC, дошел до самых интересных стадий -- полуфиналов. Можно поделиться некоторыми впечатлениями от увиденного (хотя три или четыре матча из прошедших посмотреть не довелось).
Пролистал презентацию про сопрограммы в C++ с конференции CppCon 2015... Есть у меня смутное подозрение, что с добавлением сопрограмм в C++ случится такая же фигня, как и с активным использованием JavaScript в Web-е: поначалу все хорошо, но со все большим проникновением в массы и с накоплением кодовой базы дела будут идти не так, чтобы уж очень. Для JS альтернатив почти что и нет, а вот писать на JS, да еще и сопровождать большой чужой проект на JS -- это, насколько я понимаю, то еще удовольствие. Чего-то подобного ожидаю и по отношению к сопрограммам в C++.
Раз уж начатая вчера тема получила большой интерес, можно сказать еще несколько слов на тему менеджмента. Классифицировать менеджеров можно по-разному. Одна из таких классификаций, определяющая с какими менеджерами проще строить взаимоотношения, приведена под катом. Построена, естественно, на основании собственного опыта и впечатлений людей, с которыми доводилось этот вопрос обсуждать.
То, о чем речь пойдет ниже, пройдено на моем собственном опыте. Насколько это характерно для индустрии разработки ПО в целом не могу судить. Тем не менее, если мне довелось столкнуться с этим, то не исключено, что подобные вещи актуальны и еще для кого-нибудь.
Чтобы было лучше понятно о чем речь, следует взглянуть на предыдущий пост, показывающий прогресс в развитии ветки 5.5 моего OpenSource проекта SObjectizer за год. Для меня важно подчеркнуть одну вещь, пусть даже это и выглядит самопиаром.
Ровно год назад, 29-го сентября 2014-го года, в рассказе о нововведениях в SO-5.5 был опубликован скриншот, демонстрировавший прогресс в написании документации к SObjectizer-5:
...мне не нравятся две вещи: необъективность (особенно проистекающая из незнания) и приверженность моде.
Когда кто-то говорит, что "svn говно" или "ни за что не пойду в контору, где используют svn", то очень хочется выяснить степень владения говорящим обсуждаемого инструмента. Поскольку довелось видеть случаи, когда:
В этом году еще ни разу не удавалось выбраться на этапы Кубка Гомеля по МТБ. Постоянно что-то мешалось: то простуда, то поездки куда-нибудь, то какие-то другие мероприятия. Но вот вчера все сложилось :)
Гонка была хитрой: пролог на одной локации, продолжение, в виде гонки преследования, уже на другой. Первоначально планировал побывать только на одной локации, но т.к. один из организаторов предложил подвести на вторую часть, то поснимал еще и там.
В итоге практически полностью забил две 16Gb карточки памяти и почти разрядил аккумулятор камеры. Фотографий получилось много, больше 300 штук (под "получилось" подразумевается отсутствие явного технического брака). Если есть желание, то их все можно увидеть вот в этом альбоме.
Здесь же я хочу показать несколько кадров, которые нравятся и дороги лично мне (можно сказать, избранное с гонки).
Несколько портретов кузнеца Дмитрия Андреева. Практически все снималось в полупостановочном режиме. Т.е. герой съемки занимался своим делом, мы общались, при этом я делал снимки, но не говорил, как встать, куда смотреть, что изображать. Чисто постановочных портретов всего два, если мне память не изменяет. При этом никакого колдовства со светом не было, свет из естественных источников, просто мне повезло с их расположением.
Все работы собраны вот в этом альбоме. Рекомендую посмотреть их именно там, распахнув на весь экран, т.к. маленькие фотографии не создают должного впечатления.
Съемка кузнеца за работой в настоящей кузнице -- это давнишная мечта. Теперь она воплощена в жизнь, но хочется еще :) С удовольствием бы поснимал другого мастера, в другой мастерской. Так что буду ждать удобной оказии. Если у кого-то есть знакомые кузнецы, расскажите им обо мне, плиз ;)
А еще очень бы хотелось в рамках проекта характерного портрета поснимать бармена за работой. Не знаю, чем вызвано такое желание, но вот хочется... :)))
Итак, вчера, в рамках проекта "характерный портрет в профессиональном интерьере" с удовольствием понаблюдал за работой замечательного мастера и очень интересного человека, кузнеца Дмитрия Андреева. Впечатления незабываемые, такое ощущение, что смотришь за каким-то происходящим наяву волшебством.
Дмитрий продемонстрировал кусок работы над топором. И практически полностью показал изготовление ножа (от куска стальной пластины до почти готового изделия). Наблюдать было так интересно, что временами я забывал про фотоаппарат и необходимость фотографировать происходящее.
Из того, что отснял в редкие моменты пробуждения от творящейся перед глазами магии, получилось два небольших альбома, которые можно посмотреть, кликнув по ссылкам:
Изготовление топора. |
Изготовление ножа. |
(фотографии внутри поста не размещаю, а даю ссылку на Google Photos альбомы т.к. лучше снимки смотреть в большом размере).
Приношу свои извинения тем читателям блога, которые ждут от меня материалов о программировании и разработке софта. В последнее время я чаще пишу о фотографии, а программизму уделяю меньше внимания. Тому есть два взаимосвязанных пояснения.
Погода просто порадовала. Теплынь, как летом. А лепота-то какая вокруг! :)
Но все это меркнет от магии настоящего кузнечных дел мастера. Прям волшебство какое-то, завораживает так, что снимать забывашь...
Фотографии еще нужно отфильтровать и обработать. Надеюсь, что-нибудь стоящее в этих развалах обнаружится. Хотя, уже очевидно, чтобы снять нормально кузнеца за работой и получить уникальные снимки, нужна не одна итерация (как в моем случае), а три, по меньшей мере: две уйдут на прикидки и только на третьей будет происходить осмысленная съемка. Так есть к чему стремиться.
Есть разные мнения на тему того, что же в фотографии является самым важным. Некоторые ставят на первое место свет: нет интересного освещения, значит нет фотографии. Некоторые говорят о сюжете. Некоторые -- о композиции. Все это, безусловно, важно. Но у меня к фотографии несколько другое отношение...
Несколько лет назад, когда я только-только начинал осмысленно осваивать азы цифровой фотографии, то смотрел на снимки в местных новостных изданиях как на фотоработы недостижимого для меня уровня. (В частности, вспоминается onliner, когда там был отдельный новостной раздел по Гомелю, а так же ресурсы некоторых городских газет). Прошло два или три года и на большинство фотографий в тех же изданиях (подозреваю, снятых теми же людьми) уже просто невозможно смотреть.
Одной из ключевых возможностей SObjectizer-5, которой не наблюдается у аналогов вроде C++ Actor Framework и Just::Thread Pro, является возможность запустить несколько независимых друг от друга экземпляров SObjectizer Environment внутри одного приложения. Грубо говоря, в CAF всего один ран-тайм на приложение, а в SO-5 таких может быть сколько угодно.
Важность такой фичи была хорошо прочувствована на собственной шкуре еще во времена SObjectizer-4, в котором ран-тайм был как раз один-единственный на приложение. Мы тогда сделали пару прикладных библиотек для заказчиков. Снаружи был обычный C++, а вот в потрохах, глубоко упрятанные от пользователя, работали агенты SO-4. Было удобно: мы легко пишем многопоточный код, клиенты ничего не знают про SObjectizer. Но эта благодать продолжалась не очень долго...
Упрятанный под кат текст появился под влиянием недавнего обсуждения в FB и свежей заметки ув.тов.kaa.python. Тема "правильного" инструмента для достижения успеха у программистов очень актуальна. Была актуальна в прошлом, является актуальной сейчас и вряд ли утратит актуальность в будущем. Так что можно сказать на эту тему пару слов.
Если не ошибаюсь, когда-то Бьёрн Страуструп высказался в том духе, что разрабатывать софт на C++ очень сложно, если нет готовых прикладных библиотек. Но зато очень просто, если таковые библиотеки имеются. Как человек, который очень много попрограммировал на C++, могу только подтвердить правильность этого высказывания. Однако, самый интересный вопрос таков: а откуда такие прикладные библиотеки возьмутся?
За последние месяц-полтора довелось много чего обдумать касательно фотографии. Какие-то мысли плотно засели в голове и провоцируют очередной приступ графомании дабы быть выплеснутыми на читателей. Пара последних фотосъемок настолько усилили это желание, что сдерживаться уже нет мочи :) Так что, если кому-то интересен поток сознания на фотографическую тему, то милости прошу под кат...
Вход на площадку фестиваля "Мiнск Старажытны" происходил через контрольно-пропускные пункты с довольно серьезным шмоном всех посетителей. Сумки полностью досматривались, зонтики нужно было открывать, фотоаппараты включать, делать тестовый снимок и показывать его сотруднику милиции (хорошо, что я не снимаю на пленочный средний формат), сами посетители фестиваля прощупывались (тщательно, но без фанатизма).
В минувшее воскресенье в Гомеле проходила очередная выставка собак. Попытался пофотографировать. Но толком ничего не получилось, съемка была самой неудачной за все время походов на такие мероприятия.
Отчасти помешало очень плохое освещение, даже на f=2.8 ISO приходилось задирать до 3200 и выше. На f=3.5 светочувствительность поднималась даже до 5600 :( В общем, с фотографической точки зрения настоящий экстрим. Плюс еще в этот раз работало всего два ринга, а не три, как на предыдущих выставках. Поэтому около рингов собирались большие толпы участников и выискивать что-то интересное при такой скученности было совсем непросто. Даже когда на глаза попадалась какая-то интересная сценка, как правило, не было возможности зайти с нужной стороны, чтобы снять ее с хорошего ракурса. В общем, одно растройство. Но опыт, тем не менее, ценный.
Все более-менее получившиеся кадры собраны в этом альбоме. Приятного просмотра!
Закончил выбраковку и обработку фотографий с фестиваля реконструкторов "Мiнск Старажытны". Под катом несколько фотографий, которые больше всего нравятся лично мне и ссылка на полный альбом. А пока же позволю себе несколько слов.
Я не ставил целью сделать повествовательный фоторепортаж. Такого рода репортаж со внятным рассказом и сопуствующими рассказу фотографиями с осмысленным сюжетом и приличным качеством -- это серьезная и трудная работа. Думаю, что такую работу должны делать профессионалы на профессиональной основе. Поскольку я таковым не являюсь, то снимал то, что интересно мне. Ну и так, как мне на данный момент позволяет мой фотографический уровень. Поэтому, если по моим снимкам кто-нибудь не сможет получить нормального впечатления об этом замечательном мероприятии, то приношу свои извинения. Прошу не стрелять в пианиста, снимаю играю как умею.
Так же у меня есть предложение к реконструкторам, если таковые будут вдруг читать данный пост: я слышал, что есть закрытые фестивали, куда публика и зрители не допускаются. Но мне очень хотелось бы туда попасть и поснимать реконструкторов в более спокойной обстановке, без толп посетителей и очередей к наиболее харизматичным личностям для селфи. Может поможем друг другу? Я с вашей помощью попадаю на такой фестиваль, а вы получате сделанные мной фотографии? Безвозмездно, естественно, т.е. даром :) Если, конечно, уровень моих работ вас устраивает.
Итак, несколько снимков, которые больше всего нравятся лично мне. Хотя это мое личное мнение, никому его не навязываю :)
Из вчерашней поездки в Минск привез две карточки, которые не имеют особой ценности без небольших связанных с ними историй.
C++11 упрощает проведение различных проверок в компайл-тайм. Тут и замечательный static_assert, и std::enable_if, да и старые добрые шаблонные трюки в наличии. В C++17 еще и концепты подтянут, вообще веселуха начнется :)
Временами складывается ощущение, что я уже перешел границу своих умственных возможностей и если меня попросят, то объяснить смысл и принцип работы некоторых фрагментов кода я уже не смогу :)
Под катом малюсенький кусочек современного C++ для иллюстрации...
Вопрос к уважаемым читателям: поделитесь, плиз, ссылками на Интернет-магазины, в которых можно купить кухонные ножи нормальных производителей с доставкой в РБ по почте.
Давеча в Минске в одном из магазинчиков мне попробовали продать нож Arcos стоимостью ~25EUR за 70EUR. Собственно, теперь разыскиваю возможность купить такой же или похожий через Интернет, но за нормальные деньги.
Известные мне магазины, с которыми проблем нет:
knifeworks.com, в США. Доставка к нам обычной почтой, но быстро. Для доставки в РБ стоимость покупки должна превышать 100USD.
JapaneseChifsKnife.com, в Японии (соответственно, выбор только из японских ножей, а там своя специфика). Доставка к нам через EMS всего за 7USD.
Еще недавно нашел cuchilleriaalbacete.com. Испания, большой выбор, нормальные цены. Пишут, что доставляют по всему миру. Но при оформлении заказа в списке стран РБ не оказалось :( На вопрос по почте пока не ответили. Поэтому не понятно, как делать заказ в РБ и какой службой доставляют (ориентировочная стоимость доставки 25EUR, что наводит на мысль о курьерских службах, а это дополнительные 10-15EUR + головная боль уже внутри РБ).
По катом несколько мыслей, додумать которые до отдельных постов не получается, как и не получается полностью выкинуть из головы... :)
С момента рождения SO-5 и до вчерашнего дня все отсылаемые в SObjectizer-5 сообщения должны были быть наследниками специального базового класса message_t. Даже если в сообщении нужно было передать всего один int, все равно нужно было делать наследника message_t, например, my_int_msg, и передавать этот int внутри экземпляра my_int_msg.
Около года назад, при очередном анонсе SO-5 на каком-то из профильных форумов был большой наезд на нас: мол, что за фигня? В CAF вообще все что угодно пересылать можно, а у вас такие жесткие ограничения. Полагаю, тогда я так и не смог объяснить необходимость наследования от message_t. И, возможно, это требование отвернуло от SO-5 кого-то из потенциальных пользователей. Но все течет, все изменяется...
Что-то в последнее время попадаются на глаза удивленные возгласы вида "Как, вы используете C++? Но зачем?" Причем, как я понимаю, задают их те, кто на C++ никогда ничего толком не писал, не внедрял и не сопровождал. А может и вообще не видел.
Поэтому, как мне кажется, от незнания предмета возникает неверное восприятие реальности. Откуда и происходит непонимание и подобные удивленные возгласы. Попробую высказать свое мнение о том, когда C++ является нормальным выбором в качестве основного языка разработки.
This presentation is also on SlideShare.
В процессе подготовки презентации о таймерах в SO-5.5 описываю три способа отсылки отложенного сообщения. Может показаться, что для такой элементарной операции целых три способа -- это перебор. Однако, они возникли не просто так и для каждого есть случаи, когда этот способ востребован на практике.
Осознавая это убеждаюсь, что пришедшая на днях в голову аналогия вполне имеет право на жизнь...
A version 5.5.8 of SObjectizer core is released!
In short the changes in 5.5.8 are:
В рамках подготовки релиза SO-5.5.8 написал небольшой FAQ на русском языке.
Вроде бы основные моменты осветил. Если будут какие-то вопросы/замечания/дополнения/критика, то они всячески приветствуются.
Совершенно неожиданное продолжение серии характерных портретов в профессиональном интерьере. Вот такого необычного и колоритного уличного музыканта встретил сегодня в парке Гомеля. Я уже уходил и мне еще нужно было заскочить в пару мест, но что-то дернуло, задержался, сделал несколько кадров. Несколько из них хочу предложить вашему вниманию (кто не хочет заглядывать под кат, можно зайти сразу в мини-альбом).
Поскольку данная тема всплыла, то ознакомился со статьей "Don't use Actors for concurrency", на которую давали ссылку.
...все-таки нравится мне намного больше, чем Москва.
Хотя сегодня он произвел впечатление выжженного Солнцем, задыхающегося от жары и пыли города. Впрочем, рассмотреть ничего не удалось, успел лишь заскочить в пару мест и на паровоз до дому.
PS. Подержал в руках японские ножи Yaxell. Женщина-продавец прям расцвела, когда узнала, что очередной посетитель в курсе, что это такое :) Ножи, конечно, классные. Но ручки для меня маловаты :(
Подготовка к релизу версии 5.5.8 вышла на финишную прямую. Не все, что хотелось включить в релиз, удалось полностью продумать. Но то, что удалось продумать, уже сделано и оттестировано (кстати говоря, если прогонять каждый тест по тысяче раз подряд, то можно обнаружить очень древние и очень неожиданные баги).
Теперь предстоит самая кропотливая и весьма изнурительная работа: документирование и подготовка, как минимум, двух презентаций. Документация уже полезна даже мне самому, т.к. многие вещи тупо забываются, поэтому некоторое внимание будет уделено и doxygen-комментариям к уже давно существующим классам/методам/функциям.
Если все будет нормально, то к середине/концу следующей недели релиз может состоятся, а релиз-кандидат может быть получится сделать даже в конце текущей недели. После чего начнется работа над 5.5.9. Именно над 5.5.9, а не над 5.6.0, т.к. нарушать совместимость очень не хочется и при добавлении новых фич приоритет отдается тем, которые совместимость не ломают. Поэтому старт работ над линейкой 5.6 стараюсь по мере сил отодвигать как можно дальше.
PS. Самая же изнуряющая часть работы -- это публичные анонсы релизов :)
В банках сегодня просто невероятный ажиотаж. Мало того, что куча народу стремится в последний момент оплатить коммунальные. Так еще и резкий скачок доллара и евро.
Все это очень сильно напоминает конец прошлого года. А возможно, и лето 2011-го...
PS. А вот, например, цены на электронные версии книг в РФ как были в рублях, так и остаются. Так что если инвестировать средства в развитие самого себя, то сейчас не самая плохая возможность для этого. Имхо, конечно :)
На мой дилетантский взгляд GCC всегда поддерживал C++ные шаблоны лучше и строже, чем VC++. Но вот наткнулся на ситуацию, когда GCC 4.9.2/5.1.0 отказывается компилировать код, который успешно проглатывают MSVS2013, MSVS2015, clang 3.4 и 3.6. При этом GCC 5.2.0 уже воспринимает этот код нормально.
Upd. Найден случай, когда все проглатывается.
Внезапно узнал, что этой осенью ожидается выход двух новых альбомов у очень любимых мной музыкантов.
18 сентября свой очередной сольный альбом выпускает Девид Гилмор. Заглавная композиция Rattle that Lock уже доступна для ознакомления.
А 16 октября должен выйти новый альбом Жана Мишеля Жарра. Несколько композиций из него есть на YouTube. Самая забойная, имхо, Stardust, навевает воспоминания об одном из самых сильных альбомов Жарра -- Chronologie. Более-менее ничего слушается и Conquistador. А вот в Zero Gravity, сделанной совместно с Tangerine Dream слишком много от Tangerine Dream :)
В общем, жду с нетерпением.
PS. Оба музыканта уже давно пенсионеры, если брать по советским меркам. Жарру буквально через пару дней стукнет 67, Гилмору уже 69. Как по мне, так это просто чудо, что они еще выдают что-то новое, да еще и приличного качества.
PPS. А ведь в следующем году исполнится 40(!) лет эпохальному альбому Жарра "Oxygène".
...может быть уже пора отвязывать SObjectizer от Actor Model?
Под катом тяпничный пятничный поток рефлексии на тему того, хорошо или плохо плотно ассоциировать SObjectizer с Actor Model, зачем вообще в SObjectizer-е нужны диспетчеры, как это влияет на производительность... Ну и вообще о том, зачем все это и куда все это движется.
Для демонстрации нового диспетчера, в котором приоритеты агентов используются для раздачи квот на количество обрабатываемых за один раз событий агента, в SO-5.5.8 добавлен новый пример. Пример получился довольно большим, около 800 строк. Мне этот пример кажется простым и понятным. Ну да, всего 800 строк простого и понятного кода ;)
Но вдруг это не так для сторонних наблюдателей?
Если кому-то интересно, то код примера с небольшими пояснениями размещен под катом. Любые замечания/предложения/соображения/идеи приветствуются. Сам я готов дать любые пояснения и разъяснения. Если получится обсуждение и пример в итоге станет лучше (компактнее, понятнее, выразительнее), то это будет просто очень круто и здорово.
Прослушал очередной мастер-класс в виртуальной школе "Profile". На этот раз это был мастер-класс Александра Света "Профессия -- коммерческий фотограф", на котором Александр делился знаниями о том, что же это такое -- заработок себе на жизнь фотографией.
Не прошло и полугода с момента предыдущей демонстрации того, как шаблоны C++ могут избавить от дублирования кода, и вот появился совсем свеженький пример. Как обычно, сначала был написан один простой класс. Потом из него был сделан еще один простой, но чуть-чуть другой. Потом еще один и т.к. В какой-то момент захотелось эту порочную практику прекратить. К тому же стало лучше понятно, как это сделать.
Совсем небольшое bug-fix-обновление SO-5. В версии 5.5.7.1 исправлена очень древняя ошибка, которая жила в коде, как минимум, с мая 2013-го. А скорее всего и того больше. Эта ошибка в очень специфических ситуациях могла приводить к краху приложения при вызове environment_t::stop(). Насколько мне известно, в дикой природе это баг не встречался :) Тем не менее, раз попался на глаза, то был отслежен и отловлен :)
Версия 5.5.7.1 может быть взята из Svn, из Git, или загружена с SourceForge.
PS. А вы внимательно читали документацию к std::condition_variable::wait? ;)
PPS. Работы над 5.5.8 идут полным ходом, без выходных и проходных :) Хотелось бы успеть сделать релиз к концу августа. Но не факт, что успею.
Начал было писать ответ к комментарию в предыдущей заметке. Но подумал, что имеет смысл вынести этот текст наверх.
Есть в инженерном деле какая-то магия. Она особенно ощущается когда в итоге разработки получается что-то работающее. Именно работающее, а не статичное.
Впервые за фиг знает сколько времени сделал пример, отсылающий к старым-добрым временам, когда имел какое-то отношение к задачам АСУТП. Пример простенький и к реальности имеющий далекое отношение, но вспомнить молодость приятно.
Пример имитирует управление примитивными станками (machine), в которых есть двигатель (engine) и система охлаждения (cooler). Работающий двигатель нагревается. Когда нагревается выше 70 градусов, то включается система охлаждения. Если после этого двигатель продолжает нагреваться и его температура достигает 95 градусов, то двигатель отключается. Когда двигатель охлаждается до 50 градусов, он включается вновь. Система охлаждения отключается если двигатель охлаждается до 50 градусов (при этом двигатель может быть как включенным, так и выключенным).
В примере имитируется работа четырех таких машин. Каждая машина сообщает о своем состоянии и параметрах пять раз в секунду. Эта информация анализируется и, если нужно, предпринимаются управляющие действия (отсылаются команды на включение/выключение двигателя и/или системы охлаждения). Так же раз в полторы секунды текущее состояние машин отображается на консоль... И вот за этими-то бегущими циферками я могу смотреть чуть ли не десятками минут напролет :)
Вероятно, на следующей неделе (во вторник или в четверг) придется посетить город-герой Минск с рабочим визитом. Есть ощущение, что где-то к 14:00 со своими делами я разберусь. А далее дилемма: либо уезжать поездом в 15:47 и трястись в нем 4.5 часа, либо же поездом в 18:08, который идет всего 3.5 часа. Сидеть в поезде лишний час не прельщает, посему возникает вопрос:
А как в будний день в Минске можно употребить с толком и пользой 3-3.5 часа свободного времени?
В принципе, если кого-нибудь из читателей интересует то, чем я занимаюсь или занимался, то можно было бы организовать что-то вроде встречи-семинара на какую-то заданную тему. Например: нужно ли идти из программиста в менеджеры, когда это делать и что ждет на этом пути? Или же: SObjectizer и C++ -- зачем все это нужно и стоило ли оно того? Или: как организовать дартс-клуб на своем рабочем месте? Или: как разорить друга, подарив ему зеркалку... :)
Уже неоднократно говорил, что C++11 -- это совсем другой язык, нежели C++98/03. Если же появляется возможность использовать C++14, то это еще более другой язык. Под катом свежий пример.
Год назад, когда в версии 5.3.0 появились ad-hoc агенты (агенты, для которых не нужно было описывать отдельный C++ класс), область применения таких агентов казалась очень узкой. Поэтому и функциональность, доступная в ad-hoc агентах, была меньше, чем в обычных, полноценных агентах. По-началу даже не было возможности получить доступ к direct_mbox-у ad-hoc агента.
Но время идет, накапливается собственный опыт, анализируется то, что есть в других фреймворках. И ad-hoc агенты по своей функциональности постепенно догоняют полноценных агентов. А по удобству, наверное, где-то уже и сильно их превосходят. Под катом небольшой пример. Слева т.н. полноценный агент, написанный в классическом стиле. Справа -- это полный аналог, но оформленный в виде ad-hoc агента.
Столкнулся с одной из самых больших проблем в программировании -- выборе хороших идентификаторов. В этот раз сильно столкнулся, самостоятельно справится не получается, нужна помощь :)
Изначально предполагалось, что в очередной версии SO-5 будет всего один диспетчер с поддержкой приоритетов, который будет запускать все события на одной рабочей нити. Отсюда и появилось название prio::common_thread.
Но теперь дело идет к тому, что будет целых три диспетчера с поддержкой приоритетов агентов:
Все эти диспетчеры будут внутри пространства имен so_5::disp::prio.
Но вот хорошие имена для них никак не придумываются. В голове крутится что-то вроде one_thread_vip_first (blocked, women_and_child_first, highest_first), one_thread_quoted (round_robin, proportional), thread_per_prio (separate_threads, dedicated_threads)...
Может кто-нибудь из читателей поможет? Или подтолкнет в каком-то направлении?
Данная заметка может рассматриваться как дополнение к предыдущей статье о приоритетах обработки событий и связанных с этим сложностей. Сегодня речь пойдет о том, в каких сценариях можно использовать различные типы обслуживания событий с разными приоритетами.
Заходим на сайт Highload Dev Conf. Вроде все по-русски. Выбираем English...
Начало истории здесь. Сегодня посылку получил. С доставкой на дом.
В поисках обзоров компактных видеокамер наткнулся на YouTube на несколько роликов, очень, на мой взгляд, полезных пытающихся приобщиться к жанру street photo любителей. По моему глубокому убеждению, в 99% случаев уличная фотография -- это убогие попытки преобразовать количество в качество. А размещенные под катом ролики как раз таки и показывают, чем удачный street photo отличается от неудачного.
Под катом несколько соображений на тему приоритетной обработки событий агентами (сообщений акторами, если оставаться в рамках actor model). Надеюсь, эти соображения будут интересны не только тем, кто следит за развитием SObjectizer, но тем, кто вообще интересуется построением систем на основе очередей сообщений.
Тема про выбор беззеркалки внезапно изменила свое русло в сторону Fujifilm x30 :)
Причиной тому стал уникальный момент, которому я стал свидетелем вчера вечером в парке Гомеля: впервые в жизни наблюдал за тем, как кот пытался охотиться на белку.
С каждым годом все сложнее и сложнее становится переключаться между стадиями разработки софта: все труднее переходить от маркетинга (что и почему включать в релиз?) к проектированию (что и как будет реализовано?). И уже совсем тяжко переходить от проектирования к кодированию. Ну а на подготовку документации и сопровождающих релиз материалов зачастую уже просто не остается сил и заниматься такими вещами приходится на характере.
В этот раз как-то совсем грустно. С проектированием еще более-менее разобрался. А вот строчки кода приходится из себя силой выдавливать. Наверное, это лишнее подтверждение того, что программизм -- это дело молодых.
Но, т.к. дело делать нужно, то придется на какое-то время отказаться от всяких побочных увлечений, приковать себя к рабочему месту на пару-тройку недель и таки выдать какой-то результат. И не какой-то, а как обычно: оттестированный и задокументированный.
Посему прячу фотоаппарат в шкаф, забываю про Lightroom и игнорирую все мероприятия, на которых можно было бы поупражняться в street photo. Что, к сожалению, означает, что я опять не попадаю на этап Кубка Гомеля по МТВ, а так же на соревнования по ловле рыбы на спиннинг с лодки. Действительно очень жаль, но каждая большая съемка -- это два, а то и три дня работы с фотоматериалом. Такого сейчас себе позволить уже не могу.
В общем, пора уходить с радаров. Тем более, что по каким-то неведомым для меня причинам, народ опять стал качать SObjectizer с SF.net. ХЗ чем это вызвано, но раз хоть какой-то интерес есть, то нужно продолжать долбить.
Прочел книгу Бо Бёрлингема "Великие, а не большие", фрагменты из которой я уже упоминал в блоге ранее. Впечатление, в общем, хорошие. Но некоторый осадочек остался :)
Давеча порефлексировал на тему разработки чего-либо творческого под заказ. Не суть -- фото, видео, живопись, дизайн интерьера или резьба по кости. Но обязательно творческое и обязательно из гуманитарной сферы (это важно, т.к. в технической сфере объективных критериев оценки результатов больше, вкусовщины же и возможностей сослаться на "я так вижу", гораздо меньше).
Интернет-магазин в Финляндии, в котором меня угораздило сделать покупку, выслал посылку не почтой, а UPS. Судя по UPS-ному трекеру, она уже в Минске. Так что теперь жду официальной бумажки с почты о том, что моя посылка дожидается растоможки на СВХ в аэропорту "Минск-2".
Собственно, сейчас главный вопрос в том, бабахаться с этой процедурой самостоятельно или же связаться с каким-то из таможенных представителей. Самостоятельная поездка в Минск и в "Минск-2" может выйти чуть дешевле по деньгам. Да и то не факт. А вот времени придется убить целый день.
Посему вопрос к тем, кто сталкивался с подобными вещами: имеет ли смысл связываться с таможенным представителем? Тем же UPS, Fedex, TNT, Белтаможсервис и иже с ними? И если да, есть ли такой таможенный представитель, у которого все необходимые бумажки можно было бы оформить у них в офисе прямо в Гомеле (вроде бы и у Белтаможсервиса и у UPS есть офисы в Гомеле, но работают ли они в таком режиме или нужно общаться с офисами в Минске?)
PS. О том, как происходит процедура растоможки самостоятельно я уже прочитал в Интернетах (из свежих статей толково выглядит вот эта). Но эти материалы хороши для тех, кто живет в Минске. Интересно, как подобные вопросы решаются в областных городах, в частности, в Гомеле.
Мой бывший коллега, Василий Воробьев, с которым мы долгие годы проработали в "Интервэйле", и вместе прошли огонь, воду и медные трубы, находится в поиске работы. Очень надеюсь, что мои скромные рекомендации помогут ему в этом.
В Интервэйл Василий Воробьев пришел когда в Гомельском филиале не было еще и десятка сотрудников. И он очень быстро, буквально за год-полтора, вырос из вчерашнего молодого специалиста до мега-эксперта, отвечавшего за такой важнейший фронт работ, как продукт "Мобильный банк", который компания внедрила в ряде банков стран СНГ (включая такие заметные, как Банк Москвы и Халык-банк).
С удовольствием представляю результаты очередной попытки снять характерный портрет в профессиональном интерьере. На этот раз замечательного мастера и очень обаятельного человека, резчика по дереву, Виктора Россолова.
Резчик по дереву Виктор Россолов любезно согласился на мое предложение о съемке характерного портрета в профессиональном интерьере. Была проведена почти трехчасовая фотосессия в мастерской Виктора. Материала получилось много. Как портретного, так и производственного, если можно так выразиться. Портретная серия пойдет отдельным постом. А здесь я бы хотел разместить две серии, снятые в процессе работы.
Все фото собраны в этом альбоме. Качество карточек там чуток повыше, но под катом есть немного сопроводительного текста.
Благодаря записи в чужом ЖЖ узнал, что идет Чемпионат Республики по ловле рыбы фидером. Снимал подобное мероприятие два года назад. В прошлом году прозевал. В этом так же мог прозевать, но повезло.
Вот в этом альбоме собрано несколько фотографий с турнира. Можно сказать, некоторые "картинки с выставки". Кому интересно, милости прошу заглянуть в альбом, там фото в формате 1920px по длинной стороне, надеюсь Google Photo сможет показывать их более-менее нормально.
PS. Мне показалось, что два года назад рыбы ловили больше и сама она попадалась крупнее. Сейчас вообще мелочь вытаскивали. Но тогда лов был организован в самом Соже, тогда как сейчас турнир проводился на гребном канале.
После нескольких часов прожаривания собственной туши под Солнцем на гребном канале (фоточки с соревнований по ловле рыбы фидером последуют позже) захотелось выпить пива. В связи с чем с внезапной проверкой нагрянул в недавно открывшийся паб "Гарри Портер".
Место уютное (да и расположено в местах, где я частенько играл в детстве), пиво отличное, кормят вкусно. Но зацепило, как это не странно, не это.
Интерьер паба отдаленно напомнил мне интерьер ресторана "Торро Гриль" в Москве рядом с м.Белорусская. Посему показалось, что когда на улице становится совсем темно, в "Гарри Портере" должно возникать совершенно шикарное освещение за счет светильников над столами. Было бы интересно пофотографировать там кого-нибудь.
Конечно, съемку придется вести на экстремальных ISO. Но в совокупности с антуражем крупное зерно от цифровых шумов должно создавать вкусную и настроенческую картинку. И, хотя постановочные портреты -- это совсем не мое, зарекаться все-таки не хочется, вдруг что-нибудь, когда-нибудь... А ну как получится снять, скажем, характерный портрет тамошнего бармена?... ;)
Очень важную вещь встретил в книге "Великие, а не большие". Интуитивно я подозревал что-то в этом духе. Но когда читаешь об этом в книге, то остается только недоумевать, почему же ты не мог узнать об этом раньше...
Совсем небольшое обновление SO-5. В версии 5.5.7 добавлена поддержка Visual Studio 2015 (теперь бинарники для Windows распространяются как для MSVS2013, так и для MSVS2015). А так же исправлена ошибка, которая могла приводить к передаче неправильной мониторинговой информации о количестве заявок в рабочих очередях диспетчеров one_thread/active_obj/active_group.
Версия 5.5.7 может быть взята из Svn, из Git, или загружена с SourceForge.
PS. Задержка с выпуском версии с поддержкой MSVS2015 была вызвана проблемами сайта SF.net. Приношу свои извинения.
PPS. Поскольку это минорное обновление широкого анонса данной версии на профильных ресурсах не будет. Однако, если кто-нибудь сочтет возможным поделиться этой новостью, то я буду очень признателен.
Mxx_ru обновился до версии 1.6.6. Добавлена поддержка Visual C++ v.14.0 (из состава Visual Studio 2015), что означает появление тулсета vc14. Этот тулсет может быть выставлен вручную в переменной среды MXX_RU_CPP_TOOLSET. Так же тулсет vc14 может быть определен автоматически есть переменная среды MXX_RU_CPP_TOOLSET не задана.
Установить Mxx_ru можно командой gem install Mxx_ru
Обновить Mxx_ru можно командой gem update Mxx_ru
Так же Mxx_ru можно загрузить с SourceForge (gem-файл и pdf-файл с документацией).
PS. Некоторая нерасторопность с реализацией поддержки vc14 была вызвана проблемами сайта SF.net. Приношу свои извинения.
Под катом маленький фрагмент из книги "Великие, а не большие". Об очень простых вещах. Очень простых. Но дающих поразительный эффект.
Начав читать книгу "Великие, а не большие" обнаружил одну из причин, по которой мне не удалось стать профессиональным управленцем:
Наконец, я заметил страсть, которую руководители привносили в работу. Они обожали свою специализацию, будь то музыка, предупреждающие сигналы, продукты питания, спецэффекты, шарниры с постоянным крутящим моментом, пиво, хранение документов, строительство, общественное питание или мода. Они были превосходными бизнесменами, но отнюдь не профессиональными управленцами — скорее их противоположностью. Они были сильно привязаны к компании и работающим в ней людям, ее клиентам и поставщикам; а такие чувства — гарантия провала для профессионального управленца.
Очередной World Matchplay закончился. Вполне ожидаемо победил Майкл ван Гервен. Можно было бы попытаться развить эту тему, но это будет всего лишь повторение того, о чем я говорил чуть меньше года назад по итогам World GradPrix 2014. Эпоха Тейлора закончилась. Эпоха ван Гервена наступила. Пока еще с некоторыми сюрпризами. Но, по большому счету, на ближайшие несколько лет все понятно. Если только не произойдет какого-нибудь форс-мажора.
Главные инструменты на данный момент -- бумага и карандаш. Бумаги стало чуть поменьше, часть записей с неудачными идеями уже утилизирована, оставшиеся листочки ожидают своей участи. В итоге останется всего 3-4 листочка с набросками, которые представляются удачными и реализуемыми.
Но это только проработка всего лишь одной из запланированных к реализации фич ;) На очереди еще несколько штук, на каждую из которых уйдет по полтора-два десятка исписанных и разрисованных листов бумаги.
На днях к своему стыду осознал, что имею очень поверхностное впечатление об Intel Threading Building Blocks. Т.е. понимание что и зачем было, но с самыми минимальными подробностями. Что не удивительно, т.к. к задачам parallel computing отношения не имею очень и очень давно.
Посему просмотрел официальный User Guide. Ну и что можно сказать по свежим, так сказать, следам?... ;)
Имхо, тему всяких там доморощенных RxCpp и прочих склепанных на коленке пайплайнов с самодельными таск-шедулерами, можно закрывать раз и навсегда.
Нет, конечно, можно поставить себе целью создать более дешевый аналог и пытаться отбирать себе долю рынка тупым демпингом по ценам. Только есть у меня сомнения, что это может окупиться с финансовой точки зрения.
PS. Показалось, что Intel TBB закрывает и часть проблем concurrent computing, так что в каких-то задачах flow graph-ы из TBB вполне смогут составить конкуренцию примитивным акторам.
Буду признателен, если читатели, которые пользуются при разработке софта моделью Publish/Subscribe и MQ-шными системами на ее основе, поделятся своими впечатлениями:
Что именно нравится в Pub/Sub? Может быть в используемой вами реализации Pub/Sub есть какие-то отличительные особенности, которые вам очень нравятся и упрощают вам жизнь?
Что не нравится? С чем приходится бороться и что раздражает?
Ну и если это не секрет, какие реализации Pub/Sub вы используете (с удовольствием или, напротив, с неудовольствием)?