Основной проблемой является то, что стандартный пакет библиотеки Dojo не может быть загружен на GAE из-за превышения существующего лимита платформы в 1000 файлов. Django имеет ту же самую проблему. Решением проблемы в лоб является ручное удаление ненужных файлов, что позволяет уложиться примерно в 700 файлов приложения.

С подобной проблемой столкнулись разработчики платформы LittleShoot, когда попытались запустить свое API «P2P 2.0″. Подразумевалось, что другие сайты будут выполять JavaScript запросы к сервису, что потребовало бы реализации кросс-доменного взаимодействия с библиотекой Dojo и привело бы к увеличению кода еще на 500 файлов, снова превысив лимит в 1000 файлов.

Благодаря вышедшей недавно платформе GAE версии 1.1.3, в которой анонсирован модуль “zipserve”, появилась возможность работы со статическими файлами, помещенными в zip-архив. Гвидо Ван Россум (автор Python) использовал тот же самый подход для работы Django со своим замечательным приложением Rietveld, но только для подгрузки исполняемого кода.

Для работы Dojo с zipserve, достаточно просто модифицировать файл app.yaml и включить в него подобную конфигурацию:

- url: /dojo/.*
script: $PYTHON_LIB/google/appengine/ext/zipserve

- url: /dijit/.*
script: $PYTHON_LIB/google/appengine/ext/zipserve

- url: /dojox/.*
script: $PYTHON_LIB/google/appengine/ext/zipserve

Это означает, что мы загружаем файлы dojo.zip, dijit.zip и dojox.zip в каталог верхнего уровня (тот же, куда помещен файл app.yaml). Необходимо принять во внимание, что следует создать несколько zip файлов, учитывая лимит платформы на размер самого файла (1 мегабайт). Имя каждого zip файла используется как имя каталога при извлечении адреса из URL. Таким образом, запрос к http://beta.littleshoot.org/dojo/dojo.js, к примеру, подгрузит файл dojo.js из dojo.zip (а не из каталога dojo файла dojo.zip). Ниже приведен пример скрипта, создающего zip файлы:

#!/usr/bin/env bash

function die()
{
echo $*
exit 1
}

cd static/js
dirs=”dojo dijit dojox littleshoot”

for x in $dirs
do
cd $x || die “Could not cd to $x”
echo “Building zip for $x”
zf=../../../$x.zip
rm $zf
zip -rv $zf * || die “Could not create zip”
cd ..
# Удаляем все содержимое, так как его не требуется загружать
 # в платформу.
 rm -rf $x
done

exit 0

Даже находясь в раздельных zip файлах, dijit и dojox будут близки к максимальному ограничению на размер файла в 1 мегабайт. Мы используем утилиту rsync, в параметрах которой задается список файлов, какие можно исключить. Ниже приведена функция для командного процессора bash, выполняющая эти действия (внимательно проверьте, чтобы не были исключены нужные пакеты!):

function excludeRsync
{
rsync –exclude .svn/ \
–exclude test/ \
–exclude tests/ \
–exclude demo/ \
–exclude demos/ \
–exclude soria/ \
–exclude nihilo/ \
–exclude grid/ \
–exclude charting/ \
–exclude util/ \
–exclude analytics/ \
–exclude collections/ \
–exclude README* \
–exclude *.psd \
–exclude *.uncompressed.js \
–exclude *.commented.css \
–exclude dijit/templates \
–exclude dijit/form/templates \
–exclude dijit/layout/templates \
–exclude *silverlight* \
–exclude gfx3d/ \
–exclude dojo/_base/ \
–exclude dojo/_base.js \
–exclude dojo/build.txt \
–exclude functional/ \
–exclude off/ \
–exclude presentation/ \
–exclude sketch/ \
–exclude storage/ \
–exclude wire/ \
–exclude data/ \
–exclude dtl/ \

-avz $tmpDir/js $releaseDir || die “Could not sync”

}

Запуск скрипта с rsync необходимо осуществлять после билда файлов dojo. В нашем случае билд dojo помещает все файлы в каталог “$tmpDir/js”, указанный в последней строчке параметров rsync.

Для использования Django версии 1.0 рекомендуется скопировать настройки с проекта Rietveld от Гвидо. Возможно вам захочется настроить Google App Engine Django Helper, однако на момент написания статьи в нем не была заявлена поддержка версии 1.0 Django. Мы использовали код от Гвидо – в общем случае достаточно файлов Makefile, make_release.sh, settings.py и main.py. Также я подправил его скрипт rietveld.py, переделав его в littleshoot.py. Все эти файлы можно найти в svn проекта Rietveld здесь.

