Olá a todos,

    A partir desse post começaremos a explorar também o App Engine, que é a plataforma de clouding computing do Google. Essa plataforma tem muitos conceitos parecidos com o Windows Azure pois ambas plataformas hospedam nossas aplicações em um ambiente altamente escalável, disponível e que podemos comprar sob demanda. No App Engine também podemos hospedar nossas aplicações web compostas de camada de apresentação, que são executadas na máquina cliente, e de camada de negócios, que é executada nos servidores do Google. Essa plataforma também possui um mecanismo de armazenamento de dados próprio, semelhantes às tables do Windows Azure Storage, projetado para suportar aplicações com enorme quantidade de usuários simultâneos e com alta performance.

    Podemos utilizar Java ou Python para desenvolver as aplicações que serão hospedadas no App Engine. Nos posts utilizarei somente Java, porém ambas as linguagem possuem todos os recursos da plataforma App Engine disponíveis, semelhante ao C# e VB .Net na plataforma Microsoft. Para os leitores que como eu escolherem desenvolver as aplicações em Java recomendo utilizarem o eclipse, pois há um plugin para esse IDE que auxilia nas tarefas rotineiras dos projetos.

    Após instalar o eclipse devemos instalar os pacotes para desenvolvimento em Java. No meu caso instalei os seguintes pacotes nessa ordem: java_ee_sdk-5_07-jdk-6u16-windows, jre-6u16-windows-i586, java_ee_sdk-5_04-windows_nojdk, java-tools. Após a instalação desses componentes podemos instalar o plugin do App Engine que adicionará no eclipse os seus templates. Duas vantagens da plataforma da Google é que ela possui a documentação básica em diversos idiomas, entre eles português, e que podemos utilizar uma determinada quantidade de espaço e tráfego sem custo. Com isso podemos estudar e praticar o desenvolvimento de aplicações para essa plataforma sem custos. Porém até o momento localizei somente a documentação básica e poucos exemplos com código fonte disponíveis, talvez porque comecei explorar essa plataforma a pouco tempo.

    Um pacote que tem me auxiliado no desenvolvimento dos testes é o Google Web Toolkit. Esse pacote provê objetos para compor a camada de apresentação e para montar a comunicação entre essa camada e a camada de negócio. Algo semelhante como utilizar ASP .Net com serviços em WCF, porém com protocolo de comunicação proprietário.

    Como já acontece com os posts sobre a plataforma Microsoft colocarei os códigos fonte dos exemplos utilizados na construção dos posts. No futuro pretendo praticar também a integração entre essas plataformas.

Abraço a todos e até o próximo post.

Da circa un mese Google ha messo a disposizione una feature utilissima per la sua omnipiattaforma fasotutomì App Engine: la mail in ingresso (qui l’annuncio sul blog ufficiale).

Siccome sulla documentazione c’è scritto e non c’è scritto, anche se è semplicissimo pubblico qui tutto quanto è necessario alla fruizione di questa utilissima feature, e lo faccio con Python che Java mi fa cagare in Java non lo so fare.

Per prima cosa bisogna annunciare ad App Engine di voler ricevere email e bisogna pure dirgli quale sarà lo script che le andrà a gestire. nulla di nuovo, si fa tutto da app.yaml

application: superfigatadapaura
version: 1
runtime: python
api_version: 1

inbound_services:
- mail

handlers:
- url: /_ah/mail/.+
  script: handle_mail.py

- url: .*
  script: main.py

Con la direttiva ‘inbound_services’ si attiva la mail in ingresso che di default è disabilitata, con il primo url handler si gestiscono le richieste POST che arrivano all’applicazione, sì perché la mail in ingresso viene magicamente trasformata in richieste POST all’url http://appid.appspot.com/_ah/mail/qualchecosa@appid.appspotmail.com. Occhio che gli url handlers vengono gestiti a cascata per cui l’acchiappatutto ‘.*’ deve rimanere per ultimo, pena ore di punti interrogativi che si innestano nelle meningi.

Magia o non magia le richieste POST non vengono però gestite come normali richieste POST ma vengono gestite con un’apposita classe (InboundMailHandler) che si occupa del parsing del messaggio e che noi andremo a derivare in quasi perfetta analogia con quello che capitava con RequestHandler:

import wsgiref.handlers
from google.appengine.ext import webapp
from google.appengine.ext.webapp import mail_handlers

class MailHandler(mail_handlers.InboundMailHandler):
        def receive(self, message):
                # Tutto qui. La variabile message che è di tipo InboundEmailMessage
                # contiene l'email e possiede le seguenti proprietà:
                # message.subject
                # message.sender
                # message.to
                # message.cc
                # message.date
                # message.bodies
                # message.attachments

def main():
        application = webapp.WSGIApplication([('/_ah/mail/.+', MailHandler)], debug=True)
        wsgiref.handlers.CGIHandler().run(application)

if __name__ == '__main__':
        main()

Due ultime osservazioni. La prima è che il metodo di cui fare l’override non è post() ma receive(), la seconda è che ‘bodies’ ritorna una lista di bodies (chi lo avrebbe mai detto) e ciascun body si può estrarre attraverso il metodo bodies() (questa sì che è una filastrocca da insegnare ai bambini!).

