Archive for the 'desenvolvimento' Category

Meu ambiente de trabalho em 7 itens

29 de dezembro de 2010

Para terminar o ano, fui convidado pelo instrutor Anderson Leite para escrever meu ambiente de trabalho em 7 itens:

Máquina / Sistema Operacional

Desde 2008 passei por dois Airs, um Pro e um iPad. Nesse instante estou com o Air de 11″. Costumo usar o mesmo notebook para programar no trabalho, em casa e no carro. Programação extrema.

Em casa uma TV de 32″ como segundo monitor, no trabalho qualquer coisa disponível.

Uso o OS X em coreano e Parallells para o C# no Windows. Sempre uso o sistema operacional em uma língua estrangeira que não domino.

Editor e IDE

Qualquer um que tenha opção de abrir e salvar arquivo. Quando estou em máquinas que desconheço atalhos faço tudo na unha, sem medo. Editor x IDE, Teclado x Mouse é um meio, não um fim. Se o desafio de um bom programador fosse digitar menos e digitar rápido, contrataríamos somente campeões do Typeracer.

No dia a dia uso Eclipse, Textmate e vi. Já usei emacs, gedit, visual studio. Na máquina dos outros qualquer um que tenha opção de abrir e salvar arquivos. Aprendo os atalhos, mas meu foco está no tempo parado olhando a tela, não na destreza dos quatro alts que o mac oferece.

Terminal e Editor

Bash com alguns .shs extras. Toda vez que troco de máquina ele é limpo e não reaproveito nada do anterior. A idéia é não viciar.

Abro diversas abas e não consigo ficar em um só projeto ao mesmo tempo. Enquanto rodo os testes de um, escrevo a funcionalidade de outro, mesmo que por 30 segundos. Quando possível, revezo entre três.

Browser

Chrome com gleebox, Firefox com gleebox e Safari, todos ao mesmo tempo. Internet Explorer para os sites que não funcionam e sites coreanos em geral.

Software

Vital: file explorer (finder no os x), terminal, um editor qualquer. O resto é opcional.

Opcional: SizeUp, spotlight, dropbox, google apps.

Aberto esporadicamente: skype, adium, tweet decks.

Source-code

Git. Svn em alguns projetos de terceiros. Aliás, svn que não funciona com OS coreano.

Música

Sem. 99% do tempo prestando atenção nas conversas dos outros. Fones de ouvido quando não desejo ouvir barulho.
Como não escuto música, prefiro citar outro item do meu ambiente, o pote de chá que em suas variações chinesas, japonesas e coreanas sempre está do meu lado.

Convido todos os leitores para espiarem e compartilharem o seu ambiente de trabalho.

Efeitos colaterais, programação funcional e ruby

20 de outubro de 2010

Durante a última turma de formação Rails, surgiu uma dúvida relativa a algumas idéias do mundo funcional que Ruby utiliza. É comum o uso do método returning em Rails para dar uma mão e permitir acessar um objeto, além de retorná-lo:

É uma idéia comum no mundo funcional, podendo ser pensada da seguinte maneira: precisamos executar diversos processos com efeito colateral mas estamos interessados em um único retorno.

Uma implementação comum nesse mundo seria:

Implementação de k_comb em uma linguagem funcional qualquer

Ao invocarmos k_comb com uma série de funções, somente a primeira possuirá seu valor retornado: todas as outras são executadas e seu retorno é ignorado. Por isso uma consequência direta é que ao usar tal padrão, estamos fazendo uso de efeitos colaterais.

O Ruby 1.9 já fazia:

Implementação usando o exemplo tap do Ruby 1.9

Com o tappie o ruído da variável extra pode ser removido, indo além da implementação do Ruby e do Rails, de uma maneira bem simples:

Implementação usando Tappie

Usar tais recursos de linguagens funcionais no mundo orientado a objetos de Ruby ajuda a diminuir o ruído semântico da linguagem, mas ao mesmo tempo é possível ir ainda além do que a linguagem Ruby nos fornece. Esse exemplo de implementação de k_combinator é uma possível extensão para o próprio Ruby.

Outras bibliotecas fornecem exemplos de funções como operadores.

Por uma web melhor: evite manter estado

7 de setembro de 2010

Todo dia centenas de aplicações são lançadas ou atualizadas na internet e fazem uso do protocolo http, que influencia diretamente o retorno do nossos produtos. Por exemplo, adotar web services via ftphoje em dia não parece tão viável quanto era anos atrás.

Mas mesmo com um protocolo ubíquo como o http, muitas vezes deixamos de lado conhece-lo a fundo e perdemos um grande número de potenciais clientes.

