Arquivo da tag: python

WebService em Python

Tive uma necessidade estes dias de criar um webservice em um servidor linux que retornasse os logs de emails do postfix, fazendo um grep (find) pelo usuário, tipo de protocolo e data.

Pesquisei um pouco, e achei uma solução muito boa, fazer o desenvolvimento do webservice em Python, o que é muito simples e de muito rápida execução.

O servidor que eu estava trabalhando usa CentOS e vinha com as bibliotecas padrões do python instalado, caso o seu sistema não venha, um apt-get install python ou um yum install python deve resolver o problema. Mas eu ainda precisava de mais duas bibliotecas que não vinham com a minha distro: fpconst e SOAPpy. Procurei as duas aqui: http://rpm.pbone.net/, achei a que se enquadrava para o meu sistema operacional i586.

Segue as versões de como eu usei:

mkdir /home/pacotes
cd /home/pacotes/
wget http://pypi.python.org/packages/source/f/fpconst/fpconst-0.7.2.tar.gz#md5=10ba9e04129af23108d24c22c3a698b1
wget http://downloads.sourceforge.net/project/pywebsvcs/SOAP.py/0.12.0_rc1/SOAPpy-0.12.0.tar.gz?use_mirror=ufpr
tar -cvf fpconst-0.7.2.tar.gz
tar -cvf SOAPpy-0.12.0.tar.gz
cd fpconst-0.7.2
python setup.py install
cd ../home/SOAPpy-0.12.0
python setup.py install

Pronto, minhas duas bibliotecas já estavam funcionando.

Agora vamos ao webservice:

#!/usr/bin/python
#import das bibliotecas necessarias
from SOAPpy import SOAPServer
import os
import commands
 
#caminho dos arquivos de logs
caminho = '/root/cirolini/'
 
#identifica se o protocolo for pop ou imap e direciona para a pasta solicitada
def protocolo(protocolo):
        if protocolo == 'popper':
                return 'popper/popper.log'
        if protocolo == 'imap':
                return 'imap/imap.log'
 
#literalmente da um grep nos logs que estao no formato popper.log.2010-03-16T08:00-03:00
def buscaLogs(usuario, proto, data):
        proto = protocolo(proto)
        busca = "zgrep " + usuario + " " + proto + "." + data +"*"
        var = commands.getoutput(busca)
        return var
 
#instancia o webservice para rodar na porta 8081 e responder para pesquisas como localhost
server = SOAPServer(('localhost',8081))
#registra a funcao que vamos chamar no nosso cliente
server.registerFunction(buscaLogs,'ns-buscalogs','buscaLogs')
#indica para o webservice nao parar de executar
server.serve_forever()

Acredito que já deixei tudo bem comentado de como funciona.

E segue o nosso cliente:

#!/usr/bin/python
#importa a biblioteca para fazer o webservice via SOAP
from SOAPpy import SOAPProxy
 
#parametro do webservice para ele saber a porta e o namespace (funcao) que vamos chamar
url = 'http://localhost:8081'
namespace = 'ns-buscalogs'
 
#conecta no webservice
server = SOAPProxy(url,namespace)
#isto para dar um dump das informacoes de entrada e saida
server.config.dumpSOAPOut = 1
server.config.dumpSOAPIn = 1
 
#escreve na tela o retorno da funcao do webservice buscaLogs
print server.buscaLogs('rafael','popper', '2010-03-16')

Os retornos ficaram mais ou menos desta forma:

[root@dsv cirolini]$ python cliente.py
*** Outgoing SOAP ******************************************************
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<ns1:buscaLogs xmlns:ns1="ns-buscalogs" SOAP-ENC:root="1">
<v1 xsi:type="xsd:string">rafael</v1>
<v2 xsi:type="xsd:string">popper</v2>
<v3 xsi:type="xsd:string">2010-03-16</v3>
</ns1:buscaLogs>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
************************************************************************
*** Incoming SOAP ******************************************************
<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance" xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/1999/XMLSchema">
<SOAP-ENV:Body>
<buscaLogsResponse SOAP-ENC:root="1">
<Result xsi:type="xsd:string">Mar 16 08:46:19: end session - user rafael from 127.0.0.1: time=1 inbox=0/0 quit=1/4/138 stat=1/19/9 auth=1/150099/111 </Result>
</buscaLogsResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
************************************************************************
Mar 16 08:46:19: end session - user rafael from 127.0.0.1: time=1 inbox=0/0 quit=1/4/138 stat=1/19/9 auth=1/150099/111

