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

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

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

Tarantool это замечательное высокопроизводительное no-Sql решение, разработка компании Mail.Ru. Исходники

Данное решение позволяет использовать как режим key/value, так и выборку множества записей в рекордсет по одному или нескольким критериям (полям поиска). Аналогов в рунете и не только, я пока не встречал. С натяжкой можно сравнить редис. Но в редисе — списковые данные и их нельзя выбирать по ключу. Судя до утверждениям разработчиков, скорость доступа по ключу превосходит memcache, при этом еще в бэдграунде осуществляется постоянное сохранение данных на диск. Но к сожалению, данная разработка имеет единственный perl клиент для доступа к данным, из-за чего не имеет такой популярности, как например у redis или memcache.

В doc/box-protocol источников есть описание Протокола, которое я в настоящее время переработал для написания клиента на Си и PHP. Изучив Протокол, вы можете реализоать нативный клиент на любимом Вам языке. Надеюсь, данная статья в этом Вам пригодится.

О Bitcoin я узнал относительно недавно, но он меня сразу подкупил своей идеей p2p. Чем глубже я зарывался в их Wiki, тем больше проникался этой идеей. Ее реализация красива и элегантна с технической точки зрения.

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

Новый протокол, предназначенный для того, чтобы «шарить» контент, получил поддержку от крупных компаний, таких как Microsoft, Google, LinkedIn.
С одной стороны, сайтам с контентом необходима возможность давать посетителям обмениваться ссылками на этот контент в разных системах. С другой стороны, всяким гугл-баззам хочется встраиваться в список систем для обмена со своими пользователями. Между ними ещё стоят инструменты обмена, которые в простейшем случае представляют собой различные веб-виджеты, работающие на странице в браузере. Протокол OExchange унифицирует решение этих задач.

Google изобрел протокол SPDY, который призван ускорить передачу данных, которые обычно передаются через протокол HTTP. Google выделяет следующие проблемы HTTP, негативно сказывающиеся на скорости (источник):

1. Один запрос на одно соединение. Из-за этого ради каждого нового запроса приходится заново соединяться с сервером, что отнимает по 500 мс на запрос. Сейчас есть много ухищрений, компенсирующих эту проблему, но, по мнению Гугла, они несовершенны.

2. Запросы может инициировать только клиент. Нет механизма, по которому сервер мог бы в чем-либо уведомить клиента (например о том, что некие данные готовы к отправки, и клиенту приходится периодически спрашивать его об этом).

3. Заголовки (headers) передаются несжатыми.

4. Заголовки, которые не изменяются (например, User-Agent) приходится заново посылать при каждом запросе.

5. Сжатие передаваемых данных возможно только опционально. Оптимальным является сжимать данные всегда.

Тесты выявили, что текущая реализация протокола SPDY способна повысить «скорость интернета» до 50%. SPDY является почти обратно совместимым с HTTP (разработчики надеются, что в текущих серверах не придется переделывать вообще ничего). Доступны исходники для встраивания поддержки SPDY в Chromium.

Разработчики из компании Google только что объявили, что работают над новым сетевым протоколом SPDY (читается как SPeeDY, то есть «быстрый»), который должен проапгрейдить протокол HTTP и значительно повысить скорость работы всех типов соединений.

SPDY позволяет вдвое уменьшить задержку (latency) при работе через HTTP. Делается это за счёт трёх методов:

1) мультиплексирование запросов;
2) расстановка приоритетов для запросов;
3) сжатие заголовков HTTP.

Чтобы продемонстрировать все возможности SPDY, инженеры Google подняли тестовый веб-сервер и выпустили специальную версию браузера Chrome.

По итогам предварительного тестирования на канале максимальной толщины, выигрыш в скорости загрузки для 25 крупнейших сайтов интернета составлял до 55%.

Нашел тут в интернете хокку для 404 ошибки:
Сайт, который ты ищешь
Найти невозможно, но
Ведь не счесть других…

и решил напридумывать еще…
401
Войти сюда
Лишь посвященный может.
Ты ли это?

403
Хозяин не велел
Говорить с незнакомцем
Своему сайту…

500
Не справился с запросом
Тот сайт, но
Попытался…

410
Сайт, который ты искал
Уж канул в лету — Не ищи его больше…

400
Понять речь чужестранца
Трудно простому сайту — Попробуй иначе…

Может я и не оригинален в этом, но уж очень хотелось выпендриться.

Прочитав статью и испробовав команды, научимся
--Соединяться с Jabber сервером
--Логиниться
--Менять статусы
--Отправлять сообщения
--Отключаться

И все это на чистом XML

В принципе, можно статью назвать «Введение в XMPP» или типа того… Но суть не изменится
Приступим-же!