Um caso comum que pode ser melhorado é a utilização indiscriminada de estado de cliente para responder uma requisição.

Nesse cenário, já na primeira requisição o servidor marca o cliente com um cookie de tempo determinado de expiração, por exemplo 15 minutos, e esse cookie é essencial para todas as requisições futuras. Assim que o cookie expira, o usuário é obrigado a voltar para a pagina inicial.

Por exemplo, no site da Tam, inicie uma busca e aguarde sua sessão expirar. Tente executar um refresh: o site o redireciona para a página inicial de escolha de língua, uma página que você não passou anteriormente.

Tam e a escolhe de país

Site com escolha de país. Opção para lembrar, mas será esquecida junto com o cookie.

Ao escolher um país note que devido a utilizar cookies (ou url-rewriting), o sistema não consegue realmente lembrar após o tempo passar, apesar de marcarmos o checkbox.

Além do usuário se assustar com uma tela que não existia antes, ele não retorna para onde estava, mas sim para a página inicial, perdendo o trabalho executado até então.

Se o usuário encontrou uma viagem interessante e tenta compartilhar o mesmo para Se enviar o link para um colega para que veja o preco da passagem, ele nao sera capaz de acessa-lo. Como o http pode nos ajudar? Trabalhando com a busca como um recurso (de REST), URIs amigáveis, verbo GET e sem manter o estado teríamos uma URI que resolveria quase todos os problemas acima mencionados:

http://site.com.br/viagem/cgu/seo/20110101/201101012

Podemos medir o número de clientes potenciais que podemos perder diariamente por mantermos sessão em momentos desnessários colocando um contador na página de perda de sessão.

Analise em seu site quantas pessoas entram nessa página diariamente e tem seu fluxo de pensamento quebrado devido a essa abordagem.

Na abordagem da URI baseada em recursos existe somente um ponto que não foi abordado: como saber o país do cliente? Existe uma solução padrão do http para isso: utilize o header Accept-language.

Seria possível reescrever as URIs com a língua o que apresenta desvantagem somente para o caso de compartilhar a URI com amigos que não entendem a lingua atual.

Timeout

Quando uma sessão se faz necessária e o tempo é curto, mantenha um contador indicando o mesmo para seu usuário, como no site do Banco do Brasil. Perder o fluxo de trabalho atual é sempre uma experiência negativa portanto dê a chance de seu usuário executar um refresh para continuar trabalhando.

Solução do BB: mostrar o tempo até expiração.

Caso o usuário esteja preenchendo um formulário e não queira executar um refresh, mostre um alert do javascript confirmando se o usuário deseja se manter logado, executando uma requisição ajax para prolongar o tempo, como alguns sistemas de submissão de palestra online costumam fazer.

Recentement Subbu Allamaraju comentou sobre a questão de sessão não fazer parte de HTTP e quão vital isso é para a web escalar.

Entender o cookie e o valor da sessão significa algo além do que está na URI: conhecimento fora do padrão HTTP, chamado out-of-band knowledge. Sites que se baseiam nesse tipo de trabalho, implicam em pior SEO, além de dificuldades de acesso no dia a dia por seus usuários. Por uma web melhor, não dependa de estado do seu cliente.

Aula aberta de REST e acessando CouchDB/NEO4j

17 de maio de 2010

Na semana passada houveram dois eventos que pude participar.

Na aula aberta de REST onde apresentei a parte técnica de implantação de processos e workflows através de REST, após a palestra do Jim Webber sobre motivações financeiras para tal arquitetura.

No sábado foi a vez do evento noSQLbr, organizado pelo Alexandre Porcelli, cheio de exemplos de uso avançados de banco de dados noSQL, onde pude mostrar como o CouchDB e o NEO4Jse beneficiam de características da arquitetura REST e como podem ser estendidos para obter mais vantagens ainda.

Os slides de ambos os eventos já estão no slideshare, rest
e arquitetura contemporanea com nosql via rest.

O feedback foi ótimo e semana que vem nos vemos em Belo Horizonte.

E o Luca Bastos finaliza: “A apresentação do Jim foi uma das melhores ou provavelmente a melhor que já assisti de REST. E a do Guilherm também foi incrível porque chamou a atenção para coisas muito importantes e ainda apresentou exemplos muito legais que ainda estou digerindo. ”

E você já economizou seus milhares de reais desse ano e passou a usar a web como sua plataforma?

Minha arquitetura dói. Devo mudar para REST?

6 de maio de 2010

O que perdemos em não chegar em uma arquitetura REST de verdade, mas nos manter no modelo tradicional que adotamos até então?

