Сегодня, 8 декабря, день рождения Екатерины Логвиновны. Alvaro Videla сделал сокращённый перевод этой статьи для англоязычной аудитории: medium.com/a-computer-of-ones-own/kateryna-l-yushchenko-inventor-of-pointers-6f2796fa1798 и передаёт вам, автору статьи большое спасибо!

Расскажите подробнее об опыте с InfluxDB?

Не, не так ;)

Гляньте tcpkali — генератор нагрузки для TCP и WebSockets серверов!

Язык программирования Дракон. Язык ДРАКОН создан в ракетно-космической отрасли: ru.wikipedia.org/wiki/ДРАКОН

У нас 50-хостовый кластер риака стоял несколько лет. Сейчас ужали до 17-нодного. Данных — несколько сотен гигабайт, не терабайты.

Сбоев было много (работаем поверх EC2, довольно часто вылетают хосты), восстанавливается практически всегда нормально, но однажды на два дня потеряли часть данных (пока делали восстановление InnoDB структуры), после пары лет работы (но версия была старая).

Сейчас работаем с LevelDB-бэкендом, полёт нормальный. Кросс-датацентр-репликацию не используем.

Также см. lionet.livejournal.com/tag/riak

> Насколько мне известно, в Riak странно устроена репликация данных.

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

> Riak написан на Erlang, как правило, вам будет очень сложно понять что идет не так и попробовать это исправить :)

Для многих Erlang плюс, потому что в плюсах копаться мочи уже нет. А риак код — он маленький, как на ладони.

Дочка CEO LinkedIn'а, как я понял. Будущий участник.

Она участница была, не фотограф :)

Скажем так. Есть и другое мнение по этому вопросу. ulgrad.ru/?p=107093

Нитпик: «State of the art» — это высшее достижение ремесла на текущий момент. А не «незаконченный набросок», в каком качестве эта фраза, по всей видимости, используется в этом тексте. В остальном — кул!

С провайдером договариваешься, чтобы он инет давал бесплатно, но баннеры на стенах свои мог повесить.

Если на функции навесить модификатор static в модуле (не в заголовке), то они перестанут быть доступны снаружи модуля. То есть, методами объекта станет невозможно пользоваться. Это очевидным образом разрушает идею объекта как полезной сущности.

У меня в коде единственной «ошибкой» можно считать отсутствие инициализации объекта. То есть, использование malloc() вместо calloc(), что порождает объект, инициализированный мусором. Это было сделано сознательно, в иллюстративных целях. Потому что если C++ и Java программисты ещё помнят про malloc() в C, то про calloc() помнят уже меньше.

Если мысленно заменить «malloc(» на «calloc(1,», код мгновенно становится рабочим и корректным. Но у студентов по мере прочтения появляются вопросы к периферийной, неосновной части текста, что затрудняет обучение JavaScript'у.

Что касается непрозрачных объектов в C — да, подобное скрытие является стандартной практикой.

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

Первая проблема, которая действительно появляется у новичков — это почему нужно писать Person.prototype.foo вместо Person.foo. Не переоценивайте новичков.

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

Что касается .apply и .call — это немного другая тема, отличная от темы прототипов в JS. Это тема функциональных контекстов в JS, и достойна другой статьи, которая показывает на примерах механику этого процесса. Если сделать такую статью качественной и полной, она будет едва ли не в половину от данной. Теперь представим, что нам нужно объяснить одновременно и .apply/.call, и прототипы. Стоит ли нам соединять эти две длинные статьи вместе, в одну большую портянку, говорящую обо всём? Я считаю, что не стоит. Те, кто считает, что стоит, пишут книги по 1000+ страниц, разжёвывающие каждую тему.

Короче, кроме корректности и полноты у текста есть характеристика «может ли он научить». Сделать одновременно корректный, полный и обучающий текст, да так, чтобы не расплескать по дороге учеников — это адская задача.

Убрал, чтобы не никого не вводить в заблуждение.

Напишу, а первый комментарий будет «Опять эти ежемесячные введения в замыкания от хаскелистов» :)

А если серьёзно, то что именно стоит рассмотреть? call/apply? Ведь есть на хабре такие статьи, какой именно подачи не хватает?

Спасибо за критику :)

Я решил не использовать в объяснении механики прототипов то, чего нельзя использовать в IE6. Даже __proto__ использовал только вскользь.

Впрочем, я ожидал, что критика коснётся в основном того, что используется printf() в C++, или какой-нибудь подобной ерунды. Хорошо, что она началась с действительно фундаментальных недостатков статьи, таких как Object.create.