Вкратце о Google App Engine.

Google открыл платформу для создания и запуска server-side приложений на серверах Google. Ключевые моменты:

Готовое окружение для программирования на Python, c некоторыми ограничениями.

Python запускается в sandbox, который не позволяет использовать некоторый функционал, относящийся к OS — осуществлять запись в файловую систему, использовать сокеты, threads, fork, exec, системные вызовы. Учитывая то, что приложение как бы висит в воздухе, такие ограничения объяснимы. В связи с этим некоторые модули заменены на заглушки.
Подозреваю, такая же судьба у модулей, написанных на C. Я пока что не пробовал импортировать такие модули, но без знания архитектуры и набора системных библиотек той машины, на которой будет исполняться код, такие модули бесполезны.
Вместо низкоуровневой работы с сокетами предоставлен модуль для запросов по HTTP. Отдельный модуль для email. Вместо файловой системы — Google BigTable с SQL-like интерфйсом (об этом ниже). Все остальное — обычный Python 2.5. Django — в комплекте :). Методы развертывания — от простого print до WSGI-приложения.

Вместо файловой системы - распределенное хранилище Google BigTable.

От файловой системы остаются только те статические файлы, которые загружены вместе с приложением — их можно читать. Для всего остального — BigTable. API очень смахивает на Django DB/Model API. Язык запросов — GQL — на SQL. Все просто и понятно.

Интеграция с Google Accounts

Позволяет аутентифицировать пользователей, используя механизм, принятый в Google; доступны некоторые данные текущего залогиненного пользователя Google, работающего с приложением. Что это дает? Догадайтесь.

Выводы

В-общем, к многочисленным API Google добавил возможность развертывания практически любых пользовательских приложений на своих серверах. Ограничения касаются только приложений, для которых необходимо низкоуровневое сетевое взаимодействие (за пределами HTTP). Ну или требующих некоторой специфической функциональности, типа обработки изображений, для которой обычно используются модули, реализованные на C.

Немаловажно, что бесплатный пакет — 500 Мб места и 5 млн. хитов в месяц. Цены на то что сверху пока не озвучены, но что-то мне подсказывает, что многие хостеры будут не очень довольны таким оборотом событий. А как все это приятно программистам на Python, об этом вообще речи не идет :)

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

Ну а сейчас — дискотекакино по теме.

Социальный веб: “Мы уже на Марсе”.

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

javascript.options.strict в Firefox

Дин Эдвардс написал о странных тормозах у некоторых пользователей, открывающих его сайт в Firefox, что лечилось отключением Firebug.
Причина была в установке опции javascript.options.strict в конфигурации Firefox (about:config).

Если эта опция включена, Firefox кроме серьезных ошибок в скриптах будет сообщать о возможных ошибках. Если при этом в консоли Firebug включена опция Show JavaScript Warnings, то эти сообщения вываливаются в консоль, что и порождает описанные тормоза.

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

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

Итерирование по свойствам объекта в JavaScript.

Любой объект в JavaScript может быть расширен в рантайме. Более того, прототип (свойство prototype) любого объекта может быть также расширен, что влечет за собой изменение свойств всех объектов, унаследованных от измененного. Все добавленные в объект либо в прототип объекта-предка свойства и методы будут видны при использовании for (name in obj) {...}.

JSON validation: the Schema By Example.

[lang_en]Есть по-русски
There are a lot of JSON data currently around, and virtually no standard means to validate it against a schema, the way everybody accustomed to in the XML world.

A fair number of proposals for a schema language occurred recently, and I'm going to add my 5 cents. The idea is that the schema should be expressed as JSON (no need to invent languages), and represent an example of a valid data structure of the data to be validated against. I call this "Schema By Example".[/lang_en]
[lang_ru]English version available
Формат JSON стал очень популярен в сфере обмена данными, но до сих пор пока не существует стандартных механизмов валидации, таких как схема, к каким люди уже давно привыкли, если имеют дело с XML.

Немало хороших предложений языка схемы для валидации JSON возникло в последнее время, и я хочу добавить к ним еще кое-что от себя. Моя идея в том, что схема должна быть описана в том же формате JSON (нет нужды изобретать новые языки), и представлять собой пример правильной структуры данных. По этому примеру и следует проверять действительность полученных данных. Назовем это "Схема по примеру".[/lang_ru]

Интерфейс Python для Flickr API.

Некоторое время назад нужно было использовать Flickr API. Конечно, есть и готовые Python API для Flickr, но тут сработал синдром NIH и захотелось чего-то своего, понятного и простого. Публикую как иллюстрацию развития идеи от простого к усложнению, но не слишком сложному :) Опять же, как у меня часто получается, тут скорее не про Flickr, а про Python.

Удаленная отладка приложений на Python в Eclipse с Pydev Extensions

Тем кто до сих пор не определился с тем, какой IDE для Python лучше всех, скажу, что лучший IDE — это Eclipse с плагином Pydev. Функции и вкусности перечислять не буду, скажу только что всё чего вам скорее всего захочется, в нем есть, и можно органично использовать все остальные прелести Eclipse, например интеграцию с системой контроля версий. Можете со мной спорить, но это мой блог, что хочу то и пишу :)

К базовому бесплатному Pydev также существует расширение Pydev Extensions, которое, кроме того что все-таки уже стоит денег — $42,5, на которые финансируется разработка "бесплатного" Pydev — хотя, по правде говоря, позволяет работать и бесплатно, только настойчиво напоминая о том, что хочет денег. Pydev Extensions дополняет базовый пакет некоторыми приятными возможностями, среди которых — возможность удаленной отладки. Под удаленной я имею в виду отладку во внешнем по отношению к Eclipse процессе. Он может работать как на той же машине, на которой работает Eclipse, так и на удаленной, "разговаривая" с Eclipse по TCP/IP. Простая отладка возможна и без использования Pydev Extensions.