Menor acoplamento

Em arquiteturas tradicionais, incluindo as típicas implementações de web services encontradas em clientes, temos um servidor com forte acoplamento a contratos (schemas e infinitos verbos) que inibem a evolucão de seu servidor independente de seu cliente, o que chamamos de forward-compatibility.

A arquitetura que apliquei é REST?

Um sinal que mostra a não adoção de um arquitetura REST é a existência de forte acoplamento entre clientes e servidores. Na arquitetura que está analisando, as mudanças no servidor implicam em alterações em seus clientes? Eles devem baixar código fonte (jar, gems etc)? Recompilar os projetos?

Mais genericamente, se a api disponibiliza um jar, gem ou equivalente que é sua API cliente, seu coupling é maior do que um sistema REST real.

Qualquer mudança em todos os clientes, mesmo os que não utilizam as novas funcionalidades, é um acoplamento indesejado. Imagine se todos os usuários do paypal devessem atualizar seus sistemas a cada novo release de sua API?

Se no cenária atual, os custos de manutenção estão altos pois toda mudança é refletida em manter clientes atualizados, sua aplicação claramente não é REST.

Em REST, forward-compatibility é natural.

Escalabilidade

O conceito de REST tenta pegar o que levou a web a ser esse mundo onde aplicações são criadas, alteradas e os clientes (seres humanos) continuam funcionando. É um ótimo da adaptabilidade de aplicações distribuídas como as conhecemos hoje. Não são web services educados.

Se sua empresa sofre com o alto acoplamento que web services popularizados criaram, com altíssimos custos de manutenção, ou ainda baixa escalabilidade, REST de verdade pode ser a solução.

Pergunta/Resposta

As abordagens de web services, SOA como praticado pelo mercado, EJB, RMI, Corba e RPC possuem características similares de alto acoplamento. Responda o questionário a seguir para analisar a vantagem de se usar REST:

(RPC) Qual a facilidade de colocar coisas novas e alterar servidores
existentes na sua arquitetura atual e não
encostar em nenhum cliente, tudo continuando a funcionar como antes? Seu cliente continua funcionando?

(RPC) Você consegue escalar para níveis como o da web, sem precisar comprar produtos de middleware, usando somente middleware commodity como proxies?

(RPC) Quantas vezes a api que você acessava (i.e. amazon) mudou e deixou seu programar quebrar?
(REST) Quantas vezes a amazon mudou o site e você não conseguiu comprar algo?

(RPC) Quantas vezes o sistema do correios ficou fora do ar e seu sistema não resolveu o problema de tolerância a falha, impedindo fornecer cotações de envio de produtos?
(REST): E se a estimativa continuasse válida, sem ter que alterar uma linha de código?

(RPC): Toda vez que sua API muda, você lança uma versão nova e obriga seus clientes a baixarem.
(REST): Você lança uma versão nova.

(RPC): Ao mudar a estrutura de seus recursos – como relacionamentos – todos os clientes quebram. O cliente, frágil, quebra facilmente.
(REST): O cliente, robusto, se adapta as necessidades e permite alterações no recurso e no meio que ele é representado.

Se você deseja alcançar essa arquitetura, é necessário executar diversos passos e usar REST como um todo, não somente verbos http e URIs.

– Se você deseja clientes acessando seu sistema durante anos, sem ter que atualizar todos os sistemas satélites mensalmente.

– Se você deseja escalar sem session replication.

– Se você deseja trabalhar com blue green deployment

– Se você quer ensinar clientes a funcionar com código que eles jamais viram na vida

Adotando REST

Tenho publicado uma série de artigos e vídeos em como adotar REST na prática, do zero.

Artigos técnicos que mostram os problemas e a maneira de implementar uma aplicação REST.

Antes disso, é vital mudar a maneira de pensar de arquiteturas RPC – como serviços web tradicionais – e para isso, é necessário um trabalho mais arquitetural com seus desenvolvedores.

Ao mesmo tempo, um trabalho gerencial permite encontrar os pontos de suas aplicações que se beneficiriam imediatamente, potencializando o retorno do investimento nessa arquitetura.

Eventos

Nesse ano de 2010 são diversos os eventos onde apresentaremos essas vantagens e como migrar para tal plataforma.

Seja em um evento sobre REST, Agile ou email, sinta-se a vontade para conversar sobre o assunto.

