Курс по анализу данных на github

Какие-то добрые люди разместили краткий курс по науке о данных на гитхабе. Оглавление здесь. Почитал пока только про MapReduce (в последнем, 14м модуле) - очень занятно. Думаю, и остальной материал настолько же хорош.

Лучшие способы применения Redis

Компания RedisLabs, разрабатывающая Redis, собирает советы по использованию своего детища в разделе Best practices. Рассказывается, как использовать Redis в качестве индекса, для взаимодействия приложений, в статистических целях и, конечно же, как лучше хранить в Redis данные. Ознакомиться можно по ссылке, архивные записи здесь.

Модели согласованности

Хорошая картинка с иерархией моделей согласованности. Краткое описание сути нескольких моделей со ссылками на статьи. Пересказ раздела "Согласованность и репликация" из Таненбаума.

Целостное хэширование - наконец-то!

Наконец-то я понял идею целостного хэширования (consistent hashing)! Много чего читал - и никак.

Вот, например, замечательный пост, где объясняется идея этого вида хэширования, в контексте статьи о Amazon Dynamo (ссылка на саму статью). Хорошо все рассказано - и всё равно не понял.

Но Интернет большоооой. Вот, наконец, пост, который смог мне объяснить эту простую идею.

Итак. Есть функция хэширования f(). У нее есть некоторая область значений (fmin, fmax). Сворачиваем ее в кольцо. Берем имеющиеся сервера (по которым нужно равномерно распределить ключи), у каждого своё имя (IP-адрес, например). Хэшируем имена серверов, получаем точки на кольце (эти точки разбивают кольцо на отрезки). 

Теперь берем ключи, хэшируем их названия, получаем новые точки, которые распределяются по кольцу. На каком сервере будет размещен данный ключ? Берем ключ, его хэш - точка на кольце. Двигаемся по кольцу по часовой стрелке, находим первую точку, которая представляет сервер. На этом сервере и будет размещен данный ключ. При добавлении/удалении сервера будут перераспределено лишь небольшое количество ключей. В отличие от простейшей методике, где номер сервера определяется по формуле хэш(ключ) % количество_ключей. 

В описанной схеме каждый ключ хранится на одном сервере, что небезопасно. Поэтому данный сервер может разреплицировать свои ключи по T следующим серверам в кольце.
  

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

DHCP-сервер роутера отказал в аренде IP

Вот такую ошибку нашел в журнале событий планшета:
dhcp-сервер отказал в аренде IP-адреса (имеется ввиду dhcp роутера).

Советы из интернета:
Попробуйте увеличить время аренды адресов в DHCP-сервере роутера до хотя бы 7 дней вместо суток.  Вообще-то для сети, где используются постоянные устройства , лучше ставить аренду (Lease Time) хотя бы на месяц. Или вообще на год. А то мало ли по какой причине данное устройство долгое время будет не в сети...

Сатоши Накамото на русском

Знаменитую статью "Bitcoin: A Peer-to-Peer Electronic Cash System"  можно прочитать на русском. Вот здесь лежат переводы этой работы в том числе на наш Великий и Могучий.

Разработка игр

Игры - это замечательный тренажёр для программиста. Позволяет отточить все виды навыков - от компьютерной графики до сетевого взаимодействия.

Фундаментальный труд Multiplayer game programming. Cтек TCP/IP, сокеты, сериализация объектов, репликация объектов и ... сами игры :)

Статья Distributed Architectures for Massively-Multiplayer Online Games. Кратко даются основы распределенных систем, а затем рассматривается вопрос, как писать многопользовательские игры для архитектуры peer-to-peer.

И, наконец, книжка на русском (переводная) Шаблоны игрового программирования. Приемы решения типовых задач при написании игрового ПО. Меня пока больше всего заинтересовали глава 9 Игровой цикл (по-английски game loop, основной цикл программы, в котором считывается пользовательский ввод, обновляется состояние игры, производится отрисовка) и глава 10 Метод обновления