Мы выполняем загрузку как Django, так и Dojo через svn. Нижеприведенные команды необходимо выполнять точно в тех каталогах, куда нужно поместить соответственно Django и Dojo.

svn –editor-cmd=vim pe svn:externals .

Для загрузки Dojo:

dojo http://svn.dojotoolkit.org/src/tags/release-1.2.0b2/

Для загрузки Django:

django http://code.djangoproject.com/svn/django/trunk/django

После выполнения команды “svn up” в каталог dojo будет загружен Dojo версии 1.2 beta 2, в каталог django транковая версия Django.

Если вы выполнили все инструкции, приведенные в статье, то получите последние версии библиотек Dojo и Django, работающие в Google App Engine. Теперь можно засучить рукава и начать разработку!

Несмотря на то, что App Engine позволяет гибко настраивать работу одновременно нескольких версий приложений, участвовать в процессе его создания сразу многим разработчикам, все таки версионные возможности платформы пока достаточно ограничены. Для удобной работы с кодом компания Google рекомендует использовать внешнюю систему управления версиями, такую как CVS или Subversion. Так как программа CVS по меркам ИТ является уже старичком, мы сфокусируемся на ее потомке – Subversion, который в данный момент является наиболее распространенной системой контроля версий среди разработчиков.

Допустим вы (разработчик на языке Python) и два ваших коллеги (разработчик на JavaScript и HTML-дизайнер)  пишете новое приложение под App Engine, которое должно оказаться новой бомбой в Интернете. Все трое находятся в различных городах, работают на собственных ноутбуках в разных coworking центрах. Соответственно App Engine выбрана платформой неслучайно, а позволяет в случае успеха масштабировать приложение, так как это необходимо (а в случае провала – разработчики рискуют только своим собственным временем, в отличии от многих стартапов, в бизнес плане которых заложены огромные суммы на приобретение серверного оборудования). Было бы интересно использовать аналогичный web-сервис и для размещения кода проекта и управления его версиями.

После анализа текущей ситуации на рынке On-Demand SVN систем я пришел к выводу, что пока самым вкусным вариантом является использование сервиса компании Assembla. Судите сами, в бесплатной версии даются: 200 мегабайт пространства под код, неограниченное число разработчиков, системы управления версиями Subversion, Mercurial, GIT, багтрегинг, wiki, чат и многие другое. В случае необходимости можно проапгрейдить за $12.5 и $150 в месяц до 5 и 50 гигабайт пространства соответственно и получить дополнительные возможности (автоматический бэкап на Amazon S3, поддержку и прочее).

Давайте зарегистрируемся. После чего мы увидим главный экран системы:

Щелкнем по ссылке Manage spaces и на открывшемся экране добавим новую область для проекта, нажав на кнопку Create new space:

Задаем общее название области в поле Space name и используемое URL проекта в поле URL name. Второе значение необходимо указать такое, чтобы никем еще не использовалось. В завершении для активации в этой области сервера Subversion ставим галочку в поле Software developers (integrated), после чего жмем кнопку Next. В появившемся экране убеждаемся, что в параметре Allow for public access стоит значение None (мы же не хотим, чтобы код нашего проекта видели все кто захочет?):

При необходимости можно задать другие параметры, в том числе адреса электронной почты наших коллег, для которых мы хотим отправить приглашения на подключение к этой системе. С помощью кнопки Next >> проходим все установочные экраны и создаем новую область. На экране, представленном ниже, мы видим, что теперь получить доступ к SVN репозиторию можно по url: http://svn.assembla.com/svn/superproject:

Допустим, мы используем Eclipse с установленным плагином для SVN. Если в вашей среде плагин еще не установлен, то можно обратиться к статье о его подключении к Eclipse. Переходим в перспективу SVN и добавляем наш новый репозиторий:

Нам предложат ввести имя пользователя и пароль для доступа к репозиторию. Вводим те данные, которые были указаны при регистрации:

Далее щелкаем кнопку Next и система выполнит загрузку уже существующих файлов:

Далее мы захотим поместить в наш репозиторий унаследованные проекты, которые мы раньше не вели в системе управления версиями. Щелкнем правой кнопкой мыши на области SVN Repositories и выбираем пункт New remote folder. Указываем название базового каталога, где будет храниться наш проект (к примеру, site.ru). Затем щелкнув по вновь созданному каналогу правой кнопкой мыши, выбрем из меню пункт Import. В появившемся окне задаем каталог с проектом и, при необходимости, дополнительные параметры:

Началась операция загрузки:

Проверим на другом компьютере, что файлы были загружены в SVN. Например, выполняем команду checkout: svn co http://svn.assembla.com/svn/superproject –username widgetii:

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