06 de maio – Gerenciamento ágil de projetos de Software com Scrum, USCS
13 de maio – Rest do zero, na Caelum
15 de Maio de 2010 – O papel do REST no CouchDB e Neo4J- NoSQLBR
22 de maio – Deploy contínuo – pois integração contínua não basta – Maré de agilidade/Belo Horizonte
29 de maio – Um produto em duas semanas – Maré de Agilidade/Vitória

Rest do zero – Parte 2

6 de maio de 2010

Esse video de 20 minutos mostra como mover de uma api REST tradicional para uma que utiliza recursos linkados e adiciona valor semântico real a esses links. Mais um passo para alcançar uma arquitetura realmente REST, de maneira simples.

Seu servidor e cliente REST já funcionavam assim? Ótimo.

Caso contrário, já é hora de desacoplar seu cliente de seu servidor, não?

REST a partir do zero

29 de abril de 2010

Esse é o primeiro post em uma série mostrando como usar Rails e Restfulie no servidor e Restfulie e Mikyung no cliente para criar uma arquitetura REST.

Nesse primeiro vídeo de 10 minutos você aprende a implementar em uma linha de código do Restfulie diversas representações (xml, json, atom) no servidor e também com uma linha, a enviar, receber, atualizar etc dados a partir do cliente.

Nos próximos vídeos sairemos do nível 1 do modelo de maturidade de uma arquitetura REST e passaremos para sistemas completamente REST.

Quaisquer dúvidas, junte-se ao nosso mailing list ou fale comigo no twitter.

Aplicando REST a corporações

26 de abril de 2010

Esse post é uma tradução do meu post original em inglês.

REST é o resultado de uma pesquisa que nos deixou com uma pergunta em aberto, como seu pesquisador sugeriu: REST resolve diversos problemas, mas como aplicá-lo a problemas modernos existentes em aplicações corporativas?

Aplicando REST

Após diversas conversas, resumi um modelo, derivado das restrições de REST, que nos permite medir como um sistema completo (cliente e servidor) alcança uma arquitetura REST.

O vídeo a seguir mostra um exemplo de como começar com o que acreditamos ser REST mas na verdade é uma arquitetura não REST típica e, adotando cada restrição, criar um sistema REST que executa processos de compra em quaisquer servidores REST.

O vídeo está em inglês e, em breve, postarei um tutorial do zero de como criar cliente e servidor aqui.

Qual o poder de “REST Applied”?

“REST Applied” como exemplifiquei resolve diversas preocupações modernas, preenchendo o buraco entre a dissertação de Roy e o uso da teoria em nossos problemas, abrindo espaço para um novo mundo de possibilidades.

Da mesma maneira que idéias REST, apesar de não serem chamadas de REST até então, permitiram que o crawling web fosse um cliente fantástico, “REST Applied” pode mudar a maneira como nossas aplicações se comunicam.

E por que não vimos isso antes? Pois a descrição do Roy segue o rumo de exemplos de crawling, que se beneficiam diretamente de content type negotiation. Por exemplo, o google utiliza o mesmo recurso, acessado por uma URI, com diversas línguas, podendo classificá-lo melhor do que se ficassem em URIs diferentes (sem um header adequado).

“In fact, the application details are hidden from the server by the generic connector interface, and thus a user agent could equally be an automated robot performing information retrieval for an indexing service, a personal agent looking for data that matches certain criteria, or a maintenance spider busy patrolling the information for broken references or modified content [39].”

Mas, “Not surprisingly, this exactly matches the user interface of a hypermedia browser. “… o cliente adapte-se para a representação atual, limitado a inteligência do cliente.

REST Applied pega todas essas idéias e resolve nosso problema, como os exemplos de Rest in Practice também seguem.

Frameworks/bibliotecas usadas

Restfulie dá mais suporte HTTP para bibliotecas http e provê um framework REST enquanto Mikyung permite criar seus clientes REST. Com ambos frameworks você está pronto para aplicar REST de verdade em seus problemas corporativos, não só webbies.

Mikyung significa “capital da beleza”, no sentido de “centro principal da beleza”, em coreano e é uma tentativa de reproduzir em seu nome a aparência de um belo cliente REST, comparado com código RPC.

Modelo de maturidade REST

20 de abril de 2010

Ainda não é REST

Como alcançar REST? Quão maduro é a minha aplicação em relação a REST? O modelo de Leonard Richardson foi amplamente discutido e comentado, inclusive no “Rest in Practice” (um livro que recomendo a leitura). Mas o que ficou faltando nesse modelo de maturidade? Por que o nível máximo não implica ainda em REST?

Nesse post, mais teórico, descrevemos um modelo que aborda o que é REST. Em próximos posts teremos vídeos e descrições de como aplicar REST na prática, fugindo do mundo de “serviços REST”.