Fonte: Rafael Cirolini/NerdHead

Introdução aos “decorators” do Python

Este recurso incrível apareceu na linguagem quase se desculpando, e com preocupações de que poderia não ser tão útil. Eu, por minha vez, acredito que em tempo ele será visto como um dos recursos mais poderosos na linguagem. O problema é que todas as introduções à decorators que eu já vi foram bastante confusas, então vou tentar consertar isso neste artigo.

Decorators vs. decorators pattern

Primeiro, você precisa entender que a palavra “decorator” foi usada com certo receio, porque existia uma preocupação em que confundissem o decorator pattern do livro Design Patterns. Outros termos foram considerados para substituí-lo, mas “decorator” parece ser o escolhido.

Na verdade, você pode utilizar os decorators do Python para implementar um decorator pattern, mas esse é um uso muito limitado dele. Os decorators do Python, acredito, se equivalem mais aos macros.

História dos macros

O macro tem uma longa história, mas a maioria das pessoas provavelmente tiveram experiências com os macro processadores C. Os problemas com os macros C eram os seguintes: eles estavam em uma linguagem diferente da C, e o comportamento deles, às vezes, era bizarro e inconsistente com o comportamento do resto do C.

Tanto o Java, quanto o C# adicionaram anotações, que permitem que você faça algumas coisas para os elementos da linguagem. Ambos têm problemas para fazer o que você quer. Às vezes você tem que pular através de um círculo grande e complexo. Há também o fato de que esse recurso de anotações tem suas mãos atadas pela escravidão e disciplina (ou como Martin Fowler gentilmente coloca: “Direcionamento”) natural dessas linguagens.

Muitos programadores C++ (inclusive eu) notaram as habilidades geradoras de templates C++ e utilizaram esse recurso de uma maneira macro.

Muitas outras linguagens incorporaram os macros. Eu, ainda sem saber muito sobre eles, ouso a dizer que os decoradores do Python são parecidos com os macros do Lips em poder e em possibilidades.

O objetivos dos macros

Acredito que seja certo dizer que o objetivo dos marcos em uma linguagem é fornecer uma maneira de modificar os elementos da mesma. É isso que os decorators fazem no Python: eles modificam funções. É por isso que eles normalmente fornecem uma alternativa mais simples para metaclasses.

As maiores falhas da maioria das abordagens de modificações próprias das linguagens são que elas são muito restritivas e que precisam de uma linguagem diferente (posso dizer que as anotações Java compreendem uma “linguagem diferente”, ainda que com todos os problemas pelos quais você deve passar para produzir uma anotação interessante).

O Python cai na categoria de Fowler de “habilitar” linguagens, então se você quiser fazer modificações, por que criar uma linguagem diferente, ou restrita? Por que simplesmente não usar o Python? E é isso que os decorators de Python fazem.

O que você pode fazer com decorators?

Decorators permitem que você insira, ou modifique o código em funções, ou classes. Parece um pouco como Aspect-Oriented Programming (AOP) em Java, não? Exceto que é muito mais simples e poderoso. Por exemplo, suponha que você gostaria de fazer algo nos pontos de entrada e saída de uma função (como executar algum tipo de segurança, rota, bloqueio, etc – todos os argumentos padrões para AOP). Com decorators, fica assim:

@entryExit
def func1():
   print "inside func1()"

@entryExit
def func2():
   print "inside func2()"

O @ indica a aplicação do decorator.

Decorators de funções

O decorator de uma função é aplicado a uma definição de função ao ser colocado na linha antes da que começa a definição da função. Por exemplo:

@myDecorator
def aFunction():
   print "inside aFunction"

Quando o compilador passa por este código, a aFunction() é compilada e o objeto da função resultante é passado para o código myDecorator, que faz algo para produzir um objeto do tipo função, que é, então, substituído pelo original aFunction().

Com o que o código myDecorator se parece? Bom, a maior parte dos exemplos introdutórios o mostra como uma função, mas eu achei mais fácil começar a compreender os decorators usando classes como mecanismos de decoração, ao invés de funções. Além disso, é mais poderoso.

