| Autor |
Mensagem |
|
|
|
http://lmgtfy.com/?q=XMLHttpRequest+example
|
 |
|
|
|
onclick > funcao javacript > XMLHttpRequest
|
 |
|
|
http://code.google.com/appengine/docs/java/config/cron.html
Fica executado na periodicidade que você especificar sim.
Programaticamente pelo que sei não há acesso, só pela interface administrativa(web).
Nessa URL tem o xml de configuração, a tag '<url>' é quem define o servlet que será feito o request
|
 |
|
|
Se quer executar a cada 'x segundos/minutos/horas', o melhor a fazer são os CronJobs mesmo. Nele você registra qual URL será requisitada no intervalo de tempo
Para processamento assíncrono há também o TaskQueue, mas você é quem tem de registrar cada execução.
|
 |
|
|
Pra mim 'sorte' e 'destino' são desculpas, na maioria dos casos que eu conheço, de gente acomodada.
Abri uma empresa há 1 ano, e me arrependo de não ter feito isso antes. Gostei tanto da brincadeira que vou abrir mais uma
|
 |
|
|
Edufa wrote:O problema destas APIs é que te amarram ao google. Se para o projeto isto não é um problema, então o GAE é uma escolha melhor
Algumas APIs sim, que você pode criar um SPI pra elas.
Mas a grande maioria, são implementações de JSRs que você pode substituir.
De toda forma concordo, se ficar amarrado ao GAE é um problema, então nem considere usá-lo.
|
 |
|
|
Lucas Teixeira wrote:Não sei muito bem como funciona esse "AlwaysOn" do GAE, mas na infra do AWS AutoScaling e óbvio, agora do Beanstalk, você diz quantas instâncias no mínimo vc quer que fiquem no ar, e quantas no máximo também. Você pode dizer que quer começar com 2 instâncias, pra ter um failover, e ir até 6, dependendo do pico de acesso
No GAE o AlwaysOn mantém 3 instâncias da sua aplicação sempre de pé mesmo sem receber requisições, o que evitaria os 'cold starts'
Lucas Teixeira wrote:
Tem sim toda a api pronta já pra acesso! Hoje (quer dizer, desde ontem no lançamento), é possível interagir com o beanstalk de 4 maneiras:
Me referia a API de serviços(e que pra mim ai está o grande ganho de produtividade no GAE), como: Blobstore, ImageAPI, XMPP, Channel, OpenID, Autenticação com usuários Google/Apps, etc, etc
http://code.google.com/appengine/docs/java/apis.html
|
 |
|
|
Como Tim Bray tuitou agora pouco, por enquanto é um TaaS(Tomcat as a Service)
Do teste que fiz, a única vantagem é poder ter mais controle da infraestrutura.
Pontos negativos:
-Quando você cria uma instância, ele cria o restante da infra para você, mas quando deleta não, tem de matar os outros serviços(S3, EC2, LoadBalance) na unha.
-E principalmente, não tem serviços/APIs prontas como no GAE
|
 |
|
|
Jaba wrote:Caso é caso, mais eu não tive uma boa impressão da GlobalCode.
Fui no TDC (The Developers Conference), organizado pela mesma, e a maioria das palestras tinha conteudo fraco e a infra era uma bosta, mal rolava wi-fi e nem tinha tomada. Ai eu penso: se um centro de treinamento organiza um evento desse, o evento é o reflexo da escola. Mais como eu falei ai em cima, cada caso é um caso, tem gente que pode gostar e tem gente que pode não gostar.
Não sei quais palestras você assistiu, mas foi a primeira pessoa que vi, que reclamou do conteúdo. Eu particularmente gostei bastante de todas que assisti.
Aliás, o conteúdo não foi definido pela Globalcode, cada comunidade que definiu sua trilha. Algumas pessoas da Python Brasil definiram a trilha de Python, e assim por diante.
@robinsonbsilva
Tá devendo uma visita pra gente aqui em SBC, pra tomar uma breja e jogar Xbox....
E quanto a pergunta do tópico, conheço o Edson pessoalmente e o japa manda muito bem. Não é atoa que é líder técnico de uma das maiores consultorias do Brasil.
|
 |
|
|
|
System.getProperty("os.name") ?
|
 |
|
|
|
Não houve nada que eu não conseguisse fazer em Python/Django, há MUITO material também na internet e grupos de discussão de ambos.
|
 |
|
|
Tudo depende muito da natureza do seu projeto, e não menos importante da mão de obra que você tem disponível.
Eu este ano fiz esta transição, aprendi(e continuo aprendendo) Django, e já substitui Java em uma porção de projetos por ele. Sem contar que em Python você tem milhares de outros frameworks web além do Django.
Java eu continuo usando, e bastante, mas para algumas aplicações bem específicas, JMS, EJB, JNDI, Jython, etc.
|
 |
|
|
Javart wrote:A verdade é que Julian escolheu os E.U.A para fazer suas divulgações e polêmicas sobre atividades de espionagem , se fosse escolher a China já estaria Morto.
Duvido, se tivesse vazado informações da China os Ocidentais estariam aplaudindo e indicando o cara pra prêmio Nobel. Pra uma nação que se julga 'democratica', tá bem feio pros EUA esse show de hipocrisia
|
 |
|
|
juliocbq wrote: Jni tem perda de desempenho justamente por causa desse mapeamento(Que é um método dentro de outro, que faz gerar mais código de máquina, e por sua vez leva mais tempo para ser processado).
A experiência que tenho com JNI neste projeto é o contrário. Para implementarmos um servidor Comet e manter uma requisição Http persistente, acabamos substituindo alguns conectores do JBoss, principalmente o que trata requisições HTTP por um componente nativo do SO, e tanto a quantidade de usuários simultâneos quando o tempo de resposta, são consideravelmente melhores utilizando bibliotecas nativas + JNI. E pelo que me lembro tanto driver do MySQL quanto do Postgre que usamos aqui, são do tipo IV(pure-Java)
|
 |
|
|
juliocbq wrote:
É porque normalmente o io usa jni em bibliotecas nativas. Nesse ponto você perde desempenho por causa dele. O chamado Overhead(O tempo que leva um método para executar um outro, e assim por diante).
Me referia a I/O de forma geral. Conexões com banco, serialização/deserialização de objetos, rede, chamadas ao MongoDB, requisições HTTP, etc.
|
 |
|
|