Главные инструменты на данный момент -- бумага и карандаш. Бумаги стало чуть поменьше, часть записей с неудачными идеями уже утилизирована, оставшиеся листочки ожидают своей участи. В итоге останется всего 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 вы используете (с удовольствием или, напротив, с неудовольствием)?
Upd. Сделал себе новую инсталляцию ArchLinux, взяв за основу ISO-шку версии 2015.07. Так что свои проблемы с наличием Linux-а для тестов проектов я решил. Тем не менее, спасибо всем за рекомендации! Полагаю, они обязательно пригодятся в будущем.
Upd. Похоже, проблемы были из-за того, что я неправильно перезагрузил Linux после обновления. И что-то в образе диска потерялось. Загрузился с ISO-шного образа, выполнил fsck для /dev/sda1. После чего ArchLinux начал загружаться, но с сообщениями "Failed to start Load Kernel Modules". Как это исправить не знаю. После загрузки сеть не видит в упор.
Давно не запускал, решил обновить, дабы дистрибутив не был слишком древним. Предварительно обновил VirtualBox до 4.3.30. После чего загрузил ArchLinux, зашел под root-ом, выполнил pacman -Syu. Pacman отработал успешно, выкачав и установив кучу обновленных пакетов. Но при попытке перезагрузить Linux вот на этой стадии стал ломаться сам VirtualBox:
Откат на VirtualBox 4.3.28 или обновление до 5.0.0 картинки не меняет. Такое ощущение, что именно обновление в ArchLinux жестко ломает виртуалку.
При этом FreeBSD 10.1 под VirtualBox продолжает работать нормально (накатывать там обновления уже совсем стремно [Upd. pkg upgrade отработало успешно, проблем не возникло] :)).
Вот и фиг знает, что теперь с этим делать. В принципе, потерять этот ArchLinux не страшно, там нет ничего уникального, хотя радости это не принесет. Но тогда возникает другой вопрос: если данную VM спасти уже нельзя, то что имеет смысл взять вместо? Хотелось бы иметь готовый образ Linux-а под VirtualBox, но без X-ов и каких-либо KDE/Gnome/etc. Главное требование -- довольно оперативное появление в дистрибутиве новых версий GCC и Clang, т.к. Linux мне нужен просто в качестве хоста для тестов под GCC/Clang. Ну и чтобы обновление пакетов происходило с минимальным участием пользователя (как в Arch-е, запускаешь pacman, а он сам все делает).
Завершился первый этап World Matchplay 2015. Не удалось посмотреть всего два матча из 1/16-й, оба, судя по всему, были довольно интересными.
Завершение рассказа о том, как движется разработка версии 5.6.0. На этот раз речь пойдет о двух вещах, которые хотелось бы реализовать, но пока не понятно каким образом. Да и нужно ли...
Продолжение рассказа о том, как движется разработка версии 5.6.0. Данная часть посвящена такому аспекту механизма overload control, как автоматическое удаление самых старых сообщений.
С момента релиза версии 5.5.5, после чего, собственно и началась работа над версией 5.6.0, прошло чуть меньше двух месяцев. Из этих двух месяцев по тем или иным причинам выпало полторы или две недели. Но остальное время было направленно на работу над SObjectizer (включая, правда, и рассказы о возможностях SO-5 на профильных форумах, что так же оказывается трудоемким процессом). Первоначальных задумок для 5.6.0 было много. Но что из этого имеет шанс быть воплощенным в коде и в каком именно виде? Об этом речь пойдет в небольшой серии постов.
Таки старею, старею... Если бы лет пять назад кто-нибудь мне сказал, что буду сам, по своей воле, да еще и с удовольствием варить что-нибудь из ягод... Не поверил бы. А вот поди ж ты :)
Как раз тот случай, когда жалеешь, что фотография не передает запаха ;)