O único lado ruim de um objeto retornado por um decorator é que ele pode ser usado como uma função – o que basicamente significa que ele deve ser chamável. Assim, quaisquer classes que usarmos como descoradores devem implementar __call__.

O que um decorator faz? Bem, ele pode fazer qualquer coisa, mas normalmente você espera que o código da função original seja usado em algum ponto. Isso não é necessário, no entanto:

class myDecorator(object):

   def __init__(self, f):
      print "inside myDecorator.__init__()"
      f() # Prove that function definition has completed

   def __call__(self):
      print "inside myDecorator.__call__()"

@myDecorator
def aFunction():
   print "inside aFunction()"

print "Finished decorating aFunction()"

aFunction()

Quando você rodar esse código, o verá assim:

inside myDecorator.__init__()
inside aFunction()
Finished decorating aFunction()
inside myDecorator.__call__()

Note que o construtor para myDecorator é executado no ponto da decoração da função. Como podemos chamar f() dento de __init__(), isso mostra que a criação de f() está completa antes do decorator ser chamado. Note, também, que o construtor do decorator recebe o objeto da função sendo decorado. Normalmente, você irá capturar o objeto da função no construtor e depois utilizá-lo no método __call__() (o fato de que decoração e chamado são duas fases claras quando se utiliza classes, é o motivo pelo qual eu argumento que esse é o modo mais fácil e mais poderoso).

Quando aFunction() é chamada depois de ter sido decorada, temos um comportamento completamente diferente; o método myDecorator.__call__() é chamado, ao invés do código original. Isso acontece porque o ato da decoração substitui o objeto da função original com o resutlado da decoração – no nosso caso, o objeto myDecorator substitui aFunction. De fato, antes dos decorators serem adicionados, você tinha que fazer algo muito menos elegante para alcançar a mesma coisa:

def foo(): pass
foo = staticmethod(foo)

Com a adição do operador de decoração @, agora você tem o mesmo resultado dizendo:

@staticmethod
def foo(): pass

Esse é o motivo pelo qual as pessoas argumentam contra os decorators, porque o @ é apenas uma sintaxe simplificada, que significa “passar um objeto de função, através de outra função, e atribuir o resultado à função original”.

Acredito que a razão pela qual os decorators sentem tanto o impacto é porque essa maneira mais fácil, também conhecida como “syntactic sugar“, muda o modo como você pensa programação. Certamente, ele traz a ideia de “aplicar código a outro código”(por exemplo, macros) no pensamento dominante ao formalizá-lo como um construtor de linguagem.

Levemente mais útil

Agora, vamos voltar e implementar o primeiro exemplo. Aqui, vamos fazer a coisa mais comum e de fato utilizar o código nas funções decoradoras:

class entryExit(object):

   def __init__(self, f):
      self.f = f

   def __call__(self):
      print "Entering", self.f.__name__
      self.f()
      print "Exited", self.f.__name__

@entryExit
def func1():
   print "inside func1()"

@entryExit
def func2():
   print "inside func2()"

func1()
func2()

A saída é:

Entering func1
inside func1()
Exited func1
Entering func2
inside func2()
Exited func2

Você pode ver que as funções decoradoras agora tem as declarações das linha “Entering” e “Exited” em volta do chamado.

O construtor armazena o argumento, que é o objeto da função. No chamado, usamos o atributo da função __name__ para exibir o nome da função, e então chamá-la.

Usando funções como decorators

A única restrição no resultado de um decorator é que ele é chamável, então ele pode substituir propriamente a função decoradora. Nos exemplos acima, eu substitui a função original com um objeto de classe que tem um método __call__(). Mas um objeto de função também é chamável, então podemos reescrever o exemplo anterior usando uma função, ao invés de uma classe, assim:

def entryExit(f):
   def new_f():
      print "Entering", f.__name__
      f()
      print "Exited", f.__name__
   return new_f

@entryExit
def func1():
   print "inside func1()"

@entryExit
def func2():
   print "inside func2()"

func1()
func2()
print func1.__name__

A new_f() é definida dentro do corpo de entryExit(), então ela é criada e retornada quando a entryExit() é chamada. Note que new_f() é um encerramento, porque ela captura o valor real de f.