Per fare una prova è sufficiente spedire una normale email a graziemikiperilbellissimopost@appid.appspotmail.com

Link alla documentazione ufficiale (dove c’è scritto e non c’è scritto).

Update del 10 novembre 2009:

Sempre a proposito della documentazione un po’ carente, oggi sono venuto alle mani con gli attributi ‘bodies’ e ‘attachments’ che si comportano in modo leggermente diverso da quanto mi aspettavo (attenzione: non necessariamente si comportano diversamente da quello che c’è scritto – anche se -, solo si comportano diversamente da quello che io mi aspettavo).
L’attributo ‘bodies’ ritorna una lista di tuple (e non una lista di bodies), ciascuna delle quali ha come primo membro il content type e come secondo membro un oggetto di tipo google.appengine.api.mail.EncodedPayload che non è mica una stringa come stavate già pensando sfregando tra loro le vostre manine. Per fortuna la stringa la ottengo applicando il metodo decode() a questo oggetto. La cosa triste è che anche bodies() ritorna un generatore che fornisce una tupla di questo tipo.

# ritorna ('text/plain', istanza.di.EncodedPayload)
plaintext = message.bodies(content_type='text/plain')
for body in bodies:
        fa_qualcosa((body[1].decode()) # metodo decode()

L’attributo ‘attachments’ funziona in modo analogo anche se perfino più a cazzo con le dovute differenze. Anzitutto l’attributo potrebbe non essere presente del tutto, e se abbiamo intenzione di gestire allegati dobbiamo fare subito un controllo. Se l’allegato è uno solo viene ficcato in una tupla (‘nomefile’, contenuto.come.istanza.di.EncodedPayload), se invece sono più di uno viene generata una lista di tuple di questo tipo. Va a finire che bisogna scrivere roba tipo:

allegati = None
if hasattr(message, 'attachments'):
        if isinstance(message.attachments, tuple):
                allegati = [message.attachments]
        else:
                allegati = message.attachments
        for a in allegati:
                # Per ogni allegato abbiamo in
                # a[0] il nome file ed in
                # a[1].decode() il contenuto del file

Update dell’11 novembre 2009:

Lo dicevo che la gestione degli attachments era perfino più a cazzo analoga a quella dei bodies ma con differenze fondamentali ed infatti il metodo decode() non funziona. C’è una segnalazione di bug, la 2289, baco che viene dato per fixed ma che non lo è. Per fare correttamente il decode dell’EncodedPayload che contiene l’allegato, accogliendo il suggerimento presente nella pagina di segnalazione dll’errore, bisogna quindi creare una nostra funzioncina:

def goodDecode(encodedPayload):
        encoding = encodedPayload.encoding
        payload = encodedPayload.payload
        if encoding and encoding.lower() != '7bit':
                payload = payload.decode(encoding)
        return payload

Mettendo tutto assieme avremmo quindi:

import wsgiref.handlers
from google.appengine.ext import webapp
from google.appengine.ext.webapp import mail_handlers

def goodDecode(encodedPayload):
        encoding = encodedPayload.encoding
        payload = encodedPayload.payload
        if encoding and encoding.lower() != '7bit':
                payload = payload.decode(encoding)
        return payload

class MailHandler(mail_handlers.InboundMailHandler):
        def receive(self, message):
                # Tutto qui. La variabile message che è di tipo InboundEmailMessage
                # contiene l'email e possiede le seguenti proprietà:
                # message.subject
                # message.sender
                # message.to
                # message.cc
                # message.date
                # message.bodies
                # message.attachments
                plaintext = message.bodies(content_type='text/plain')
                for body in bodies:
                           fa_qualcosa((body[1].decode())
                allegati = None
                if hasattr(message, 'attachments'):
                        if isinstance(message.attachments, tuple):
                                allegati = [message.attachments]
                        else:
                                allegati = message.attachments
                        for a in allegati:
                                # Per ogni allegato abbiamo in
                                # a[0] il nome file ed in
                                # goodDecode(a[1]) il contenuto del file

def main():
        application = webapp.WSGIApplication([('/_ah/mail/.+', MailHandler)], debug=True)
        wsgiref.handlers.CGIHandler().run(application)

if __name__ == '__main__':
        main()

Yesterday support for pluggable e-mail backends has landed in Django’s trunk and today I’m happy to announce two e-mail backend implementations to be used with Django-based App Engine applications.

The e-mail backends allow you to use native Django functions for sending e-mails like django.core.mail.send_mail() on App Engine.

To use pluggable e-mail backends you’ll have to use a recent version of Django. Support for pluggable e-mail backends was introduced in rev11709 and will be released in Django 1.2.

Using the e-mail backend

The e-mail backends are available as a single package on bitbucket. To check out the most recent sources run:

$ hg clone http://bitbucket.org/andialbrecht/appengine_emailbackends/

or got to the downloads page and grab a zip file.

To use the e-mail backend for App Engine copy the appengine_emailbackend directory to the top-level directory of you App Engine application and add the following line to your settings.py:

EMAIL_BACKEND = 'appengine_emailbackend'

If you prefer asynchronous e-mail delivery use this line in your settings.py instead:

EMAIL_BACKEND = 'appengine_emailbackend.async'

When using the async backend e-mails will not be sent immediately but delivered via a taskqueue.

Running the demo application

There’s also a demo application included in this repository. Run this application using

$ dev_appserver.py .

and open http://localhost:8080 in your web browser. Remember to include a current checkout of the Django SVN repository in the top-level directory of the demo application.

Download Eclipse Java EE IDE, and follow the instructions for getting all of the AppEngine plugins. It’s important to get these because it simplifies the deployment process to single click.

1. Create a new web application project.
2. Download all of the Wave Robot Java Client Library jars from here.
   1. Copy them to your /war/WEB-INF/lib directory.
   2. Reference them (Alt + Enter > Java Build Path > Libraries > Add JARS…).
      If successful, they’ll appear in a Referenced Libraries node in Package Explorer.

Edit web.xml

Add an endpoint for Wave to post to:

<servlet>
    <servlet-name>SearchServlet</servlet-name>
    <servlet-class>org.coriander.wave.sevendigital.servlets.search.SearchServlet</servlet-class>
</servlet>
<servlet-mapping>
    <servlet-name>SearchServlet</servlet-name>
    <url-pattern>/_wave/robot/jsonrpc</url-pattern>
</servlet-mapping>

We now have a handler for incoming wave requests. All wave requests will be routed to SearchServlet.

Add capabilities.xml

Registers servlets for wave events, add one to your /war/_wave directory:

<?xml version="1.0" encoding="utf-8"?>
<w:robot xmlns:w="http://wave.google.com/extensions/robots/1.0">
  <w:capabilities>
    <w:capability name="WAVELET_PARTICIPANTS_CHANGED" content="true" />
    <w:capability name="BLIP_SUBMITTED" content="true" />
  </w:capabilities>
  <w:version>1</w:version>
</w:robot>

Implementing a robot servlet

Very easy, derive from com.google.wave.api.AbstractRobotServlet, which has a single method:

import com.google.wave.api.AbstractRobotServlet;
import com.google.wave.api.RobotMessageBundle;

public class SearchServlet extends AbstractRobotServlet {
    @Override
    public void processEvents(RobotMessageBundle bundle) { }
}

There are numerous tutorials around describing what to do next.

Setting robot profile image

This amounts to adding the root /_wave/robot/profile endpoint. There easiest way to do this is to derive a servlet from com.google.wave.api.ProfileServlet, and override any of the methods you choose.

To set the avatar image, override getRobotAvatarUrl:

import com.google.wave.api.ProfileServlet;
...
public class Profile extends ProfileServlet {
    @Override
    public String getRobotAvatarUrl() {
        return "http://coriander-7digital.appspot.com/_wave/coriander-7digital.png;
    }
}

And then place your image your /war/_wave directory. There are other useful settings like display name which can also be provided by override. The default content type of ProfileServlet-derive types is application/json.

Don’t forget to register the new servlet by updating web.xml.

Deployment

Very simple, it’s all done by the IDE.

References

• Google Wave Robots: Java Tutorial.

If you’re a regular Dominion player like me, you’re always in search for new card sets. Fortunately I’ve had a little time this weekend to write a simple App Engine application that gives me a random card set on demand.

You can see it in action at http://dominionsets.appspot.com

That’s it, just a short post on this, now back to the next match

P.s.: Some technical stuff… There’s Django with it’s i18n support under the hood. The UI is powered by JQuery.

Ejecuta tus aplicaciones web en la infraestructura de Google.
Fácil de crear, de mantener y de ampliar.

logo de google app engine

Google has created an example on how to use google app engine with java. In this example they demonstrate the basic usage of Servlet API and JDO, it’s a simple example that stores, retrieves and renders entities in google app engine.
After the first tutorial on how to deploy Stripes in google app engine I decided to re-write this example using the Stripes framework of course.

Download the source code!

Steps:

1. Create a project and name it Guestbook

2. Follow the Getting started with Stripes and google app engine to configure Stripes

3. Add the JSTL jars (standard.jar and jstl.jar) in the lib directory

4. Create an ActionBean that will handle the greeting requests

package com.guestbook.action;

import java.util.Date;
import java.util.List;

import javax.jdo.PersistenceManager;

import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.Resolution;

import com.google.appengine.api.users.User;
import com.google.appengine.api.users.UserService;
import com.google.appengine.api.users.UserServiceFactory;
import com.guestbook.manager.PMF;
import com.guestbook.model.Greeting;

/**
 * @author 110j
 */
public class GreetingActionBean implements ActionBean {
	private static final String VIEW = "/guestbook.jsp";
	private ActionBeanContext ctx;
	private UserService userService = UserServiceFactory.getUserService();
	private Greeting greeting;

	@DefaultHandler
	public Resolution welcome() {
		return new ForwardResolution(VIEW);
	}

	public Resolution addGreeting() {
		if (greeting != null) {
			greeting.setAuthor(getUser());
			greeting.setDate(new Date());

			PersistenceManager pm = PMF.get().getPersistenceManager();
	        try {
	            pm.makePersistent(greeting);
	        } finally {
	            pm.close();
	        }
		}
		return new ForwardResolution(VIEW);
	}

	public Resolution signin() {
		ForwardResolution fd = new ForwardResolution(VIEW);
		if (!userService.isUserLoggedIn())
			fd = new ForwardResolution(userService.createLoginURL("/Greeting.action"));
		return fd;
	}

	public Resolution signout() {
		ForwardResolution ForwardResolution ">fd = new ForwardResolution(VIEW);
		if (userService.isUserLoggedIn())
			fd = new ForwardResolution(userService.createLogoutURL("/Greeting.action"));
		return fd;
	}

	@SuppressWarnings("unchecked")
	public List getGreetings() {
		PersistenceManager pm = PMF.get().getPersistenceManager();
		String query = "select from " + Greeting.class.getName() + " order by date desc range 0,5";
	    return (List) pm.newQuery(query).execute();
	}

	public Greeting getGreeting() {
		return greeting;
	}

	public void setGreeting(Greeting greeting) {
		this.greeting = greeting;
	}

	public User getUser() {
		return userService.getCurrentUser();
	}

	public ActionBeanContext getContext() {
		return this.ctx;
	}

	public void setContext(ActionBeanContext ctx) {
		this.ctx = ctx;
	}
}

5. Create the model class called Greeting (as described in the google example, no changes here!)

package com.guestbook.model;

import java.util.Date;
import javax.jdo.annotations.IdGeneratorStrategy;
import javax.jdo.annotations.IdentityType;
import javax.jdo.annotations.PersistenceCapable;
import javax.jdo.annotations.Persistent;
import javax.jdo.annotations.PrimaryKey;
import com.google.appengine.api.users.User;

@PersistenceCapable(identityType = IdentityType.APPLICATION)
public class Greeting {
    @PrimaryKey
    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
    private Long id;

    @Persistent
    private User author;

    @Persistent
    private String content;

    @Persistent
    private Date date;

    public Greeting() {}

    public Greeting(User author, String content, Date date) {
        this.author = author;
        this.content = content;
        this.date = date;
    }

    public Long getId() {
        return id;
    }

    public User getAuthor() {
        return author;
    }

    public String getContent() {
        return content;
    }

    public Date getDate() {
        return date;
    }

    public void setAuthor(User author) {
        this.author = author;
    }

    public void setContent(String content) {
        this.content = content;
    }

    public void setDate(Date date) {
        this.date = date;
    }
}

6. Create the utility class that will instantiate the EntityManager (no changes here also!)

package com.guestbook.manager;
import javax.jdo.JDOHelper;
import javax.jdo.PersistenceManagerFactory;

public final class PMF {
    private static final PersistenceManagerFactory pmfInstance =
        JDOHelper.getPersistenceManagerFactory("transactions-optional");

    private PMF() {}

    public static PersistenceManagerFactory get() {
        return pmfInstance;
    }
}

7. Modify the guestbook.jsp, there are a lot of changes here since in their example google uses scriptlets, I have replaced the scriptlets with jstl tags and Stripes tags, all the logic has moved to the ActionBean.

8. Modify the welcome file list in the web.xml and set as welcome file the Greeting.action

Download the source code!

This is a basic example of using Stripes Framework with the cloud infrastructure of Google. I am using Stripes in one of my projects that I am thinking to move it to google app engine so I decided to experiment before the migration. More posts will follow in this topic as I progress with it. The first objective is to create the basic project structure, configure and deploy, well… a hello world web application. This is a trivial application but there are some limitations using google app engine so trying to use the framework as is will fail with some non-sense stack traces.

The following is a list of things that we will be need to complete this application:
1. Stripes Framework (home page: http://www.stripesframework.org/display/stripes/Home )
2. Google app engine sdk – if you use eclipse and google plugin the sdk is included in the plugin.
3. Eclipse (you can use whatever IDE or environment you like, it’s not mandatory to use eclipse, it’s just easier).

Note: For information on how to install the google plugin visit http://code.google.com/appengine/docs/java/tools/eclipse.html

I assume you are familiar with java web frameworks and that you will use eclipse with the google plugin.

The first step is to create a project in the eclipse IDE:

Give a name to the project and an initial package name. For the moment we do not need GWT so just deselect it.

After pressing finish we have the following project structure.

Before continuing copy the Stripes jars in the the lib directory under hello_project/web/WEB_INF/lib and add them to the project’s build path by selecting them, right click-> Build Path -> Add to Build Path. Also copy and paste the StripesResources.properties in the directory “src” (not in a package).

By default the google plugin will generate a servlet for us, under the package name that we entered in the previews step. It will also generate the following configuration files:
Servlet spec requirement:
1. web.xml (this is the well known deployment descriptor required by the servlet specification)

Google App engine specific (we will not use them for this application):
1. appengine-web.xml
2. jdoconfig.xml

Logging property files:
1. log4j.properties
2. logging.properties

For the purpose of this trivial application we will only need to edit the web.xml (a.k.a Deployment Descriptor so from know on I will call it DD).
By default the plugin registers the generated servlet in the DD, so open the DD and delete the servlet and servlet-mapping it’s not needed.

The following is the generated DD that need to be edited:

The following is the new and final DD containing the Stripes filter and dispatcher servlet:

Note that the web-app tag version has changed from 2.5 to 2.4 there are some jsp exceptions with the 2.5.

The Stripes filter includes two initial parameters the ActionResolver.Packages which tells Stripes where to find the ActionBeans (more on this in next post or in Stripes documentation) and the MultipartWrapperFactory.Class, a factory class used to upload files, but uploading files is not supported by google app engine and the Stripes filter will fail to initialize. Therefore we need to disable this by providing an empty configuration.

The first step to disable file uploading is to add MultipartWrapperFactory.Class initial parameter to the Stripes filter as shown in the DD and the second step is to create the appropriate class. So create a package in the project (I created the com.helloworld.exclude but you can create anything that make sense for your project) and add the following class:

import java.io.IOException;

import javax.servlet.http.HttpServletRequest;

import net.sourceforge.stripes.config.Configuration;
import net.sourceforge.stripes.controller.FileUploadLimitExceededException;
import net.sourceforge.stripes.controller.multipart.MultipartWrapper;
import net.sourceforge.stripes.config.ConfigurableComponent;
import net.sourceforge.stripes.controller.multipart.MultipartWrapperFactory;

/**
 * GAE does not support file uploading so we need to disable this feature from Stripes.
 *
 * @author 110j
 */
public class EmptyMultipartWapper implements ConfigurableComponent, MultipartWrapperFactory {

	/**
	 * @see net.sourceforge.stripes.config.ConfigurableComponent#init(net.sourceforge.stripes.config.Configuration)
	 */
	public void init(Configuration conf) throws Exception {
	}

	/**
	 * @see net.sourceforge.stripes.controller.multipart.MultipartWrapperFactory#wrap(javax.servlet.http.HttpServletRequest)
	 */
	public MultipartWrapper wrap(HttpServletRequest request) throws IOException, FileUploadLimitExceededException {
		return null;
	}
}

Now that we disabled the file uploading lets create an ActionBean that will handle our request. Create a package in the project called com.helloworld.action and add the following class:

package com.helloworld.action;

import net.sourceforge.stripes.action.ActionBean;
import net.sourceforge.stripes.action.ActionBeanContext;
import net.sourceforge.stripes.action.DefaultHandler;
import net.sourceforge.stripes.action.ForwardResolution;
import net.sourceforge.stripes.action.Resolution;

/**
 * The action bean that will handle the our simple request.
 *
 * @author 110j
 */
public class EasyActionBean implements ActionBean {
	private static final String VIEW = "/WEB-INF/jsp/hello_world.jsp";
	private static final String MY_MESSAGE = "hello world";
	private ActionBeanContext ctx;

	private String message;

	@DefaultHandler
	public Resolution showMe() {
		this.setMessage(MY_MESSAGE);
		return new ForwardResolution(VIEW);
	}

	/**
	 * @see net.sourceforge.stripes.action.ActionBean#getContext()
	 */
	public ActionBeanContext getContext() {
		return this.ctx;
	}

	/**
	 * @see net.sourceforge.stripes.action.ActionBean#setContext(ActionBeanContext)
	 */
	public void setContext(ActionBeanContext ctx) {
		this.ctx = ctx;
	}

	/**
	 * @return the message
	 */
	public String getMessage() {
		return message;
	}

	/**
	 * @param message the message to set
	 */
	public void setMessage(String message) {
		this.message = message;
	}
}

Next lets create a jsp file that will render the response, create the hello_world.jsp under WEB_INF/jsp/ and add the following content:

Finally create a welcome file called index.jsp if it does not exist or rename the index.html to index.jsp and add just a forward to the action:

You can delete the servlet generated by the google plugin there is no need for it.

In order to test it you just need to run the hello_world in the Run history of eclipse as the google plugin will create one for us, or under the run button in the toolbar, and then visit the address localhost:8080

NOTE: if your application require session you need to enable it in the appengine-web.xml since it is disabled by default (but keep in mind the implication it may have in a distributed environment such as google app engine, maybe your attributes will need to implement the HttpSessionActivationListener if you plan to add them in the session).

You can upload your application by using eclipse or the command line tool, for more information visit http://code.google.com/appengine/docs/java/gettingstarted/uploading.html

To be continued!

В общем, друзья мои, так и не удалось мне раскачегарить App Engine на Снежном барсе. Редактирование исходников не помогло. Обходишь одну ошибку, получаешь другую.

В целом все сводится к тому, что в АппЭнджине библиотеки 32-битные, поэтому он отказывается работать, если есть возможность 64-битности. Так как Ява 6 на старом Леопарде была только 64-битной, АппЭнджин проверяет версию Явы. Если она не начинается со строки “1.5″, он выдает ошибку.

В интернете я встречал предложения установить 5-ю яву на Snow Leopard. И видел предостережения Эппловских разработчиков этого не делать. Последующие обновления, говорят они, все равно ее снесут.

Так что ж делать? Я ж кул хацкер, так ведь И App Engine мне нужен. И решение я нашел до гениальности простое.

Я попилил жесткий диск на партиции, поставил в одну из них (маленькую, 50 гб) старого Леопарда, и там у меня отлично живет Апп Энджин. То же можно, по-видимому, проделать и в Параллелзах (Parallels desktop), но, мне кажется, будет тормозить.

这次给大家写个简单的教程,有兴趣的坛友试试.
注册地址: http://appengine.google.com/
你也可以把这个做你的文件存储,不过限制文件最大为1M
演示:
http://lxvoip8.appspot.com/static/lxvoipbanner.gif

1.首先申请Google App Engine的帐号
打开网址:  http://appengine.google.com/
Gmail邮箱应该有吧,用你的gmail邮箱和密码登录就可以.

2.点击“Create an Application”按钮，开始申请：

3.这里要验证你的手机号码,你输入你的手机号码，手机号码需要填写国际区号，中国的区号是86，如果你的手机号是13088888888，那么就填写 “+8613088888888” 的形式，填写好后点击“Send”按钮.[只支持中国联通手机]
你的手机就会收到一条短信，发件人号码是“10655505905518”，短信的内容如下：

Google App Engine Code：1234567 [lxvoip]

将你手机收到的验证码输入,点send. 一个手机号码只能申请一个Google App Engine服务。

4.填完验证码后就是填写一些基本的信息，比如说是域名、站点的名称等等。
如: http://lxvoip8.appspot.com/
然后确定，就申请成功了。

5.下载SDUpload:
SDUpload是Google App Engine的第三方上传工具,使不懂Google App Engine和python的人也可以轻松上传.
下载地址:点击进入下载－SDUpload.rar
备用下载: http://p.lxvoip.com/lxfile/SDUpload.rar

GOOGLE项目备用地址：http://mickeywaley-blog.googlecode.com/files/SDUpload.rar

6.解压,将SDUpload文件夹置于E盘根目录下.找到lxvoip目录下的app.yaml文件,用网页设计软件dreamweaver打开,将第一行的lxvoip8,改成你的应用名,也就是第四步你所申请的域名.然后保存.你也可以修改lxvoip目录下的main.html文件,使你的首页更加个性化.

7.开始上传,如下图所示,lxvoip文件夹是你要上传的在线代理程序.
运行 cmd
e:
cd SDUPload

SDUPload update lxvoip

接着提示,要你输入你的邮箱,你输入你的gmail邮箱,回车,再输入你的密码,回车.

出现下面的提示,就说明成功了:
Loaded authentication cookies from H:\Documents and Settings\Administrator/.appc
fg_cookies
Scanning files on local disk.
Initiating update.
Email: lxvoip@gmail.com
Password for lxvoip@gmail.com:
Saving authentication cookies to H:\Documents and Settings\Administrator/.appcfg
_cookies
Could not guess mimetype for static/favicon.ico.  Using application/octet-stream
.
Cloning 8 static files.
Cloning 5 application files.
Closing update.
Uploading index definitions.
Error 400: — begin server output —
Creating a composite index failed: This index:
entity_type: “EntryPoint”
ancestor: false
Property {
name: “last_updated”
direction: 2
}
is not necessary, since single-property indices are built in. Please remove it f
rom your index file and upgrade to the latest version of the SDK, if you haven’t
already.
— end server output —
E:\SDUpload>

8.没有问题的话,你就可以打开, http://lxvoip8.appspot.com/ ,记得将lxvoip8换成你的域名.

At VendAsta we develop, among other things, social networking applications deployed to Google AppEngine. One of the aspects of our suite is a feature where users (e.g., Facebook users) can trust experts from our StepRep software.

A desirable, and obvious, feature is to identify the experts that my friends trust, or conversely, which of my friends trust a particular set of experts. From a use case perspective, a lot of this information is jammed on to the screen at one time; that is, we cannot simply query for a single friend or a single expert.

This is a classic graph walk style problem that is relatively easy to scale in a parallel processing environment, but nasty where you can only do serialized queries.

Initially, we felt a bit limited by the AppEngine query model. It is very fast, but only allows for serialized queries.

In reaction, we began investigations into using a MapReduce mechanism to compute these “trust networks” offline. Specifically, we were planning on using MapReduce deployed into Amazon’s Elastic MapReduce engine. The results of these computations were to be stored on Amazon’s S3 (as JSON docs) and simply accessed statically from our AppEngine applications.

This solution, while sound, suffered some drawbacks. We had a difficult time with dealing with the recomputation of the trust networks. We could choose to recompute them daily, but this was wasteful of resources: many of the networks would be completely unchanged. Alternatively, we could queue jobs when new trusts are formed and process just those, but then we have to develop another job to determine which trust networks cascade from the new trust and need recomputation. The absolute nail in the coffin of this approach is that we (typically) use Facebook to define friend networks and their T&C do not allow the storage of friend relationships for any great amount of time, making offline processing difficult and incomplete at best.

We needed another solution that allowed for the real time computation of trust networks.

An architect at our company, Kevin Pierce, also happens to be one of the best reverse engineers I know. He started poking around the gory depths of the AppEngine source and discovered that all of the API calls stub out in MakeSyncCall. This inevitably led to the discovery of the partner MakeCall which yields an RPC object that you can wait on. Of course, if I can wait on one RPC object, I can also wait on many of them. A subsequent release of AppEngine capitalized on this fact allowing the developer to easily make parallel UrlFetch requests. There were some earlier code libraries that also facilitated parallel UrlFetch requests leveraging the same mechanism.

At Google I/O, Ryan Baldwin and I had the opportunity to corner Ryan Barrett (AppEngine’s supersmart Data Store guru) and chat with him about using this approach for other API interaction. Ryan seemed pretty excited about our exploration of this area and indicated that this was something they had intended to expose to developers but, like any successful software project, competing priorities kept getting in the way.

Encouraged, we set about developing code to allow developers to queue up a set of AppEngine API calls and then kick them off in parallel. In particular, for the use case that we were looking to solve was the ability to perform multiple Data Store Queries in parallel; this would allow us to query for each friend’s trusts in parallel and collect the results together.

An example invocation might look something like this:


# set up the async queries
runner = MultiTask()
for uid in user_ids:
    query = db.GqlQuery("SELECT __key__ FROM Account WHERE facebook_id = :1", uid)
    runner.append(QueryTask(query, limit=1, client_state=uid))

# peel out the results
for task in runner:
    task_result = task.get_result() # will raise any exception that occurred for the given query
    print '%s: %s' % (task.client_state, task_result[0])


Here, we’re making multiple parallel queries, though the mechanism allows for mixing around different API calls.

As an aside, this can yield some pretty scary/awesome looking values in the logs files:

Three seconds can chew up a lot of API time!

I’m excited to announce that we’ve bundled up this code into a package and released it to the wild on Google Code as asynctools. So far, we’ve wrapped Query (including GqlQuery) and UrlFetch. Others will come as we have time/motivation. Note that you can combine these together and execute arbitrary combinations of them in parallel.

Send us any feedback, comments, encouragement you have.

Google App Engine

I’ve recently got myself a Java app engine account from google but have held out about reviewing the various features until I had tested it in anger. Well, now I have!

Background Details

I have two applications running on app engine, one is a jsp based website www.oxfordgeekjam.net, which is no more than a static site with a bit of generated markup and one Java servlet application which makes use of several other google APIs. All my development work is done using the opensolaris operating system from Sun (now part of oracle).

What You Get

When you register for a google app engine account (python or java) you get space to host ten applications. Once they are gone you’re on your own! Each one of your apps has a quota which is reset every 24 hours, this quota includes factors such as CPU load, bandwidth etc. Once you breach these, you are on your own again unless you have signed up for googles pay as you go type service, which automatically charges for anything above the standard quotas.

When you register one of your ten applications, you must give it a unique name which becomes it’s application ID. To access your app you can use the URI [applicationID].appspot.com and also your own domain as well if you choose (see below). Its worth noting that once an app has been registered it can not be deleted to make room for another app!

Your application also comes with a “dashboard” which is kind of like a control panel for your app. It gives you information about how much of your quota you are using as well as providing an interface to your server logs. This second point is crucial because one thing you don’t get with the app engine is direct access to the file system space of your application (see deployment below).

Using Your Own Domain Name

The first site is hosted using its own domain name (rather than the default *.appspot.com).  To use my own registered domain name, which I bought through a third party vendor rather than google, was a bit fiddly to begin with but now I know the process should be a cinch. To use your own domain you must have the ability to change your own DNS settings, in particular the CNAME records. Most domain vendors will allow you to do this as did eurodns with whom mine was registered with. You also have to register with google apps (yes, another google service to register with) to prove domain ownership and link your domain to your google “web master tools”. After that you simply need to click on versions in you app dashboard and link the domain to your app.

One downside of the process, and one that is causing quite a stir with other app engine developers, is that you cannot have a naked domain resolve to your application. That is to say, if I registered thebestdomainever.com the URI as it stands can NOT resolve to your app! www.thebestdomainever.com or anything.thebestdomainever.com would be fine though! Of course the way to get around this is to redirect the naked domain to the google acceptable domain, but I understand some registrars don’t allow this, again I was lucky, mine did!

Coding the Application

For vanilla jsp applications this is no more difficult than coding the pages and bundling them with the xml deployment descriptor and a couple of settings files in standard WAR format. The process is somewhat more difficult when it comes to writing servlets and using regular java classes.

There is a plugin for the eclipse IDE which is supposed to mange the coding and build process for you but I haven’t used it therefore cannot comment! I used netbeans (as I always do) and managed to configure the IDE relatively easily with a bit of  help from the documentation, and using apache ant to manage the build. I won’t go into too many details unless somebody asks for it but it basically involves downloading the app engine SDK in zip format (which rolls in at a hefty 20Mb)  and importing the com.google.appengine libraries. App engine applications use the Java Servlet Standard so most developers should feel right at home.

The only thing to watch out while coding is that all applications run in a sand box with a restricted white-list of java classes which are allowed to be used, so you may want to check the dependencies of your favorite libraries before using them!

Deploying the Application

This is the part of the process which I found really pleasantly surprising. The testing and deployment process worked (for me) straight out of the box!

Given the following constraints I really appreciate this level of detail…

1. I’m using opensolaris
2. I was using a really early version of the app engine API
3. The SDK is a single download regardless of whether you use a mac, linux or windoze

To run the app using the localhost as a testing server was as simple as issuing the command…

dev_appserver.sh [war-location]

to the shell.

Uploading the app to your app engine space is similarly easy…

appcfg.sh update [war-location]

One thing to note is that you must make sure that the settings file appengine-web.xml is in the WEB-INF folder and points to your application ID.

Once your app has uploaded, it has gone. You have no way of retrieving it back as there is no access to your application’s file space. This even includes access by the app itself (for obvious reasons).  If you do need persistence and serialisation then you are encouraged to use google’s datastore, but this comes with quota limits.

Quotas

Each application has quotas which are reset every 24 hours. These quotas include CPU time, bandwidth (both ways), Mail and deployments, among others. If you go for google’s premium service then once you reach these quota limits then anything above the quota is charged for, if you don’t then app will not function for the part which requires the quota. There are also hard limits which even premium customers can’t breach. The ten application limit per app engine account is one.

Two of the quota limits are for google datastore api usage and URLFetch usage. So even if your app is only making use of google provided services then you are still limited to amount of traffic you are allowed.

Conclusions

Things I like

• The testing and uploading process is a doddle to use
• Once you’ve set up your IDE coding and deploying is also easy
• The service is free which makes the quotas quite generous
• Using you own domain is relatively easy and can be done any time before or after the app is finished

Things I Dislike

• Why oh why can’t I delete an application once I am done with it?
• Why can I only have ten applications, especially considering the above?
• Why am I penalised by quota limits for google’s own services? Shouldn’t they encourage use of their own services rather than those of third parties?

I hope this post is of some value to some of you, please feel free to comment and if you would like me to send you my netbeans and/or jsp development templates, I am more than happy to do so!

Cheers,

Matty

Resources

http://code.google.com/appengine/ – The Google App Engine

http://www.google.com/apps/intl/en/business/index.html – Google apps for business

http://java.sun.com/j2ee/tutorial/1_3-fcs/doc/WCC3.html – The WAR packaging standard

http://ant.apache.org/ – Apache ANT

http://java.sun.com/products/servlet/ – The Java servlet standard

http://code.google.com/appengine/docs/java/jrewhitelist.html – The Java class app-engine white-list

Updated: Today we’ve received an email and seen multiple tweets alerting us to the fact that Google’s (s Goog) App Engine software development platform is down. We’ve emailed the company for details, but in the meantime, a check of the App Engine status page won’t even load at 11:30 a.m. PDT, and updates on the site indicate that it’s been put into unplanned maintainance mode after experiencing problems this morning.

Update: A Google spokeswoman tells us that the service was down because of a storage issue. She emailed a statement that read: “Today at 8 am PT datastore access for App Engine applications was affected due to a cluster-wide issue. The team identified and fixed the underlying problem and service has now been restored. We apologize for the inconvenience and encourage anyone having technical difficulty to visit the System Status Dashboard or the Downtime Notify Group, which are both linked from the Google App Engine Community site.”

We’ve seen several complaints about the impersonal way Google seems to be handling this, criticism that certainly may cause the company harm in its quest to woo the enterprise to its platform. Readers, can Google keep App Engine flying?

As allways, developing anything but MS stuff on your windows platform  causes headaces …I’m running through Using Google App Engine, 1st Edition but the code doesn’t quit take care of windows path problems and in section 6.10. Extending Our Application a general purpose method is introduced to take care of finding a template, assigning values to it and render it like this:

def doRender(handler, tname='index.htm', values={}):
  temp = os.path.join(
      os.path.dirname(__file__),
      'templates/' + tname)
  if not os.path.isfile(temp):
    return False

  # Make a copy of the dictionary and add the path
  newval = dict(values)
  newval['path'] = handler.request.path

  outstr = template.render(temp, newval)
  handler.response.out.write(outstr)
  return True

- which is fine if your on anything but windows! But on windows “templates/” will give you a problem because that’s not where the file is located! If you want to us a general purpose method for finding your template files i a subfolder, use this snippet:

def assign(template):
 return os.path.join(os.path.join(
 os.path.dirname(__file__), 'templates'), template)

Assign may not be the best name, but the method returns a valid path to your template, you can then use it like this:

class HomePage(webapp.RequestHandler):
  def get(self):
    path = assign('home.html')
    self.response.out.write(template.render(path, {}))

But I would suggest adding something more to the method so that the entire call to self.response.out.write can be removed from the get method.