Blog sendo desativado
Para o que vem seguindo o blog e tem notado que não posto por aqui, visite meu blog definitivo: http://paulosuzart.github.com/. Desde o início do ano decidi mudar para o github e postar apenas em inglês.
Este blog ficará no ar pois ainda recebe muitos visitantes. Agradeço aos leitores e os aguardos no novo blog.
Abraços!
Paulo Suzart. @paulosuzart
Twitter Finagle, primeiras impressões
Quanto tempo sem postar sobre Scala! Mas isso não significa que fiquei sem estudar a linguagem e muito do que gira ao seu redor. Neste Post, vou colocar alguma scoisas sobre o Twitter Finagle, auto entitulado como uma biblioteca para construção de servidores e clientes RPC assíncronos em Java, Scala ou qualquer coisa que execute na JVM.
O finagle é uma camada muuuuuito fina em cima do JBoss Netty, que é um framework Java NIO realmente surpreendente e sabidamente veloz. O Netty é a base para o Aleph (clojure), framework que postei outro dia.
Aqui vai um hello world tosco com o Finagle:
class SimpleService extends Service[HttpRequest, HttpResponse] {
def apply(request: HttpRequest): Future[HttpResponse] = {
val response = new DefaultHttpResponse(HTTP_1_1, Ok)
Future.value(response)
}
}
A coisa é simples. Service é uma classe do finagle que extende uma função que recebe um HttpRequest do netty e retorna um Future[HttpResponse]. Future é uma estrutura para programação assíncrona fantástica, mas talvez seja assunto para outro post. No exemplo acima, a única coisa que o servidor faz é responder um 200 para o cliente.
E sim, se eu quiser saber os parâmetros de uma query string ou mesmo de um formulário submetido, teria que fazer tudo isso manualmente. Para isso o finagle traz uma pequena abstração em cima do HttpRequest do Netty, é o Request. Nela é possível encontrar funções mais civilizadas e algumas outras facilidades como gerar o response a partir da requisição, aproveitando então seu encoding, versão http, etc. Uma versão mais interessante usando algumas classes providas no finagle é a seguinte:
class AdvancedService extends Service[Request, Response] {
def apply(request: Request): Future[Response] = {
(Path(request.path)) match {
case Root / "user" / Integer(id) =>
val response = request.response
response.setContentString("The user id is %d\n\n" format id)
Future.value(response)
}
}
}
Aqui aparecem algumas coisas interessantes. A classe Path permite extrair os conhecidos Path Parameters em um pattern match, que no caso pega o caminho imediatamente após /user. Se requisitarmos /user/21, a resposta do servidor apresentará o identificador repreentado no path. O pacote http.path do finagle possui outras facilidades para parâmetros em query string e métodos Http. Acabei usando em um pequeno trabalho pessoal para facilitar as coisas.
Mas espera! Tem muito código aqui. Então por que não reduzir essa coisa toda? Eu queria chegar ao ponto de apenas entregar uma função parcialmente aplicada que fizesse um match na requisição para saber seu HTTP VERB. Se for o que desejo tratar, então faço um pattern mach nos seus parâmetros para seguir com o processamento. Pode ficar assim:
val superAd = ~~ {
case (Get, request) =>
(Path(request.path)) match {
case Root / "user" / Integer(id) =>
val response = request.response
response.setContentString("The user id is %d\n\n" format id)
Future.value(response)
}
}
Wow! Bem melhor.E fiz isso com uma minuscula abstração que é a seguinte:
val methNotAllwd: PartialFunction[(HttpMethod, Request), Future[Response]] = {
case (_, request) =>
val response = request.response
response.status = MethodNotAllowed
Future.value(response)
}
def ~~(body: PartialFunction[(HttpMethod, Request), Future[Response]]) = {
new Service[Request, Response] {
def apply(request: Request): Future[Response] = {
val pf: PartialFunction[(HttpMethod, Request), Future[Response]] = {
body orElse methNotAllwd
}
pf(request.method, request)
}
}
}
Além de poder usar a função ~~ para tratar minhas requisições, caso o método da requisição não tenha um pattern definido, será retornado um 405 para o cliente. Prefiro abstrações pequenas à mega abstrações que custumávamos fazer há uns 8 anos atrás. Tinhamos quase que um framework caseiro em cima de qualquer outro framework que usávamos.
Para executar um servidor http com o superAd atendendo as requisições, use o codec RitchHttp ao invés do Http puro.
Aqui falei muito rapidamente da parte Http para o lado servidor do Finagle, mas existe uma gama de features muito legais. Uma delas é a possibilidade de encadear filtros na requisição, semelhante aos filtros Servlet. No código de exemplo deste post, você pode ver que usei o ExceptionFilter que já vem no finagle. Ele vai tratar qualquer exceção no seu código.
Como estou usando o Finagle?
Bem, construí um proxy SQS para um projeto de um amigo. Ele precisa receber mensagens mas não pode tornar as suas filas públicas. Além disso, é preciso validar a mensagem e autenticar o usuário antes de permitir que a mensagem vá para a fila.
Por que o Finagle?
Eu realmente acredito que precisamos reaproveitar coisas boas. O finagle oferece uma camada fina sobre o netty, e por isto não precisamos de um container WEB ou Servido de aplicação JEE, etc. Todo o seu código vai rodar com o mínimo de camadas e num nível baixo de abstração, o que tende a ser mais performático. Além de tornar o netty com uma cara de Scala.
Outro ponto importante é que a construção de clients é tão simples quanto a criação de services. Além de poder em alguns casos usar outros protocolos (Thrift, TCP puro com codecs) e manter a mesma simplicidade.
O finagle – e quase todos os projetos open source do Twitter – pode fazer sua vida ficar mais fácil. Outro projeto que uso neste mesmo caso é Logging. Simples, direto e com cara de Scala.
O código do post pode ser baixado aqui no meu github.
Flowchart de apoio a escolha de tipos em Clojure
Muitas vezes fiquei em dúvida sobre qual forma de definição de tipos em Clojure utilizar. As opçõe são muitas: deftype, defrecord, reify, proxy, e gen-class e é fundamental um bom entendimento de cada uma delas para fazer a melhor escolha sua implementação.
Foi aí que encontrei este post de Chas Emerick, um dos autores de Clojure Programming: Rough Cuts Version. Este livro promete muito e não vejo a hora de tê-lo em mãos.
No post, Chas fala a respeito da tarefa de escolher o tipo certo e mostra um fluxo que ajuda e muito, não só entender os tipos, mas como fazer a melhor escolha. Depois de OGINO Masanori oferecer uma versão em Japonês, me ofereci para fazer uma tradução para português, e Chas aceitou. Assim você pode usar como Wall paper ou fazer impressão bem grande para deixar na parede mais próxima. Clique na imagem para ampliar.
Usando as próprias palavras do autor, a Zona de Interoperabilidade (ou “The ‘Interop Zone'”) do chart, agrega os seguintes casos:
“The ‘Interop Zone’” demarcates use cases (e.g. needing to define multiple constructors) and forms (
proxyandgen-class) that are exclusively the domain of Clojure’s JVM interoperability support. Using these forms is fine, but be aware that by doing so, you are stepping outside of Clojure’s “native” abstractions; unless you are defining a type for the express purpose of meeting interoperability requirements, one of Clojure’s simpler type-definition forms may suit your needs better. (Chas Emerick)
Eu já precisei usar um misto de Protocols, types e Proxy como você pode ver aqui. Era justamente um caso de interoperabilidade com classe puramente Java, e obtive um ótimo resultado.
Espero que o flowchart seja útil para você também.
Update 2011-11-17 07:46 pm UTC: Chas teve uma grande ideia! Ele criou um repositório no Github onde é possível contribuir com traduções para este chart, que é dos mais úteis que já vi. Ele me acionou pelo twitter e tive o prazer em fazer a versão em Português para colocar no repo. O chart original estará publicado em seu livro Clojure Programming – que sai no final deste ano.
Stream Server com Clojure e Aleph
Hoje vou ser objetivo e já começo com o código:
(ns NewStream.core
(:use [aleph.http])
(:require [lamina.core :as l]
[beanstalk.core :as b]))
(def beans (b/new-beanstalk "192.168.0.105" 11300))
(defn init
[ch]
(l/receive-all ch (fn[_]))
(future
(loop [job (b/reserve beans)]
(l/enqueue ch (:payload job))
(b/delete beans (:id job))
(recur (b/reserve beans)))))
(defn handler
[ch requet]
(let [stream (l/named-channel :news-stream init)]
(l/enqueue ch
{:status 200
:headers {"content-type" "text/html"}
:body (l/fork stream)})))
(defn -main[& args]
(start-http-server handler {:port 8089}))
E mais objetivo ainda eu digo: O Aleph é simplesmente sensacional! É um framework de comunicação assíncrona feito com o excelente JBoss Netty e um framework muito completo para programações baseada em eventos do mesmo autor do Aleph, o Lamina.
O Lamina usa canais como cidadãos de primeiro nível e compartilha o mesmo princípio de canais em Go. Mas é muuuuuuito mais poderoso.
O código acima nasceu de um desafio lançado para @abraaoisvi, @lucastex, @rafaelfelini e eu (@paulosuzart). O desafio era fazer um servidor de stream de notícias de um dado evento sem usar websocket e algumas outras restrições que não vem ao caso.
Na minha solução, tenho um servidor beanstalkd rodando num linux. Este servidor recebe mensagens de uma aplicação usada por um editor de notícias fictícia (na verdade um código tosco em python meu mesmo). E cada cliente que conecta no Aleph, vai passar então a receber as notícias uma vez emitidas pelo editor.
O código acima tem handler como a função que recebe as requisições de um browser, por exemplo. Veja que nela, stream é um canal que recebe todas as mensagens vindas do beanstalkd. O detalhe é:news-stream que é o nome dado ao canal de mensagens. Isto é, existirá apenas um canal com este nome no servidor.
init é a função que inicializa o canal stream (recebido como parâmetro ch). Como a função reserve da lib beanstalk é blocking, executo ela em outra thread usando future, e a cada nova mensagem recebida, faço o enqueue no canal stream.
O http handler responde imediatamente para o Browser com status 200 OK, mas o body é um channel que sofreu um fork do canal stream. O fork permite que cada cliente receba uma cópia das mensagens de stream a partir do momento em que fez o fork. O Lamina se encarrega de repassar todas as mensages de stream para os canais gerados a partir do fork.
Com um body sendo um channel, o Aleph vai responder a requisição usando uma resposta Chunked.
Ao acessar http://localhost:8089, o Browser vai manter a conexão aberta. Cada nova mensagem emitida será então enviada imediatamente para cada browser pendurado no server. Simples assim 🙂
Aleph + Lamina, ta aí uma boa combinação para tirar o máximo do seus processadores! Até a próxima.
Update: Algumas pessoas me perguntaram como rodar este pequeno programa. Você pode usar o Leiningen com o seguinte project.clj:
(defproject NewStream "1.0.0-SNAPSHOT"
:description "Simple news stream server"
:dependencies [[org.clojure/clojure "1.2.1"]
[lamina "0.4.0-beta2-SNAPSHOT"]
[aleph "0.2.0-beta2-SNAPSHOT"]
[org.clojars.bengl3rt/beanstalk "1.0.2"]]
:main NewStream.core)
Depois é só executar lein deps e então lein run. Ah, não esquece de ter um Servidor beanstalkd rodando.
Golang – Templates e formatters
Adivinhou! Irei escrever: “Quanto tempo sem postar no blog!” É isso mesmo. Quanto tempo!
Se você tem acompanhado meus tweets, deve ter notado que estou focado em Go. Bom, na verdade não estou twittando ou postando no blog sobre Go como fiz com Scala e Clojure por alguns motivos. Mas é proposital.
Não aguentei me segurar e segue uma dica sobre templates em Go. Existem outras soluções, até mesmo mais simples, para o problema. Mas resolvi fazer dessa forma para não interferir nos dados da aplicação por questão de apresentação e visualização de dados.
var CustomFormatter = template.FormatterMap{
"f2mi": func(w io.Writer, format string, value ...interface{}) {
fmt.Fprint(w, strconv.Ftoa64(value[0].(float64)/1000000, 'f', -1))
},
"i2mi": func(w io.Writer, format string, value ...interface{}) {
fmt.Fprintf(w, strconv.Ftoa64(float64(value[0].(int64))/1000000, 'f', -1))
},
}
var OutPutTemplate = `
=========================================================================
Test Summary (gb. Version: 0.0.2 alpha)
-------------------------------------------------------------------------
Total Go Benchmark Time | {Elapsed|i2mi} milisecs
Requests Performed | {TotalSuc}
Requests Lost | {TotalErr}
Average Response Time | {Avg|f2mi} milisecs
Max Response Time | {Max|i2mi} milisecs
Min Response Time | {Min|i2mi} milisecs
`
//The resunting summary of a master
type Summary struct {
Start, End int64
TotalSuc, TotalErr int
Min, Max int64
Avg float64
Elapsed int64
}
func (self *Summary) String() string {
t := template.MustParse(OutPutTemplate, CustomFormatter)
sw := new(StringWritter)
t.Execute(sw, self)
return sw.s
}
Wow! O que está acontecendo aqui? Bem, começando pela variável OutPutTemplate, temos o template usado no GoBenchmark como saída no final do teste.
Note que entre as chaves ({}) estão exatamente os campos da struct Summary, definida mais abaixo. a função (self *Summary) String() em Go, é o correspondente do método .toString() em Java. Ok? Acontece que os campos com in64 estão guardando valores em nanosegundos. Mas para o usuário final desejo mostrar em milisegundos.
E por que não dividir cada campo por 10 elevada à 6 potência? Realmente daria, mas precisaria cuidar disso no meu código da aplicação, e não quero isso.
Uma solução é combinar ao template alguns formatadores de valor. Por isso a média (campo Avg) é representada no template por {Avg|f2mi}, isto é, {Campo|formatador}. Note que em String(), ao efetuar o parse do template eu uso o CustomFormatter para indicar quais os formatadores usados.
É possível usar reflection para, em um mesmo formatador, decidir se o argumento value é um int64 ou float64. Mas, prefiro deixar reflection pra situações realmente relevantes.
É isso! Os formatadores são boas opções e permite soluções criativas.
Se você não me segue no twitter, aproveite: @paulosuzart. Até a próxima!
Clojure + Coherence = Cloherence
Que combinação! Datagrid Coherence e Clojure! O último post deu uma prévia da abstração simples em cima do Coherence que venho escrevendo. Na verdade não há nada demais nela, a não ser permitir o acesso aos caches e ao processamento de entradas no datagrid de forma mais natural em Clojure. O Cloherence permite duas semânticas, uma que é uma pequena DSL para operações de put, get, remove put de sequencias e processamento no cluster. Vamos a elas:
(def a1 {:name "Nacho" :breed "Bulldog"})
(def a2 {:name "Sushi" :breed "Shire"})
(with-cache "dogs"
(put-val 1 a1)
(println (get-val 1)))
;; put a1 into a named cache "dogs" and print the value get from 1
(with-cache "dogs"
(put-seq :name (list a1 a2)))
;; put a1 and a2 using :name as key
A função put-seq é interessante pra casos onde alguma função retorna uma lista, e esta pode ser “cacheada” de uma vez. Acontece é que NamedCaches no Coherence são herdeiros de java.util.Map. E isso me deu a ideia de usar a mesma semântica de maps em clojure para tratar os caches Coherence. E ficamos assim:
(cache-map cats)
(assoc cats 1 {:name "chico" :breed :unknown})
(get cats 1) ;; {:name "chico" :breed :unknown}
(inplace-update cats 1
(fn [e]
{:name (.toUpperCase (:name e)) :breed "none"}))
;;put {:name "CHICO" :breed "none"} in the cache with key 1
inplace-update não existe em clojure. A lib oferece uma função update para se assemelhar à função update-in, com a diferença que não permite chaves encadeadas.
A função inplace-update emite um Entry Processor para o grid, e no nó do DataGrid que reside a entrada, a função f é invocada com a entrada passada como argumento. A vantagem é não trazer para a JVM que emite o processador, a entrada encontrada. Escalando isso, livramos a JVM da aplicação de receber possíveis milhares de entradas do cache para efetuar a alteração nas entradas.
Vamos examinar o par EntryProcessor mais a função inplace-update:
;;PProcess é do pacote .core
(deftype CljProcessor
[f args] java.io.Serializable PProcessor
(process [this entry]
(apply f (.getValue entry) args)))
(defn inplace-update
[cache e-key f & args]
(with-cache cache
(process e-key (cloherence.maps.CljProcessor. f args))))
Aqui conto com a função process, com a própria DSL da lib with-cache e com o protocol PProcessor. f de inplace-update é executada assim que a entrada é encontrada, recebendo o valor como primeiro argumento e &args como restante dos argumentos.
Bom, além de divertido, a lib cloherence se propõe a dar uma melhor aderência dos caches Coherence com Clojure. Como próximos passos (não sei se vou fazer, mas pretendo), pretendo implementar inplace-update para várias chaves, iplementar locks e utilizar primitivas de concorrência clojure para algumas operações no cache.
É isso, boa diversão!
P.S. Gostaria de um feedback pra saber que nível seria mais adequado abordar Clojure aqui no blog. As vezes sinto que estou escrevendo coisas sem ter feito uma base como fiz com os posts sobre Scala. Quem quiser pode dar um feed. 😉
OO Funcional: Clojure, Coherence e JavaScript
Nossa! Estou escrevendo cada vez menos. Isso me deixa um pouco triste. Mas é consequencia de algumas mudanças, até agora positivas.
Durante o carnaval decidi implementar uma ideia que havia comentado com @danielamadei. É uma idea simples: Criar uma fina camada REST em cima do Coherence, expandindo assim sua aplicabilidade para além do Java, .Net e C. Bom, o objetivo mesmo é estudar e aplicar o que tenho aprendido em algum caso que eventualmente pode se tornar útil. A mistura de Coherence com Clojure e Javascript motivou a elaboração do post e o título dele.
O resultado foi: Clojure, Ring, Rhino e Moustache. As libs contrib usadas foram: Duck-streams, json e string.
Mas, antes tentei fazer uma coisa mais louca com Aleph e Lamina. Aleph é um framework de comunicação assíncrono escrito sobre lamina e JBoss Netty criado pelo mesmo autor do Lamina. É interessante, mas o Aleph acabou se mostrando com um nível de maturidade insuficiente para o que queria fazer, embora fosse simples.
Na lib que dei o nome de CoheREST, fiz a parte de inserção e busca pela chave. A parte mais interessante foi usar o Rhino pra executar funções Javascript submetidas via http para o servidor Ring. Bom, a abstração para acesso ao Coherence ficou assim:
(with-cache "My-Cache"
(put-val 1 {"name" "Paulo" "age" 20}))
É isso mesmo, basta esse código para iniciar, criar e inserir um Map com a chave 1 no cache de nome “My-Cache”. Analogamente, pare obter o valor, basta usar uma função chamada get-val. Mas isso foi só pra ilustrar como ficou a simples abstração.
Ok! O Coherence tem uma feature muito interessante. Ao invés de pesquisar no cache uma certa quantidade de entradas, efetuar algum tipo de operação e depois submeter as mudanças ao cache, ele permite que o processamento seja emitido por todo o cache (EntryProcessor). Isto faz com que o processamento ocorra localmente – no nó do grid em que a entrada reside – sem onerar o nó emissor do processamento. Isto é obtido emitindo para o cache uma implementação de AbstractProcessor.
Para emitir um Entry Processor, é possível fazer como se faz para por ou resgatar uma entrada no cache:
(with-cache "My-Cache"
(process 1 (coherest.processor.JSProcessor. some-js)))
Só uma observação, nesta versão implementei a emissão de um EntryProcessor para uma única entrada, aqui com a chave 1. E agora começa a parte interessante. coherest.processor.JSProcessor é executado por um EntryProcessor (apresentado mais abaixo), e é ele quem executa javascript no cluster, desde que o javascript tenha o seguinte formato:
function(e) {//e é a entrada no cache
e.age = e.age + 1;
return e;
}
Isto é, caso a entrada seja encontrada, ela será passada no formato JSON para a função que pode alterar a entrada e retornar o resultado do processamento. Aqui o exemplo é um simples incremento da propriedade age da entrada. A função é a string some-js passada na construção do JSProcessor. E é aqui que o OO funcional começa.
JSProcessor é um type que implementa um Protocol (leia-se interface em clojure) que define apenas uma função: process. O Protocol e o type ficam assim:
(defprotocol PProcessor
(process [this entry]))
(deftype JSProcessor
[^String script] java.io.Serializable PProcessor
(process [this entry]
;; Implementation went here))
Simples, o Coherence vai invocar apenas o método process(entry) na Implementação de AbstractProcessor. Como o processor é espalhado pelo cluster, ele também precisa implementar Serializable. Mas no início do post falei que um EntryProcessor deve implementar AbstractProcessor, mas esta classe não apareceu em lugar nenhum aqui até agora. Acontece que por questões de design, meu Protocol PProcessor é na verdade invocado por uma implementação anonima de AbstractProcess. Esta implementação anonima é que contem a implementação do método process, que por sua vez se encarrega em a função process do JSProcessor, passando como argumento a entrada encontrada no cache. Veja como ficou:
(defn make-processor "Create a valid Coherence EntryProcessor from the PProcessor passed as agurment" [processor] (proxy [AbstractProcessor] [] (process [entry] (process processor entry))))
Ufa! make-processor é uma função que recebe a instância de JSProcessor, cria um proxy de AbstractProcessor, onde sua implementação é justamente a invocação da função process nele passando a entrada encontrada. A implementação de AbstractProcessor não passa de uma porta de entrada para a invocação das funções definidas pelo PProcessor. E usar um Protocol para o carro chefe na execução de funções no cluster permite que criemos instâncias deste protocol que façam o que desejarmos. O JSProcessor no caso, usa o Rhino pra executar funões no grid.
O CoheREST foi feito sem nenhuma intenção comercial, tão pouco para uso em ambiente corporativo. Isto por que ainda preciso verificar algumas questões de licença. Aí posso liberar o fonte no meu github. O post já foi bastante longo e não pude entrar em detalhes sobre o CoheREST ou sobre o Ring e o Rhino sendo usado direto em Clojure. Mas fica uma deixa pra próximos posts.
Bom, e aqui tivemos herança, programação com interfaces, etc, tudo em clojure, uma linguagem não orientada a objetos, mas que não nos limita em nada a usar conceitos OO. Obrigado e lembre-se: @paulosuzart.
clojure + xml com saxon e xstandard
Outro dia no trabalho estava definindo alguns padrões de como um XSD deveria ser escrito. Coisas simples como formato de nomes de elements, complexTypes, se o XSD deveria ter targetNamespace e attributeFormDefault.
Foi aí que surgiu a ideia de fazer um script em clojure que validasse isso em um dado XML e indicasse o que está fora destes padrões. Claro, algo assim existe por aí. Mas não dá pra perder a oportunidade. Juntei algumas funções auxiliares em cima do Saxon, um wrapper clojure do Saxon XSLT and XQuery Processor. A ideia foi pegar a base do Saxon e usar de tal forma que eu pudesse aplicar algumas asserções a um documento XML.
Queria trabalhar com a idea de assertions. Elas, além do nome, seriam compostas por uma expressão xPath, uma mensagem de falha, uma segunda expressão xPath para localizar que atributo do nó sendo avaliado seria considerado como display-name e uma função de validação que receberá o nó sendo avaliado e simplesmente retornaria true ou false. O resultado foi uma pequena lib commitada no meu github: xstandard.
Por questão de praticidade, escolhi uma estrutura de map par armazenar as informações de uma assertion. Ah, e pra tornar ainda mais prático, criei uma macro que ajuda a definir uma assertion assim:
(defassertion element-name "//xsd:element[@name]" :msg "element %s does not match [a-z].*." :validator (attr-matches "name" #"[a-z].*") :display-name "data(./@name)")
Esta assertion fará análise – através do validator – de todo elemento do meu XSD cujo atributo name esteja presente. Ok, mas decidi agrupar as assertions, eu poderia eventualmente tratar grupos diferentes de formas diferentes ou usar a saída delas de forma diferente. Por isso existe uma outra macro que me permite fazer assim:
(defassertions *default-assertions*
(defassertion element-name "//xsd:element[@name]"
:msg "element %s does not match [a-z].*."
:validator (attr-matches "name" #"[a-z].*")
:display-name "data(./@name)")
(defassertion type-name "//xsd:complexType[@name]"
:msg "type %s does not match [A-Z].*Type."
:validator (attr-matches "name" #"[A-Z].*Type")
:display-name "data(./@name)")
(defassertion element-form-default "/xsd:schema"
:msg "schema hasn't attr elementFormDefault=\"qualified\""
:validator (attr-eq "elementFormDefault" "qualified"))
(defassertion target-ns "/xsd:schema"
:msg "schema hasn't targetNamespace attr"
:validator (attr-present "targetNamespace")))
Legal, agora temos um grupo de assertions. Mas como executá-las? Simples, basta passar o conjunto de assertions aqui chamado *default-assertions* para a função run provida pela lib. O que fica mais ou menos assim:
(xs/run *default-assertions* xs/*nss* xmldoc) ;; *nss* is provided by the lib with a default namespace prefixe for xml schema.
Por padrão a lib vai retornar o resultado do processamento em um map contendo o nome de cada assertion, o caminho para o nó analisado no xml, a linha no arquivo:
{:assertion :element-name, :status false, :display-name Item,
:details {:result-msg element Item does not match [a-z].*.,
:line 25,
:path /xs:schema/xs:element[1]/xs:complexType[1]/xs:sequence[1]/xs:element[3]}}
Note no código onde declarei todas as asserções, a função attr-matches sendo usada na assertion type-name. Ela recebe como parâmetro o nome do atributo do nó analisado e uma regex para verificar o formato do atributo. Note também que a função é executada no momento da montagem da assertion, pois ela retorna uma segunda função, que esta sim, receberá o nó analisado e fará a checkagem do formato. O código de attr-matches é:
(defn attr-matches
"Validates the format of a given node `n` against `regex`."
[attr regex]
(fn [n]
(not (nil? (re-matches regex (get-attr n attr))))))
Lindo, não? Bom, para se divertir mais no código basta acessar meu github.
Pra fechar, durante a criação desse projetinho tive a oportunidade de usar a IntelliJ IDEA. Surpreendente! Muito boa e estável, sem falar do plugin clojure e leiningen muito bons. Ah, pra somar ao aprendizado, utilizei o Marginalia pra gerar a documentação do xcode, veja aqui. Basta salvar o html e ver a doc do projeto de uma forma bem interessante. O Marginalia é um projeto do @fogus.
Não esqueça de me seguir no twitter: @paulosuzart.
5 coisas para tornar o seu cérebro funcional
Desde janeiro de 2009, no meu primeiro post sobre Scala, venho na verdade falando de um paradigma desafortunadamente não ensinado na maioria das universidades brasileiras: Programação Funcional. Se alguém tem/teve aulas de programação funcional na universidade por favor deixe o nome da instituição nos comments.
O que percebi nestes dois anos de posts sobre programação funcional e duas (Scala e Clojure) das linguages que suportam este paradigma, é que muitos leitores sentem uma dificuldade em se livrar das suas raizes imperativas, e a syntax destas linguagems acabam ficando até como uma dificuldade em segundo plano.
Por isso resolvi escrever este post compacto que serve mais como direcionamento para tornar o seu cérebro funcional. Aqui vão 5 coisas que vão ajudar o programador a atingir seu momento de iluminação funcional:
1. Lambda Calculus
Estude essa coisa. Lambda Calculos, em muito alto nível, é a raiz da programação funcional. Neste cálculo, tudo é uma função, inclusive os números naturais, as operações algébricas, etc. Este sistema formal, possui uma série de colorários e propriedades que vão embasar as linguagens de programação funcional. E não, eu não sou especialista em Lambda Calculus e estou longe de ter fôlego intelectual pra isso. Mas ver a introdução é um bom começo pra se sentir confortável.
2. Diga ‘o quê’, não ‘como’
Isto está bastante ligado a funções de alto nível (High-order functions). São aquelas funções que recebem funções como argumento e até mesmo retornam alguma função. Fortes exemplos de funções de alto nível são funções de mapeamento em listas. Ou seja, você tira da sua responsabilidade a iteração de uma sequencia e informa para a função de mapeamento, qual função você quer aplicar nos elementos da sequencia. Exemplo:
(def numbers (range 5)) (map #(* % %) numbers);; obtem o quadrado de cada ítem da lista de 0 a 4.
Aqui podemos ver a funções de alto nível map em ação, esta é provavelmente a função mais utilizada e mais exemplificada na internet. Mas é realmente prática e fácil de entender a coisa. Simplesmente pedimos que seja aplicada a função anônima que multiplica cada ítem por ele mesmo. Esta: #(* % %). Não vemos um for, iterações ou coisas do gênero.
3. Entenda funções parcialmente aplicadas
Elas são úteis. Você pode computar somente entradas pra uma função, mas ao invés de aguarda que você obtenha todas as entradas para ela, você pode começar a aplicar (invocá-la) com os parâmetros que você possue em mãos e passá-la a diante. Veja um exemplo: Usando o mesmo numbers acima, vamos computar a multipliação de cada ítem de 0 a 4 por algum número que ainda não conhecemos.
(def partials (map #(partial * %) numbers))) (map #(% 2) partials);; = (0 2 4 6 8 )
partial também é uma função que recebe uma função (a função de multiplicação *) e um parâmetro para ser aplicado a esta função, no caso cada ítem da sequencia. partials é a minha lista de funções parcialmente aplicadas. Algo como: ((* 0 ?) (* 1 ?) (* 2 ?) (* 3 ?) (* 4 ?)). Wow! Interessante. A segunda funão no código acima aplica a função gerada na lista de partials ao 2. 2 é o número que gostariamos de multiplicar cada elemento de 0 a 4 inicialmente, lembra? Acredite, isso é útil demais e existem muitos frameworks usando fortemente funções parcialmente aplicadas.
4. Imutabilidade é natural
Este é o tópico que talvez tenha gerado o maior hype nesta história de programação funcional. O resultado foi um monte de final nas variáveis em java, na esperança de isso ser suficiente para programar funcional ou garantir alguma imutabilidade. Na verdade de nada adianta colocar final na variável da classe, digamos, Pessoa e todos os seus atributos não serem final. E aí vem: Mas clonar a cada set vai custar memória? Vai. Clojure resolve essa questões com estruturas de dados persistêntes. Aqui você encontra uma boa explicação sobre estas estruturas. Vamos a um exemplo: Pegue a lista numbers e faça um prepend do valor 5 nesta lista:
(cons 5 numbers);; o REPL mostrará (5 0 1 2 3 4) numbers;; e o REPL mostrará novamente (0 1 2 3 4)
Isso deixa claro como numbers não vai mudar. A menos que você use algum artifício da sua linguagem (clojure: atoms, refs, vars, agents e pods brevemente) para acesso aos valores de uma identidade ao longo do tempo. Ainda assim, o que vai mudar é o para onde no tempo a sua identidade aponta, mas os valores nunca irão mudar. Assim como seu passado não mudará. Profundo. Mas não fica proibido o uso de alguma variável completamente mutável.
5. Recursividade não deve ser estranho
Funções recursivas por incrível que parece ainda causam confusão na cabeça da grandíssima maioria dos programadores. Este post de Michael Kohl (@citizen428) fala especificamente de Y Combinator que é implementado com um conjunto de funções recursivas, lambdas e high-order functions ao mesmo tempo. Entender este post é obrigatório se você quer seu cérebro afiado.
Além disso…
Na verdade existem conceitos mais profundos no universo funcional. Coisas que sinceramente são capazes de torcer o cérebro de qualquer um. Existem também outras linguagens que não estas que mais estudo como Erlang, Haskell (talvez a mais impressionante em termos conceituais e expressividade funcional), Scheme, Lisp, Racket (sensacional), e outras.
Programação funcional não é sobre moda, ou sobre “passar um método como argumento”, ou “sobre escrever um programa inteiro em uma linha só”. FP (Functional Programming) é sobre elaborar soluções focadas no problema, e de forma elegante e muito concisa. Ainda que não use no seu dia-a-dia, é de grande utilidade para suas próximas construções mesmo numa linguagem imperativa. 🙂
É isso e não esqueça de me seguir no twitter: @paulosuzart.
Ah, este post deveria ter 10 itens. Estou buscando os demais itens no exterior. Espero conseguí-los. Este post teve apoio de @jneira.
Basic Authentication no GAE com Tornado
Olá! Pra quem já usou o Tornado, vai perceber que o framework permite autenticação via cookie criptografado. O exemplo original da documentação usa uma autenticação por formulário, o que é ótimo para visitantes que desejem utilizar as funcionalidades da nossa aplicação via página web, mas o que fazer para proteger uma API rest construída no GAE com o Tornado?
Uma possibilidade simples é o uso da autenticação no nível do transporte, o HTTP Basic Authentication, que não é lá estas coisas, mas tem seu lugar. Outro ponto importante é que na minha API, eu gostaria de usar um esquema de Decorator em Python (explicar o funcionamento dos decorators está fora do escopo deste post, mas o link anterior oferece bastante info) para facilitar a minha vida. Isto é, eu gostaria de usar algo semelhante a interceptors ou filters em Java. O uso deveria ficar mais ou menos assim:
MyRequestHandler(tornado.web.RequestHandler):
@authenticated(authenticator)
def post(self, username):
#alguma protegida aqui
def authenticator(user,pass):
#Nossa logica de auth aqui, seja acessar o DataStore
#ou qualquer coisa para verificar a autenticidade da informação
@authenticated é uma função de decoração que receberá nosso autenticador como parâmetro, que por sua vez será utilizado dentro do código que irá iterceptar a invocação da função post em MyRequestHandler.
Agora a parte mais interessante, o nosso Decorator propriamente dito. Este cara precisa fazer o seguinte: verificar se o usuário tem um cookie criptografado, se não tiver, verificar os cabeçalhos http referentes a Basic Authentication, que por sua vez fornecerão usuário e senha para passarmos para a função authenticator. Naturalmente, se existe um cookie criptografado e válido, pulamos a validação do cabeçalho HTTP e permitimos a invocação do da função post do MyRequestHandler. Abaixo o código inteiro do Decorator e depois os comentários:
def authenticated(auth):
"""Decorate a function to request user authentication before processing.
Just uses Basic HTTP Authentication.
"""
def decore(f):
def _request_auth(handler):
"""Responds 401 to the client, that may prompts the user for auth data."""
handler.set_header('WWW-Authenticate', 'Basic realm=tmr')
handler.set_status(401)
handler.finish()
return False
@functools.wraps(f)
def new_f(*args):
"""The actual wrapper of the function. Check if auth data is present, if so, invokes
the auth (authenticated argument) for credential check, if ok, the wrapper function is invoked
with an aditional argument, the username."""
handler = args[0]
auth_header = handler.request.headers.get('Authorization')
if (not handler.get_secure_cookie("user") and (auth_header is None or not auth_header.startswith('Basic '))):
return _request_auth(handler)
elif handler.get_secure_cookie("user"):
logging.info("####Login by cookie")
user = handler.get_secure_cookie("user")
else:
logging.info("###First login by http")
auth_decoded = base64.decodestring(auth_header[6:])
user, password = auth_decoded.split(':', 2)
if not auth(user, password):
_request_auth(handler)
handler.set_secure_cookie("user", user)
f(username=user, *args)
return
return new_f
return decore
O código poderia ter sido escrito de alguma outra fora, sei lá, organizar e encadear os ifs de outra maneira, enfim. Acho que aqui fica suficiente pra representar o que falei logo acima, que é a lógica de execução da coisa.
Veja que authenticated na verdade é uma função definida como outra qualquer. Ela recebe uma função que recebe dois argumentos (usuário e senha), que por sua vez retornará True ou False, indicando sucesso na autenticação. authenticated de fato retorna outra função, a função decore. decore é uma função qure retorna uma função decorada (a new_f) com @functools.wraps, que nada mais é permitir que new_f fique com a mesma “cara” que a nossa função post do MyRequestHandler. Estranho? Veja detalhes aqui.
Pois bem, nossa decore recebe f como parâmetro, que na verdade é a função post do Request Handler e retorna new_f, que por sua vez recebe os mesmos parâmetros que post na forma de *args. *args é o jeito python de uma função receber um número de argumentos variável, dado que quando decoramos uma função, não sabemos exatamente quantos parâmetros aquela função receberá. Mais detalhes sobre *args e **kwargs aqui.
Quem mantém a lógica de verificação da presença das credenciais (seja por cookie, seja por http) é new_f, que delega para _request_auth os casos onde a credencial não está presente e para auth os casos onde existem as credenciais http. _request_auth só envia um status code 401 para o client, para que este envie as informações do usuário e senha.
A execução de post fica no final de new_f onde ela invoca f (username=user, *args). Aqui podemos ver uma pseudo injeção de dependência, dado que username poderia ser um objeto do tipo user retornado da base ou qualquer outra coisa. Por que injeção? Por que o Tornado não conhece este parâmetro, quer ficaria nulo caso a função post não tivesse sido anotada com @authenticated.
O código aqui está em funcionamento em uma aplicação que estou fazendo. Mas não postei aqui a aplicação completa. Ao usar este decorator, meu log mostra (considerando usuário jordan e uma senha qualquer):
INFO 2010-11-06 13:30:27,448 utils.py:37] ###First login by http INFO 2010-11-06 13:30:27,448 api.py:34] ########jordan###### INFO 2010-11-06 13:30:27,461 dev_appserver.py:3283] "GET /api/track/twitter/mentions HTTP/1.1" 200 - INFO 2010-11-06 13:30:31,903 utils.py:34] ####Login by cookie INFO 2010-11-06 13:30:31,904 api.py:34] ########jordan######
Meu autenticador passado para @authenticated, por enquanto é um lambda que retorna True para qualquer usuário e senha.
@authenticated(lambda x,y: True) def post(self, username): #...
Acho que é só. A intenção aqui é de orientação e mostrar alguns dos desafios que podemos enfrentar usando o Google App Engine (GAE) e o Tornado.
Não mostro aqui os detalhes gerais de se usar o Tornado no GAE, mas é possível encontrar muito material bom na internet. Espero que tenham gostado e não esqueçam, follow me on twitter: @paulosuzart
Post UPDATE: por algum motivo sobrenatural eu escrevi *Basich* e não Basic. Por isto a URL contem um erro que ficará para a posteridade. Mereço um #Fail!
Codemountain, Paulo Suzart's Blog 