[photo] По поводу анонса 50Mpx Canon Mark 5DS и 5DSR

Интернет уже пару дней бурлит, а я как-то пока еще и ничего не сказал. Не порядок :) Нужно исправляться.

[prog.flame.c++] А потом говорят, что C++ ущербный язык...

По следам недавней темы заглянул в кишки проекта disruptor-cpp. На первый взгляд, это калька Disruptor-а с Java на C++. Вроде как и сделанная нормально. Но, в то же время, хороший пример того, что не нужно делать в современном C++. И об этом чуть подробнее под катом.

[prog.humour] Two Haskell job postings in one day! Ну теперь уж точно мейнстрим! :)

[prog.flame] Microsoft Bond, а унутри у ней Haskell. Ахиреть, куда катится этот мир?!!!

Microsoft Bond, конкурент Google Protobuf и Apache Thrift. Для сборки транслятора bond-описаний в C++ или C# нужен Haskell! Не вру, ей богу:

In order to build Bond you will need CMake (2.8.12+), Haskell (ghc 7.4+ and cabal-install 1.18+) and Boost (1.54+).

Мля, когда я кому-то говорю, что для сборки C++ проекта нужен Ruby или Python, то мне, в принципе, обоснованно, замечают: "а ты не *банулся, часом?"

А тут даже не Ruby или Python, а Haskell...

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

Upd. Как оказалось, там Haskell-евского кода всего около 2K строк (1996 по показаниям cloc-а). Блин, даже если на C++ код в пять раз объемнее, транслятор был бы всего 10K строк. Ну, ёлки, это же совсем не о чем.

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

[prog.question] А кого-нибудь в C++ мире интересуют Event Sourcing, Disruptors, Reactive Streams и пр.базворды?

Собственно, сабжевый вопрос к читателям блога и просто случайно сюда заглянувшим прохожим :)

В последнее время на глаза постоянно попадаются упоминания event sourcing-а и reactive streams, а так же более мелких вещей, вроде disruptor-ов. Но все это вроде как относится к managed-миру. Т.е., в основном, Scala и Java. А вот касательно C++ что-то ничего не вспоминается.

Поэтому хочется понять: это все находится вне C++ного мира, т.к. сервер-сайд заняли managed-языки, или же для C++ это тоже есть, но просто не настолько раскручено?

[prog.sobjectizer] На пути к 50M msg/sec... (Akka нам не страшна?)

Некоторое время назад наткнулся на пост "50 million messages per second - on a single machine". Речь там идет о замере пропускной способности Akka 2.0 посредством небольшого микробенчмарка. Не смотря на то, что результаты замеров там приведены более чем трехлетней давности, интересно было посмотреть, что в этом плане может показать SObjectizer.

[prog.akka] Интересная презентация "The Road to Akka Cluster and Beyond"

Очень интересно.

The Road to Akka Cluster and Beyond from Jonas Bonér

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

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

[prog.c++] Состоялся релиз SObjectizer-5.5.2.1

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

Версия 5.5.2.1 может быть загружена из раздела Files или получена из Subversion-репозитория.

В Files для загрузки доступны следующие архивы:

• so-5.5.2.1.7z -- исходный текст ядра SObjectizer (включая тесты и примеры);
• so-5.5.2.1--doc-html.7z -- сгенерированный посредством Doxygen API Reference Manual;
• so-5.5.2.1--bin-msvs2013-x86.7z -- исходные тексты и 32-битовые бинарники для Windows (скомпилированы посредством MS Visual Studio 2013 Express);
• so-5.5.2.1--bin-msvs2013-x86_amd64.7z -- исходные тексты и 64-битовые бинарники для Windows (скомпилированы посредством MS Visual Studio 2013 Express).

[life] Дебилизм происходящего в соцсетях временами зашкаливает

Вот, например, недавнее из LinkedIn:

Там же арифметическое выражение записано неправильно: если первые два ряда 1+1... являются частью выражения, то в конце каждой из строк должен стоять знак плюса, который показывает, что выражение продолжается. Ну и, соответственно, доставляют попытки вычислять непонятно как записанное выражение. Особенно, когда в ответе получается единица :)

Таки количество разума на планете -- величина постоянная, а население-то растет :(

[prog.c++11] Uniform initialization syntax позволяет писать в духе Ruby-новых eDSL :)

Появившаяся в C++11 штука под названием uniform initialization syntax позволяет писать код, который очень напоминает Ruby-новые eDSL-и.

[prog] Хорошая презентация про Akka

Building Reactive Systems with Akka (in Java 8 or Scala) from Jonas Bonér

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

PS. Надо бы собраться с силами и сделать что-то подобное про SObjectizer.

[prog.wow] В 2015-ом код уже можно не отлаживать?

Походу, я проспал какой-то фундаментальный прорыв. По крайней мере на RSDN так утверждают:

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

[prog.c++] Еще в качестве рекламы современного C++ :)

Совсем маленький пример того, как современный C++ защищает от элементарных ошибок разработчика.

[prog.c++] Серия статей "Code reuse series"

По ссылке на isocpp.org наткнулся на серию статей "Code reuse series" в блоге "Modern Maintainable Code". Имхо, для тех, кто в свое время не штудировал Джосаттиса, Вандервуда, Александреску, Мейерса и Саттера или же штудировал их очень давно, имеет смысл прочитать эти статьи. В них рассказывается о том, как использовать перегрузку и шаблоны (в том числе различные варианты специализации шаблонов) для того, чтобы адаптировать свои функции/классы под разные условия. Например, как получить функцию getNthElement(), учитывающую тип контейнера, из которого нужно достать элемент по порядковому номеру. Или как std::unique_ptr удается работать правильно с разными типами ресурсов.

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

Вот перечень статей в хронологическом порядке:

• A Roadmap
• The basics of type-dependent code reuse (solution)
• Two fundamental implementations for one conceptual task
• Two fundamental implementations for one conceptual task (solution)
• Two fundamental implementations for one conceptual object
• Two fundamental implementations for one conceptual object (solution)
• When half is the same and half is different

Еще в догонку к этим статьям могу порекомендовать статью из того же блога "A corollary on overloading". Хотя я сам там далеко не со всем согласен (например, с запретом делать перегрузку стандартых функций для своих типов в пространстве имен std::, имхо, для std::swap именно так и нужно делать). Но прочитать имеет смысл. Полагаю, тема пересекается с тем, что пару дней назад обсуждалось у меня в блоге (#1, #2).

PS. ИМХО, перечисленные выше статьи отлично показывают, с какими именно проблемами сейчас сталкиваются C++ разработчики. Это отнюдь не повисшие указатели, расстрелянная память или ее утечки. Актуальность этих древних проблем, имхо, за последние годы сильно снизилась. А вот как разобраться в современных возможностях такого мощного языка, как C++11/14, как выбрать наилучший баланс между эффективностью/запутанностью -- вот это сейчас более актуально.