Взаимодействие между клиентом и сервером как правило устроено очень просто и опирается на довольно примитивный инструментарий. Это не создает проблем само по себе, но зачастую даже небольшое усложнение поставленной задачи плохо укладываться в привычные подходы, порождая не слишком изящные решения-заплатки. Многие задачи решаются в каждом новом проекте заново, бессистемно и независимо друг от друга. К подобным задачам относятся, например:

• Batch-запросы
• Передача даты в составе сложной структуры данных
• Обозначение кастомных типов данных
• Проброс round-trip данных, которые сервер должен вернуть в ответе
• Дополнение запроса и ответа метаданными
• Обработка ошибок, пришедших в ответе

Разработчики тратят немало времени, раз за разом создавая неказистые велосипеды на серверной стороне, после чего их приходится поддерживать еще и на стороне клиента.

jsonex представляет собой попытку объединить решение упомянутых выше и многих других задач в рамках простого единого подхода, основанного на концепции вычислимых данных (callable data).

Статья "Недопонимание CAP-теоремы" и комментарии к ней свидетельствуют, что непонимание действительно есть. И связано оно не только с неправильным толкованием термина «partitioning», но и с ментальными ошибками на других уровнях. Попробую внести ясность.

Асинхронные программы чертовски неудобно писать. Настолько неудобно, что даже в node.js, заявленном как «у нас все правильное-асинхронное», понадобавляли таки синхронных аналогов асинхронных функций. Что уж говорить про питоновский синтаксис, не дающий объявить лямбду со сколь-либо сложным кодом внутри…

Забавно, что красивое решение проблемы не требует ничего экстраординарного, но почему-то до сих пор не реализовано.

Google Developer Day состоялся сегодня.

Все-таки Google такой Google… :-)
Очень интересные люди, интересный способ мыслить, интересные идеи.
В общем, если вас там не было, вы многое потеряли.

Самым интересным рассказчиком для меня оказался Бретт Слаткин. А самой интересной темой — его рассказ про PubSubHubbub, publish-subscribe протокол. Бретт рассказывал как там все устроено и, что было особенно ценно, почему оно устроено именно так.

И вот ведь интересно, как бы поступили нормальные люди, создавая свой publish-subscribe? Пожалуй, взяли бы какое-нибудь готовое решение из множества возможных, и опираясь на него, придумывали бы, как сделать лучше и избавиться от существующих недостатков. Но это Google, и ребята зашли совершенно с другого конца. Они взяли Atom и RSS, и стали думать, чего там не хватает, чтобы получить instant notification. Поэтому их решение очень простое, очень изящное и очень вебовское.