Внезапно выяснилось, что мою недавнюю заметку про противопоставление исключений кодам возврата, обсуждают в свежем выпуске DevZen Podcast №45 (где-то с 37:10 до 54:00).
Размышления и впечатления, которые не хочется держать в себе. О программировании в частности. Ну и о творчестве, и о жизни вообще.
суббота, 13 июня 2015 г.
[prog.c++11.sobjectizer] Вынесу из комментариев про overload control
Про организацию overload control в агентных системах вообще и в SObjectizer-е сказано уже много. Но т.к. эта тема все еще остается актуальной и не разрешенной полностью (хотя вряд ли она может быть полностью разрешена), то возвращаться к ней приходится снова и снова. Под катом текущие соображения на этот счет, написанные в комментариях к одной из предыдущих заметок. Поскольку в комментариях их искать сложнее, то выношу в отдельный пост дабы не потерялись.
пятница, 12 июня 2015 г.
[prog.thoughts] Одна из сторон NIH-синдрома
Могу ошибаться, но думается, что с NIH-синдромом (т.е. Not Invented Here или велосипедостроением в просторечии) связана сильная отрицательная коннотация. Но многие ли критики NIH-синдрома задаются таким вопросом: если высмеиваются создатели маленьких велосипедиков, то откуда возникнут изобретатели больших новых систем/проектов?
Когда ТОП-менеджмент вызывает на ковер руководителей подразделений разработки и требует придумать что-нибудь, чтобы повысить производительность или снизить ресурсоемкость, повысить качество и т.д., поскольку на существующей технологической базе не удается снижать издержки и оставаться конкурентно способными, то кто, собственно, будет придумывать? Кто будет рожать идею, воплощать в жизнь и доводить до ума?
Менеджеры среднего звена? Архитекторы-астронавты? "Опытные" разработчики, которые всю жизнь следовали придуманным кем-то best practices? Нанятые со стороны консультанты?
Грустная правда состоит в том, что у NIH-синдрома не зря такая сильная отрицательная коннотация. Велосипедостроение -- это действительно не есть хорошо. Однако, без культивирования велосипедостроения не вырастить людей, способных придумывать, воплощать и доводить до ума. Так что все гораздо сложнее, чем показать пальцем и уничижительно сказать: "NIH-синдром!"
среда, 10 июня 2015 г.
[prog.flame] Пять копеек на тему error codes VS exceptions (С++ only!!!)
Специальный дисклаймер для читателей, которые пришли сюда по ссылке из DevZen Podcast №45. Все нижеследующее относится только к C++. Пожалуйста, не распространяйте написанные ниже высказывания на другие языки программирования.
К своему удивлению обнаружил в последнее время, что спор error codes или exception по накалу идиотии вполне может стоять в одном ряду с такими эпическими темами, как "tabs vs spaces", "canon vs nikon", "box vs karate" и т.д.
вторник, 9 июня 2015 г.
[prog.c++11] О планах по поводу delivery priorities и overload control для версии 5.6.0
Начал писать нижеследующий текст как ответ для LOR-а. Но, т.к. объем текста стал быстро расти, решил утащить его в блог, дабы иметь под рукой.
понедельник, 8 июня 2015 г.
[prog.c++11] Промежуточный итог экспериментов с конвейерами и реактивным программированием поверх SO-5
Эксперименты с реактивными программированием и выстраиванием обработчиков сообщений в конвейеры начались из-за обсуждения релиза SO-5.5.5 на LOR-е. То, что получилось на данный момент -- это чистой воды черновой proof-of-concept, который развивается как один из примеров в дистрибутиве SO-5. Каких-либо планов по включению pipelines в состав штатных средств SObjectizer пока нет. Более того...
воскресенье, 7 июня 2015 г.
[prog.c++11] Что-то торможу с интересным примером для конвейеров в SO-5
По мотивам недавнего сообщения на счет реактивного программирования поверх SObjectizer-5. Хочется в качестве иллюстрации предложить какой-то интересный и более-менее жизненный пример. И как раз с этим есть сложности...