Uma vez que a new_f() tenha sido definida, ela é retornada a partir de entryExit(), de modo que o mecanismo do decorator possa determinar o resultado como uma função decoradora.

O output da linha print func1.__name__ é new_f, porque a função new_f foi substituída pela função original durante a decoração. Se isso for um problema, você pode mudar o nome da função antes de retorná-la:

def entryExit(f):
   def new_f():
      print "Entering", f.__name__
      f()
      print "Exited", f.__name__
   new_f.__name__ = f.__name__
   return new_f

A informação que você consegue obter dinamicamente sobre as funções, e as modificações que você consegue fazer nelas são bastante poderosas no Python.

Mais exemplos

Agora que você sabe o básico, você pode dar uma olhada em mais exemplos de decorators aqui. Observe o número de exemplos que usam classes, ao invés de funções como decorators.

Neste artigo eu intencionalmente evitei lidar com os argumentos da função decoradora, mas farei isso em um próximo. Arguardem!

***

Texto original disponível em: http://www.artima.com/weblogs/viewpost.jsp?thread=240808

Fonte: IMasters

PyPy 1.7: o mais rápido interpretador de Python, ainda mais rápido

Foi lançado nesta semana, o PyPy 1.7, nova versão do interpretador da linguagem Python escrito inteiramente em Python. O principal foco desta versão foi o aumento de desempenho de bibliotecas, em relação ao CPython e ao próprio PyPy 1.6.

O PyPy é uma alternativa a outros interpretadores como CPython (o padrão), Jython e IronPython, e de acordo com os diversos benchmarks publicados, o mais rápido entre eles. Segundo os desenvolvedores do projeto, “se alguma implementação for mais lenta que o interpretador CPython, então é um bug”.

A performance excepcional do PyPy se deve principalmente ao seu compilador JIT. O interpretador já é suportado em Linux 32/64, MacOS 32/64, mas o atual release (com JIT) ainda não foi concluído para o Windows.

Algumas funcionalidades estão em fase avançada de desenvolvimento, mas ainda não ficaram prontas para este release:

  • Implementação especializada de listas: Está já em fase de testes a implementação de listas de inteiros/float/string compactadas como um array de arrays, o que deve aumentar a perfomance e reduzir o consumo de memória de algumas aplicações.
  • Duas novas implementações do compilador JIT direcionadas aos processadores PowerPC e ARM

Para conhecer mais sobre o PyPy, fazer o download ou ajudar nos testes da plataforma, visite a página oficial do projeto.

Fonte: Rafael Nunes/InfoQ

Google App Engine 1.6.0: Graduação oficial e mais novidades

Após três anos e meio do lançamento da plataforma, o Google AppEngine deixa de ser um produto ‘preview’ e passa a ser completamente suportado pelo Google. O crescimento da plataforma neste tempo foi excepcional. Estatísticas atuais dão conta de mais de 100 bilhões de requisições por mês, 300 mil aplicações em execução e acima de 100 mil novos desenvolvedores adicionados mensalmente. Ficam claros, portanto, o sucesso e a necessidade de investimentos a longo prazo no GAE.

Com a nova versão 1.6.0, oficialmente será adotado o novo modelo de cobrança, conforme anunciado em maio; também foram publicados os documentos termos de serviço e política de uso, e há uma SLA de 99.95%.

E a nova versão traz um conjunto de novas funcionalidades:

  • Min Idle Instances: Agora você pode ajustar o número mínimo de instâncias da sua aplicação que ficarão em execução(de 1 a 100).
  • Max Pending Latency: Aplicações que necessitam de menor latência no acesso, agora podem configurar por quanto tempo uma requisição irá aguardar para ser atendida antes de iniciar uma nova instância da aplicação.
  • Python 2.7: Agora o SDK suporta também esta versão do Python; assim se pode testar aplicações localmente contra a versão 2.7, antes de publicá-las em produção.
  • Map Reduce (Python): Foi liberada uma versão experimental de um framework de Map Reduce, que inclui as fases Map, Shuffle e Reduce
  • Memcache API (Java): A API de memcache agora suporta chamadas assíncronas também para a plataforma Java.
  • Datastore Callback (Java): Pode-se agora especificar ações a serem executadas antes e depois das operações de put e delete no Datastore.
  • Blobstore API: Não será mais necessário habilitar a cobrança de sua aplicação para utilizar a API do Blobstore

