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

Довольно интересной находкой оказался 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

Python 2.7, повышение лимитов, Cloud SQL Preview, Google Storage for Developers, Premier Accounts

Неужели свершилось? Основное ограничение, мешавшее переносу существующих приложений на платформу GAE — отсутствие обычного, нормального SQL уходит в прошлое? Компания Google анонсировала свой новых продукт: Google Cloud SQL.

Для того, что бы получить доступ к данному API необходимо на странице Services вашего проекта в GAE «Запросить» данное API — заполнить небольшую форму (кстати реализованную при помощи Google Docs) — и остается дальше только ждать когда же дадут доступ — что бы воочию пощупать — действительно ли там нормальный SQL без каких-либо ограничений?

Вышла новая версия GAE SDK 1.5.4.

Основные изменения:

• Blobstore API — появилась возможность задать максимальный размер для загружаемого файла
• Datastore — улучшение внутреннего механизма выборки по нескольким полям с использованием операции = (равно)
• Prospective Search API теперь доступна и для Java
• Memcache — стало возможным делать запись в Memcache без ожидания ответа от сервиса. Мы просто передаем данные, и не дожидаемся пока они будут обработаны этим сервисом для продолжения работы

Несмотря на последние события, связанные с повышением цен, Google App Engine продолжает работать над улучшением качества своего продукта, что нас радует.

Список изменений для Python
Список изменений для Java
Скачать GAE SDK 1.5.4

Источник: официальный блог Google App Engine

P.S. В текущей версии SDK не появилась возможность выборки по условию несоответствия <, >, !=.

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

Сегодня мы «научим» webapp не загружать лишнее.

Google объявила об изменениях, касающихся введения новых правил учета ресурсов, используемых приложениями под App Engine.
Главная новость в том, что теперь будет предоставлено 28 бесплатных часов в сутки на приложение вместо 24. Это дает хороший шанс для слабо нагруженных приложений оставаться в рамках бесплатных квот.
Кроме того, переход на новую систему отложен до 1 ноября. Peter Magnusson (технический директор Google, ответственный, за App Engine) признал, что было ошибкой дать так мало времени пользователям системы на предварительную оценку ситуации и оптимизацию своих приложений. Обещаются улучшения в консоли, касающиеся учета инстансов, а отчеты (usage reports) теперь будут доступны уже на следующий день.
Также продлен срок действия 50%-ной скидки. Теперь она будет сохранена до 1 декабря (предполагается, что к тому времени будет доступен Python 2.7).