De acordo com o modelo, nível 3 adiciona suporte a hipermídia, aperfeiçoando um sistema através do uso de linked data – um requerimento fundamental para REST. Mas HATEOAS sozinho não implica em REST, como o próprio Roy já mencionou.

Lembremos como RMI e objetos distribuídos permitiam a navegação dentre objetos e seus estados? O exemplo a seguir ilustra tal situação:


orders = RemoteSystem.locate().orders();
System.out.println(orders.get(0).getProducts().get(0));
receipt = order.payment(payment_information);
System.out.println(receipt.getCode());

Mas e se o código acima for uma sequência de invocações remotas de EJB? Se navegando através de relacionamentos (linked data) é REST, implementar o código acima a través de HTTP também seria (fora a falta de uniform interface).

O modelo se aproxima de REST no lado do servidor, e Rest in Practice chega a REST em ambos os lados, descrevendo a importância da semantica e de media types. O resto desse post descreve o que ficou de fora desse modelo de “serviços REST via web”, que na realidade são “serviços via web”.

O que ficou faltando?

O exemplo anterior não inspecionou a representação atual e relacionamentos antes de decidir qual seria o próximo passo e isso cria um alto acoplamento inexistente em aplicações REST.

O exemplo anterior contem um conjunto fixo de instruções a ser seguido, independentemente de qualquer resposta do servidor. O cliente não se adapta, não responde ao resultado de suas interações, mas assume um processo fixo.

The model application is therefore an engine that moves from one state to the next by examining and choosing from among the alternative state transitions in the current set of representations.“.

Se a API fosse http e o servidor respondesse com “Server too busy”, um cliente REST de verdade tentaria novamente em 10 minutos, o que os clientes tradicionais que escrevemos não fazem.

Mesmo alcançando o máximo de maturidade no modelo de Richardson, a aplicação que envolve cliente e servidor, não se adapta ao estado do recurso, ainda não é REST: seu cliente ainda possui um alto acoplamento.

Por esse motivo não existe tal serviço como REST web service, mas para ter uma aplicação REST, tanto o cliente quanto o servidor devem seguir suas características arquiteturais.

Modelo de Richardson e HTTP

Relações ricas em semânticas podem ser compreendidas por clientes e são fundamentais para a criação de um sistema REST. Um ponto importante é lembrar que o modelo continua sendo muito importante para demonstrar a maturidade de uma arquitetura em cima do uso de HTTP, mas ainda não impede o alto consumo financeiro vindo do uso do “mindset de web services” de maneira mais elegante, mas com o mesmo custo de acoplamento.

Um modelo de maturidade REST

Por todos esses motivos, proponho um modelo de maturidade independente do protocolo, onde podemos medir o uso dos aspectos de REST em um sistema:

Rest Architecture Maturity Model

Rest Architecture Maturity

Para atingir REST, o primeiro passo é a utilização de uma uniform interface: um conjunto padrão de ações que podem ser executadas em todos os recursos existentes. Por exemplo, em HTTP, os verbos definem a interface uniforme, o que pode ser efetuado com cada recurso.

O segundo passo é a adoção de linked data para permitir ao cliente navegar entre estados e recursos de maneira uniforme. Através de HTTP, como o modelo de Richardson descreve, este é o uso de hypermídia como connectedness.

O terceiro passo é adicionar valor semântico aos links. Relações definidas como “related” podem possuir valor semântico em determinados processos, menos valor em outros. “payment” pode fazer senido para outros. A criação e adoção de media types permitem – mas não implicam – em código sendo escrito de maneira menos acoplada.

O quarto passo é criar clientes de maneira que suas decisões sejam baseadas nos relacionamentos e estado de recursos, além do conhecimento do media type. É o media type e seus relacionamentos que criam o acoplamento entre clientes e servidores, qualquer outro acoplamento vem de arquiteturas que não REST.

Todos os passos acima devem ser tomados para minimizar o acoplamento do cliente ao servidor – e vice versa.

O último passo é a evolução do cliente. Code on demand permite educar clientes como se comportar em situações específicas que não foram previstas, como por exemplo ao encontrar um novo media type desconhecido.

Note que para a adoção de REST, o modelo apresentado no gráfico, nenhuma menção foi feita ao protocolo HTTP (somente exemplos), pois REST é agnóstico ao mesmo.

O post a seguir descreve como criar um cliente REST e suas vantagens.

Agilenomundoreal.com.br

13 de abril de 2010

Para quem acompanha o blog, já podemos acessá-lo através do link agilenomundoreal.com.br.