Todas as funcionalidades e correções podem ser acompanhadas para ambas as plataformas nas notas da versão, para Python e Java.

Fonte: Rafael Nunes/InfoQ

Novo suporte a bancos relacionais no Google Apps Engine

Desde o lançamento da plataforma Google App Engine (GAE) em 2008, umas das funcionalidades mais pedidas pelos desenvolvedores foi a possibilidade de criar e fazer deploy de aplicações utilizando bancos de dados relacionais. E conforme antecipado no Google IO deste ano, foi disponibilizada uma versão (ainda limitada) da funcionalidade, chamada de Google Cloud SQL.

O Google Cloud SQL oferece um ambiente MySQL com acesso para as plataformas Java (via JDBC) e Python (via DB-API). O serviço segue princípios fundamentais da plataforma GAE, como:

  • É livre de administração: Como todos os outros serviços do Google App Engine, as operações de administração geral, backup e escalonamento (quando necessário), são feitos automaticamente pela plataforma.
  • Alta disponibilidade e confiabilidade: Os dados armazenados são replicados em múltiplos datacenters; sendo assim, falhas de hardware em um servidor, rack ou mesmo datacenter inteiro, serão gerenciadas pela plataforma, ficando transparentes para as aplicações.

O serviço também inclui ferramenta para importação e exportação de dados, caso você queira migrar um banco já existente para a plataforma.

Por enquanto, a plataforma é gratuita e o Google promete que os preços serão anunciados pelo menos 30 dias antes de oficialmente começar a cobrança. Lembrando que o serviço ainda é um “Labs” (em testes) e será necessário fazer o cadastro para obter acesso.

Para conhecer mais sobre o Google Cloud SQL, veja as principais tarefas que podem ser realizadas com ele e detalhes sobre as funcionalidades em Java e Python.

Fonte: Rafael Nunes/InfoQ

PySide e aplicações web

Recentemente eu me vi obrigado a mudar a linha de desenvolvimento de um projeto meu, e pra isso eu resolvi abandonar muita coisa e me dedicar de fato ao Python. Eu sempre soube que a comunidade do Python era muito grande e bem entusiasmada, mas me surpreendi com o quanto eu consegui progredir em tão pouco tempo, tá dando tempo até de postar no blog e adiantar tempo no cronograma.

Enfim, minha situação é a seguinte: pretendo fazer um sistema web, com a interface inteira em HTML e um back-end qualquer (tá, eu vou escolher o Django, mas você que está lendo é livre para escolher qualquer outro), mas que o usuário final veja esse sistema como um software comum, com atalho na área de trabalho, janelinha dedicada e tudo mais. Até ai eu poderia usar um Adobe AIR da vida, mas o problema é que eu preciso me comunicar com alguns recursos do PC, tipo comandos no terminal, janela de autenticação, ou até mesmo um “visual” mais desktop. Então me surgiram diversas opções pra Mono, Python, e até o C++… Mas quem me agradou de verdade foi o PySide, uma binding oficial do Qt em Python.

O que me convenceu a gostar do PySide foi a facilidade de implementar instâncias derivadas de QObject dentro de um QWebView, essas instâncias ficam acessíveis no objeto window do JavaScript. Suponhamos que eu tenha uma classe mais ou menos assim:

from PySide import QtCore

class MyJSObject(QtCore.QObject):
    @QtCore.Slot()
    def teste(self):
         print "Hello from JavaScript"

Com essa classe criada, eu posso adicioná-la ao frame principal de um determinado QWebView da seguinte maneira:

	meuBrowser = QtWebKit.QWebView()
	meuBrowser.load(QtCore.QUrl('http://localhost/minhapagina.htm'))
	meuBrowser.page().mainFrame().addToJavaScriptWindowObject('myjs', MyJSObject())

Experimente fazer uma chamada no JavaScript ao objeto window[“myjs”].teste(), ou se você preferir injetar um código JavaScript para esse fim, também é possível através do evaluateJavaScript():

	meuBrowser.page().mainFrame().evaluateJavaScript('window["myjs"].teste()')

