Со времени публикации новости о выходе Google App Engine 1.6.0 прошло уже много времени. А между прочем вышло 5 обновлений, каждое из которых принесло много вкусного и интересного. Попробую восполнить этот пробел.

Добрый день!

В одном проекте мне потребовалось сохранять контакты в Google Contacts. Это несложно — надо только авторизоваться через OAuth в Google и получить ключ доступа. Но дело в том, что при этом делается переход на сайт Google, где собственно происходит авторизация и подтверждение доступа приложения к контактным данным. Я же предполагал делать работу с контактом в iframe, а в целях предотвращения clickjacking'а Google не позволяет этого делать. Стало быть, требуется как-то сделать, чтобы страница OAuth открывалась в главном окне, а не во фрейме. Мой вариант решения — под катом.

Гомес Хульё Марильё де Серванте — известный международный наркобарон, который беспокоится о качестве предоставляемых его организацией услуг. По этому он, Гомес, решил разработать систему online-заказов для своих партнёров.

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

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

Итак, встречайте — Evernote Offline (лучшего названия пока не придумал)

Вступление

Многие знают про инфраструктуру от google под названием gae, некоторые считают её слишком проприетарной, другие слишком дорогой. Да она не дешевая, и мы попробуем написать оптимальное приложение для gae, которое жрало бы очень мало ресурсов и в идеале не выходило из бесплатных квот даже при хабраэффекте. Опишу мои ошибки, удачные технологические решения при написания сервиса японских кроссвордов. Фишка сайта в том что он позволяет создавать свои кроссворды и из обычной картинки тоже и делиться ими с друзьями.
Для построения сайта используется след. технологии:
backbone.js — фреймворк для обработки запросов на javascript'е. C его помощью будем надеяться, что уложимся в бесплатные квоты, так как весь код выполняется на клиенте, с сервера запрашиваются только данные о кроссвордах в json формате.
require.js — библиотека для дозагрузки любых ресурсом(js, html), можно указать код, который выполнится после загрузки всех ресурсов. Идеальна если у вас есть на сайте javascript и он используется в 1% случаев, и вы не хотите включать js-файл в index.html, то она вам подойдет.
undescore.js — всякие плюшки для слежения за изменением всего объекта или за конкретным его свойством. Очень большая и крутая библиотека, но я использую её как шаблонизатор.
bootstrap — чтобы не заморачиться с дизайном.
less — не ну, а почему б не использовать? (Потому что мы можем)
Ну и конечно же gae — на чем все это будет крутиться.

Наверняка каждый из вас в своей жизни находил удобный для себя файловый хостинг, а через какое-то время обнаруживал, что на нем от количества рекламы начинают болеть глаза, условия уже далеко не такие лояльные и вообще пора бы уже найти что-то новое. Вариантов дальнейших действий два — или найти новый, пока еще не раскрученный файлообменник и использовать его, пока он не испортится, или организовать собственное решение. Для второго варианта, в свою очередь, можно приобрести хостинг (придется правда набить шишек, пока не найдется добросовестный хостер с качественными услугами) или воспользоваться облачным сервисом.

Довольно интересной находкой оказался PaaS-хостинг от Google — Google App Engine (далее GAE), который дает возможность хранить до 5 Гб файлов при 1 Гб входящего и 1 Гб исходящего трафика в день, и кроме всего прочего, в нем используется модель High Replication, то есть ваши данные будут хранится сразу на нескольких серверах по всему миру!
Особенностью GAE является несколько нестандартный интерфейс для работы с файлами, поэтому я и сделал собственный сервис, о чем расскажу в данной статье.

Подключение PayPal Standard Checkout

В данном руководстве последовательно описан мой опыт внедрения PayPal Standard Checkout с использованием языка Java на платформе Google App Engine. Данная статья рассчитана на людей уже имеющих опыт работы с облачной платформой GAE.

Задача

Потребовалось мне интегрировать платёжную систему PayPal на сайт собственного проекта который будет предоставлять сервис по подписке. Начав работу с PayPal Express Checkout API через некоторое время пришло осознание того что система приёма платежа становится слишком громоздкой, в то время как у готовых кнопок Standard Checkout отсутствует необходимая гибкость, которая требуется в случае интеграции сайта с другими платёжными системами.
Выход был найден в использовании инструментов Standard Checkout которые предоставляет PayPal разработчикам сторонних “корзин” для сайта.

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

Очевидным решением является поставить веб-сервер, написать маленький скрипт, обрабатывающий запрос на некий URL вида http: //myproject/ontrial и далее моя программа при запуске должна делать запрос на этот URL.

Ранее я уже делал небольшие поделки на GAE, поэтому есть кое какой опыт, да и развертывания сервисов меня привлекла. Поэтому долго даже не думал над тем где расположить свой сервис, тем более он состоит из 1 простого метода, который по сути ничего не делает. Что еще более обрадовало, так это статистика в панели администратора GAE, в которой можно видеть какие методы и сколько раз дергались. Далее привожу сухую статистику использования и цены (много картинок)

Возможно, кто-то из читателей сталкивался с этой проблемой. В багтрекере GAE она уже давно висит в виде незакрытого Issue 3379. Кажется, изначально проблема касалась только Java, но сейчас она наблюдается и в Python (по крайней мере в 2.7). Описание ошибки и решение для Java можно найти, например, там, а в этом топике речь пойдёт про Python.

Коротко о сути. Часто сайты пытаются установить более одной cookie за раз. Делают они это путём указания нескольких заголовков Set-Cookie в ответе на запрос. По странному ведёт себя в этом случае urlfetch (и базирующиеся на нём urllib/urllib2): все эти заголовки склеиваются в один и разделяются запятыми. Надо ли напоминать, что запятые также присутствуют в полях expiries, а порой и в самих значениях cookie, что очень затрудняет обратный разбор такой строки. А стандартный HTTPCookieProcessor из urllib2 и mechanize просто не справляется с такой ситуацией.

Итак, если ваш проект использует поддержку cookies «из коробки» в urllib2 или mechanize, то вам безусловно подойдёт

Спустя три с половиной года после презентации платформы на Campfire One, App Engine выросла и стала полноправным продуктом Google. Мы создавали прокдукт, следуя простой философии: «удобно использовать, просто масштабировать и легко начать». Сейчас у нас более 100 миллиардов посещений в месяц, более 300 тысяч активных приложений и более 100 тысяч разработчиков, использующий продукт. Подход полностью оправдал себя. Спасибо за Вашу поддержку. Google верит в светлое будущее App Engine.
via The App Engine Team