Agora é só conferir o terminal do Python pra você ver o print do método teste() funcionando. A partir desse conceito você tem uma gama de opções para desenvolver aplicações ricas usando todo potencial do Python e do que há de melhor na web ao mesmo tempo.

Não se esqueça de os métodos declarados dentro da sua classe derivada de QObject precisam do decorator Slot para ficarem visíveis no JavaScript. Para tirar mais dúvidas quanto as slots e aos signals, leia esse trecho da documentação oficial.

Dedico esse artigo ao pessoal do canal #python na rede vIRCio, em especial ao Rafaelzinhu por ter me indicado esse servidor IRC e ao vitorlobo com o blog Pythonando, que serviu de ótima referência pra que eu pudesse destrinchar bastante coisa sobre o PySide.

Fonte: TimoteoRamos

Python no Visual Studio agora é cidadão de primeira classe

A Microsoft lançou uma extensão para desenvolvimento em Python no Visual Studio 2010. A ferramenta Python Tools for Visual Studio, de código aberto (licença Apache 2.0), oferece suporte a CPython, IronPython, Jython e PyPy.

Entre as principais funcionalidades do Python Tools, estão recursos avançados de edição de código, como IntelliSense e a localização de referências (Find all Refs), o comando Go to Definition e um navegador de objetos (Object Browser). Há ainda métodos de refatoração, como “Extract Method” e uma janela nativa para REPL (read-eval-print loop). O suporte para depuração, profiling local e remoto, e clusters HPC e MPI são outros destaques. Para desenvolvimento com HPC, é necessário obter o SDK, também gratuito, separadamente.

Após a instalação do Python Tools, são disponibilizados quatro templates de projetos: o mais flexível é o Python Application, em que há a opção de escolher o interpretador/runtime para execução das aplicações; os outros três, todos para o interpretador IronPython, facilitam a criação de aplicações Winforms, Silverlight e WPF.

No mesmo anúncio, a Microsoft informou o lançamento dos pacotes NumPy e SciPy para IronPython e .NET.

Há um bom screencast mostrando como utilizar o Python Tools. A extensão pode ser obtida no site oficial do projeto, no Codeplex.

Fonte: Elemar Jr./InfoQ

PyPy 1.6 implementa Python 2.7

O PyPy anunciou o lançamento da versão 1.6 do seu interpretador Python integrado com rastreamento Just-in-Time (JIT). De acordo com os desenvolvedores, a versão implementa totalmente o Python 2.7.1, além de trazer maior velocidade e melhorias na estabilidade.

Com o codinome “Kickass Panda”, o PyPy 1.6 está 30% mais rápido que a versão anterior e vem com melhorias de desempenho, que incluem maior rapidez no tempo de aquecimento JIT e melhor funcionalidade do Garbage Collector.

A ferramenta web-based JitViewer está incluída para ver quais partes do código foram compiladas utilizando JIT. O módulo de extensão API para CPython, o intérprete padrão C para Python, agora inclui suporte para outras extensões.

Fonte: Under-Linux

Google App Engine 1.5.3: Foco em persistência e melhorias no cache

Foi lançada ontém mais uma nova versão do SDK do Google AppEngine, a 1.5.3. O rimo de lançamentos vem se acelerando, com a perspectiva de novos release mensais. Desta vez as principais melhorias ficaram por conta do mecanismo de persistência. Veja o que mudou:

  • Foi removido o limite de tamanho dos arquivos binários inseridos no Blobstore. A partir desta versão, aplicações executando no App Engine poderão fazer upload/download de arquivos de qualquer tamanho.
  • Há novo acesso via programação ao índices criados no datastores e, consequentemente, ao status de cada um deles.
  • No SDK Java, agora é possível habilitar a interface de administração do Datastore dentro do console de administração da aplicação. Assim o desenvolvedor poderá utilizar funções como remover entidades de um determinado tipo ou copiar entidades para outra aplicação. (Aplicações em Python já tinham acesso a esta funcionalidade.)

Para a plataforma Python, as principais mudanças foram no Memcache e no gerenciamento de fontes. No Memcache, foi inserido o suporte a operações CAS (compare-and-swap), já disponível no ambiente Java. O CAS é utilizado para atualizar valores no Memcache somente se nenhuma outra requisição tiver atualizado o mesmo valor concorrentemente.

Mais detalhes sobre correções de bugs e outras pequenas mudanças podem ser verificados diretamente nas notas de lançamento de cada plataforma: Python e Java.

Fonte: InfoQ

Oracle lança primeira versão do Java sob seu comando

A Oracle anunciou nesta segunda-feira (15/08) a disponibilidade do Java Platform, Standard Edition 7 (Java SE 7), a primeira versão do programa sob administração da companhia. A plataforma de desenvolvimento aberto foi para a mãos da companhia ema abril de 2009, junto ao pacote da Sun, empresa responsável pela sua criação.

Conforme comunicado encaminhado à imprensa, “a versão é resultado do desenvolvimento que envolveu revisão aberta, compilações semanais e extensa colaboração entre engenheiros da Oracle e membros do ecossistema Java em todo o mundo por meio da comunidade OpenJDK e do Java Community Process (JCP)”.

O material detalha que o Java SE 7, que é compatível com as versões anteriores, possui, conforme a Oracle:

  • Mudanças na linguagem para ajudar a aumentar a produtividade dos desenvolvedores e simplificar as tarefas comuns de programação, reduzindo o volume de código necessário, esclarecendo a sintaxe e facilitando a leitura do código. (JSR 334: Project Coin);
  • Suporte aprimorado para linguagens dinâmicas (como, Ruby, Python e JavaScript), resultando em melhoria substancial no desempenho do JVM. (JSR 292: InvokeDynamic);
  • A nova API multicore-ready oferece aos desenvolvedores maior facilidade para detalhar falhas em tarefas que podem ser executadas em paralelo por números arbitrários de núcleos do processador. (JSR 166: Fork/Join Framework)
  • A interface de I/O (entrada/saída) completa para trabalhar com sistemas de arquivos permite acesso a uma ampla variedade de atributos de arquivos e oferece mais informações quando ocorrem erros. (JSR 203: NIO.2)
  • Novos recursos de rede e segurança.
  • Suporte ampliado para internacionalização inclui suporte ao Unicode 6.0.

Fonte: ItWeb

Google lança a sua própria linguagem de programação GO

O Gigante da pesquisa não para de surpreender na sua caminhada pela conquista do mundo tecnológico.

Desta vez a Google foi mais longe e criou a sua própria linguagem de programação denominada GO, que segundo ela é rápida e dinâmica como o Python, e segura como o C ou o C++.

A linguagem GO nasce como uma necessidade para a Google, esta linguagem havia sido criada pela empresa internamente para solucionar problemas de software e servidores, e passa agora a estar inteiramente disponível para quem quiser iniciar uma nova etapa em termos de programação.

A GO oferece uma simplicidade não só de compilação mas também porque a partir dela é possível tirar o máximo partido em termos de hardware de servidor sem ser necessário recorrer a software terceiro em algumas circunstâncias.

Fonte: Tecnologia.com

Infinispan 5.0 Oferece Mais de 45 Novos Recursos

A edição 5.0 da plataforma computacional de código aberto Infinispan, conhecido como Pagoa, foi liberado hoje (09). Após seis meses de um trabalho de desenvolvimento e oito candidatos de lançamento, a versão mais recente contém mais de 30 correções de bugs e apresenta mais de 45 novas funções, que incluem um novo rehash scheme, suporte para nós virtuais e um modo de recuperação, caso ocorram falhas de transacionais. Além disso, Infinispan 5.0 também suporta agora a Spring, CDI e plataformas OSGi.

Infinispan pode ser utilizado para construir redes de dados sobre as últimas arquiteturas computacionais do mercado. No núcleo da aplicação baseada em Java, está uma interface de cache compatível, que pode ser opcionalmente, suportada por uma arquitetura de rede peer-to-peer.

De acordo com o projeto de roadmap, as futuras versões poderão ser utilizadas em conjunto com C, PHP ou Python através de um módulo de linguagem de servidor independente, ao invés de combiná-las somente com Java. Lembrando que Infinispan é uma solução altamente escalável, o que caracteriza uma plataforma smart grid de alta disponibilidade de dados, de código aberto e escrito em Java. O seu intuito, é apresentar uma estrutura de dados que possua um nível concorrencial significativo.

Fonte: Under-Linux